7:29 a.m.
Hi!
I was in Gnus, stepped out of a group and re-entered it, and have
been rewarded with the following core. No Lisp-Backtrace ...
#0 0x185563d0 in kill () from /usr/lib/libc.so.3
#1 0x80c58b3 in fatal_error_signal (sig=6) at emacs.c:535
#2 0xbfbfdfdc in ?? ()
#3 0x80c89fa in assert_failed (file=0x829f47f "alloc.c", line=2245,
expr=0x829fd60 "! MARKED_RECORD_HEADER_P (lheader)") at emacs.c:3214
#4 0x808e173 in allocate_managed_lcrecord (lcrecord_list={gu = {
type = Lisp_Type_Record, val = 35405760}, s = {bits = 0,
val = 70811520}, u = {bits = 0, val = 70811520}, ui = 141623040,
i = 141623040, v = 0x870ff00, cv = 0x870ff00}) at alloc.c:2245
#5 0x81a5a5f in Lstream_new (imp=0x83243c0, mode=0x82ee36a "r")
at lstream.c:245
#6 0x81a76b5 in make_fixed_buffer_input_stream (buf=0xbfbfa2a8, size=63)
at lstream.c:1267
#7 0x8098256 in dfc_convert_to_external_format (source_type=DFC_TYPE_DATA,
source=0xbfbfa2a0, coding_system={gu = {type = Lisp_Type_Record,
val = 35003808}, s = {bits = 0, val = 70007616}, u = {bits = 0,
val = 70007616}, ui = 140015232, i = 140015232, v = 0x8587680,
cv = 0x8587680}, sink_type=DFC_TYPE_DATA, sink=0xbfbfa298)
at buffer.c:1890
#8 0x81b0754 in std_handle_out_va (stream=0x832e118,
fmt=0x82b3b00 "Fatal error: assertion failed, file %s, line %d, %s\n",
args=0xbfbfc2d4 "'O+\b]\a") at print.c:186
#9 0x81b0852 in stderr_out (
fmt=0x82b3b00 "Fatal error: assertion failed, file %s, line %d, %s\n")
at print.c:208
#10 0x80c89f2 in assert_failed (file=0x82b4f27 "eval.c", line=1885,
expr=0x82b4a88 "abort()") at emacs.c:3208
#11 0x80cb485 in signal_1 (sig={gu = {type = Lisp_Type_Record,
val = 34449089}, s = {bits = 0, val = 68898178}, u = {bits = 0,
val = 68898178}, ui = 137796356, i = 137796356, v = 0x8369b04,
cv = 0x8369b04}, data={gu = {type = Lisp_Type_Record, val = 38119923},
s = {bits = 0, val = 76239846}, u = {bits = 0, val = 76239846},
ui = 152479692, i = 152479692, v = 0x916a7cc, cv = 0x916a7cc})
at eval.c:1885
#12 0x80d509e in Fsignal (error_symbol={gu = {type = Lisp_Type_Record,
val = 34449089}, s = {bits = 0, val = 68898178}, u = {bits = 0,
val = 68898178}, ui = 137796356, i = 137796356, v = 0x8369b04,
cv = 0x8369b04}, data={gu = {type = Lisp_Type_Record, val = 38119923},
s = {bits = 0, val = 76239846}, u = {bits = 0, val = 76239846},
ui = 152479692, i = 152479692, v = 0x916a7cc, cv = 0x916a7cc})
at eval.c:2052
#13 0x8195d48 in barf_if_buffer_read_only (buf=0x8daca00, from=1, to=1)
at insdel.c:3061
#14 0x8191e05 in prepare_to_modify_buffer (buf=0x8daca00, start=1, end=1,
lockit=1) at insdel.c:2317
#15 0x8192197 in buffer_insert_string_1 (buf=0x8daca00, pos=1,
nonreloc=0x9139400 "e: /usr/users/support/nk/mail/bsd-cvs/10041\n17841: 3517: Jan
26 04:08:26 2001: 6: File: /usr/users/support/nk/mail/bsd-cvs/10122\n17841: 3518: Jan 26
04:08:26 2001: 6: File: /usr/users/support/nk/mail/"..., reloc={
gu = {type = Lisp_Type_Record, val = 34448897}, s = {bits = 0,
val = 68897794}, u = {bits = 0, val = 68897794}, ui = 137795588,
i = 137795588, v = 0x8369804, cv = 0x8369804}, offset=0, length=512,
flags=0) at insdel.c:2455
#16 0x8195a2d in buffer_insert_raw_string_1 (buf=0x8daca00, pos=1,
nonreloc=0x9139400 "e: /usr/users/support/nk/mail/bsd-cvs/10041\n17841: 3517: Jan
26 04:08:26 2001: 6: File: /usr/users/support/nk/mail/bsd-cvs/10122\n17841: 3518: Jan 26
04:08:26 2001: 6: File: /usr/users/support/nk/mail/"...,
length=512, flags=0) at insdel.c:2585
norbert.
--
After THIS, let's go to PHILADELPHIA and have TRIPLETS!!
7:54 a.m.
>>>> "N" == Norbert Koch <nk(a)LF.net>
writes:
N> Hi!
N> I was in Gnus, stepped out of a group and re-entered it, and have
N> been rewarded with the following core. No Lisp-Backtrace ...
N> #0 0x185563d0 in kill () from /usr/lib/libc.so.3
N> #1 0x80c58b3 in fatal_error_signal (sig=6) at emacs.c:535
N> #2 0xbfbfdfdc in ?? ()
N> #3 0x80c89fa in assert_failed (file=0x829f47f "alloc.c", line=2245,
N> expr=0x829fd60 "! MARKED_RECORD_HEADER_P (lheader)") at emacs.c:3214
N> #4 0x808e173 in allocate_managed_lcrecord (lcrecord_list={gu = {
N> type = Lisp_Type_Record, val = 35405760}, s = {bits = 0,
N> val = 70811520}, u = {bits = 0, val = 70811520}, ui = 141623040,
N> i = 141623040, v = 0x870ff00, cv = 0x870ff00}) at alloc.c:2245
You're using pdump?
Could you see whether my recent changes make a difference (assuming
you can reproduce this)?
Index: src/lstream.c
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/src/lstream.c,v
retrieving revision 1.12.2.16
diff -u -w -r1.12.2.16 lstream.c
--- src/lstream.c 2000/10/12 04:58:59 1.12.2.16
+++ src/lstream.c 2001/01/24 06:23:50
＠＠ -179,11 +179,17 ＠＠
}
}
+inline static size_t
+aligned_sizeof_lstream (size_t lstream_type_specific_size)
+{
+ return ALIGN_SIZE (offsetof (Lstream, data) + lstream_type_specific_size,
+ ALIGNOF (max_align_t));
+}
+
static size_t
sizeof_lstream (const void *header)
{
- const Lstream *lstr = (const Lstream *) header;
- return sizeof (*lstr) + lstr->imp->size - 1;
+ return aligned_sizeof_lstream (((const Lstream *) header)->imp->size);
}
DEFINE_LRECORD_SEQUENCE_IMPLEMENTATION ("stream", lstream,
＠＠ -231,15 +237,15 ＠＠
assert (lstream_type_count < countof (lstream_types));
lstream_types[lstream_type_count] = imp;
Vlstream_free_list[lstream_type_count] =
- make_lcrecord_list (sizeof (*p) + imp->size - 1,
+ make_lcrecord_list (aligned_sizeof_lstream (imp->size),
&lrecord_lstream);
lstream_type_count++;
}
p = XLSTREAM (allocate_managed_lcrecord (Vlstream_free_list[i]));
/* Zero it out, except the header. */
- memset ((char *) p + sizeof (p->header), 0,
- sizeof (*p) - sizeof (p->header) + imp->size - 1);
+ memset ((char *) p + sizeof (p->header), '\0',
+ aligned_sizeof_lstream (imp->size) - sizeof (p->header));
p->imp = imp;
Lstream_set_buffering (p, LSTREAM_BLOCK_BUFFERED, 0);
p->flags = LSTREAM_FL_IS_OPEN;
Index: src/lstream.h
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/src/lstream.h,v
retrieving revision 1.5.2.8
diff -u -w -r1.5.2.8 lstream.h
--- src/lstream.h 2000/10/12 04:59:04 1.5.2.8
+++ src/lstream.h 2001/01/23 04:16:15
＠＠ -167,8 +167,8 ＠＠
size_t unget_buffer_ind; /* pointer to next buffer spot to write a character */
size_t byte_count;
- long flags; /* Align pointer for 64 bit machines (kny) */
- char data[1];
+ int flags;
+ max_align_t data[1];
};
#define LSTREAM_TYPE_P(lstr, type) \
8:41 a.m.
Martin Buchholz <martin(a)xemacs.org> writes:
Hi Martin!
You're using pdump?
No. I've just succeeded in building my first pdump xemacs.
Could you see whether my recent changes make a difference (assuming
you can reproduce this)?
Assumption failure: I can't reproduce it :-(
[patch snipped]
should I apply this patch on top of the current CVS?
norbert.
8:55 a.m.
>>>> "N" == Norbert Koch <nk(a)LF.net>
writes:
N> Martin Buchholz <martin(a)xemacs.org> writes:
N> Hi Martin!
> You're using pdump?
N> No. I've just succeeded in building my first pdump xemacs.
Well, in that case, my big patch can't fix the crash, since it only
changes pdump.
> Could you see whether my recent changes make a difference
(assuming
> you can reproduce this)?
N> Assumption failure: I can't reproduce it :-(
:-(
N> [patch snipped]
N> should I apply this patch on top of the current CVS?
Oops, confusion.
The patch actually contained in my recent email to you was a patch
that was already IN your xemacs sources. The idea was that you could
_undo_ these changes.
The patch I alluded to in my second message (and only changes pdump)
is a patch I just posted to xemacs-patches, but is not yet in CVS.
Why not try `make check'?
8:27 a.m.
>>>> "N" == Norbert Koch <nk(a)LF.net>
writes:
N> expr=0x829fd60 "! MARKED_RECORD_HEADER_P (lheader)") at emacs.c:3214
N> #4 0x808e173 in allocate_managed_lcrecord (lcrecord_list={gu = {
N> type = Lisp_Type_Record, val = 35405760}, s = {bits = 0,
N> val = 70811520}, u = {bits = 0, val = 70811520}, ui = 141623040,
N> i = 141623040, v = 0x870ff00, cv = 0x870ff00}) at alloc.c:2245
N> #5 0x81a5a5f in Lstream_new (imp=0x83243c0, mode=0x82ee36a "r")
N> at lstream.c:245
If you are using pdump, my recent patch "Dumper fixes patch, version
3" might fix this problem.
One way to run xemacs without the dumper is
make run-temacs
to check whether it is indeed dumping that is the problem.
8701
days inactive
8701
days old
4 comments
2 participants
participants (2)
-
Martin Buchholz -
Norbert Koch