* emacs from head segfaults when run with -nw
@ 2010-04-02 19:02 Alfred M. Szmidt
2010-04-02 20:49 ` Dan Nicolaescu
` (2 more replies)
0 siblings, 3 replies; 57+ messages in thread
From: Alfred M. Szmidt @ 2010-04-02 19:02 UTC (permalink / raw)
To: emacs-devel
When I start emacs with -nw, it segfaults, if I run with -Q it
segfaults in a different place,
0x0816911d in mark_object (arg=-7552029) at alloc.c:5595
5595 if (XMISCANY (obj)->gcmarkbit)
But without -nw it works expecdetly in X11.
This is with -nw, and no -Q:
Program received signal SIGSEGV, Segmentation fault.
mark_object (arg=-106975578) at alloc.c:5674
5674 if (CONS_MARKED_P (ptr))
(gdb) bt full
#0 mark_object (arg=-106975578) at alloc.c:5674
ptr = 0xf99faea0
obj = 138959074
cdr_count = <value optimized out>
#1 0x0816965f in mark_vectorlike (ptr=0x859cfc0) at alloc.c:5368
size = 138986034
i = <value optimized out>
#2 0x081695dd in mark_char_table (ptr=0x8579398) at alloc.c:5396
val = <value optimized out>
size = 130
i = <value optimized out>
#3 0x0816961c in mark_char_table (ptr=0x8491338) at alloc.c:5393
val = <value optimized out>
size = 34
i = <value optimized out>
#4 0x0816961c in mark_char_table (ptr=0x8540870) at alloc.c:5393
val = <value optimized out>
size = 18
i = <value optimized out>
#5 0x0816961c in mark_char_table (ptr=0x8487d78) at alloc.c:5393
val = <value optimized out>
size = 70
i = <value optimized out>
#6 0x0816933d in mark_buffer (arg=140899293) at alloc.c:5745
buffer = 0x865f3d8
ptr = <value optimized out>
tmp = <value optimized out>
base_buffer = <value optimized out>
#7 mark_object (arg=140899293) at alloc.c:5500
obj = <value optimized out>
cdr_count = <value optimized out>
#8 0x08169168 in mark_object (arg=140823250) at alloc.c:5572
ptr = 0x848f7f8
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#9 0x0816905d in mark_object (arg=141498278) at alloc.c:5685
ptr = 0x86f17a0
obj = <value optimized out>
cdr_count = <value optimized out>
#10 0x0816905d in mark_object (arg=139501238) at alloc.c:5685
ptr = 0x86f1798
obj = <value optimized out>
cdr_count = <value optimized out>
#11 0x0816917e in mark_object (arg=139454838) at alloc.c:5574
ptr = 0x848c350
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#12 0x0816905d in mark_object (arg=139447942) at alloc.c:5685
ptr = 0x84fe978
obj = <value optimized out>
cdr_count = <value optimized out>
#13 0x08169173 in mark_object (arg=139774418) at alloc.c:5573
ptr = 0x854c9d0
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#14 0x081695dd in mark_char_table (ptr=0x84b7b30) at alloc.c:5396
val = <value optimized out>
size = 130
i = <value optimized out>
#15 0x0816961c in mark_char_table (ptr=0x848c838) at alloc.c:5393
val = <value optimized out>
size = 68
i = <value optimized out>
#16 0x0816905d in mark_object (arg=138952014) at alloc.c:5685
ptr = 0x8483d40
obj = <value optimized out>
cdr_count = <value optimized out>
#17 0x08169168 in mark_object (arg=139067586) at alloc.c:5572
ptr = 0x848c798
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#18 0x0816905d in mark_object (arg=139465814) at alloc.c:5685
ptr = 0x85016d0
obj = <value optimized out>
cdr_count = <value optimized out>
#19 0x0816917e in mark_object (arg=140830210) at alloc.c:5574
ptr = 0x854cd80
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#20 0x0816905d in mark_object (arg=141411878) at alloc.c:5685
ptr = 0x86dc620
obj = <value optimized out>
cdr_count = <value optimized out>
#21 0x0816905d in mark_object (arg=139719318) at alloc.c:5685
ptr = 0x86dc628
obj = <value optimized out>
cdr_count = <value optimized out>
#22 0x08169168 in mark_object (arg=141449870) at alloc.c:5572
ptr = 0x8582878
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#23 0x08169168 in mark_object (arg=140093638) at alloc.c:5572
ptr = 0x858d4e0
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#24 0x0816905d in mark_object (arg=139205374) at alloc.c:5685
ptr = 0x859a8b8
obj = <value optimized out>
cdr_count = <value optimized out>
#25 0x0816917e in mark_object (arg=138988898) at alloc.c:5574
ptr = 0x848cd60
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#26 0x0816905d in mark_object (arg=139285902) at alloc.c:5685
ptr = 0x84d5588
obj = <value optimized out>
cdr_count = <value optimized out>
#27 0x0816905d in mark_object (arg=139285950) at alloc.c:5685
ptr = 0x84d5580
obj = <value optimized out>
cdr_count = <value optimized out>
#28 0x0816905d in mark_object (arg=139285206) at alloc.c:5685
ptr = 0x84d55a0
obj = <value optimized out>
cdr_count = <value optimized out>
#29 0x081cc38f in traverse_intervals_noorder (tree=0x84cb6c0, function=0x8169670 <mark_interval>, arg=138959050) at intervals.c:217
No locals.
#30 0x08168fd9 in mark_interval_tree (arg=139285198) at alloc.c:1514
No locals.
#31 mark_object (arg=139285198) at alloc.c:5467
ptr = 0x84f7ec8
obj = <value optimized out>
cdr_count = <value optimized out>
#32 0x0816936b in mark_object (arg=139139467) at alloc.c:5611
ptr = 0x84b1988
obj = <value optimized out>
cdr_count = <value optimized out>
#33 0x08169168 in mark_object (arg=139724114) at alloc.c:5572
ptr = 0x8540550
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#34 0x0816905d in mark_object (arg=139191566) at alloc.c:5685
ptr = 0x84d7290
obj = <value optimized out>
cdr_count = <value optimized out>
#35 0x0816933d in mark_buffer (arg=141207229) at alloc.c:5745
buffer = 0x86aa6b8
ptr = <value optimized out>
tmp = <value optimized out>
base_buffer = <value optimized out>
#36 mark_object (arg=141207229) at alloc.c:5500
obj = <value optimized out>
cdr_count = <value optimized out>
#37 0x08169376 in mark_object (arg=140867587) at alloc.c:5612
ptr = 0x8657800
obj = <value optimized out>
cdr_count = <value optimized out>
#38 0x08169168 in mark_object (arg=141596798) at alloc.c:5572
ptr = 0x853fcd8
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#39 0x0816933d in mark_buffer (arg=139062709) at alloc.c:5745
buffer = 0x849edb0
ptr = <value optimized out>
tmp = <value optimized out>
base_buffer = <value optimized out>
#40 mark_object (arg=139062709) at alloc.c:5500
obj = <value optimized out>
cdr_count = <value optimized out>
#41 0x0816965f in mark_vectorlike (ptr=0x849ec58) at alloc.c:5368
size = 51
i = <value optimized out>
#42 0x0816944a in mark_object (arg=139062365) at alloc.c:5534
ptr = 0x849ec58
w = 0x849ec58
obj = <value optimized out>
cdr_count = <value optimized out>
#43 0x0816965f in mark_vectorlike (ptr=0x849eb00) at alloc.c:5368
size = 51
i = <value optimized out>
#44 0x0816944a in mark_object (arg=139062021) at alloc.c:5534
ptr = 0x849eb00
w = 0x849eb00
obj = <value optimized out>
cdr_count = <value optimized out>
#45 0x0816965f in mark_vectorlike (ptr=0x849e960) at alloc.c:5368
size = 21
i = <value optimized out>
#46 0x0816948b in mark_object (arg=139061605) at alloc.c:5527
ptr = 0x849e960
obj = <value optimized out>
cdr_count = <value optimized out>
#47 0x08169381 in mark_object (arg=141634979) at alloc.c:5613
ptr = 0x8712da0
obj = <value optimized out>
cdr_count = <value optimized out>
#48 0x08169168 in mark_object (arg=139078178) at alloc.c:5572
ptr = 0x84a2a20
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#49 0x0816905d in mark_object (arg=141596894) at alloc.c:5685
ptr = 0x87098d8
obj = <value optimized out>
cdr_count = <value optimized out>
#50 0x0816905d in mark_object (arg=141596934) at alloc.c:5685
ptr = 0x87098e0
obj = <value optimized out>
cdr_count = <value optimized out>
#51 0x0816933d in mark_buffer (arg=139167501) at alloc.c:5745
buffer = 0x84b8708
ptr = <value optimized out>
tmp = <value optimized out>
base_buffer = <value optimized out>
#52 mark_object (arg=139167501) at alloc.c:5500
obj = <value optimized out>
cdr_count = <value optimized out>
#53 0x08169376 in mark_object (arg=140867563) at alloc.c:5612
ptr = 0x86577e8
obj = <value optimized out>
cdr_count = <value optimized out>
#54 0x08169168 in mark_object (arg=140550650) at alloc.c:5572
ptr = 0x860a1f8
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#55 0x0816905d in mark_object (arg=141596726) at alloc.c:5685
ptr = 0x8709830
obj = <value optimized out>
cdr_count = <value optimized out>
#56 0x0816905d in mark_object (arg=141596734) at alloc.c:5685
ptr = 0x8709838
obj = <value optimized out>
cdr_count = <value optimized out>
#57 0x0816933d in mark_buffer (arg=138984917) at alloc.c:5745
buffer = 0x848bdd0
ptr = <value optimized out>
tmp = <value optimized out>
base_buffer = <value optimized out>
#58 mark_object (arg=138984917) at alloc.c:5500
obj = <value optimized out>
cdr_count = <value optimized out>
#59 0x08169376 in mark_object (arg=140867635) at alloc.c:5612
ptr = 0x8657830
obj = <value optimized out>
cdr_count = <value optimized out>
#60 0x08169168 in mark_object (arg=139127922) at alloc.c:5572
ptr = 0x84aec70
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#61 0x0816905d in mark_object (arg=139508086) at alloc.c:5685
ptr = 0x8577340
obj = <value optimized out>
cdr_count = <value optimized out>
#62 0x0816917e in mark_object (arg=141514094) at alloc.c:5574
ptr = 0x84d93b0
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#63 0x0816905d in mark_object (arg=141514102) at alloc.c:5685
ptr = 0x86f5570
obj = <value optimized out>
cdr_count = <value optimized out>
#64 0x0816905d in mark_object (arg=139288718) at alloc.c:5685
ptr = 0x84d6080
obj = <value optimized out>
cdr_count = <value optimized out>
#65 0x0816917e in mark_object (arg=140520298) at alloc.c:5574
ptr = 0x84dc188
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#66 0x0816905d in mark_object (arg=140143886) at alloc.c:5685
ptr = 0x85a6d08
obj = <value optimized out>
cdr_count = <value optimized out>
#67 0x0816917e in mark_object (arg=139358130) at alloc.c:5574
ptr = 0x84e6fb0
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#68 0x081695dd in mark_char_table (ptr=0x84b77c8) at alloc.c:5396
val = <value optimized out>
size = 130
i = <value optimized out>
#69 0x0816961c in mark_char_table (ptr=0x848c978) at alloc.c:5393
val = <value optimized out>
size = 68
i = <value optimized out>
#70 0x0816905d in mark_object (arg=138952030) at alloc.c:5685
ptr = 0x8483d50
obj = <value optimized out>
cdr_count = <value optimized out>
#71 0x08169173 in mark_object (arg=139059474) at alloc.c:5573
ptr = 0x848c7c8
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#72 0x0816905d in mark_object (arg=141672078) at alloc.c:5685
ptr = 0x871be30
obj = <value optimized out>
cdr_count = <value optimized out>
#73 0x0816905d in mark_object (arg=141672166) at alloc.c:5685
ptr = 0x871bf68
obj = <value optimized out>
cdr_count = <value optimized out>
#74 0x081690f4 in mark_object (arg=140466485) at alloc.c:5519
size = 6
i = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#75 0x08169173 in mark_object (arg=140105078) at alloc.c:5573
ptr = 0x858f400
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#76 0x0816905d in mark_object (arg=138941566) at alloc.c:5685
ptr = 0x859d568
obj = <value optimized out>
cdr_count = <value optimized out>
#77 0x0816917e in mark_object (arg=138988874) at alloc.c:5574
ptr = 0x848cd48
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#78 0x0816905d in mark_object (arg=140029662) at alloc.c:5685
ptr = 0x858aed8
obj = <value optimized out>
cdr_count = <value optimized out>
#79 0x0816905d in mark_object (arg=140031430) at alloc.c:5685
ptr = 0x858b598
obj = <value optimized out>
cdr_count = <value optimized out>
#80 0x0816917e in mark_object (arg=140606410) at alloc.c:5574
ptr = 0x860a3f0
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#81 0x0816905d in mark_object (arg=141517230) at alloc.c:5685
ptr = 0x86f61a8
obj = <value optimized out>
cdr_count = <value optimized out>
#82 0x08169168 in mark_object (arg=139404906) at alloc.c:5572
ptr = 0x84d2e38
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#83 0x0816905d in mark_object (arg=139465638) at alloc.c:5685
ptr = 0x8501290
obj = <value optimized out>
cdr_count = <value optimized out>
#84 0x0816917e in mark_object (arg=140215074) at alloc.c:5574
ptr = 0x85b8320
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#85 0x0816905d in mark_object (arg=139464182) at alloc.c:5685
ptr = 0x8500df0
obj = <value optimized out>
cdr_count = <value optimized out>
#86 0x0816905d in mark_object (arg=139475510) at alloc.c:5685
ptr = 0x8500dd8
obj = <value optimized out>
cdr_count = <value optimized out>
#87 0x0816917e in mark_object (arg=140214954) at alloc.c:5574
ptr = 0x85b82a8
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#88 0x0816905d in mark_object (arg=139474302) at alloc.c:5685
ptr = 0x85036d0
obj = <value optimized out>
cdr_count = <value optimized out>
#89 0x0816917e in mark_object (arg=140214978) at alloc.c:5574
ptr = 0x85b82c0
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#90 0x0816965f in mark_vectorlike (ptr=0x8485ce0) at alloc.c:5368
size = 1511
i = <value optimized out>
#91 0x0816c9c4 in Fgarbage_collect () at alloc.c:5083
bind = <value optimized out>
catch = <value optimized out>
handler = <value optimized out>
stack_top_variable = 0 '\000'
i = <value optimized out>
message_p = 1
total = {139303842, 138959050, 141669550, -1073750712, 135732313, 141670198, 141670246, -1073750740}
count = 259915227
t1 = {
tv_sec = 1270232637,
tv_usec = 195920
}
t2 = {
tv_sec = -1073750744,
tv_usec = -1
}
#92 0x08182a31 in Feval (form=141670182) at eval.c:2238
fun = <value optimized out>
val = <value optimized out>
original_fun = <value optimized out>
original_args = <value optimized out>
funcar = <value optimized out>
backtrace = {
next = 0xbfffe04c,
function = 0x0,
args = 0xbfffdd84,
nargs = 2,
evalargs = 1 '\001',
debug_on_exit = 0 '\000'
}
#93 0x081a4b09 in readevalloop (readcharfun=139059402, stream=0x85696c0, sourcename=141705673, evalfun=0x81829a0 <Feval>, printflag=0, unibyte=138959050, readfun=
138959050, start=138959050, end=138959050) at lread.c:1789
count1 = 60
c = <value optimized out>
val = <value optimized out>
count = 259915227
b = 0x0
continue_reading_p = <value optimized out>
whole_buffer = 0
first_sexp = <value optimized out>
#94 0x081a5994 in Fload (file=141703609, noerror=138959050, nomessage=138959098, nosuffix=138959050, must_suffix=<value optimized out>) at lread.c:1266
stream = 0x85696c0
fd = 9
count = 6686019
found = <value optimized out>
efound = <value optimized out>
hist_file_name = 141704209
newer = 0
compiled = 1
handler = <value optimized out>
safe_p = 1
fmode = 0x81fb8c3 "r"
tmp = {0, -1073750152}
version = 23
#95 0x0818b985 in Frequire (feature=140711594, filename=138959050, noerror=138959050) at fns.c:2962
count = 181085
nesting = <value optimized out>
tem = <value optimized out>
from_file = <value optimized out>
#96 0x0818148d in Ffuncall (nargs=2, args=0xbfffe090) at eval.c:3030
fun = <value optimized out>
original_fun = <value optimized out>
funcar = <value optimized out>
lisp_numargs = <value optimized out>
val = <value optimized out>
backtrace = {
next = 0xbfffe174,
function = 0xbfffe090,
args = 0xbfffe094,
nargs = 1,
evalargs = 0 '\000',
debug_on_exit = 0 '\000'
}
internal_args = 0xbfffe000
i = <value optimized out>
#97 0x081b9d01 in Fbyte_code (bytestr=<value optimized out>, vector=139224461, maxdepth=8) at bytecode.c:680
count = 47
op = <value optimized out>
vectorp = 0x84c6590
stack = {
pc = 0x8722277 "\207",
top = 0xbfffe094,
bottom = 0xbfffe090,
byte_string = 141703561,
byte_string_start = 0x8722270 "\300\301!\210\300\302!\207",
constants = 139224461,
next = 0xbfffe5f4
}
top = 0xbfffe090
result = <value optimized out>
#98 0x08182e7a in Feval (form=141676238) at eval.c:2352
numargs = <value optimized out>
args_left = <value optimized out>
i = 3
maxargs = 3
argvals = {141703561, 139224461, 8, -1, 139059402, 1, 139059402, 139064610}
fun = <value optimized out>
val = <value optimized out>
original_fun = 139079298
original_args = 141676246
funcar = <value optimized out>
backtrace = {
next = 0xbfffe404,
function = 0xbfffe18c,
args = 0xbfffe154,
nargs = 3,
evalargs = 1 '\001',
debug_on_exit = 0 '\000'
}
#99 0x081a4b09 in readevalloop (readcharfun=139059402, stream=0x864f390, sourcename=141703449, evalfun=0x81829a0 <Feval>, printflag=0, unibyte=138959050, readfun=
138959050, start=138959050, end=138959050) at lread.c:1789
count1 = 47
c = <value optimized out>
val = <value optimized out>
count = 259915227
b = 0x0
continue_reading_p = <value optimized out>
whole_buffer = 0
first_sexp = <value optimized out>
#100 0x081a5994 in Fload (file=136339193, noerror=138959050, nomessage=138959098, nosuffix=138959050, must_suffix=<value optimized out>) at lread.c:1266
stream = 0x864f390
fd = 8
count = 6686018
found = <value optimized out>
efound = <value optimized out>
hist_file_name = 141693561
newer = 0
compiled = 1
handler = <value optimized out>
safe_p = 1
fmode = 0x81fb8c3 "r"
tmp = {141665945, 8}
version = 23
#101 0x0818b985 in Frequire (feature=139067042, filename=138959050, noerror=138959050) at fns.c:2962
count = 181072
nesting = <value optimized out>
tem = <value optimized out>
from_file = <value optimized out>
#102 0x08182e7a in Feval (form=141680022) at eval.c:2352
numargs = <value optimized out>
args_left = <value optimized out>
i = 3
maxargs = 3
argvals = {139067042, 138959050, 138959050, -1073748928, -1073748924, 1, 140899293, 139064610}
fun = <value optimized out>
val = <value optimized out>
original_fun = 139070162
original_args = 141680046
funcar = <value optimized out>
backtrace = {
next = 0xbfffe54c,
function = 0xbfffe41c,
args = 0xbfffe3e4,
nargs = 1,
evalargs = 1 '\001',
debug_on_exit = 0 '\000'
}
#103 0x081a4b09 in readevalloop (readcharfun=140899293, stream=0x0, sourcename=141665945, evalfun=0x81829a0 <Feval>, printflag=0, unibyte=138959050, readfun=
138959050, start=138959050, end=138959050) at lread.c:1789
count1 = 34
c = <value optimized out>
val = <value optimized out>
count = 259915227
b = 0x865f3d8
continue_reading_p = <value optimized out>
whole_buffer = 1
first_sexp = <value optimized out>
#104 0x081a4db0 in Feval_buffer (buffer=140899293, printflag=138959050, filename=141658937, unibyte=138959050, do_allow_print=138959098) at lread.c:1850
count = 181066
tem = <value optimized out>
buf = 140899293
#105 0x08181450 in Ffuncall (nargs=6, args=0xbfffe590) at eval.c:3038
fun = <value optimized out>
original_fun = <value optimized out>
funcar = <value optimized out>
lisp_numargs = <value optimized out>
val = <value optimized out>
backtrace = {
next = 0xbfffe6cc,
function = 0xbfffe590,
args = 0xbfffe594,
nargs = 5,
evalargs = 0 '\000',
debug_on_exit = 0 '\000'
}
internal_args = 0xbfffe594
i = <value optimized out>
#106 0x081b9d01 in Fbyte_code (bytestr=<value optimized out>, vector=136420677, maxdepth=24) at bytecode.c:680
count = 21
op = <value optimized out>
vectorp = 0x8219d48
stack = {
pc = 0x83861e4 "\210,\336\b!\210\016\"\204\256",
top = 0xbfffe5a4,
bottom = 0xbfffe590,
byte_string = 136420657,
byte_string_start = 0x8386158 "\306\b!\204\022",
constants = 136420677,
next = 0xbfffe974
}
top = 0xbfffe590
result = <value optimized out>
#107 0x081832a4 in funcall_lambda (fun=136420589, nargs=4, arg_vector=0xbfffe724) at eval.c:3211
val = <value optimized out>
syms_left = 138959050
next = <value optimized out>
count = 181055
i = 4
optional = <value optimized out>
rest = <value optimized out>
#108 0x081812c3 in Ffuncall (nargs=5, args=0xbfffe720) at eval.c:3081
fun = <value optimized out>
original_fun = 139295594
funcar = <value optimized out>
lisp_numargs = <value optimized out>
val = <value optimized out>
backtrace = {
next = 0xbfffe8cc,
function = 0xbfffe720,
args = 0xbfffe724,
nargs = 4,
evalargs = 0 '\000',
debug_on_exit = 0 '\000'
}
internal_args = <value optimized out>
i = <value optimized out>
#109 0x08181649 in call4 (fn=139295594, arg1=141658937, arg2=141658937, arg3=138959098, arg4=138959098) at eval.c:2878
ret_ungc_val = 250
#110 0x081a5c3a in Fload (file=<value optimized out>, noerror=138959098, nomessage=138959098, nosuffix=138959050, must_suffix=<value optimized out>) at lread.c:1219
val = <value optimized out>
stream = <value optimized out>
fd = 8
count = 6686016
found = 141658937
efound = <value optimized out>
hist_file_name = 141658937
newer = 0
compiled = 0
handler = <value optimized out>
safe_p = 1
fmode = 0x81fb8c3 "r"
tmp = {141594326, 139572742}
version = 0
#111 0x08181450 in Ffuncall (nargs=4, args=0xbfffe910) at eval.c:3038
fun = <value optimized out>
original_fun = <value optimized out>
funcar = <value optimized out>
lisp_numargs = <value optimized out>
val = <value optimized out>
backtrace = {
next = 0xbfffea4c,
function = 0xbfffe910,
args = 0xbfffe914,
nargs = 3,
evalargs = 0 '\000',
debug_on_exit = 0 '\000'
}
internal_args = 0xbfffe870
i = <value optimized out>
#112 0x081b9d01 in Fbyte_code (bytestr=<value optimized out>, vector=136621221, maxdepth=28) at bytecode.c:680
count = 13
op = <value optimized out>
vectorp = 0x824aca8
stack = {
pc = 0x836ae98 "\210\v\321=\203_",
top = 0xbfffe91c,
bottom = 0xbfffe910,
byte_string = 136621201,
byte_string_start = 0x836ae59 "\b\205\264",
constants = 136621221,
next = 0xbfffeae4
}
top = 0xbfffe910
result = <value optimized out>
#113 0x081832a4 in funcall_lambda (fun=136621181, nargs=0, arg_vector=0xbfffea94) at eval.c:3211
val = <value optimized out>
syms_left = 138959050
next = <value optimized out>
count = 181051
i = 0
optional = <value optimized out>
rest = <value optimized out>
#114 0x081812c3 in Ffuncall (nargs=1, args=0xbfffea90) at eval.c:3081
fun = <value optimized out>
original_fun = 136621181
funcar = <value optimized out>
lisp_numargs = <value optimized out>
val = <value optimized out>
backtrace = {
next = 0xbfffeb74,
function = 0xbfffea90,
args = 0xbfffea94,
nargs = 0,
evalargs = 0 '\000',
debug_on_exit = 0 '\000'
}
internal_args = <value optimized out>
i = <value optimized out>
#115 0x081b9d01 in Fbyte_code (bytestr=<value optimized out>, vector=136624301, maxdepth=8) at bytecode.c:680
count = 13
op = <value optimized out>
vectorp = 0x824b8b0
stack = {
pc = 0x836a4f3 "\210\302\211\021\207",
top = 0xbfffea90,
bottom = 0xbfffea90,
byte_string = 136624273,
byte_string_start = 0x836a4f1 "\b \210\302\211\021\207",
constants = 136624301,
next = 0xbfffed24
}
top = 0xbfffea90
result = <value optimized out>
#116 0x08182e7a in Feval (form=136624262) at eval.c:2352
numargs = <value optimized out>
args_left = <value optimized out>
i = 3
maxargs = 3
argvals = {136624273, 136624301, 8, 141658593, 141658592, 1, 141658593, 2}
fun = <value optimized out>
val = <value optimized out>
original_fun = 139079298
original_args = 136624270
funcar = <value optimized out>
backtrace = {
next = 0xbfffedfc,
function = 0xbfffeb8c,
args = 0xbfffeb54,
nargs = 3,
evalargs = 1 '\001',
debug_on_exit = 0 '\000'
}
#117 0x081839b2 in internal_lisp_condition_case (var=138997026, bodyform=136624262, handlers=136624334) at eval.c:1435
val = <value optimized out>
c = {
tag = 138959050,
val = 138959050,
next = 0xbffff044,
gcpro = 0x0,
jmp = {{
__jmpbuf = {136624328, 136621864, 4, -1073746776, 1332294638, -2134087039},
__mask_was_saved = 0,
__saved_mask = {
__val = {0, 4096, 144, 0, 1270232467, 139073962, 3221220392, 138984912, 138959050, 139067064, 3221220456, 135735557, 139067066, 139066235, 138959050,
138984912, 139073962, 138959050, 139220512, 0, 141658481, 3221220336, 141658481, 138959074, 2, 2, 3221220552, 139067066, 138959050, 139066232, 3221220520,
135797620}
}
}},
backlist = 0xbfffedfc,
handlerlist = 0xbffff10c,
lisp_eval_depth = 2,
pdlcount = 13,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0xbfffed24
}
h = {
handler = 136624334,
var = 138997026,
chosen_clause = 141599566,
tag = 0xbfffebc4,
next = 0xbffff10c
}
#118 0x081b8f4b in Fbyte_code (bytestr=<value optimized out>, vector=136621869, maxdepth=28) at bytecode.c:870
handlers = <value optimized out>
body = <value optimized out>
count = 4
op = <value optimized out>
vectorp = 0x824af30
stack = {
pc = 0x836aaa9 "\210\016o\203\071\004\016p\203\071\004r\201\260",
top = 0xbfffecc0,
bottom = 0xbfffecc0,
byte_string = 136621849,
byte_string_start = 0x836a6fb "\306 \020\307\021\n\023\307\024\310\311!\211\035\307=\204\064",
constants = 136621869,
next = 0xbfffeea4
}
top = 0xbfffecc0
result = <value optimized out>
#119 0x081832a4 in funcall_lambda (fun=136621829, nargs=0, arg_vector=0xbfffee44) at eval.c:3211
val = <value optimized out>
syms_left = 138959050
next = <value optimized out>
count = 181042
i = 0
optional = <value optimized out>
rest = <value optimized out>
#120 0x081812c3 in Ffuncall (nargs=1, args=0xbfffee40) at eval.c:3081
fun = <value optimized out>
original_fun = 139881210
funcar = <value optimized out>
lisp_numargs = <value optimized out>
val = <value optimized out>
backtrace = {
next = 0xbfffefd4,
function = 0xbfffee40,
args = 0xbfffee44,
nargs = 0,
evalargs = 0 '\000',
debug_on_exit = 0 '\000'
}
internal_args = <value optimized out>
i = <value optimized out>
#121 0x081b9d01 in Fbyte_code (bytestr=<value optimized out>, vector=136618797, maxdepth=24) at bytecode.c:680
count = 2
op = <value optimized out>
vectorp = 0x824a330
stack = {
pc = 0x836b4a7 "\210*\340\341\342\"\210\343\321\344\"\211\036$;\203\251",
top = 0xbfffee40,
bottom = 0xbfffee40,
byte_string = 136618777,
byte_string_start = 0x836b419 "\b\203\b",
constants = 136618797,
next = 0x0
}
top = 0xbfffee40
result = <value optimized out>
#122 0x081832a4 in funcall_lambda (fun=136618757, nargs=0, arg_vector=0xbfffef40) at eval.c:3211
val = <value optimized out>
syms_left = 138959050
next = <value optimized out>
count = 193144
i = 0
optional = <value optimized out>
rest = <value optimized out>
#123 0x081834a3 in apply_lambda (fun=136618757, args=138959050, eval_flag=1) at eval.c:3135
args_left = 138959050
numargs = 0
arg_vector = 0xbfffef40
i = <value optimized out>
tem = <value optimized out>
#124 0x08182b84 in Feval (form=139200302) at eval.c:2406
fun = <value optimized out>
val = <value optimized out>
original_fun = 139866330
original_args = 138959050
funcar = <value optimized out>
backtrace = {
next = 0x0,
function = 0xbfffefec,
args = 0xbfffef40,
nargs = 0,
evalargs = 0 '\000',
debug_on_exit = 0 '\000'
}
#125 0x08119bb3 in top_level_2 () at keyboard.c:1369
No locals.
#126 0x08180811 in internal_condition_case (bfun=0x8119ba0 <top_level_2>, handlers=138997026, hfun=0x811de80 <cmd_error>) at eval.c:1490
val = <value optimized out>
c = {
tag = 138959050,
val = 138959050,
next = 0xbffff168,
gcpro = 0x0,
jmp = {{
__jmpbuf = {139414184, 139414184, 139414200, -1073745624, 1331573742, -2135822207},
__mask_was_saved = 0,
__saved_mask = {
__val = {21, 21, 0, 0, 0, 3086895784, 3221159938, 16363901, 134536444, 3086912756, 16428996, 30226892, 27, 3221221372, 16341833, 5, 140509042, 0,
894700736, 0, 429496729, 139726016, 500, 31723508, 30652257, 31730716, 3221221284, 3221221936, 3221221632, 3221221936, 3221221784, 135455780}
}
}},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
h = {
handler = 138997026,
var = 138959050,
chosen_clause = 0,
tag = 0xbffff044,
next = 0x0
}
#127 0x0811dc35 in top_level_1 () at keyboard.c:1377
No locals.
#128 0x081808f1 in internal_catch (tag=138994098, func=0x811dbd0 <top_level_1>, arg=138959050) at eval.c:1226
c = {
tag = 138994098,
val = 138959050,
next = 0x0,
gcpro = 0x0,
jmp = {{
__jmpbuf = {139414184, 139414184, 139414200, -1073745352, 1331491822, -2135963519},
__mask_was_saved = 0,
__saved_mask = {
__val = {3221221924, 3221222072, 135386978, 3221221936, 0, 0, 0, 0, 0, 0, 138984912, 138959050, 139126440, 3221221912, 135735557, 139126442,
139124395, 138959050, 138984912, 0, 31492322, 31728576, 119, 124, 31492322, 110, 138959074, 124, 14, 3221222028, 139126442, 138959050}
}
}},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
#129 0x0811dcb1 in command_loop () at keyboard.c:1332
No locals.
#130 0x0811e06b in recursive_edit_1 () at keyboard.c:954
count = 1
val = <value optimized out>
#131 0x0811e192 in Frecursive_edit () at keyboard.c:1016
count = 259722069
buffer = 138959050
#132 0x081132b8 in main (argc=<value optimized out>, argv=0xbffff674) at emacs.c:1787
dummy = -1073744440
stack_bottom_variable = 8 '\b'
do_initial_setlocale = <value optimized out>
skip_args = 1
rlim = {
rlim_cur = 10485760,
rlim_max = 18446744073709551615
}
no_loadup = 0
junk = 0x0
dname_arg = 0x0
Lisp Backtrace:
"require" (0xbfffe094)
"byte-code" (0xbfffe154)
"require" (0xbfffe3e4)
"eval-buffer" (0xbfffe594)
"load-with-code-conversion" (0xbfffe724)
"load" (0xbfffe914)
0x824ac7d PVEC_COMPILED
"byte-code" (0xbfffeb54)
"command-line" (0xbfffee44)
"normal-top-level" (0xbfffef40)
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-02 19:02 emacs from head segfaults when run with -nw Alfred M. Szmidt
@ 2010-04-02 20:49 ` Dan Nicolaescu
2010-04-02 23:07 ` Juri Linkov
2010-04-05 9:04 ` Eli Zaretskii
2010-04-16 8:26 ` Sascha Wilde
2 siblings, 1 reply; 57+ messages in thread
From: Dan Nicolaescu @ 2010-04-02 20:49 UTC (permalink / raw)
To: ams; +Cc: Juri Linkov, emacs-devel
"Alfred M. Szmidt" <ams@gnu.org> writes:
> When I start emacs with -nw, it segfaults, if I run with -Q it
> segfaults in a different place,
>
It happens because of this change:
* image.c: Add `Qextension_data'.
(syms_of_image): Initialize and staticpro `Qextension_data'.
(Fimage_metadata): Rename from `Fimage_extension_data'.
(gif_load): Put GIF extension data to the property
`Qextension_data'.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-02 20:49 ` Dan Nicolaescu
@ 2010-04-02 23:07 ` Juri Linkov
2010-04-02 23:48 ` Dan Nicolaescu
0 siblings, 1 reply; 57+ messages in thread
From: Juri Linkov @ 2010-04-02 23:07 UTC (permalink / raw)
To: Dan Nicolaescu; +Cc: ams, emacs-devel
>> When I start emacs with -nw, it segfaults, if I run with -Q it
>> segfaults in a different place,
>
> It happens because of this change:
>
> * image.c: Add `Qextension_data'.
> (syms_of_image): Initialize and staticpro `Qextension_data'.
> (Fimage_metadata): Rename from `Fimage_extension_data'.
> (gif_load): Put GIF extension data to the property
> `Qextension_data'.
That's strange. I can't reproduce this segfault.
--
Juri Linkov
http://www.jurta.org/emacs/
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-02 23:07 ` Juri Linkov
@ 2010-04-02 23:48 ` Dan Nicolaescu
2010-04-03 10:42 ` Alfred M. Szmidt
2010-04-03 22:12 ` Juri Linkov
0 siblings, 2 replies; 57+ messages in thread
From: Dan Nicolaescu @ 2010-04-02 23:48 UTC (permalink / raw)
To: Juri Linkov; +Cc: ams, emacs-devel
Juri Linkov <juri@jurta.org> writes:
>>> When I start emacs with -nw, it segfaults, if I run with -Q it
>>> segfaults in a different place,
>>
>> It happens because of this change:
>>
>> * image.c: Add `Qextension_data'.
>> (syms_of_image): Initialize and staticpro `Qextension_data'.
>> (Fimage_metadata): Rename from `Fimage_extension_data'.
>> (gif_load): Put GIF extension data to the property
>> `Qextension_data'.
>
> That's strange. I can't reproduce this segfault.
./configure --with-x-toolkit=lucid
works
./configure
[i.e. using Gtk]
segfaults
on Fedora12.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-02 23:48 ` Dan Nicolaescu
@ 2010-04-03 10:42 ` Alfred M. Szmidt
2010-04-03 19:19 ` Dan Nicolaescu
2010-04-03 22:12 ` Juri Linkov
1 sibling, 1 reply; 57+ messages in thread
From: Alfred M. Szmidt @ 2010-04-03 10:42 UTC (permalink / raw)
To: Dan Nicolaescu; +Cc: juri, emacs-devel
Does it segfault for you if you run with -nw? Since without it,
everything works for me. It seems strange the the X11 toolkit would
affect -nw...
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-03 10:42 ` Alfred M. Szmidt
@ 2010-04-03 19:19 ` Dan Nicolaescu
0 siblings, 0 replies; 57+ messages in thread
From: Dan Nicolaescu @ 2010-04-03 19:19 UTC (permalink / raw)
To: ams; +Cc: juri, emacs-devel
"Alfred M. Szmidt" <ams@gnu.org> writes:
> Does it segfault for you if you run with -nw? Since without it,
> everything works for me. It seems strange the the X11 toolkit would
> affect -nw...
Yes, the segfaults happen only when using -nw.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-02 23:48 ` Dan Nicolaescu
2010-04-03 10:42 ` Alfred M. Szmidt
@ 2010-04-03 22:12 ` Juri Linkov
2010-04-03 23:56 ` Ken Hori
` (3 more replies)
1 sibling, 4 replies; 57+ messages in thread
From: Juri Linkov @ 2010-04-03 22:12 UTC (permalink / raw)
To: Dan Nicolaescu; +Cc: ams, emacs-devel
> ./configure --with-x-toolkit=lucid
> works
>
> ./configure
> [i.e. using Gtk]
> segfaults
>
> on Fedora12.
I tried ./configure using Gtk on Debian and Ubuntu,
and no segfaults with -nw.
Maybe it's Fedora specific?
--
Juri Linkov
http://www.jurta.org/emacs/
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-03 22:12 ` Juri Linkov
@ 2010-04-03 23:56 ` Ken Hori
2010-04-04 11:06 ` Juri Linkov
2010-04-04 8:10 ` Jan Djärv
` (2 subsequent siblings)
3 siblings, 1 reply; 57+ messages in thread
From: Ken Hori @ 2010-04-03 23:56 UTC (permalink / raw)
To: Juri Linkov; +Cc: Dan Nicolaescu, ams, emacs-devel
I experience segfaults with emacs under X.
bzr 2010-04-01 version. so it's not just for "nw" emacs.
On Sat, Apr 3, 2010 at 3:12 PM, Juri Linkov <juri@jurta.org> wrote:
>> ./configure --with-x-toolkit=lucid
>> works
>>
>> ./configure
>> [i.e. using Gtk]
>> segfaults
>>
>> on Fedora12.
>
> I tried ./configure using Gtk on Debian and Ubuntu,
> and no segfaults with -nw.
>
> Maybe it's Fedora specific?
>
> --
> Juri Linkov
> http://www.jurta.org/emacs/
>
>
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-03 22:12 ` Juri Linkov
2010-04-03 23:56 ` Ken Hori
@ 2010-04-04 8:10 ` Jan Djärv
2010-04-05 17:22 ` Dan Nicolaescu
2010-04-14 15:05 ` Randal L. Schwartz
3 siblings, 0 replies; 57+ messages in thread
From: Jan Djärv @ 2010-04-04 8:10 UTC (permalink / raw)
To: Juri Linkov; +Cc: Dan Nicolaescu, ams, emacs-devel
Juri Linkov skrev 2010-04-04 00.12:
>> ./configure --with-x-toolkit=lucid
>> works
>>
>> ./configure
>> [i.e. using Gtk]
>> segfaults
>>
>> on Fedora12.
>
> I tried ./configure using Gtk on Debian and Ubuntu,
> and no segfaults with -nw.
>
> Maybe it's Fedora specific?
>
FWIW, I could not reproduce this on Fedora 12 with Gtk+.
Jan D.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-03 23:56 ` Ken Hori
@ 2010-04-04 11:06 ` Juri Linkov
0 siblings, 0 replies; 57+ messages in thread
From: Juri Linkov @ 2010-04-04 11:06 UTC (permalink / raw)
To: Ken Hori; +Cc: Dan Nicolaescu, ams, emacs-devel
> I experience segfaults with emacs under X.
> bzr 2010-04-01 version. so it's not just for "nw" emacs.
Does `make bootstrap' help you?
--
Juri Linkov
http://www.jurta.org/emacs/
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-02 19:02 emacs from head segfaults when run with -nw Alfred M. Szmidt
2010-04-02 20:49 ` Dan Nicolaescu
@ 2010-04-05 9:04 ` Eli Zaretskii
2010-04-05 13:34 ` Alfred M. Szmidt
` (3 more replies)
2010-04-16 8:26 ` Sascha Wilde
2 siblings, 4 replies; 57+ messages in thread
From: Eli Zaretskii @ 2010-04-05 9:04 UTC (permalink / raw)
To: ams; +Cc: emacs-devel
> From: "Alfred M. Szmidt" <ams@gnu.org>
> Date: Fri, 02 Apr 2010 15:02:23 -0400
>
> When I start emacs with -nw, it segfaults, if I run with -Q it
> segfaults in a different place,
Does this still happen with current bzr, and after you make a clean
bootstrap? If so, could you please post a backtrace from the segfault
you get in "emacs -Q"?
I think I see a similar problem on MS-Windows, and I'd like to compare
the backtraces we see. The segfault only happens for me in an
optimized build, btw. It seems to happen when GC tries to mark the
value of Buffer-menu-mode-map.
I cannot reproduce the segfault on GNU/Linux.
Thanks.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-05 9:04 ` Eli Zaretskii
@ 2010-04-05 13:34 ` Alfred M. Szmidt
2010-04-05 14:06 ` Eli Zaretskii
2010-04-05 13:52 ` Stefan Monnier
` (2 subsequent siblings)
3 siblings, 1 reply; 57+ messages in thread
From: Alfred M. Szmidt @ 2010-04-05 13:34 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 28672 bytes --]
> When I start emacs with -nw, it segfaults, if I run with -Q it
> segfaults in a different place,
Does this still happen with current bzr, and after you make a clean
bootstrap? If so, could you please post a backtrace from the
segfault you get in "emacs -Q"?
Tried a clean bootstrap today, still get the segfault with -nw -Q:
Program received signal SIGSEGV, Segmentation fault.
0x081692bd in mark_object (arg=-7552029) at alloc.c:5595
5595 if (XMISCANY (obj)->gcmarkbit)
(gdb) bt full
#0 0x081692bd in mark_object (arg=-7552029) at alloc.c:5595
obj = -7552029
cdr_count = <value optimized out>
#1 0x081697ff in mark_vectorlike (ptr=0x859cfc0) at alloc.c:5368
size = 138959698
i = <value optimized out>
#2 0x0816977d in mark_char_table (ptr=0x8579398) at alloc.c:5396
val = <value optimized out>
size = 130
i = <value optimized out>
#3 0x081697bc in mark_char_table (ptr=0x8491338) at alloc.c:5393
val = <value optimized out>
size = 34
i = <value optimized out>
#4 0x081697bc in mark_char_table (ptr=0x8540870) at alloc.c:5393
val = <value optimized out>
size = 18
i = <value optimized out>
#5 0x081697bc in mark_char_table (ptr=0x8487d78) at alloc.c:5393
val = <value optimized out>
size = 70
i = <value optimized out>
#6 0x081694dd in mark_buffer (arg=141207229) at alloc.c:5745
buffer = 0x86aa6b8
ptr = <value optimized out>
tmp = <value optimized out>
base_buffer = <value optimized out>
#7 mark_object (arg=141207229) at alloc.c:5500
obj = <value optimized out>
cdr_count = <value optimized out>
#8 0x08169516 in mark_object (arg=139139395) at alloc.c:5612
ptr = 0x84b1940
obj = <value optimized out>
cdr_count = <value optimized out>
#9 0x08169308 in mark_object (arg=139093770) at alloc.c:5572
ptr = 0x84a6708
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#10 0x081691fd in mark_object (arg=141597014) at alloc.c:5685
ptr = 0x84f16b8
obj = <value optimized out>
cdr_count = <value optimized out>
#11 0x081694dd in mark_buffer (arg=139429661) at alloc.c:5745
buffer = 0x84f8718
ptr = <value optimized out>
tmp = <value optimized out>
base_buffer = <value optimized out>
#12 mark_object (arg=139429661) at alloc.c:5500
obj = <value optimized out>
cdr_count = <value optimized out>
#13 0x08169516 in mark_object (arg=139139347) at alloc.c:5612
ptr = 0x84b1910
obj = <value optimized out>
cdr_count = <value optimized out>
#14 0x08169308 in mark_object (arg=139123586) at alloc.c:5572
ptr = 0x84adb80
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#15 0x081691fd in mark_object (arg=141596950) at alloc.c:5685
ptr = 0x8592850
obj = <value optimized out>
cdr_count = <value optimized out>
#16 0x081694dd in mark_buffer (arg=141427382) at alloc.c:5745
buffer = 0x84b8708
ptr = <value optimized out>
tmp = <value optimized out>
base_buffer = <value optimized out>
#17 mark_object (arg=141427382) at alloc.c:5500
obj = <value optimized out>
cdr_count = <value optimized out>
#18 0x081697ff in mark_vectorlike (ptr=0x86d3678) at alloc.c:5368
size = 2
i = <value optimized out>
#19 0x081691fd in mark_object (arg=139983118) at alloc.c:5685
ptr = 0x86e0200
obj = <value optimized out>
cdr_count = <value optimized out>
#20 0x081691fd in mark_object (arg=139491526) at alloc.c:5685
ptr = 0x857f928
obj = <value optimized out>
cdr_count = <value optimized out>
#21 0x081691fd in mark_object (arg=138952014) at alloc.c:5685
ptr = 0x85078b8
obj = <value optimized out>
cdr_count = <value optimized out>
#22 0x08169308 in mark_object (arg=139067586) at alloc.c:5572
ptr = 0x848c798
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#23 0x081691fd in mark_object (arg=139454590) at alloc.c:5685
ptr = 0x84fe710
obj = <value optimized out>
cdr_count = <value optimized out>
#24 0x0816931e in mark_object (arg=139409330) at alloc.c:5574
ptr = 0x84f37b0
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#25 0x081691fd in mark_object (arg=139454518) at alloc.c:5685
ptr = 0x84fe830
obj = <value optimized out>
cdr_count = <value optimized out>
#26 0x081691fd in mark_object (arg=139454510) at alloc.c:5685
ptr = 0x84fe828
obj = <value optimized out>
cdr_count = <value optimized out>
#27 0x081691fd in mark_object (arg=139454494) at alloc.c:5685
ptr = 0x84fe820
obj = <value optimized out>
cdr_count = <value optimized out>
#28 0x0816931e in mark_object (arg=139776114) at alloc.c:5574
ptr = 0x84f37e0
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#29 0x081691fd in mark_object (arg=139204886) at alloc.c:5685
ptr = 0x85057d8
obj = <value optimized out>
cdr_count = <value optimized out>
#30 0x0816931e in mark_object (arg=139182858) at alloc.c:5574
ptr = 0x84bc308
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#31 0x0816977d in mark_char_table (ptr=0x84b7460) at alloc.c:5396
val = <value optimized out>
size = 130
i = <value optimized out>
#32 0x081697bc in mark_char_table (ptr=0x848cab8) at alloc.c:5393
val = <value optimized out>
size = 68
i = <value optimized out>
#33 0x081691fd in mark_object (arg=138952046) at alloc.c:5685
ptr = 0x8483d60
obj = <value optimized out>
cdr_count = <value optimized out>
#34 0x08169313 in mark_object (arg=139866426) at alloc.c:5573
ptr = 0x848c7f8
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#35 0x081691fd in mark_object (arg=139457254) at alloc.c:5685
ptr = 0x84ff2e0
obj = <value optimized out>
cdr_count = <value optimized out>
#36 0x081691fd in mark_object (arg=139392278) at alloc.c:5685
ptr = 0x84ff2d8
obj = <value optimized out>
cdr_count = <value optimized out>
#37 0x0816931e in mark_object (arg=139866378) at alloc.c:5574
ptr = 0x8563108
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#38 0x081691fd in mark_object (arg=139392262) at alloc.c:5685
ptr = 0x84ef500
obj = <value optimized out>
cdr_count = <value optimized out>
#39 0x081691fd in mark_object (arg=139457654) at alloc.c:5685
ptr = 0x84ef4f8
obj = <value optimized out>
cdr_count = <value optimized out>
#40 0x0816931e in mark_object (arg=140046522) at alloc.c:5574
ptr = 0x84e58f8
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#41 0x08169313 in mark_object (arg=140614218) at alloc.c:5573
ptr = 0x858f0d0
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#42 0x081691fd in mark_object (arg=141443854) at alloc.c:5685
ptr = 0x86e4308
obj = <value optimized out>
cdr_count = <value optimized out>
#43 0x081691fd in mark_object (arg=139846214) at alloc.c:5685
ptr = 0x86e4300
obj = <value optimized out>
cdr_count = <value optimized out>
#44 0x081691fd in mark_object (arg=139846198) at alloc.c:5685
ptr = 0x855e238
obj = <value optimized out>
cdr_count = <value optimized out>
#45 0x0816931e in mark_object (arg=141414838) at alloc.c:5574
ptr = 0x84f26b0
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#46 0x081691fd in mark_object (arg=141519534) at alloc.c:5685
ptr = 0x86e3208
obj = <value optimized out>
cdr_count = <value optimized out>
#47 0x08169308 in mark_object (arg=139822698) at alloc.c:5572
ptr = 0x84f4480
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#48 0x081691fd in mark_object (arg=139458798) at alloc.c:5685
ptr = 0x84ff8e8
obj = <value optimized out>
cdr_count = <value optimized out>
#49 0x081691fd in mark_object (arg=139458734) at alloc.c:5685
ptr = 0x84ff8a8
obj = <value optimized out>
cdr_count = <value optimized out>
#50 0x081691fd in mark_object (arg=139279278) at alloc.c:5685
ptr = 0x84ff8a0
obj = <value optimized out>
cdr_count = <value optimized out>
#51 0x0816931e in mark_object (arg=139073778) at alloc.c:5574
ptr = 0x84a18f0
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#52 0x081691fd in mark_object (arg=139279166) at alloc.c:5685
ptr = 0x84d3b38
obj = <value optimized out>
cdr_count = <value optimized out>
#53 0x081691fd in mark_object (arg=139197294) at alloc.c:5685
ptr = 0x84d3b30
obj = <value optimized out>
cdr_count = <value optimized out>
#54 0x081691fd in mark_object (arg=139191998) at alloc.c:5685
ptr = 0x84bfb60
obj = <value optimized out>
cdr_count = <value optimized out>
#55 0x081691fd in mark_object (arg=139288206) at alloc.c:5685
ptr = 0x84d5ef8
obj = <value optimized out>
cdr_count = <value optimized out>
#56 0x08169308 in mark_object (arg=139331274) at alloc.c:5572
ptr = 0x85403b8
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#57 0x0816977d in mark_char_table (ptr=0x84b77c8) at alloc.c:5396
val = <value optimized out>
size = 130
i = <value optimized out>
#58 0x081697bc in mark_char_table (ptr=0x848c978) at alloc.c:5393
val = <value optimized out>
size = 68
i = <value optimized out>
#59 0x081691fd in mark_object (arg=138952030) at alloc.c:5685
ptr = 0x8483d50
obj = <value optimized out>
cdr_count = <value optimized out>
#60 0x08169308 in mark_object (arg=141246442) at alloc.c:5572
ptr = 0x848c7b0
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#61 0x081691fd in mark_object (arg=141430334) at alloc.c:5685
ptr = 0x86e0e38
obj = <value optimized out>
cdr_count = <value optimized out>
#62 0x081691fd in mark_object (arg=139286734) at alloc.c:5685
ptr = 0x86e0e30
obj = <value optimized out>
cdr_count = <value optimized out>
#63 0x0816931e in mark_object (arg=139000162) at alloc.c:5574
ptr = 0x848c308
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#64 0x08169313 in mark_object (arg=139209002) at alloc.c:5573
ptr = 0x84c2928
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#65 0x081691fd in mark_object (arg=140139598) at alloc.c:5685
ptr = 0x85a5c70
obj = <value optimized out>
cdr_count = <value optimized out>
#66 0x0816931e in mark_object (arg=140574642) at alloc.c:5574
ptr = 0x8617a18
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#67 0x081691fd in mark_object (arg=141459606) at alloc.c:5685
ptr = 0x86e8090
obj = <value optimized out>
cdr_count = <value optimized out>
#68 0x081691fd in mark_object (arg=141459518) at alloc.c:5685
ptr = 0x86e8088
obj = <value optimized out>
cdr_count = <value optimized out>
#69 0x0816931e in mark_object (arg=139466470) at alloc.c:5574
ptr = 0x84a8730
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#70 0x081691fd in mark_object (arg=139465814) at alloc.c:5685
ptr = 0x85016d8
obj = <value optimized out>
cdr_count = <value optimized out>
#71 0x0816931e in mark_object (arg=140830210) at alloc.c:5574
ptr = 0x854cd80
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#72 0x081691fd in mark_object (arg=141411878) at alloc.c:5685
ptr = 0x86dc620
obj = <value optimized out>
cdr_count = <value optimized out>
#73 0x081691fd in mark_object (arg=139719318) at alloc.c:5685
ptr = 0x86dc628
obj = <value optimized out>
cdr_count = <value optimized out>
#74 0x08169308 in mark_object (arg=141449870) at alloc.c:5572
ptr = 0x8582878
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#75 0x08169308 in mark_object (arg=140093638) at alloc.c:5572
ptr = 0x858d4e0
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#76 0x081691fd in mark_object (arg=139205374) at alloc.c:5685
ptr = 0x859a8b8
obj = <value optimized out>
cdr_count = <value optimized out>
#77 0x0816931e in mark_object (arg=138988898) at alloc.c:5574
ptr = 0x848cd60
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#78 0x081691fd in mark_object (arg=139285902) at alloc.c:5685
ptr = 0x84d5588
obj = <value optimized out>
cdr_count = <value optimized out>
#79 0x081691fd in mark_object (arg=139285950) at alloc.c:5685
ptr = 0x84d5580
obj = <value optimized out>
cdr_count = <value optimized out>
#80 0x081691fd in mark_object (arg=139285206) at alloc.c:5685
ptr = 0x84d55a0
obj = <value optimized out>
cdr_count = <value optimized out>
#81 0x081cc52f in traverse_intervals_noorder (tree=0x84cb6c0, function=0x8169810 <mark_interval>, arg=138959050) at intervals.c:217
No locals.
#82 0x08169179 in mark_interval_tree (arg=139285198) at alloc.c:1514
No locals.
#83 mark_object (arg=139285198) at alloc.c:5467
ptr = 0x84f7ec8
obj = <value optimized out>
cdr_count = <value optimized out>
#84 0x0816950b in mark_object (arg=139139467) at alloc.c:5611
ptr = 0x84b1988
obj = <value optimized out>
cdr_count = <value optimized out>
#85 0x08169308 in mark_object (arg=139724114) at alloc.c:5572
ptr = 0x8540550
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#86 0x081691fd in mark_object (arg=139191566) at alloc.c:5685
ptr = 0x84d7290
obj = <value optimized out>
cdr_count = <value optimized out>
#87 0x081694dd in mark_buffer (arg=139062709) at alloc.c:5745
buffer = 0x849edb0
ptr = <value optimized out>
tmp = <value optimized out>
base_buffer = <value optimized out>
#88 mark_object (arg=139062709) at alloc.c:5500
obj = <value optimized out>
cdr_count = <value optimized out>
#89 0x081697ff in mark_vectorlike (ptr=0x849ec58) at alloc.c:5368
size = 51
i = <value optimized out>
#90 0x081695ea in mark_object (arg=139062365) at alloc.c:5534
ptr = 0x849ec58
w = 0x849ec58
obj = <value optimized out>
cdr_count = <value optimized out>
#91 0x081697ff in mark_vectorlike (ptr=0x849eb00) at alloc.c:5368
size = 51
i = <value optimized out>
#92 0x081695ea in mark_object (arg=139062021) at alloc.c:5534
ptr = 0x849eb00
w = 0x849eb00
obj = <value optimized out>
cdr_count = <value optimized out>
#93 0x081697ff in mark_vectorlike (ptr=0x849e960) at alloc.c:5368
size = 21
i = <value optimized out>
#94 0x0816962b in mark_object (arg=139061605) at alloc.c:5527
ptr = 0x849e960
obj = <value optimized out>
cdr_count = <value optimized out>
#95 0x08169521 in mark_object (arg=141634979) at alloc.c:5613
ptr = 0x8712da0
obj = <value optimized out>
cdr_count = <value optimized out>
#96 0x08169308 in mark_object (arg=139078178) at alloc.c:5572
ptr = 0x84a2a20
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#97 0x081691fd in mark_object (arg=141592942) at alloc.c:5685
ptr = 0x8708968
obj = <value optimized out>
cdr_count = <value optimized out>
#98 0x081691fd in mark_object (arg=141592950) at alloc.c:5685
ptr = 0x8708970
obj = <value optimized out>
cdr_count = <value optimized out>
#99 0x081694dd in mark_buffer (arg=138984917) at alloc.c:5745
buffer = 0x848bdd0
ptr = <value optimized out>
tmp = <value optimized out>
base_buffer = <value optimized out>
#100 mark_object (arg=138984917) at alloc.c:5500
obj = <value optimized out>
cdr_count = <value optimized out>
#101 0x08169516 in mark_object (arg=139330355) at alloc.c:5612
ptr = 0x84e0330
obj = <value optimized out>
cdr_count = <value optimized out>
#102 0x08169308 in mark_object (arg=140606410) at alloc.c:5572
ptr = 0x8561a08
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#103 0x081691fd in mark_object (arg=141517230) at alloc.c:5685
ptr = 0x86f61a8
obj = <value optimized out>
cdr_count = <value optimized out>
#104 0x08169308 in mark_object (arg=139404906) at alloc.c:5572
ptr = 0x84d2e38
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#105 0x081691fd in mark_object (arg=139465638) at alloc.c:5685
ptr = 0x8501290
obj = <value optimized out>
cdr_count = <value optimized out>
#106 0x0816931e in mark_object (arg=140215074) at alloc.c:5574
ptr = 0x85b8320
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#107 0x081691fd in mark_object (arg=139464182) at alloc.c:5685
ptr = 0x8500df0
obj = <value optimized out>
cdr_count = <value optimized out>
#108 0x081691fd in mark_object (arg=139475510) at alloc.c:5685
ptr = 0x8500dd8
obj = <value optimized out>
cdr_count = <value optimized out>
#109 0x0816931e in mark_object (arg=140214954) at alloc.c:5574
ptr = 0x85b82a8
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#110 0x081691fd in mark_object (arg=139474302) at alloc.c:5685
ptr = 0x85036d0
obj = <value optimized out>
cdr_count = <value optimized out>
#111 0x0816931e in mark_object (arg=140214978) at alloc.c:5574
ptr = 0x85b82c0
ptrx = <value optimized out>
obj = <value optimized out>
cdr_count = <value optimized out>
#112 0x081697ff in mark_vectorlike (ptr=0x8485ce0) at alloc.c:5368
size = 1511
i = <value optimized out>
#113 0x0816cb64 in Fgarbage_collect () at alloc.c:5083
bind = <value optimized out>
catch = <value optimized out>
handler = <value optimized out>
stack_top_variable = 8 '\b'
i = <value optimized out>
message_p = 1
total = {141665376, 2, 141705398, -1073747656, 135428239, 141694094, 138959050, 0}
count = 259443384
t1 = {tv_sec = 1270474786, tv_usec = 761356}
t2 = {tv_sec = 136458365, tv_usec = -1073747492}
#114 0x081814b5 in Ffuncall (nargs=2, args=0xbfffe9d8) at eval.c:2958
fun = <value optimized out>
original_fun = <value optimized out>
funcar = <value optimized out>
lisp_numargs = <value optimized out>
val = <value optimized out>
backtrace = {next = 0xbfffeb0c, function = 0xbfffe9d0, args = 0x848e702, nargs = -1073747528, evalargs = 66 'B', debug_on_exit = 37 '%'}
internal_args = <value optimized out>
i = <value optimized out>
#115 0x081b9ea1 in Fbyte_code (bytestr=<value optimized out>, vector=139433773, maxdepth=32) at bytecode.c:680
count = 10
op = <value optimized out>
vectorp = 0x84f9730
stack = {pc =
0x871f1d2 "\"\210\316\f\t\"\210)\320 \210\321 \210\322Ó‰\211\211\035\036\066\036\067\036\070\036\071\324 \210\325\326!\210\327Ó‰\330#Ùš\203$\001\327Ó‰\330#Úš\203$\001\327Ó‰\330#\211\026\070Ûš\204\206", top = 0xbfffe9dc, bottom = 0xbfffe9d0, byte_string = 141693321, byte_string_start = 0x871f19c "\306\307\310 \"\203\034",
constants = 139433773, next = 0xbfffeba4}
top = 0xbfffe9d8
result = <value optimized out>
#116 0x08183444 in funcall_lambda (fun=139434117, nargs=0, arg_vector=0xbfffeb54) at eval.c:3211
val = <value optimized out>
syms_left = 138959050
next = <value optimized out>
count = 181222
i = 0
optional = <value optimized out>
rest = <value optimized out>
#117 0x08181463 in Ffuncall (nargs=1, args=0xbfffeb50) at eval.c:3081
fun = <value optimized out>
original_fun = 141678042
funcar = <value optimized out>
lisp_numargs = <value optimized out>
val = <value optimized out>
backtrace = {next = 0xbfffec7c, function = 0xbfffeb50, args = 0xbfffeb54, nargs = 0, evalargs = 0 '\000', debug_on_exit = 0 '\000'}
internal_args = <value optimized out>
i = <value optimized out>
#118 0x081b9ea1 in Fbyte_code (bytestr=<value optimized out>, vector=136571821, maxdepth=16) at bytecode.c:680
count = 6
op = <value optimized out>
vectorp = 0x823ebb0
stack = {pc = 0x836f5b8 "\210\320\t\321\r#)+\207", top = 0xbfffeb50, bottom = 0xbfffeb50, byte_string = 136571801, byte_string_start = 0x836f58c "\b\206\a",
constants = 136571821, next = 0xbfffed24}
top = 0xbfffeb50
result = <value optimized out>
#119 0x08183444 in funcall_lambda (fun=136571749, nargs=1, arg_vector=0xbfffecc4) at eval.c:3211
val = <value optimized out>
syms_left = 138959050
next = <value optimized out>
count = 181216
i = 1
optional = <value optimized out>
rest = <value optimized out>
#120 0x08181463 in Ffuncall (nargs=2, args=0xbfffecc0) at eval.c:3081
fun = <value optimized out>
original_fun = 139297914
funcar = <value optimized out>
lisp_numargs = <value optimized out>
val = <value optimized out>
backtrace = {next = 0xbfffedfc, function = 0xbfffecc0, args = 0xbfffecc4, nargs = 1, evalargs = 0 '\000', debug_on_exit = 0 '\000'}
internal_args = <value optimized out>
i = <value optimized out>
#121 0x081b9ea1 in Fbyte_code (bytestr=<value optimized out>, vector=136619085, maxdepth=28) at bytecode.c:680
count = 4
op = <value optimized out>
vectorp = 0x824a450
stack = {pc = 0x836a20e "\210\354\201", <incomplete sequence \327>, top = 0xbfffecc4, bottom = 0xbfffecc0, byte_string = 136619065, byte_string_start =
0x8369c09 "\306 \020\307\021\n\023\307\024\310\311!\211\035\307=\204\064", constants = 136619085, next = 0xbfffeea4}
top = 0xbfffecc0
result = <value optimized out>
#122 0x08183444 in funcall_lambda (fun=136619045, nargs=0, arg_vector=0xbfffee44) at eval.c:3211
val = <value optimized out>
syms_left = 138959050
next = <value optimized out>
count = 181216
i = 0
optional = <value optimized out>
rest = <value optimized out>
#123 0x08181463 in Ffuncall (nargs=1, args=0xbfffee40) at eval.c:3081
fun = <value optimized out>
original_fun = 139881210
funcar = <value optimized out>
lisp_numargs = <value optimized out>
val = <value optimized out>
backtrace = {next = 0xbfffefd4, function = 0xbfffee40, args = 0xbfffee44, nargs = 0, evalargs = 0 '\000', debug_on_exit = 0 '\000'}
internal_args = <value optimized out>
i = <value optimized out>
#124 0x081b9ea1 in Fbyte_code (bytestr=<value optimized out>, vector=136616013, maxdepth=24) at bytecode.c:680
count = 2
op = <value optimized out>
vectorp = 0x8249850
stack = {pc = 0x836a9b5 "\210*\340\341\342\"\210\343\321\344\"\211\036$;\203\251", top = 0xbfffee40, bottom = 0xbfffee40, byte_string = 136615993,
byte_string_start = 0x836a927 "\b\203\b", constants = 136616013, next = 0x0}
top = 0xbfffee40
result = <value optimized out>
#125 0x08183444 in funcall_lambda (fun=136615973, nargs=0, arg_vector=0xbfffef40) at eval.c:3211
val = <value optimized out>
syms_left = 138959050
next = <value optimized out>
count = 193318
i = 0
optional = <value optimized out>
rest = <value optimized out>
#126 0x08183643 in apply_lambda (fun=136615973, args=138959050, eval_flag=1) at eval.c:3135
args_left = 138959050
numargs = 0
arg_vector = 0xbfffef40
i = <value optimized out>
tem = <value optimized out>
#127 0x08182d24 in Feval (form=139200302) at eval.c:2406
fun = <value optimized out>
val = <value optimized out>
original_fun = 139866330
original_args = 138959050
funcar = <value optimized out>
backtrace = {next = 0x0, function = 0xbfffefec, args = 0xbfffef40, nargs = 0, evalargs = 0 '\000', debug_on_exit = 0 '\000'}
#128 0x08119d53 in top_level_2 () at keyboard.c:1365
No locals.
#129 0x081809b1 in internal_condition_case (bfun=0x8119d40 <top_level_2>, handlers=138997026, hfun=0x811e020 <cmd_error>) at eval.c:1490
val = <value optimized out>
c = {tag = 138959050, val = 138959050, next = 0xbffff168, gcpro = 0x0, jmp = {{__jmpbuf = {139414184, 139414184, 139414200, -1073745624, -208416349,
1013011148}, __mask_was_saved = 0, __saved_mask = {__val = {21, 21, 0, 0, 0, 3086895784, 3221159938, 1421693, 134536480, 3086912756, 1486788, 16726476, 27,
3221221372, 1399625, 5, 140509042, 0, 894700736, 0, 429496729, 139726016, 500, 18223092, 17151841, 18230300, 3221221284, 3221221936, 3221221632, 3221221936,
3221221784, 135456196}}}}, backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, poll_suppress_count = 1, interrupt_input_blocked = 0,
byte_stack = 0x0}
h = {handler = 138997026, var = 138959050, chosen_clause = 0, tag = 0xbffff044, next = 0x0}
#130 0x0811ddd5 in top_level_1 () at keyboard.c:1373
No locals.
#131 0x08180a91 in internal_catch (tag=138994098, func=0x811dd70 <top_level_1>, arg=138959050) at eval.c:1226
c = {tag = 138994098, val = 138959050, next = 0x0, gcpro = 0x0, jmp = {{__jmpbuf = {139414184, 139414184, 139414200, -1073745352, -208596573, 1013410508},
__mask_was_saved = 0, __saved_mask = {__val = {3221221924, 3221222072, 135387394, 3221221936, 0, 0, 0, 0, 0, 0, 138984912, 138959050, 139126440,
3221221912, 135735973, 139126442, 139124395, 138959050, 138984912, 0, 17991906, 18228160, 119, 124, 17991906, 110, 138959074, 124, 14, 3221222028, 139126442,
138959050}}}}, backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, poll_suppress_count = 1, interrupt_input_blocked = 0, byte_stack = 0x0}
#132 0x0811de51 in command_loop () at keyboard.c:1328
No locals.
#133 0x0811e20b in recursive_edit_1 () at keyboard.c:950
count = 1
val = <value optimized out>
#134 0x0811e332 in Frecursive_edit () at keyboard.c:1012
count = 259722069
buffer = 138959050
#135 0x08113458 in main (argc=<value optimized out>, argv=0xbffff674) at emacs.c:1784
dummy = -1073744440
stack_bottom_variable = 8 '\b'
do_initial_setlocale = <value optimized out>
skip_args = 1
rlim = {rlim_cur = 10485760, rlim_max = 18446744073709551615}
no_loadup = 0
junk = 0x0
dname_arg = 0x0
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-05 9:04 ` Eli Zaretskii
2010-04-05 13:34 ` Alfred M. Szmidt
@ 2010-04-05 13:52 ` Stefan Monnier
2010-04-05 14:17 ` Eli Zaretskii
2010-04-05 14:11 ` Chong Yidong
2010-04-16 14:18 ` Juanma Barranquero
3 siblings, 1 reply; 57+ messages in thread
From: Stefan Monnier @ 2010-04-05 13:52 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: ams, emacs-devel
> I think I see a similar problem on MS-Windows, and I'd like to compare
> the backtraces we see. The segfault only happens for me in an
> optimized build, btw. It seems to happen when GC tries to mark the
> value of Buffer-menu-mode-map.
> I cannot reproduce the segfault on GNU/Linux.
I think I've seen the same crash on my GNU/Linux system. But I've had
difficulty reproducing it (it was in an unusal situation and I can't
quite remember what I did to get there).
Stefan
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-05 13:34 ` Alfred M. Szmidt
@ 2010-04-05 14:06 ` Eli Zaretskii
2010-04-05 15:03 ` Alfred M. Szmidt
2010-04-05 16:49 ` Eli Zaretskii
0 siblings, 2 replies; 57+ messages in thread
From: Eli Zaretskii @ 2010-04-05 14:06 UTC (permalink / raw)
To: ams; +Cc: emacs-devel
> From: "Alfred M. Szmidt" <ams@gnu.org>
> CC: emacs-devel@gnu.org
> Date: Mon, 05 Apr 2010 09:34:59 -0400
>
> > When I start emacs with -nw, it segfaults, if I run with -Q it
> > segfaults in a different place,
>
> Does this still happen with current bzr, and after you make a clean
> bootstrap? If so, could you please post a backtrace from the
> segfault you get in "emacs -Q"?
>
> Tried a clean bootstrap today, still get the segfault with -nw -Q:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x081692bd in mark_object (arg=-7552029) at alloc.c:5595
> 5595 if (XMISCANY (obj)->gcmarkbit)
> (gdb) bt full
> #0 0x081692bd in mark_object (arg=-7552029) at alloc.c:5595
> obj = -7552029
> cdr_count = <value optimized out>
Thanks. It's different from what I see, but given that this seems to
be a Heisenbug (it disappears in a non-optimized build), perhaps it is
not surprising.
Can you see if this is the first GC since startup? It is for me: if
I set a breakpoint in Fgarbage_collect, it breaks only once, and if I
let Emacs continue from there, it crashes in a subroutine of GC.
Also, do you get the crash in a non-optimized (-O0) build? It's hard
to do anything with all those "value optimized out" variables.
If a non-optimized build does not crash, the only way I know of to
find out which data structure is invalid is by stepping with GDB
through a non-optimized build, trying to match the frames and local
variables that do appear in the backtrace of the crashed Emacs, and
compare the values between the optimized and non-optimized builds to
see what got corrupted.
In my case, I found so far that one of the submaps of
Buffer-menu-mode-map is corrupted (a NULL pointer):
#2 0x01068682 in mark_char_table (ptr=0x2fee200) at alloc.c:5393
5393 mark_char_table (XVECTOR (val));
(gdb) p *ptr
$33 = {
size = 3222274066,
next = 0x2ff3000,
contents = {4}
}
(gdb) p ptr->contents[0]
$34 = 4
(gdb) p size
$35 = 18
(gdb) p ptr->contents[1]
$36 = 0
(gdb) p ptr->contents[2]
$37 = 50252549
(gdb) xtype
Lisp_Vectorlike
PVEC_SUB_CHAR_TABLE
(gdb) xvector
$38 = (struct Lisp_Vector *) 0x0 <<<<<<<<<<<<<<<<
Cannot access memory at address 0x0 <<<<<<<<<<<<<<<<
(gdb)
whereas in a non-optimized build, the same submap seems to be okay:
#1 0x0102b3f0 in mark_char_table (ptr=0x3019200) at alloc.c:5393
5393 mark_char_table (XVECTOR (val));
(gdb) p size
$31 = 18
(gdb) p i
$32 = 2
(gdb) p ptr->contents[0]
$33 = 4
(gdb) p ptr->contents[1]
$34 = 0
(gdb) p ptr->contents[2]
$35 = 50404101
(gdb) xtype
Lisp_Vectorlike
PVEC_SUB_CHAR_TABLE
(gdb) xvector
$36 = (struct Lisp_Vector *) 0x3011b00
0
(gdb) p *$36
$37 = {
size = 3222274082,
next = 0x3019200,
contents = {8}
}
(gdb)
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-05 9:04 ` Eli Zaretskii
2010-04-05 13:34 ` Alfred M. Szmidt
2010-04-05 13:52 ` Stefan Monnier
@ 2010-04-05 14:11 ` Chong Yidong
2010-04-05 14:19 ` Eli Zaretskii
2010-04-16 14:18 ` Juanma Barranquero
3 siblings, 1 reply; 57+ messages in thread
From: Chong Yidong @ 2010-04-05 14:11 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: ams, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> I think I see a similar problem on MS-Windows, and I'd like to compare
> the backtraces we see. The segfault only happens for me in an
> optimized build, btw. It seems to happen when GC tries to mark the
> value of Buffer-menu-mode-map.
If you can easily reproduce the problem, maybe the easiest approach is
to try to bisect.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-05 13:52 ` Stefan Monnier
@ 2010-04-05 14:17 ` Eli Zaretskii
2010-04-05 20:00 ` Sean Sieger
2010-04-06 18:49 ` Andreas Schwab
0 siblings, 2 replies; 57+ messages in thread
From: Eli Zaretskii @ 2010-04-05 14:17 UTC (permalink / raw)
To: Stefan Monnier; +Cc: ams, emacs-devel
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: ams@gnu.org, emacs-devel@gnu.org
> Date: Mon, 05 Apr 2010 09:52:43 -0400
>
> > I think I see a similar problem on MS-Windows, and I'd like to compare
> > the backtraces we see. The segfault only happens for me in an
> > optimized build, btw. It seems to happen when GC tries to mark the
> > value of Buffer-menu-mode-map.
> > I cannot reproduce the segfault on GNU/Linux.
>
> I think I've seen the same crash on my GNU/Linux system. But I've had
> difficulty reproducing it (it was in an unusal situation and I can't
> quite remember what I did to get there).
It's very elusive; it even managed to defeat "bzr bisect". I
eventually bisected manually, and it looks like my bidi merge is the
culprit, although it beats me how that could happen, given the
evidence I posted, and given that the bidi code is not even called
once between startup and the crash. Perhaps my merge rearranged
memory and somehow awoke this sleeping dog. Or maybe I'm missing
something.
I posted some details of what I succeeded to find out; any ideas about
how to proceed are welcome.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-05 14:11 ` Chong Yidong
@ 2010-04-05 14:19 ` Eli Zaretskii
0 siblings, 0 replies; 57+ messages in thread
From: Eli Zaretskii @ 2010-04-05 14:19 UTC (permalink / raw)
To: Chong Yidong; +Cc: ams, emacs-devel
> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: ams@gnu.org, emacs-devel@gnu.org
> Date: Mon, 05 Apr 2010 10:11:28 -0400
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > I think I see a similar problem on MS-Windows, and I'd like to compare
> > the backtraces we see. The segfault only happens for me in an
> > optimized build, btw. It seems to happen when GC tries to mark the
> > value of Buffer-menu-mode-map.
>
> If you can easily reproduce the problem, maybe the easiest approach is
> to try to bisect.
Tried that; see my other mail.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-05 14:06 ` Eli Zaretskii
@ 2010-04-05 15:03 ` Alfred M. Szmidt
2010-04-05 15:24 ` Eli Zaretskii
2010-04-05 16:49 ` Eli Zaretskii
1 sibling, 1 reply; 57+ messages in thread
From: Alfred M. Szmidt @ 2010-04-05 15:03 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Thanks. It's different from what I see, but given that this seems to
be a Heisenbug (it disappears in a non-optimized build), perhaps it is
not surprising.
Can you see if this is the first GC since startup? It is for me: if
I set a breakpoint in Fgarbage_collect, it breaks only once, and if I
let Emacs continue from there, it crashes in a subroutine of GC.
Also, do you get the crash in a non-optimized (-O0) build? It's hard
to do anything with all those "value optimized out" variables.
Yeah I do, I'll see if I can get some time to make a patch. Here is
the backtrace of -Q -nw compiled with -ggdb3 -O0:
Program received signal SIGSEGV, Segmentation fault.
0x081a9af5 in mem_insert (start=0x8632398, end=0x86323b0, type=MEM_TYPE_VECTORLIKE) at alloc.c:3557
3557 c = start < c->start ? c->left : c->right;
(gdb) bt full
#0 0x081a9af5 in mem_insert (start=0x8632398, end=0x86323b0, type=MEM_TYPE_VECTORLIKE) at alloc.c:3557
c = 0x3
parent = 0x3
x = 0x4
#1 0x081a7942 in lisp_malloc (nbytes=24, type=MEM_TYPE_VECTORLIKE) at alloc.c:872
val = 0x8632398
#2 0x081a905f in allocate_vectorlike (len=4) at alloc.c:2927
p = 0x854fe40
nbytes = 24
#3 0x081a90c7 in allocate_vector (nslots=4) at alloc.c:2953
v = 0x854fe40
#4 0x081a925d in Fmake_vector (length=3, init=139319498) at alloc.c:3037
vector = 139787845
sizei = 4
index = 4
p = 0x4
#5 0x081ca166 in concat (nargs=2, args=0xbfffd9b8, target_type=Lisp_Vectorlike, last_special=0) at fns.c:616
val = 139787845
tail = 139319498
this = 140750630
toindex = 4
toindex_byte = 0
result_len = 4
result_len_byte = 4
argnum = 2
last_tail = 139319498
prev = 139319498
some_multibyte = 0
textprops = 0x0
num_textprops = 0
sa_count = 16
sa_must_free = 0
#6 0x081c9bb6 in Fvconcat (nargs=2, args=0xbfffd9b8) at fns.c:455
No locals.
#7 0x08158532 in append_key (key_sequence=140356685, key=139719522) at keymap.c:1444
args = {140356685, 140750630}
#8 0x081598f2 in accessible_keymaps_1 (key=139719522, cmd=140383118, args=139319498, data=0xbfffdb00) at keymap.c:2192
d = 0xbfffdb00
maps = 141379494
tail = 140750190
thisseq = 140356685
is_metized = 0
tem = 139319498
#9 0x08156c1c in map_keymap_item (fun=0x8159702 <accessible_keymaps_1>, args=139319498, key=139719522, val=140425550, data=0xbfffdb00) at keymap.c:649
No locals.
#10 0x08156d35 in map_keymap_internal (map=140428622, fun=0x8159702 <accessible_keymaps_1>, args=139319498, data=0xbfffdb00) at keymap.c:687
binding = 140425182
gcpro1 = {next = 0x2, var = 0x84e4e22, nvars = -1073751368}
gcpro2 = {next = 0x855ca3e, var = 0x84e4e22, nvars = 139319498}
gcpro3 = {next = 0xbfffda98, var = 0x81a90c7, nvars = 0}
tail = 140425174
#11 0x08156ed4 in map_keymap (map=140428622, fun=0x8159702 <accessible_keymaps_1>, args=139319498, data=0xbfffdb00, autoload=0) at keymap.c:734
gcpro1 = {next = 0x1, var = 0x1, nvars = 3}
#12 0x08159ca6 in Faccessible_keymaps (keymap=139312462, prefix=139319498) at keymap.c:2283
data = {maps = 141384662, tail = 140750190, thisseq = 140356685, is_metized = 0}
thismap = 140428622
last = 8
maps = 141384662
tail = 140750190
prefixlen = 0
#13 0x0815a8e0 in where_is_internal (definition=139689282, keymaps=140495598, noindirect=0, nomenus=0) at keymap.c:2738
maps = 140495614
found = 140495590
data = {definition = 1, this = 4, last = 135619172, last_is_meta = 139319498, noindirect = -1073750880, sequences = -1073751080}
#14 0x0815ad24 in Fwhere_is_internal (definition=139689282, keymap=139852222, firstonly=139319498, noindirect=139319498, no_remap=139319498) at keymap.c:2881
keymaps = 140495598
sequences = 139319498
found = 139319498
nomenus = 0
gcpro1 = {next = 0xbfffdc88, var = 0x81583b6, nvars = 139312462}
gcpro2 = {next = 0x1, var = 0x8158247, nvars = 1}
gcpro3 = {next = 0x1, var = 0x84e4d92, nvars = 139852222}
gcpro4 = {next = 0x855f9ae, var = 0x84dd8ca, nvars = 139852214}
gcpro5 = {next = 0x8676010, var = 0x855f9be, nvars = 2}
remapped_sequences = 139319498
remapped = 0
tem = 135619172
#15 0x081c5753 in Ffuncall (nargs=3, args=0xbfffdd60) at eval.c:3038
fun = 136678997
original_fun = 139350282
funcar = 0
numargs = 2
lisp_numargs = 140563389
val = 139852222
backtrace = {next = 0xbfffdfd0, function = 0xbfffdd60, args = 0xbfffdd64, nargs = 2, evalargs = 0 '\000', debug_on_exit = 0 '\000'}
internal_args = 0xbfffdca0
i = 139319498
#16 0x08205e1a in Fbyte_code (bytestr=137646377, vector=137646397, maxdepth=40) at bytecode.c:680
count = 15
op = 2
vectorp = 0x8345140
bytestr_length = 345
stack = {pc = 0x8371bc8 "\034\311\312\313\"\035\311\312\314\"\036*\r\315=?\205%", top = 0xbfffdd68, bottom = 0xbfffdd60, byte_string = 137646377,
byte_string_start = 0x8371bb9 "\b\204\006", constants = 137646397, next = 0xbfffe1a0}
top = 0xbfffdd60
result = 139319498
#17 0x081c5df1 in funcall_lambda (fun=137646293, nargs=6, arg_vector=0xbfffe034) at eval.c:3211
val = 139319498
syms_left = 139319498
next = 139689594
count = 10
i = 6
optional = 1
rest = 1
#18 0x081c58b5 in Ffuncall (nargs=7, args=0xbfffe030) at eval.c:3070
fun = 137646293
original_fun = 140125042
funcar = 135954334
numargs = 6
lisp_numargs = 16
val = 139319498
backtrace = {next = 0xbfffe100, function = 0xbfffe030, args = 0xbfffe034, nargs = 6, evalargs = 0 '\000', debug_on_exit = 0 '\000'}
internal_args = 0x84dd8ca
i = 6
#19 0x081c4e45 in Fapply (nargs=6, args=0xbfffe164) at eval.c:2503
ret_ungc_val = 135984404
i = 7
numargs = 6
spread_arg = 139319498
funcall_args = 0xbfffe030
fun = 137646293
gcpro1 = {next = 0x81ca18a, var = 0x3, nvars = 7}
#20 0x081c55c4 in Ffuncall (nargs=7, args=0xbfffe160) at eval.c:3005
fun = 138315245
original_fun = 139428634
funcar = 139587714
numargs = 6
lisp_numargs = 0
val = 141834630
backtrace = {next = 0xbfffe3c0, function = 0xbfffe160, args = 0xbfffe164, nargs = 6, evalargs = 0 '\000', debug_on_exit = 0 '\000'}
internal_args = 0x2
i = -1073748956
#21 0x08205e1a in Fbyte_code (bytestr=137646153, vector=137646173, maxdepth=28) at bytecode.c:680
count = 10
op = 6
vectorp = 0x8345060
bytestr_length = 12
stack = {pc = 0x8371d31 "\207", top = 0xbfffe178, bottom = 0xbfffe160, byte_string = 137646153, byte_string_start =
0x8371d26 "\304\305\b\t\306\307!\n\v&\006\207", constants = 137646173, next = 0xbfffe460}
top = 0xbfffe160
result = 139319498
#22 0x081c5df1 in funcall_lambda (fun=137646077, nargs=5, arg_vector=0xbfffe424) at eval.c:3211
val = 139319498
syms_left = 139319498
next = 139689594
count = 6
i = 5
optional = 1
rest = 1
#23 0x081c58b5 in Ffuncall (nargs=6, args=0xbfffe420) at eval.c:3070
fun = 137646077
original_fun = 140125018
funcar = 135982840
numargs = 5
lisp_numargs = 0
val = 139319498
backtrace = {next = 0xbfffe680, function = 0xbfffe420, args = 0xbfffe424, nargs = 5, evalargs = 0 '\000', debug_on_exit = 0 '\000'}
internal_args = 0x0
i = -1073748252
#24 0x08205e1a in Fbyte_code (bytestr=137646873, vector=137646893, maxdepth=24) at bytecode.c:680
count = 6
op = 5
vectorp = 0x8345330
bytestr_length = 105
stack = {pc =
0x8371b7a "\210\302\326\b\327\"\330\315\316\331%\210\302\326\b\332\"\333\"\210\302\326\b\334\"\335\315\316\336%\210\302\337\340\"\210\302\341\342\"\210\343\301!\031\344\345\346\211\347\350%\210\344\351\352\353\347\354%)\207", top = 0xbfffe434, bottom = 0xbfffe420, byte_string = 137646873, byte_string_start =
0x8371b4f "\302\303\304\"\210\302\305\306\"\210\302\307\310\"\210\302\311\312\"\210\302\313\314\315\316\317%\210\302\320\321\315\316\322%\210\302\323\324\315\316\325%\210\302\326\b\327\"\330\315\316\331%\210\302\326\b\332\"\333\"\210\302\326\b\334\"\335\315\316\336%\210\302\337\340\"\210\302\341\342\"\210\343\301!\031\344\345\346\211\347\350%\210\344\351\352\353\347\354%)\207", constants = 137646893, next = 0xbfffe710}
top = 0xbfffe420
result = 141895462
#25 0x081c5df1 in funcall_lambda (fun=137646853, nargs=0, arg_vector=0xbfffe6e4) at eval.c:3211
val = 141895462
syms_left = 139319498
next = -1073748440
count = 6
i = 0
optional = 0
rest = 0
#26 0x081c58b5 in Ffuncall (nargs=1, args=0xbfffe6e0) at eval.c:3070
fun = 137646853
original_fun = 140091290
funcar = 0
numargs = 0
lisp_numargs = 139319498
val = 141834630
backtrace = {next = 0xbfffe930, function = 0xbfffe6e0, args = 0xbfffe6e4, nargs = 0, evalargs = 0 '\000', debug_on_exit = 0 '\000'}
internal_args = 0x0
i = -1073747564
#27 0x08205e1a in Fbyte_code (bytestr=137644633, vector=137644653, maxdepth=16) at bytecode.c:680
count = 5
op = 0
vectorp = 0x8344a70
bytestr_length = 128
stack = {pc = 0x8371f48 "\210\202J", top = 0xbfffe6e0, bottom = 0xbfffe6e0, byte_string = 137644633, byte_string_start =
0x8371f09 "\303 \030\t\304=\203\016", constants = 137644653, next = 0xbfffe9d0}
top = 0xbfffe6e0
result = 141589224
#28 0x081c5df1 in funcall_lambda (fun=137644589, nargs=1, arg_vector=0xbfffe994) at eval.c:3211
val = 139319498
syms_left = 139319498
next = 139735962
count = 4
i = 1
optional = 1
rest = 0
#29 0x081c58b5 in Ffuncall (nargs=2, args=0xbfffe990) at eval.c:3070
fun = 137644589
original_fun = 140091266
funcar = 135982840
numargs = 1
lisp_numargs = 2
val = 139319498
backtrace = {next = 0xbfffebf0, function = 0xbfffe990, args = 0xbfffe994, nargs = 1, evalargs = 0 '\000', debug_on_exit = 0 '\000'}
internal_args = 0x0
i = 112
#30 0x08205e1a in Fbyte_code (bytestr=136981529, vector=136981549, maxdepth=28) at bytecode.c:680
count = 4
op = 1
vectorp = 0x82a2c30
bytestr_length = 1665
stack = {pc = 0x83c26a5 "\210\201\230", top = 0xbfffe994, bottom = 0xbfffe990, byte_string = 136981529, byte_string_start =
0x83c23fb "\306 \020\307\021\n\023\307\024\310\311!\211\035\307=\204\064", constants = 136981549, next = 0xbfffec90}
top = 0xbfffe990
result = 139576473
#31 0x081c5df1 in funcall_lambda (fun=136981509, nargs=0, arg_vector=0xbfffec54) at eval.c:3211
val = 139576473
syms_left = 139319498
next = 139571722
count = 4
i = 0
optional = 0
rest = 0
#32 0x081c58b5 in Ffuncall (nargs=1, args=0xbfffec50) at eval.c:3070
fun = 136981509
original_fun = 140134050
funcar = 135982840
numargs = 0
lisp_numargs = 0
val = 220
backtrace = {next = 0xbfffef58, function = 0xbfffec50, args = 0xbfffec54, nargs = 0, evalargs = 0 '\000', debug_on_exit = 0 '\000'}
internal_args = 0x0
i = 48
#33 0x08205e1a in Fbyte_code (bytestr=136978457, vector=136978477, maxdepth=24) at bytecode.c:680
count = 2
op = 0
vectorp = 0x82a2030
bytestr_length = 220
stack = {pc = 0x83c31a7 "\210*\340\341\342\"\210\343\321\344\"\211\036$;\203\251", top = 0xbfffec50, bottom = 0xbfffec50, byte_string = 136978457,
byte_string_start = 0x83c3119 "\b\203\b", constants = 136978477, next = 0x0}
top = 0xbfffec50
result = 29
#34 0x081c5df1 in funcall_lambda (fun=136978437, nargs=0, arg_vector=0xbfffee70) at eval.c:3211
val = 4096
syms_left = 139319498
next = 30
count = 2
i = 0
optional = 0
rest = 0
#35 0x081c5aae in apply_lambda (fun=136978437, args=139319498, eval_flag=1) at eval.c:3135
args_left = 139319498
numargs = 0
arg_vector = 0xbfffee70
gcpro1 = {next = 0x0, var = 0x8719128, nvars = 0}
gcpro2 = {next = 0xb8273c, var = 0xbfffef20, nvars = 10390076}
gcpro3 = {next = 0xbfffef3c, var = 0x9d2d28, nvars = -1073746132}
i = 0
tem = -1073744432
#36 0x081c4a98 in Feval (form=139560030) at eval.c:2388
fun = 136978437
val = 0
original_fun = 140244746
original_args = 139319498
funcar = 0
backtrace = {next = 0x0, function = 0xbfffef70, args = 0xbfffee70, nargs = 0, evalargs = 0 '\000', debug_on_exit = 0 '\000'}
gcpro1 = {next = 0x0, var = 0x0, nvars = 0}
gcpro2 = {next = 0x9e34d8, var = 0x0, nvars = 0}
gcpro3 = {next = 0x85dd628, var = 0x814c620, nvars = 0}
#37 0x0814387d in top_level_2 () at keyboard.c:1365
No locals.
#38 0x081c3388 in internal_condition_case (bfun=0x814386a <top_level_2>, handlers=139357474, hfun=0x81434d8 <cmd_error>) at eval.c:1490
val = 0
c = {tag = 139319498, val = 139319498, next = 0xbffff108, gcpro = 0x0, jmp = {{__jmpbuf = {-1073744432, -1073744572, -1073745164, -1073745720, -304938895,
711649054}, __mask_was_saved = 0, __saved_mask = {__val = {134538479, 3086895784, 2, 10322301, 134536708, 3086912756, 10387396, 130431436, 27, 3221221276,
10300233, 0, 429496729, 140367400, 500, 131928052, 130856801, 131935260, 3221221172, 139242848, 139242976, 3221221812, 3221221672, 135654657, 2, 3221221684,
3221221520, 0, 0, 0, 0, 0}}}}, backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, poll_suppress_count = 1, interrupt_input_blocked = 0,
byte_stack = 0x0}
h = {handler = 139357474, var = 139319498, chosen_clause = 130591995, tag = 0xbfffeff4, next = 0x0}
#39 0x081438b4 in top_level_1 () at keyboard.c:1373
No locals.
#40 0x081c2e6a in internal_catch (tag=139354546, func=0x814387f <top_level_1>, arg=139319498) at eval.c:1226
c = {tag = 139354546, val = 139319498, next = 0x0, gcpro = 0x0, jmp = {{__jmpbuf = {-1073744432, -1073744572, -1073745164, -1073745448, -303218575,
709891870}, __mask_was_saved = 0, __saved_mask = {__val = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 130880286, 0, 0, 0, 130880286, 0, 0, 131933112, 0, 0, 139484843,
3221221848, 135984067, 139486890, 139484843, 139319498, 139345360, 140955060, 136637276, 14, 22, 0}}}}, backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0,
pdlcount = 2, poll_suppress_count = 1, interrupt_input_blocked = 0, byte_stack = 0x0}
#41 0x081437ed in command_loop () at keyboard.c:1328
No locals.
#42 0x081430f7 in recursive_edit_1 () at keyboard.c:950
count = 1
val = 134884005
#43 0x08143262 in Frecursive_edit () at keyboard.c:1012
count = 0
buffer = 139319498
#44 0x08141a62 in main (argc=3, argv=0xbffff674) at emacs.c:1784
dummy = -1073744688
stack_bottom_variable = 0 '\000'
do_initial_setlocale = 1
skip_args = 1
rlim = {rlim_cur = 10485760, rlim_max = 18446744073709551615}
no_loadup = 0
junk = 0x0
dname_arg = 0x0
(gdb)
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-05 15:03 ` Alfred M. Szmidt
@ 2010-04-05 15:24 ` Eli Zaretskii
2010-04-06 21:08 ` Alfred M. Szmidt
0 siblings, 1 reply; 57+ messages in thread
From: Eli Zaretskii @ 2010-04-05 15:24 UTC (permalink / raw)
To: ams; +Cc: emacs-devel
> From: "Alfred M. Szmidt" <ams@gnu.org>
> CC: emacs-devel@gnu.org
> Date: Mon, 05 Apr 2010 11:03:20 -0400
>
> Thanks. It's different from what I see, but given that this seems to
> be a Heisenbug (it disappears in a non-optimized build), perhaps it is
> not surprising.
>
> Can you see if this is the first GC since startup? It is for me: if
> I set a breakpoint in Fgarbage_collect, it breaks only once, and if I
> let Emacs continue from there, it crashes in a subroutine of GC.
>
> Also, do you get the crash in a non-optimized (-O0) build? It's hard
> to do anything with all those "value optimized out" variables.
>
> Yeah I do, I'll see if I can get some time to make a patch. Here is
> the backtrace of -Q -nw compiled with -ggdb3 -O0:
Thanks. But where's the Lisp backtrace (xbacktrace)? Is this also
during startup, or did you manage to invoke some command after it
started? It looks like it crashed inside where-is, not in GC.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-05 14:06 ` Eli Zaretskii
2010-04-05 15:03 ` Alfred M. Szmidt
@ 2010-04-05 16:49 ` Eli Zaretskii
2010-04-05 16:59 ` Juri Linkov
1 sibling, 1 reply; 57+ messages in thread
From: Eli Zaretskii @ 2010-04-05 16:49 UTC (permalink / raw)
To: ams, emacs-devel
> Date: Mon, 05 Apr 2010 17:06:41 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
>
> In my case, I found so far that one of the submaps of
> Buffer-menu-mode-map is corrupted (a NULL pointer):
>
> #2 0x01068682 in mark_char_table (ptr=0x2fee200) at alloc.c:5393
> 5393 mark_char_table (XVECTOR (val));
> (gdb) p *ptr
> $33 = {
> size = 3222274066,
> next = 0x2ff3000,
> contents = {4}
> }
> (gdb) p ptr->contents[0]
> $34 = 4
> (gdb) p size
> $35 = 18
> (gdb) p ptr->contents[1]
> $36 = 0
> (gdb) p ptr->contents[2]
> $37 = 50252549
> (gdb) xtype
> Lisp_Vectorlike
> PVEC_SUB_CHAR_TABLE
> (gdb) xvector
> $38 = (struct Lisp_Vector *) 0x0 <<<<<<<<<<<<<<<<
> Cannot access memory at address 0x0 <<<<<<<<<<<<<<<<
> (gdb)
That was incorrect, sorry. Here is a more accurate account:
#2 0x01068682 in mark_char_table (ptr=0x2fee200) at alloc.c:5393
5393 mark_char_table (XVECTOR (val));
(gdb) p val
$29 = 0
(gdb) down
#1 0x01068649 in mark_char_table (ptr=0x2fecb00) at alloc.c:5396
5396 mark_object (val);
(gdb) p size
$30 = 34
(gdb) p i
$31 = 8
(gdb) p *ptr->contents@34
$32 = {8, 0, 50277381, 46032898, 46032898, 46032898, 46032898, 46024706,
46032898 <repeats 26 times>}
(gdb) p ptr->contents[7]
$33 = 46024706
(gdb) p *$33
$34 = 702
(gdb) xtype
Lisp_Cons
(gdb) xcons
$35 = (struct Lisp_Cons *) 0x2b8 <<<<<<<<<<<<<<<<
Cannot access memory at address 0x2b8 <<<<<<<<<<<<<<<<
(gdb) p ptr->contents[6]
$36 = 46032898
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$37 = (struct Lisp_Symbol *) 0x2be6800
"nil"
So 46032898 is nil, but what is the mysterious 46024706? Observe:
(gdb) p/x 46032898
$41 = 0x2be6802
(gdb) p/x 46024706
$42 = 0x2be4802
So 46024706 is nil with one of its bits reset! What does it mean? A
bad memory chip in my computer?
In the "good" session (unoptimized build), btw, the contents of the
same char-table is dandy:
#0 mark_char_table (ptr=0x3011b00) at alloc.c:5388
5388 if (INTEGERP (val) || SYMBOLP (val) && XSYMBOL(val)->gcmarkbit)
(gdb) p val
$56 = 46221314
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$57 = (struct Lisp_Symbol *) 0x2c14800
"nil"
(gdb) p size
$58 = 34
(gdb) p *ptr->contents@34
$59 = {8, 0, 50483205, 46221314 <repeats 31 times>}
46221314 is nil, as you see above.
Ideas?
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-05 16:49 ` Eli Zaretskii
@ 2010-04-05 16:59 ` Juri Linkov
2010-04-05 21:39 ` Eli Zaretskii
0 siblings, 1 reply; 57+ messages in thread
From: Juri Linkov @ 2010-04-05 16:59 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: ams, emacs-devel
> So 46024706 is nil with one of its bits reset! What does it mean? A
> bad memory chip in my computer?
Did you run `M-x butterfly' before that?
--
Juri Linkov
http://www.jurta.org/emacs/
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-03 22:12 ` Juri Linkov
2010-04-03 23:56 ` Ken Hori
2010-04-04 8:10 ` Jan Djärv
@ 2010-04-05 17:22 ` Dan Nicolaescu
2010-04-14 15:05 ` Randal L. Schwartz
3 siblings, 0 replies; 57+ messages in thread
From: Dan Nicolaescu @ 2010-04-05 17:22 UTC (permalink / raw)
To: Juri Linkov; +Cc: ams, emacs-devel
Juri Linkov <juri@jurta.org> writes:
>> ./configure --with-x-toolkit=lucid
>> works
>>
>> ./configure
>> [i.e. using Gtk]
>> segfaults
>>
>> on Fedora12.
>
> I tried ./configure using Gtk on Debian and Ubuntu,
> and no segfaults with -nw.
>
> Maybe it's Fedora specific?
It might be a problem with the way I use
bzr revert -rVERSION
to reproduce this.
I cannot reproduce is with the trunk now...
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-05 14:17 ` Eli Zaretskii
@ 2010-04-05 20:00 ` Sean Sieger
2010-04-05 21:49 ` Eli Zaretskii
2010-04-06 18:49 ` Andreas Schwab
1 sibling, 1 reply; 57+ messages in thread
From: Sean Sieger @ 2010-04-05 20:00 UTC (permalink / raw)
To: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> I think I've seen the same crash on my GNU/Linux system. But I've had
> difficulty reproducing it (it was in an unusal situation and I can't
> quite remember what I did to get there).
It's very elusive
Um, I hadn't done much more than started GNU Emacs 24.0.50.3
(i686-pc-linux-gnu, GTK+ Version 2.18.3) of 2010-03-30 on g41r2f1 and
Gnus, went to Firefox and when I was done with a mail noticed Emacs was
... gone! I've been screwing around on the MS Windows partition and so
haven't used Emacs in GNU/Linux much lately.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-05 16:59 ` Juri Linkov
@ 2010-04-05 21:39 ` Eli Zaretskii
2010-04-06 0:41 ` Stefan Monnier
0 siblings, 1 reply; 57+ messages in thread
From: Eli Zaretskii @ 2010-04-05 21:39 UTC (permalink / raw)
To: Juri Linkov; +Cc: ams, emacs-devel
> From: Juri Linkov <juri@jurta.org>
> Cc: ams@gnu.org, emacs-devel@gnu.org
> Date: Mon, 05 Apr 2010 19:59:36 +0300
>
> > So 46024706 is nil with one of its bits reset! What does it mean? A
> > bad memory chip in my computer?
>
> Did you run `M-x butterfly' before that?
I wish I did.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-05 20:00 ` Sean Sieger
@ 2010-04-05 21:49 ` Eli Zaretskii
0 siblings, 0 replies; 57+ messages in thread
From: Eli Zaretskii @ 2010-04-05 21:49 UTC (permalink / raw)
To: Sean Sieger; +Cc: emacs-devel
> From: Sean Sieger <sean.sieger@gmail.com>
> Date: Mon, 05 Apr 2010 16:00:40 -0400
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > I think I've seen the same crash on my GNU/Linux system. But I've had
> > difficulty reproducing it (it was in an unusal situation and I can't
> > quite remember what I did to get there).
>
> It's very elusive
>
> Um, I hadn't done much more than started GNU Emacs 24.0.50.3
> (i686-pc-linux-gnu, GTK+ Version 2.18.3) of 2010-03-30 on g41r2f1 and
> Gnus, went to Firefox and when I was done with a mail noticed Emacs was
> ... gone!
Consider running it under GDB and posting the backtrace here when it
crashes.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-05 21:39 ` Eli Zaretskii
@ 2010-04-06 0:41 ` Stefan Monnier
0 siblings, 0 replies; 57+ messages in thread
From: Stefan Monnier @ 2010-04-06 0:41 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Juri Linkov, ams, emacs-devel
>> > So 46024706 is nil with one of its bits reset! What does it mean? A
>> > bad memory chip in my computer?
>> Did you run `M-x butterfly' before that?
> I wish I did.
!? You didn't !?!?
No wonder we're in this mess now!
Stefan
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-05 14:17 ` Eli Zaretskii
2010-04-05 20:00 ` Sean Sieger
@ 2010-04-06 18:49 ` Andreas Schwab
2010-04-07 3:25 ` Eli Zaretskii
1 sibling, 1 reply; 57+ messages in thread
From: Andreas Schwab @ 2010-04-06 18:49 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: ams, Stefan Monnier, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> I posted some details of what I succeeded to find out; any ideas about
> how to proceed are welcome.
Have you tried --enable-checking?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-05 15:24 ` Eli Zaretskii
@ 2010-04-06 21:08 ` Alfred M. Szmidt
2010-04-07 3:06 ` Eli Zaretskii
0 siblings, 1 reply; 57+ messages in thread
From: Alfred M. Szmidt @ 2010-04-06 21:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Thanks. But where's the Lisp backtrace (xbacktrace)? Is this also
during startup, or did you manage to invoke some command after it
started? It looks like it crashed inside where-is, not in GC.
That would be correct, here is the lisp backtrace:
(gdb) xbacktrace
"where-is-internal" (0xbfffdd64)
"tool-bar-local-item-from-menu" (0xbfffe034)
"apply" (0xbfffe164)
"tool-bar-add-item-from-menu" (0xbfffe424)
"tool-bar-setup" (0xbfffe6e4)
"tool-bar-mode" (0xbfffe994)
"command-line" (0xbfffec54)
"normal-top-level" (0xbfffee70)
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-06 21:08 ` Alfred M. Szmidt
@ 2010-04-07 3:06 ` Eli Zaretskii
2010-04-08 20:03 ` Alfred M. Szmidt
0 siblings, 1 reply; 57+ messages in thread
From: Eli Zaretskii @ 2010-04-07 3:06 UTC (permalink / raw)
To: ams; +Cc: emacs-devel
> From: "Alfred M. Szmidt" <ams@gnu.org>
> CC: emacs-devel@gnu.org
> Date: Tue, 06 Apr 2010 17:08:29 -0400
>
> Thanks. But where's the Lisp backtrace (xbacktrace)? Is this also
> during startup, or did you manage to invoke some command after it
> started? It looks like it crashed inside where-is, not in GC.
>
> That would be correct, here is the lisp backtrace:
>
> (gdb) xbacktrace
> "where-is-internal" (0xbfffdd64)
> "tool-bar-local-item-from-menu" (0xbfffe034)
> "apply" (0xbfffe164)
> "tool-bar-add-item-from-menu" (0xbfffe424)
> "tool-bar-setup" (0xbfffe6e4)
> "tool-bar-mode" (0xbfffe994)
> "command-line" (0xbfffec54)
> "normal-top-level" (0xbfffee70)
??? How come tool-bar functions are called in a non-GUI session?
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-06 18:49 ` Andreas Schwab
@ 2010-04-07 3:25 ` Eli Zaretskii
2010-04-07 3:57 ` Stefan Monnier
0 siblings, 1 reply; 57+ messages in thread
From: Eli Zaretskii @ 2010-04-07 3:25 UTC (permalink / raw)
To: Andreas Schwab; +Cc: ams, monnier, emacs-devel
> From: Andreas Schwab <schwab@linux-m68k.org>
> Date: Tue, 06 Apr 2010 20:49:44 +0200
> Cc: ams@gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > I posted some details of what I succeeded to find out; any ideas about
> > how to proceed are welcome.
>
> Have you tried --enable-checking?
No. Does it really work? I got the impression that it tends to crash
without good reasons, because it makes invalid assumptions in several
assertions.
Or am I confused?
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-07 3:25 ` Eli Zaretskii
@ 2010-04-07 3:57 ` Stefan Monnier
2010-04-07 5:35 ` Eli Zaretskii
0 siblings, 1 reply; 57+ messages in thread
From: Stefan Monnier @ 2010-04-07 3:57 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: ams, Andreas Schwab, emacs-devel
> No. Does it really work? I got the impression that it tends to crash
> without good reasons, because it makes invalid assumptions in several
> assertions.
It does at times, yes. But note that I always build and run my Emacs
with ENABLE_CHECKING, so those crashes are really not that common (I
usually fix and/or report them when I bump into one).
Stefan
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-07 3:57 ` Stefan Monnier
@ 2010-04-07 5:35 ` Eli Zaretskii
2010-04-07 11:11 ` Juanma Barranquero
2010-04-09 11:10 ` Eli Zaretskii
0 siblings, 2 replies; 57+ messages in thread
From: Eli Zaretskii @ 2010-04-07 5:35 UTC (permalink / raw)
To: Stefan Monnier; +Cc: ams, schwab, emacs-devel
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Andreas Schwab <schwab@linux-m68k.org>, ams@gnu.org, emacs-devel@gnu.org
> Date: Tue, 06 Apr 2010 23:57:06 -0400
>
> > No. Does it really work? I got the impression that it tends to crash
> > without good reasons, because it makes invalid assumptions in several
> > assertions.
>
> It does at times, yes. But note that I always build and run my Emacs
> with ENABLE_CHECKING, so those crashes are really not that common (I
> usually fix and/or report them when I bump into one).
OK, I will try that, then. Thanks.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-07 5:35 ` Eli Zaretskii
@ 2010-04-07 11:11 ` Juanma Barranquero
2010-04-09 11:10 ` Eli Zaretskii
1 sibling, 0 replies; 57+ messages in thread
From: Juanma Barranquero @ 2010-04-07 11:11 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: ams, schwab, Stefan Monnier, emacs-devel
On Wed, Apr 7, 2010 at 07:35, Eli Zaretskii <eliz@gnu.org> wrote:
> OK, I will try that, then. Thanks.
FWIW, I always build Emacs with -DENABLE_CHECKING, and most times an
assertion triggered, it was a real bug (a couple of times the
assertion was making invalid assumptions, but then, that's something
to fix too).
Juanma
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-07 3:06 ` Eli Zaretskii
@ 2010-04-08 20:03 ` Alfred M. Szmidt
0 siblings, 0 replies; 57+ messages in thread
From: Alfred M. Szmidt @ 2010-04-08 20:03 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
> (gdb) xbacktrace
> "where-is-internal" (0xbfffdd64)
> "tool-bar-local-item-from-menu" (0xbfffe034)
> "apply" (0xbfffe164)
> "tool-bar-add-item-from-menu" (0xbfffe424)
> "tool-bar-setup" (0xbfffe6e4)
> "tool-bar-mode" (0xbfffe994)
> "command-line" (0xbfffec54)
> "normal-top-level" (0xbfffee70)
??? How come tool-bar functions are called in a non-GUI session?
Non-GUI sessions could have tool-bar support, so it isn't harmful to
call tool-bar-mode; very much like scroll-bar-mode is also called for
non-GUI sessions.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-07 5:35 ` Eli Zaretskii
2010-04-07 11:11 ` Juanma Barranquero
@ 2010-04-09 11:10 ` Eli Zaretskii
2010-04-10 1:25 ` Stefan Monnier
1 sibling, 1 reply; 57+ messages in thread
From: Eli Zaretskii @ 2010-04-09 11:10 UTC (permalink / raw)
To: monnier, ams, schwab, emacs-devel
> From: Eli Zaretskii <eliz@gnu.org>
> Date: Wed, 07 Apr 2010 01:35:19 -0400
> Cc: ams@gnu.org, schwab@linux-m68k.org, emacs-devel@gnu.org
>
> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > Cc: Andreas Schwab <schwab@linux-m68k.org>, ams@gnu.org, emacs-devel@gnu.org
> > Date: Tue, 06 Apr 2010 23:57:06 -0400
> >
> > > No. Does it really work? I got the impression that it tends to crash
> > > without good reasons, because it makes invalid assumptions in several
> > > assertions.
> >
> > It does at times, yes. But note that I always build and run my Emacs
> > with ENABLE_CHECKING, so those crashes are really not that common (I
> > usually fix and/or report them when I bump into one).
>
> OK, I will try that, then. Thanks.
One more question: do you recommend to enable all the checks
(i.e. --enable-checking=all), or just some of them? If the latter,
which checks to enable?
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-09 11:10 ` Eli Zaretskii
@ 2010-04-10 1:25 ` Stefan Monnier
0 siblings, 0 replies; 57+ messages in thread
From: Stefan Monnier @ 2010-04-10 1:25 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: ams, schwab, emacs-devel
> One more question: do you recommend to enable all the checks
> (i.e. --enable-checking=all), or just some of them? If the latter,
> which checks to enable?
I use -DENABLE_CHECKING.
Stefan
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-03 22:12 ` Juri Linkov
` (2 preceding siblings ...)
2010-04-05 17:22 ` Dan Nicolaescu
@ 2010-04-14 15:05 ` Randal L. Schwartz
2010-04-18 2:35 ` Randal L. Schwartz
3 siblings, 1 reply; 57+ messages in thread
From: Randal L. Schwartz @ 2010-04-14 15:05 UTC (permalink / raw)
To: emacs-devel
>>>>> "Juri" == Juri Linkov <juri@jurta.org> writes:
>> ./configure --with-x-toolkit=lucid
>> works
>>
>> ./configure
>> [i.e. using Gtk]
>> segfaults
>>
>> on Fedora12.
Juri> I tried ./configure using Gtk on Debian and Ubuntu,
Juri> and no segfaults with -nw.
Juri> Maybe it's Fedora specific?
I normally don't start emacs from the command line on OSX (I normally
use the nextstep interface). But apparently, emacs -Q is crashing for
me as well. If I get some time later today, I'll try bisecting.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-02 19:02 emacs from head segfaults when run with -nw Alfred M. Szmidt
2010-04-02 20:49 ` Dan Nicolaescu
2010-04-05 9:04 ` Eli Zaretskii
@ 2010-04-16 8:26 ` Sascha Wilde
2010-04-16 21:01 ` Eli Zaretskii
2 siblings, 1 reply; 57+ messages in thread
From: Sascha Wilde @ 2010-04-16 8:26 UTC (permalink / raw)
To: ams; +Cc: emacs-devel
"Alfred M. Szmidt" <ams@gnu.org> wrote:
> When I start emacs with -nw, it segfaults, if I run with -Q it
> segfaults in a different place,
[...]
> But without -nw it works expecdetly in X11.
>
> This is with -nw, and no -Q:
For the record: I experience the same problem. Since about start of
April Emacs from trunk segfaults on me regularly sometimes instantly
sometimes after some minutes of use.
As I'm using -nw most of the time (working on a remote system) this
renders HEAD useless to me so I build from 23.1 release sources
yesterday (on the very same system) and it seems to run stable.
This seems to be another indication, that the problem actually lies
within the current source... :-/
cheers
sascha
--
Sascha Wilde : "Der Nicht-Denkende glaubt, dass niemand denkt,
: der Denkende weiss es!"
: (Gabriel Laub)
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-05 9:04 ` Eli Zaretskii
` (2 preceding siblings ...)
2010-04-05 14:11 ` Chong Yidong
@ 2010-04-16 14:18 ` Juanma Barranquero
2010-04-16 21:06 ` Eli Zaretskii
3 siblings, 1 reply; 57+ messages in thread
From: Juanma Barranquero @ 2010-04-16 14:18 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: ams, emacs-devel
On Mon, Apr 5, 2010 at 11:04, Eli Zaretskii <eliz@gnu.org> wrote:
> I think I see a similar problem on MS-Windows, and I'd like to compare
> the backtraces we see. The segfault only happens for me in an
> optimized build, btw. It seems to happen when GC tries to mark the
> value of Buffer-menu-mode-map.
I get this with -Q -nw even on non-optimized builds.
Juanma
alloc.c:5576: Emacs fatal error: assertion failed: STRINGP(ptr->xname)
Breakpoint 1, w32_abort () at w32fns.c:7349
7349 button = MessageBox (NULL,
(gdb) bt
#0 w32_abort () at w32fns.c:7349
#1 0x0104b85c in die (msg=0x15489a0 "assertion failed:
STRINGP(ptr->xname)", file=0x1546d38 "alloc.c", line=5576) at
alloc.c:6250
#2 0x01049fed in mark_object (arg=49829890) at alloc.c:5576
#3 0x0104988d in mark_char_table (ptr=0x3394e00) at alloc.c:5396
#4 0x01049880 in mark_char_table (ptr=0x3382f00) at alloc.c:5393
#5 0x01049880 in mark_char_table (ptr=0x3391e00) at alloc.c:5393
#6 0x01049f0a in mark_object (arg=54074885) at alloc.c:5558
#7 0x01049fa7 in mark_object (arg=54030674) at alloc.c:5572
#8 0x010496e0 in mark_vectorlike (ptr=0x2f88000) at alloc.c:5368
#9 0x01049f48 in mark_object (arg=49840133) at alloc.c:5560
#10 0x0104892f in Fgarbage_collect () at alloc.c:5083
#11 0x0103c0cd in Ffuncall (nargs=2, args=0x88f640) at eval.c:2958
#12 0x011ef458 in Fbyte_code (bytestr=20502681, vector=20503613,
maxdepth=28) at bytecode.c:680
#13 0x0103d67c in funcall_lambda (fun=20502661, nargs=0,
arg_vector=0x88f904) at eval.c:3211
#14 0x0103ce9c in Ffuncall (nargs=1, args=0x88f900) at eval.c:3070
#15 0x011ef458 in Fbyte_code (bytestr=20498769, vector=20498989,
maxdepth=24) at bytecode.c:680
#16 0x0103d67c in funcall_lambda (fun=20498749, nargs=0,
arg_vector=0x88fb20) at eval.c:3211
#17 0x0103d0c3 in apply_lambda (fun=20498749, args=49838082,
eval_flag=1) at eval.c:3135
#18 0x0103aff0 in Feval (form=50108990) at eval.c:2388
#19 0x01006ee8 in top_level_2 () at keyboard.c:1365
#20 0x010389aa in internal_condition_case (bfun=0x1006ed5
<top_level_2>, handlers=49894618, hfun=0x10069e5 <cmd_error>) at
eval.c:1490
#21 0x01006f1f in top_level_1 () at keyboard.c:1373
#22 0x0103842c in internal_catch (tag=49893810, func=0x1006eea
<top_level_1>, arg=49838082) at eval.c:1226
#23 0x01006e58 in command_loop () at keyboard.c:1328
#24 0x010060f0 in recursive_edit_1 () at keyboard.c:950
#25 0x0100660b in Frecursive_edit () at keyboard.c:1012
#26 0x01002a95 in main (argc=3, argv=0xcb2bd0) at emacs.c:1784
(gdb)
Lisp Backtrace:
"command-line" (0x88f904)
"normal-top-level" (0x88fb20)
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-16 8:26 ` Sascha Wilde
@ 2010-04-16 21:01 ` Eli Zaretskii
2010-04-17 10:28 ` Sascha Wilde
0 siblings, 1 reply; 57+ messages in thread
From: Eli Zaretskii @ 2010-04-16 21:01 UTC (permalink / raw)
To: Sascha Wilde; +Cc: ams, emacs-devel
> From: Sascha Wilde <wilde@sha-bang.de>
> Date: Fri, 16 Apr 2010 10:26:09 +0200
> Cc: emacs-devel@gnu.org
>
> "Alfred M. Szmidt" <ams@gnu.org> wrote:
>
> > When I start emacs with -nw, it segfaults, if I run with -Q it
> > segfaults in a different place,
> [...]
> > But without -nw it works expecdetly in X11.
> >
> > This is with -nw, and no -Q:
>
> For the record: I experience the same problem. Since about start of
> April Emacs from trunk segfaults on me regularly sometimes instantly
> sometimes after some minutes of use.
Is your backtrace similar to Alfred's? Can you show it?
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-16 14:18 ` Juanma Barranquero
@ 2010-04-16 21:06 ` Eli Zaretskii
2010-04-16 23:18 ` Juanma Barranquero
0 siblings, 1 reply; 57+ messages in thread
From: Eli Zaretskii @ 2010-04-16 21:06 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: ams, emacs-devel
> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 16 Apr 2010 16:18:50 +0200
> Cc: ams@gnu.org, emacs-devel@gnu.org
>
> I get this with -Q -nw even on non-optimized builds.
>
> Juanma
>
>
> alloc.c:5576: Emacs fatal error: assertion failed: STRINGP(ptr->xname)
>
> Breakpoint 1, w32_abort () at w32fns.c:7349
> 7349 button = MessageBox (NULL,
> (gdb) bt
> #0 w32_abort () at w32fns.c:7349
> #1 0x0104b85c in die (msg=0x15489a0 "assertion failed:
> STRINGP(ptr->xname)", file=0x1546d38 "alloc.c", line=5576) at
> alloc.c:6250
> #2 0x01049fed in mark_object (arg=49829890) at alloc.c:5576
What is ptr->xname in frame #2?
> #3 0x0104988d in mark_char_table (ptr=0x3394e00) at alloc.c:5396
> #4 0x01049880 in mark_char_table (ptr=0x3382f00) at alloc.c:5393
> #5 0x01049880 in mark_char_table (ptr=0x3391e00) at alloc.c:5393
Can you find out which char-table is being marked here?
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-16 21:06 ` Eli Zaretskii
@ 2010-04-16 23:18 ` Juanma Barranquero
2010-04-17 7:55 ` Eli Zaretskii
0 siblings, 1 reply; 57+ messages in thread
From: Juanma Barranquero @ 2010-04-16 23:18 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: ams, emacs-devel
On Fri, Apr 16, 2010 at 23:06, Eli Zaretskii <eliz@gnu.org> wrote:
> What is ptr->xname in frame #2?
(gdb) frame 2
#2 0x01049fed in mark_object (arg=49829890) at alloc.c:5576
5576 if (!PURE_POINTER_P (XSTRING (ptr->xname)))
(gdb) p *ptr
$1 = {
gcmarkbit = 1,
indirect_variable = 0,
constant = 0,
interned = 0,
xname = 0,
value = 0,
function = 0,
plist = 0,
next = 0x0
}
> Can you find out which char-table is being marked here?
How can I do that?
Juanma
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-16 23:18 ` Juanma Barranquero
@ 2010-04-17 7:55 ` Eli Zaretskii
2010-04-17 16:19 ` Juanma Barranquero
0 siblings, 1 reply; 57+ messages in thread
From: Eli Zaretskii @ 2010-04-17 7:55 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: ams, emacs-devel
> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sat, 17 Apr 2010 01:18:16 +0200
> Cc: ams@gnu.org, emacs-devel@gnu.org
>
> On Fri, Apr 16, 2010 at 23:06, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > What is ptr->xname in frame #2?
>
> (gdb) frame 2
> #2 0x01049fed in mark_object (arg=49829890) at alloc.c:5576
> 5576 if (!PURE_POINTER_P (XSTRING (ptr->xname)))
> (gdb) p *ptr
> $1 = {
> gcmarkbit = 1,
> indirect_variable = 0,
> constant = 0,
> interned = 0,
> xname = 0,
> value = 0,
> function = 0,
> plist = 0,
> next = 0x0
> }
So ptr->xname is NULL. This is the same problem I see on my system.
> > Can you find out which char-table is being marked here?
>
> How can I do that?
You go up the call stack printing the objects that are being marked,
until you find one that is a symbol with a meaningful name. (Be
careful not to use `pp' or `pr', because in a crashed Emacs session
they can cause a SIGSEGV and mess up the GDB session.)
Here's what I did in this case:
(gdb) bt 20
#0 mark_object (arg=20065856) at alloc.c:5577
#1 0x01068769 in mark_char_table (ptr=0x2fdbb00) at alloc.c:5396
#2 0x010687a2 in mark_char_table (ptr=0x2fe2200) at alloc.c:5393
#3 0x010687a2 in mark_char_table (ptr=0x2fe6000) at alloc.c:5393
#4 0x01067e89 in mark_object (arg=20065856) at alloc.c:5685
#5 0x01067f92 in mark_object (arg=20065856) at alloc.c:5572
#6 0x010687e3 in mark_vectorlike (ptr=0x2be8000) at alloc.c:5368
#7 0x01069517 in Fgarbage_collect () at alloc.c:5083
#8 0x0100c37b in Ffuncall (nargs=2, args=0x82ef60) at eval.c:2958
#9 0x0111f346 in Fbyte_code (bytestr=0, vector=8580960, maxdepth=1)
at bytecode.c:680
#10 0x0100bfc2 in funcall_lambda (fun=18630341, nargs=4, arg_vector=0x82f0d4)
at eval.c:3211
#11 0x0100c3a6 in Ffuncall (nargs=5, args=0x11c46c5) at eval.c:3081
#12 0x0111f346 in Fbyte_code (bytestr=0, vector=8581328, maxdepth=4)
at bytecode.c:680
#13 0x0100bfc2 in funcall_lambda (fun=18640949, nargs=2, arg_vector=0x82f244)
at eval.c:3211
#14 0x0100c3a6 in Ffuncall (nargs=3, args=0x11c7035) at eval.c:3081
#15 0x0111f346 in Fbyte_code (bytestr=0, vector=8581696, maxdepth=2)
at bytecode.c:680
#16 0x0100bfc2 in funcall_lambda (fun=18641317, nargs=2, arg_vector=0x82f3b4)
at eval.c:3211
#17 0x0100c3a6 in Ffuncall (nargs=3, args=0x11c71a5) at eval.c:3081
#18 0x0111f346 in Fbyte_code (bytestr=0, vector=8582064, maxdepth=2)
at bytecode.c:680
#19 0x0100bb95 in Feval (form=20091344) at eval.c:2352
(More stack frames follow...)
Lisp Backtrace:
"set-face-attribute" (0x82f0d4)
"face-spec-reset-face" (0x82f244)
"face-spec-recalc" (0x82f3b4)
"byte-code" (0x82f490)
"face-set-after-frame-default" (0x82f754)
"frame-notice-user-settings" (0x82f8d4)
"byte-code" (0x82f9c0)
"normal-top-level" (0x82fc00)
(gdb) frame 4
#4 0x01067e89 in mark_object (arg=20065856) at alloc.c:5685
5685 mark_object (ptr->car);
(gdb) p *ptr
$7 = {
car = 50225157,
u = {
cdr = 47281638,
chain = 0x2d175e6
}
}
(gdb) p ptr->car
$8 = 50225157
(gdb) xtype
Lisp_Vectorlike
PVEC_CHAR_TABLE
(gdb) xchartable
$9 = (struct Lisp_Char_Table *) 0x2fe6000
Purpose: "keymap" 0 extra slots <<<<<<<<<<<<<<<<<<<
(gdb) up
#5 0x01067f92 in mark_object (arg=20065856) at alloc.c:5572
5572 mark_object (ptr->value);
(gdb) p *ptr
$10 = {
gcmarkbit = 1,
indirect_variable = 0,
constant = 0,
interned = 2,
xname = 19319113,
value = 47281342,
function = 46037018,
plist = 47277422,
next = 0x2f67ad0
}
(gdb) p ptr->xname
$11 = 19319113
(gdb) xtype
Lisp_String
(gdb) xstring
$12 = (struct Lisp_String *) 0x126c948
"Buffer-menu-mode-map" <<<<<<<<<<<<<<<<<<<<<<<<<<
The two lines marked with "<<<<<<<<<<<<<<" tell me that the char-table
belongs to Buffer-menu-mode-map which is a keymap.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-16 21:01 ` Eli Zaretskii
@ 2010-04-17 10:28 ` Sascha Wilde
2010-04-17 12:39 ` Eli Zaretskii
0 siblings, 1 reply; 57+ messages in thread
From: Sascha Wilde @ 2010-04-17 10:28 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: ams, emacs-devel
Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Sascha Wilde <wilde@sha-bang.de>
>> Date: Fri, 16 Apr 2010 10:26:09 +0200
>> Cc: emacs-devel@gnu.org
>>
>> "Alfred M. Szmidt" <ams@gnu.org> wrote:
>>
>> > When I start emacs with -nw, it segfaults, if I run with -Q it
>> > segfaults in a different place,
>> [...]
>> > But without -nw it works expecdetly in X11.
>> >
>> > This is with -nw, and no -Q:
>>
>> For the record: I experience the same problem. Since about start of
>> April Emacs from trunk segfaults on me regularly sometimes instantly
>> sometimes after some minutes of use.
>
> Is your backtrace similar to Alfred's? Can you show it?
I think it looks quite alike, but I haven't done a not optimized build
yet. Here is what I have anyway:
Program received signal SIGSEGV, Segmentation fault.
0x08177b13 in mark_object (arg=-1) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5695
5695 FLOAT_MARK (XFLOAT (obj));
(gdb) bt
#0 0x08177b13 in mark_object (arg=-1)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5695
#1 0x08177a8e in mark_object (arg=171118298)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5574
#2 0x08177f9f in mark_vectorlike (ptr=0xa351998)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5368
#3 0x08177a83 in mark_object (arg=141516934)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5573
#4 0x08177a78 in mark_object (arg=171285954)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5572
#5 0x08177f9f in mark_vectorlike (ptr=0x86d3b30)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5368
#6 0x08177a83 in mark_object (arg=140104546)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5573
#7 0x0817796a in mark_object (arg=140039334)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5685
#8 0x0817796a in mark_object (arg=139792318)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5685
#9 0x08177a78 in mark_object (arg=141516422)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5572
#10 0x08177a78 in mark_object (arg=139995414)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5572
#11 0x0817796a in mark_object (arg=139274966)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5685
#12 0x08177a8e in mark_object (arg=139058530)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5574
#13 0x0817796a in mark_object (arg=139267526)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5685
#14 0x0817796a in mark_object (arg=139267454)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5685
#15 0x08177a8e in mark_object (arg=139443802)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5574
#16 0x0817796a in mark_object (arg=139266246)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5685
---Type <return> to continue, or q <return> to quit---
Quit
(gdb) xbacktrace
"require" (0xbff3a0f4)
"byte-code" (0xbff3a1c4)
"require" (0xbff3a4d4)
"byte-code" (0xbff3a594)
"c-mode" (0xbff3a874)
"set-auto-mode-0" (0xbff3a9e4)
"set-auto-mode" (0xbff3aae0)
"normal-mode" (0xbff3ae34)
"after-find-file" (0xbff3afb4)
"find-file-noselect-1" (0xbff3b124)
"find-file-noselect" (0xbff3b2a4)
"find-file" (0xbff3b424)
"call-interactively" (0xbff3b674)
(gdb) p obj
$1 = <value optimized out>
If it helps I can make an unoptimized build and send more complete
debugging output...
cheers
sascha
--
Sascha Wilde : VI is to EMACS as masturbation is to making love:
: effective and always available but probably not your
: first choice...
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-17 10:28 ` Sascha Wilde
@ 2010-04-17 12:39 ` Eli Zaretskii
2010-04-17 18:49 ` Sascha Wilde
0 siblings, 1 reply; 57+ messages in thread
From: Eli Zaretskii @ 2010-04-17 12:39 UTC (permalink / raw)
To: Sascha Wilde; +Cc: ams, emacs-devel
> From: Sascha Wilde <wilde@sha-bang.de>
> Cc: ams@gnu.org, emacs-devel@gnu.org
> Date: Sat, 17 Apr 2010 12:28:36 +0200
>
> > Is your backtrace similar to Alfred's? Can you show it?
>
> I think it looks quite alike, but I haven't done a not optimized build
> yet. Here is what I have anyway:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x08177b13 in mark_object (arg=-1) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5695
> 5695 FLOAT_MARK (XFLOAT (obj));
> (gdb) bt
> #0 0x08177b13 in mark_object (arg=-1)
> at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5695
Thanks. Can you show more of the backtrace? I'd like to see if we
are marking a char-table here.
> If it helps I can make an unoptimized build and send more complete
> debugging output...
It would certainly help, if the unoptimized build crashes as well.
TIA
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-17 7:55 ` Eli Zaretskii
@ 2010-04-17 16:19 ` Juanma Barranquero
2010-04-17 16:37 ` Eli Zaretskii
0 siblings, 1 reply; 57+ messages in thread
From: Juanma Barranquero @ 2010-04-17 16:19 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: ams, emacs-devel
On Sat, Apr 17, 2010 at 09:55, Eli Zaretskii <eliz@gnu.org> wrote:
> You go up the call stack printing the objects that are being marked,
> until you find one that is a symbol with a meaningful name.
See attached log.
Juanma
(gdb) bt
#0 w32_abort () at w32fns.c:7349
#1 0x0104b85c in die (msg=0x15489a0 "assertion failed:
STRINGP(ptr->xname)", file=0x1546d38 "alloc.c", line=5576) at
alloc.c:6250
#2 0x01049fed in mark_object (arg=49829890) at alloc.c:5576
#3 0x0104988d in mark_char_table (ptr=0x3394e00) at alloc.c:5396
#4 0x01049880 in mark_char_table (ptr=0x3382f00) at alloc.c:5393
#5 0x01049880 in mark_char_table (ptr=0x3391e00) at alloc.c:5393
#6 0x01049f0a in mark_object (arg=54074885) at alloc.c:5558
#7 0x01049fa7 in mark_object (arg=54030674) at alloc.c:5572
#8 0x010496e0 in mark_vectorlike (ptr=0x2f88000) at alloc.c:5368
#9 0x01049f48 in mark_object (arg=49840133) at alloc.c:5560
#10 0x0104892f in Fgarbage_collect () at alloc.c:5083
#11 0x0103c0cd in Ffuncall (nargs=2, args=0x88f640) at eval.c:2958
#12 0x011ef458 in Fbyte_code (bytestr=20502681, vector=20503613,
maxdepth=28) at bytecode.c:680
#13 0x0103d67c in funcall_lambda (fun=20502661, nargs=0,
arg_vector=0x88f904) at eval.c:3211
#14 0x0103ce9c in Ffuncall (nargs=1, args=0x88f900) at eval.c:3070
#15 0x011ef458 in Fbyte_code (bytestr=20498769, vector=20498989,
maxdepth=24) at bytecode.c:680
#16 0x0103d67c in funcall_lambda (fun=20498749, nargs=0,
arg_vector=0x88fb20) at eval.c:3211
#17 0x0103d0c3 in apply_lambda (fun=20498749, args=49838082,
eval_flag=1) at eval.c:3135
#18 0x0103aff0 in Feval (form=50108990) at eval.c:2388
#19 0x01006ee8 in top_level_2 () at keyboard.c:1365
#20 0x010389aa in internal_condition_case (bfun=0x1006ed5
<top_level_2>, handlers=49894618, hfun=0x10069e5 <cmd_error>) at
eval.c:1490
#21 0x01006f1f in top_level_1 () at keyboard.c:1373
#22 0x0103842c in internal_catch (tag=49893810, func=0x1006eea
<top_level_1>, arg=49838082) at eval.c:1226
#23 0x01006e58 in command_loop () at keyboard.c:1328
#24 0x010060f0 in recursive_edit_1 () at keyboard.c:950
#25 0x0100660b in Frecursive_edit () at keyboard.c:1012
#26 0x01002a95 in main (argc=3, argv=0x992bd0) at emacs.c:1784
Lisp Backtrace:
"command-line" (0x88f904)
"normal-top-level" (0x88fb20)
(gdb) frame 6
#6 0x01049f0a in mark_object (arg=54074885) at alloc.c:5558
5558 mark_char_table (XVECTOR (obj));
(gdb) p obj
$1 = 54074885
(gdb) xtype
Lisp_Vectorlike
PVEC_CHAR_TABLE
(gdb) xchartable
$2 = (struct Lisp_Char_Table *) 0x3391e00
Purpose: "nil" 0 extra slots
(gdb) up
#7 0x01049fa7 in mark_object (arg=54030674) at alloc.c:5572
5572 mark_object (ptr->value);
(gdb) p ptr
$3 = (struct Lisp_Symbol *) 0x3387150
(gdb) p ptr->value
$4 = 54074885
(gdb) xtype
Lisp_Vectorlike
PVEC_CHAR_TABLE
(gdb) xchartable
$5 = (struct Lisp_Char_Table *) 0x3391e00
Purpose: "nil" 0 extra slots
(gdb) up
#8 0x010496e0 in mark_vectorlike (ptr=0x2f88000) at alloc.c:5368
5368 mark_object (ptr->contents[i]);
(gdb) p ptr
$6 = (struct Lisp_Vector *) 0x2f88000
(gdb) p ptr->contents[i]
$7 = 54030674
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$8 = (struct Lisp_Symbol *) 0x3387150
"fill-nospace-between-words-table"
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-17 16:19 ` Juanma Barranquero
@ 2010-04-17 16:37 ` Eli Zaretskii
2010-04-17 19:12 ` Juanma Barranquero
0 siblings, 1 reply; 57+ messages in thread
From: Eli Zaretskii @ 2010-04-17 16:37 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: ams, emacs-devel
> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sat, 17 Apr 2010 18:19:16 +0200
> Cc: ams@gnu.org, emacs-devel@gnu.org
>
> On Sat, Apr 17, 2010 at 09:55, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > You go up the call stack printing the objects that are being marked,
> > until you find one that is a symbol with a meaningful name.
>
> See attached log.
Thanks.
> #8 0x010496e0 in mark_vectorlike (ptr=0x2f88000) at alloc.c:5368
> 5368 mark_object (ptr->contents[i]);
> (gdb) p ptr
> $6 = (struct Lisp_Vector *) 0x2f88000
> (gdb) p ptr->contents[i]
> $7 = 54030674
> (gdb) xtype
> Lisp_Symbol
> (gdb) xsymbol
> $8 = (struct Lisp_Symbol *) 0x3387150
> "fill-nospace-between-words-table"
Could please you go up one more level, and show what is the argument
of mark_object in this frame:
#9 0x01049f48 in mark_object (arg=49840133) at alloc.c:5560
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-17 12:39 ` Eli Zaretskii
@ 2010-04-17 18:49 ` Sascha Wilde
2010-04-19 12:31 ` Eli Zaretskii
0 siblings, 1 reply; 57+ messages in thread
From: Sascha Wilde @ 2010-04-17 18:49 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: ams, emacs-devel
Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Sascha Wilde <wilde@sha-bang.de>
[...]
> Thanks. Can you show more of the backtrace? I'd like to see if we
> are marking a char-table here.
>
>> If it helps I can make an unoptimized build and send more complete
>> debugging output...
>
> It would certainly help, if the unoptimized build crashes as well.
Took me some time to get the segfault, but finally I succeeded... :-)
Ok, here we go:
Program received signal SIGSEGV, Segmentation fault.
mark_object (arg=17) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5464
5464 if (STRING_MARKED_P (ptr))
(gdb) bt
#0 mark_object (arg=17) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5464
#1 0x081c4da8 in mark_object (arg=139549338) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5572
#2 0x081c49bb in mark_vectorlike (ptr=0x854b1a8) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5368
#3 0x081c4d76 in mark_object (arg=173450358) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5560
#4 0x081c4db3 in mark_object (arg=173801986) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5573
#5 0x081c49bb in mark_vectorlike (ptr=0xa6c0fc8) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5368
#6 0x081c4d76 in mark_object (arg=175834341) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5560
#7 0x081c4db3 in mark_object (arg=175000194) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5573
#8 0x081c49bb in mark_vectorlike (ptr=0xa737790) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5368
#9 0x081c4d76 in mark_object (arg=175054693) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5560
#10 0x081c4db3 in mark_object (arg=176956906) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5573
#11 0x081c49bb in mark_vectorlike (ptr=0xa8c6560) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5368
#12 0x081c4d76 in mark_object (arg=176973309) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5560
#13 0x081c4db3 in mark_object (arg=142175186) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5573
#14 0x081c49bb in mark_vectorlike (ptr=0x865c070) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5368
#15 0x081c4d76 in mark_object (arg=173472525) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5560
#16 0x081c4db3 in mark_object (arg=173488954) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5573
#17 0x081c49bb in mark_vectorlike (ptr=0xa574600) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5368
#18 0x081c4d76 in mark_object (arg=141086918) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5560
#19 0x081c4db3 in mark_object (arg=173519426) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5573
#20 0x081c49bb in mark_vectorlike (ptr=0xa5c7450) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5368
#21 0x081c4d76 in mark_object (arg=173831501) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5560
#22 0x081c4db3 in mark_object (arg=173519450) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5573
#23 0x081c5029 in mark_object (arg=142043326) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5685
#24 0x081c5029 in mark_object (arg=142023486) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5685
#25 0x081c4bfa in mark_object (arg=173831733) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5519
#26 0x081c4db3 in mark_object (arg=139712370) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5573
#27 0x081c5029 in mark_object (arg=140596358) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5685
#28 0x081c5029 in mark_object (arg=140578038) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5685
#29 0x081c4da8 in mark_object (arg=142176594) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5572
#30 0x081c49bb in mark_vectorlike (ptr=0x8797888) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5368
#31 0x081c4d76 in mark_object (arg=142178709) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5560
#32 0x081c4db3 in mark_object (arg=140314194) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5573
#33 0x081c49bb in mark_vectorlike (ptr=0x8796130) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5368
#34 0x081c4d76 in mark_object (arg=142172709) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5560
#35 0x081c4db3 in mark_object (arg=140108982) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5573
#36 0x081c5029 in mark_object (arg=140109446) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5685
#37 0x081c5029 in mark_object (arg=140110798) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5685
#38 0x081c4dbe in mark_object (arg=142125562) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5574
#39 0x081c5029 in mark_object (arg=139940478) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5685
#40 0x081c4da8 in mark_object (arg=173821890) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5572
#41 0x081c49bb in mark_vectorlike (ptr=0x86ecf90) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5368
#42 0x081c4d76 in mark_object (arg=141147429) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5560
---Type <return> to continue, or q <return> to quit---
[SNIP -- _many_ rounds in alloc.c and some extra in intervals.c ...]
#1363 0x081c4d76 in mark_object (arg=139427045) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5560
#1364 0x081c42af in Fgarbage_collect () at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5083
#1365 0x081de0c2 in Ffuncall (nargs=2, args=0xbfcfade0) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/eval.c:2958
#1366 0x0821eaea in Fbyte_code (bytestr=173608505, vector=174689573, maxdepth=52)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/bytecode.c:680
#1367 0x081dea91 in funcall_lambda (fun=175015845, nargs=0, arg_vector=0xbfcfb0c4)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/eval.c:3211
#1368 0x081de555 in Ffuncall (nargs=1, args=0xbfcfb0c0) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/eval.c:3070
#1369 0x0821eaea in Fbyte_code (bytestr=174186641, vector=175017085, maxdepth=24)
---Type <return> to continue, or q <return> to quit---
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/bytecode.c:680
#1370 0x081dea91 in funcall_lambda (fun=175017309, nargs=0, arg_vector=0xbfcfb384)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/eval.c:3211
#1371 0x081de555 in Ffuncall (nargs=1, args=0xbfcfb380) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/eval.c:3070
#1372 0x0821eaea in Fbyte_code (bytestr=174239473, vector=174664165, maxdepth=24)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/bytecode.c:680
#1373 0x081dea91 in funcall_lambda (fun=174134565, nargs=3, arg_vector=0xbfcfb644)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/eval.c:3211
#1374 0x081de555 in Ffuncall (nargs=4, args=0xbfcfb640) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/eval.c:3070
#1375 0x0821eaea in Fbyte_code (bytestr=174244001, vector=174040565, maxdepth=16)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/bytecode.c:680
#1376 0x081dea91 in funcall_lambda (fun=174141013, nargs=2, arg_vector=0xbfcfb8f4)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/eval.c:3211
#1377 0x081de555 in Ffuncall (nargs=3, args=0xbfcfb8f0) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/eval.c:3070
#1378 0x0821eaea in Fbyte_code (bytestr=174155265, vector=173650173, maxdepth=24)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/bytecode.c:680
#1379 0x081dea91 in funcall_lambda (fun=174095165, nargs=1, arg_vector=0xbfcfbbb4)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/eval.c:3211
#1380 0x081de555 in Ffuncall (nargs=2, args=0xbfcfbbb0) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/eval.c:3070
#1381 0x0821eaea in Fbyte_code (bytestr=174105665, vector=174030709, maxdepth=12)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/bytecode.c:680
#1382 0x081dd53c in Feval (form=174344094) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/eval.c:2352
#1383 0x081da746 in Fprogn (args=174343070) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/eval.c:415
#1384 0x080b61c1 in Fsave_window_excursion (args=174343070) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/window.c:6563
#1385 0x0821f737 in Fbyte_code (bytestr=174105713, vector=141350829, maxdepth=4)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/bytecode.c:841
#1386 0x081dea91 in funcall_lambda (fun=174130877, nargs=0, arg_vector=0xbfcfc194)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/eval.c:3211
#1387 0x081de555 in Ffuncall (nargs=1, args=0xbfcfc190) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/eval.c:3070
#1388 0x081ddeb9 in apply1 (fn=174553986, arg=139425994) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/eval.c:2765
#1389 0x081d8771 in Fcall_interactively (function=174553986, record_flag=139425994, keys=139460285)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/callint.c:396
#1390 0x081de380 in Ffuncall (nargs=4, args=0xbfcfc460) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/eval.c:3030
#1391 0x081ddf74 in call3 (fn=139546458, arg1=174553986, arg2=139425994, arg3=139425994)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/eval.c:2854
#1392 0x0816ab20 in Fcommand_execute (cmd=174553986, record_flag=139425994, keys=139425994, special=139425994)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/keyboard.c:10345
#1393 0x0815cc9f in command_loop_1 () at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/keyboard.c:1756
#1394 0x081dc028 in internal_condition_case (bfun=0x815c5cb <command_loop_1>, handlers=139463994, hfun=0x815bfa5 <cmd_error>)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/eval.c:1490
#1395 0x0815c321 in command_loop_2 () at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/keyboard.c:1356
#1396 0x081dbb0a in internal_catch (tag=139461066, func=0x815c2fc <command_loop_2>, arg=139425994)
at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/eval.c:1226
---Type <return> to continue, or q <return> to quit---
#1397 0x0815c2da in command_loop () at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/keyboard.c:1335
#1398 0x0815bbc4 in recursive_edit_1 () at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/keyboard.c:950
#1399 0x0815bd2f in Frecursive_edit () at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/keyboard.c:1012
#1400 0x0815a52a in main (argc=3, argv=0xbfcfcc14) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/emacs.c:1784
Lisp Backtrace:
"Info-fontify-node" (0xbfcfb0c4)
"Info-select-node" (0xbfcfb384)
"Info-find-node-2" (0xbfcfb644)
"Info-find-node" (0xbfcfb8f4)
"Info-goto-node" (0xbfcfbbb4)
"byte-code" (0xbfcfbdb4)
"Info-next" (0xbfcfc194)
"call-interactively" (0xbfcfc464)
(gdb) p obj
$1 = 16
(gdb) p *obj
Cannot access memory at address 0x10
cheers
sascha
--
Sascha Wilde : VI is to EMACS as masturbation is to making love:
: effective and always available but probably not your
: first choice...
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-17 16:37 ` Eli Zaretskii
@ 2010-04-17 19:12 ` Juanma Barranquero
2010-04-17 19:18 ` Eli Zaretskii
0 siblings, 1 reply; 57+ messages in thread
From: Juanma Barranquero @ 2010-04-17 19:12 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: ams, emacs-devel
On Sat, Apr 17, 2010 at 18:37, Eli Zaretskii <eliz@gnu.org> wrote:
> Could please you go up one more level, and show what is the argument
> of mark_object in this frame:
>
> #9 0x01049f48 in mark_object (arg=49840133) at alloc.c:5560
(gdb) frame 9
#9 0x01049f48 in mark_object (arg=49840133) at alloc.c:5560
5560 mark_vectorlike (XVECTOR (obj));
(gdb) p obj
$1 = 49840133
(gdb) xtype
Lisp_Vectorlike
1511
(gdb) up
#10 0x0104892f in Fgarbage_collect () at alloc.c:5083
5083 mark_object (*staticvec[i]);
(gdb) p i
$2 = 0
(gdb) p *staticvec[i]
$3 = 49840133
so it is the first object in staticvec[].
Juanma
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-17 19:12 ` Juanma Barranquero
@ 2010-04-17 19:18 ` Eli Zaretskii
2010-04-17 19:20 ` Juanma Barranquero
0 siblings, 1 reply; 57+ messages in thread
From: Eli Zaretskii @ 2010-04-17 19:18 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: ams, emacs-devel
> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sat, 17 Apr 2010 21:12:46 +0200
> Cc: ams@gnu.org, emacs-devel@gnu.org
>
> (gdb) frame 9
> #9 0x01049f48 in mark_object (arg=49840133) at alloc.c:5560
> 5560 mark_vectorlike (XVECTOR (obj));
> (gdb) p obj
> $1 = 49840133
> (gdb) xtype
> Lisp_Vectorlike
> 1511
> (gdb) up
> #10 0x0104892f in Fgarbage_collect () at alloc.c:5083
> 5083 mark_object (*staticvec[i]);
> (gdb) p i
> $2 = 0
> (gdb) p *staticvec[i]
> $3 = 49840133
>
> so it is the first object in staticvec[].
Ah, that's obarray. Thanks.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-17 19:18 ` Eli Zaretskii
@ 2010-04-17 19:20 ` Juanma Barranquero
2010-04-17 21:02 ` Eli Zaretskii
0 siblings, 1 reply; 57+ messages in thread
From: Juanma Barranquero @ 2010-04-17 19:20 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: ams, emacs-devel
On Sat, Apr 17, 2010 at 21:18, Eli Zaretskii <eliz@gnu.org> wrote:
> Ah, that's obarray. Thanks.
Hope that was useful.
Juanma
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-17 19:20 ` Juanma Barranquero
@ 2010-04-17 21:02 ` Eli Zaretskii
0 siblings, 0 replies; 57+ messages in thread
From: Eli Zaretskii @ 2010-04-17 21:02 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: ams, emacs-devel
> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sat, 17 Apr 2010 21:20:16 +0200
> Cc: ams@gnu.org, emacs-devel@gnu.org
>
> On Sat, Apr 17, 2010 at 21:18, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > Ah, that's obarray. Thanks.
>
> Hope that was useful.
It was.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-14 15:05 ` Randal L. Schwartz
@ 2010-04-18 2:35 ` Randal L. Schwartz
2010-04-18 3:05 ` Randal L. Schwartz
0 siblings, 1 reply; 57+ messages in thread
From: Randal L. Schwartz @ 2010-04-18 2:35 UTC (permalink / raw)
To: emacs-devel
>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
Randal> I normally don't start emacs from the command line on OSX (I normally
Randal> use the nextstep interface). But apparently, emacs -Q is crashing for
Randal> me as well. If I get some time later today, I'll try bisecting.
So are we getting closer to solving this? Would more stuff from me
help?
I already have a bug in the bugtracker.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-18 2:35 ` Randal L. Schwartz
@ 2010-04-18 3:05 ` Randal L. Schwartz
0 siblings, 0 replies; 57+ messages in thread
From: Randal L. Schwartz @ 2010-04-18 3:05 UTC (permalink / raw)
To: emacs-devel
>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
Randal> So are we getting closer to solving this? Would more stuff from me
Randal> help?
And for me, it's now solved! Case closed. I can type "emacs -Q" again.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-17 18:49 ` Sascha Wilde
@ 2010-04-19 12:31 ` Eli Zaretskii
2010-04-20 10:30 ` Sascha Wilde
0 siblings, 1 reply; 57+ messages in thread
From: Eli Zaretskii @ 2010-04-19 12:31 UTC (permalink / raw)
To: Sascha Wilde, Juanma Barranquero, ams; +Cc: emacs-devel
> From: Sascha Wilde <wilde@sha-bang.de>
> Date: Sat, 17 Apr 2010 20:49:20 +0200
> Cc: ams@gnu.org, emacs-devel@gnu.org
>
> Eli Zaretskii <eliz@gnu.org> wrote:
> >> From: Sascha Wilde <wilde@sha-bang.de>
> [...]
> > Thanks. Can you show more of the backtrace? I'd like to see if we
> > are marking a char-table here.
> >
> >> If it helps I can make an unoptimized build and send more complete
> >> debugging output...
> >
> > It would certainly help, if the unoptimized build crashes as well.
>
> Took me some time to get the segfault, but finally I succeeded... :-)
> Ok, here we go:
>
> Program received signal SIGSEGV, Segmentation fault.
> mark_object (arg=17) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5464
> 5464 if (STRING_MARKED_P (ptr))
> (gdb) bt
> #0 mark_object (arg=17) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5464
> #1 0x081c4da8 in mark_object (arg=139549338) at /home/wilde/src/stdsrc/emacs/emacs-wilde.hg/src/alloc.c:5572
I think I finally nailed it. Thanks to all who offered ideas and
backtraces, and suffered silently while I was looking for the reason.
And yes, it was my fault :-(
Please try again and see if the crashes are gone now. They are for
me, on MS-Windows.
For the record, here's how I found the culprit:
. Start a new Emacs session under GDB with "start -Q -nw".
. When it stopped at the beginning of `main', compare the contents
of the corrupted entry in the offending char-table between the
crashed and the new sessions. Notice that the value in the new
session was correct (nil). (As I reported earlier, the value at
the same address in the crashed session was like nil, but with one
extra bit set.)
. Put a hardware watchpoint on the value that was corrupted in the
crashed session, and run the newly started session. When the
watchpoint was triggered, GDB had my bug staring at me. The rest,
as they say, is in the history DAG ;-)
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-19 12:31 ` Eli Zaretskii
@ 2010-04-20 10:30 ` Sascha Wilde
2010-04-20 12:03 ` Eli Zaretskii
0 siblings, 1 reply; 57+ messages in thread
From: Sascha Wilde @ 2010-04-20 10:30 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Juanma Barranquero, ams, emacs-devel
Eli Zaretskii <eliz@gnu.org> wrote:
> I think I finally nailed it. Thanks to all who offered ideas and
> backtraces, and suffered silently while I was looking for the reason.
Thanks for the good news. :)
> And yes, it was my fault :-(
>
> Please try again and see if the crashes are gone now. They are for
> me, on MS-Windows.
I'm running a fixed build since yesterday with no crashes, so I'd say it
seems to be solved for me, too.
Again, Many thanks for looking into this!
sascha
--
Sascha Wilde : The sum of intelligence on earth is a constant;
: population is growing
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: emacs from head segfaults when run with -nw
2010-04-20 10:30 ` Sascha Wilde
@ 2010-04-20 12:03 ` Eli Zaretskii
0 siblings, 0 replies; 57+ messages in thread
From: Eli Zaretskii @ 2010-04-20 12:03 UTC (permalink / raw)
To: Sascha Wilde; +Cc: lekktu, ams, emacs-devel
> From: Sascha Wilde <wilde@sha-bang.de>
> Date: Tue, 20 Apr 2010 12:30:16 +0200
> Cc: Juanma Barranquero <lekktu@gmail.com>, ams@gnu.org, emacs-devel@gnu.org
>
> Eli Zaretskii <eliz@gnu.org> wrote:
> > I think I finally nailed it. Thanks to all who offered ideas and
> > backtraces, and suffered silently while I was looking for the reason.
>
> Thanks for the good news. :)
>
> > And yes, it was my fault :-(
> >
> > Please try again and see if the crashes are gone now. They are for
> > me, on MS-Windows.
>
> I'm running a fixed build since yesterday with no crashes, so I'd say it
> seems to be solved for me, too.
Thanks for testing.
^ permalink raw reply [flat|nested] 57+ messages in thread
end of thread, other threads:[~2010-04-20 12:03 UTC | newest]
Thread overview: 57+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-04-02 19:02 emacs from head segfaults when run with -nw Alfred M. Szmidt
2010-04-02 20:49 ` Dan Nicolaescu
2010-04-02 23:07 ` Juri Linkov
2010-04-02 23:48 ` Dan Nicolaescu
2010-04-03 10:42 ` Alfred M. Szmidt
2010-04-03 19:19 ` Dan Nicolaescu
2010-04-03 22:12 ` Juri Linkov
2010-04-03 23:56 ` Ken Hori
2010-04-04 11:06 ` Juri Linkov
2010-04-04 8:10 ` Jan Djärv
2010-04-05 17:22 ` Dan Nicolaescu
2010-04-14 15:05 ` Randal L. Schwartz
2010-04-18 2:35 ` Randal L. Schwartz
2010-04-18 3:05 ` Randal L. Schwartz
2010-04-05 9:04 ` Eli Zaretskii
2010-04-05 13:34 ` Alfred M. Szmidt
2010-04-05 14:06 ` Eli Zaretskii
2010-04-05 15:03 ` Alfred M. Szmidt
2010-04-05 15:24 ` Eli Zaretskii
2010-04-06 21:08 ` Alfred M. Szmidt
2010-04-07 3:06 ` Eli Zaretskii
2010-04-08 20:03 ` Alfred M. Szmidt
2010-04-05 16:49 ` Eli Zaretskii
2010-04-05 16:59 ` Juri Linkov
2010-04-05 21:39 ` Eli Zaretskii
2010-04-06 0:41 ` Stefan Monnier
2010-04-05 13:52 ` Stefan Monnier
2010-04-05 14:17 ` Eli Zaretskii
2010-04-05 20:00 ` Sean Sieger
2010-04-05 21:49 ` Eli Zaretskii
2010-04-06 18:49 ` Andreas Schwab
2010-04-07 3:25 ` Eli Zaretskii
2010-04-07 3:57 ` Stefan Monnier
2010-04-07 5:35 ` Eli Zaretskii
2010-04-07 11:11 ` Juanma Barranquero
2010-04-09 11:10 ` Eli Zaretskii
2010-04-10 1:25 ` Stefan Monnier
2010-04-05 14:11 ` Chong Yidong
2010-04-05 14:19 ` Eli Zaretskii
2010-04-16 14:18 ` Juanma Barranquero
2010-04-16 21:06 ` Eli Zaretskii
2010-04-16 23:18 ` Juanma Barranquero
2010-04-17 7:55 ` Eli Zaretskii
2010-04-17 16:19 ` Juanma Barranquero
2010-04-17 16:37 ` Eli Zaretskii
2010-04-17 19:12 ` Juanma Barranquero
2010-04-17 19:18 ` Eli Zaretskii
2010-04-17 19:20 ` Juanma Barranquero
2010-04-17 21:02 ` Eli Zaretskii
2010-04-16 8:26 ` Sascha Wilde
2010-04-16 21:01 ` Eli Zaretskii
2010-04-17 10:28 ` Sascha Wilde
2010-04-17 12:39 ` Eli Zaretskii
2010-04-17 18:49 ` Sascha Wilde
2010-04-19 12:31 ` Eli Zaretskii
2010-04-20 10:30 ` Sascha Wilde
2010-04-20 12:03 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).