* Recent trunk build crashes a lot under Win32
@ 2008-04-15 11:16 Claus
2008-04-15 11:54 ` Jason Rumney
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: Claus @ 2008-04-15 11:16 UTC (permalink / raw)
To: Emacs Devel
Hi,
recent builds of current Emacs trunk (GNU Emacs 23.0.60.1
(i386-mingw-nt5.1.2600) of 2008-04-14) has been crashing a lot for me
(under Windows Vista SP1). In yesterdays build I get right after
startup upon trying to open any file:
[...]
Loaded symbols for /cygdrive/c/Windows/system32/rasadhlp.dll
Reading symbols from /cygdrive/c/Windows/System32/wshtcpip.dll...done.
Loaded symbols for /cygdrive/c/Windows/System32/wshtcpip.dll
[Switching to thread 540.0x1474]
(gdb) continue
Continuing.
[New thread 540.0x1788]
Error: dll starting at 0x20fc0000 not found.
Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 540.0x1550]
0x0104977b in Fexpand_file_name (name=76847264,
default_directory=33147443) at fileio.c:1402
1402 fileio.c: No such file or directory.
in fileio.c
(gdb)
--------------------------------
Stacktrace:
#0 0x0104977b in Fexpand_file_name (name=76847264,
default_directory=33147443) at fileio.c:1402
#1 0x01049504 in Fexpand_file_name (name=30021747,
default_directory=29622099) at fileio.c:1143
#2 0x0107b9a9 in openp (path=31657349, str=30021747,
suffixes=75109141, storeptr=0x82e9a4, predicate=24815617) at
lread.c:1434
#3 0x0107f290 in Fload (file=30021747, noerror=24815665,
nomessage=24815665, nosuffix=24815617, must_suffix=24815665) at
lread.c:1068
#4 0x0108b910 in Frequire (feature=30569001, filename=24815617,
noerror=24815665) at fns.c:2964
#5 0x0100b383 in Feval (form=74483461) at eval.c:2369
#6 0x0100db89 in Fand (args=74483509) at eval.c:372
#7 0x0100b468 in Feval (form=74483453) at eval.c:2310
#8 0x0100db14 in Fif (args=75109117) at eval.c:395
#9 0x0100b468 in Feval (form=75109125) at eval.c:2310
#10 0x0100b1a4 in Feval (form=74483445) at eval.c:2421
#11 0x0100b66f in Fprogn (args=74483437) at eval.c:451
#12 0x0100b8d9 in funcall_lambda (fun=74481896, nargs=0,
arg_vector=0x82eef0) at eval.c:3212
#13 0x0100b9dc in apply_lambda (fun=74481901, args=24815617,
eval_flag=1) at eval.c:3143
#14 0x0100b0a4 in Feval (form=74449637) at eval.c:2423
#15 0x0100b650 in Fprogn (args=74449541) at eval.c:451
#16 0x0100d924 in Flet (args=74450861) at eval.c:1079
#17 0x0100b468 in Feval (form=74450845) at eval.c:2310
#18 0x0100b66f in Fprogn (args=76123829) at eval.c:451
#19 0x0108ffae in Fsave_current_buffer (args=76123829) at editfns.c:1021
#20 0x0100b468 in Feval (form=76123837) at eval.c:2310
#21 0x0100b1a4 in Feval (form=74450725) at eval.c:2421
#22 0x0100b66f in Fprogn (args=74450669) at eval.c:451
#23 0x0100b8d9 in funcall_lambda (fun=74449792, nargs=0,
arg_vector=0x82f420) at eval.c:3212
#24 0x0100b9dc in apply_lambda (fun=74449797, args=24815617,
eval_flag=1) at eval.c:3143
#25 0x0100b0a4 in Feval (form=74444909) at eval.c:2423
#26 0x0100b650 in Fprogn (args=74444917) at eval.c:451
#27 0x0100b468 in Feval (form=74444901) at eval.c:2310
#28 0x0100c470 in Funwind_protect (args=74445045) at eval.c:1343
#29 0x0100b468 in Feval (form=74444893) at eval.c:2310
#30 0x0100b66f in Fprogn (args=74446821) at eval.c:451
#31 0x0100d924 in Flet (args=74446757) at eval.c:1079
#32 0x0100b468 in Feval (form=74446717) at eval.c:2310
#33 0x0100b650 in Fprogn (args=74446693) at eval.c:451
#34 0x0100b8d9 in funcall_lambda (fun=74445184, nargs=0,
arg_vector=0x82f9f4) at eval.c:3212
#35 0x0100bc54 in Ffuncall (nargs=1, args=0x82f9f0) at eval.c:3089
#36 0x0100d3bc in apply1 (fn=30817449, arg=24815617) at eval.c:2773
#37 0x0110a195 in Fcall_interactively (function=30817449,
record_flag=24815617, keys=24849156) at callint.c:391
#38 0x0100be4e in Ffuncall (nargs=4, args=0x82fbd0) at eval.c:3038
#39 0x0100c026 in call3 (fn=25010177, arg1=30817449, arg2=24815617,
arg3=24815617) at eval.c:2858
#40 0x01056f8e in Fcommand_execute (cmd=30817449,
record_flag=24815617, keys=24815617, special=24815617) at
keyboard.c:10470
#41 0x0105e702 in command_loop_1 () at keyboard.c:1917
#42 0x01009fd5 in internal_condition_case (bfun=0x105e39d
<command_loop_1>, handlers=24879297, hfun=0x1057a01 <cmd_error>) at
eval.c:1501
#43 0x01051baa in command_loop_2 () at keyboard.c:1374
#44 0x01009f0a in internal_catch (tag=24875369, func=0x1051b87
<command_loop_2>, arg=24815617) at eval.c:1237
#45 0x010519b7 in command_loop () at keyboard.c:1353
#46 0x01051a50 in recursive_edit_1 () at keyboard.c:962
#47 0x01051b71 in Frecursive_edit () at keyboard.c:1024
#48 0x01002a6b in main (argc=1, argv=0x2888d60) at emacs.c:1784
Hope someone can make sense out of this. If more information is
necessary, someone let me know how I can provide it.
Thanks,
Claus
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Recent trunk build crashes a lot under Win32 2008-04-15 11:16 Recent trunk build crashes a lot under Win32 Claus @ 2008-04-15 11:54 ` Jason Rumney 2008-04-15 15:18 ` Claus 2008-04-15 15:07 ` Kyle M. Lee 2008-04-15 17:01 ` Stefan Monnier 2 siblings, 1 reply; 10+ messages in thread From: Jason Rumney @ 2008-04-15 11:54 UTC (permalink / raw) To: Claus; +Cc: Emacs Devel Claus wrote: > 0x0104977b in Fexpand_file_name (name=76847264, > default_directory=33147443) at fileio.c:1402 > 1402 fileio.c: No such file or directory. > in fileio.c > Please run emacs under gdb from the src directory so that the source files are picked up. I don't see any way that line 1402 of fileio.c in the current sources could cause a segment violation, so it is likely that the source differs in your environment for whatever reason. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Recent trunk build crashes a lot under Win32 2008-04-15 11:54 ` Jason Rumney @ 2008-04-15 15:18 ` Claus 2008-04-15 16:24 ` Claus 0 siblings, 1 reply; 10+ messages in thread From: Claus @ 2008-04-15 15:18 UTC (permalink / raw) To: Emacs Devel; +Cc: Jason Rumney OK, here we go (the crash-line looks harmless to me, but who knows...): [...] [Switching to thread 4868.0xb0] (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. [Switching to thread 4868.0x1188] 0x0104977b in Fexpand_file_name (name=33140256, default_directory=33147443) at fileio.c:1402 1402 collapse_newdir = 0; (gdb) backtrace #0 0x0104977b in Fexpand_file_name (name=33140256, default_directory=33147443) at fileio.c:1402 #1 0x01049504 in Fexpand_file_name (name=30126771, default_directory=29673395) at fileio.c:1143 #2 0x0107b9a9 in openp (path=39516501, str=30126771, suffixes=76838269, storeptr=0x82e9a4, predicate=24815617) at lread.c:1434 #3 0x0107f290 in Fload (file=30126771, noerror=24815665, nomessage=24815665, nosuffix=24815617, must_suffix=24815665) at lread.c:1068 #4 0x0108b910 in Frequire (feature=30570025, filename=24815617, noerror=24815665) at fns.c:2964 #5 0x0100b383 in Feval (form=74475197) at eval.c:2369 #6 0x0100db89 in Fand (args=74475245) at eval.c:372 #7 0x0100b468 in Feval (form=74475189) at eval.c:2310 #8 0x0100db14 in Fif (args=76838309) at eval.c:395 #9 0x0100b468 in Feval (form=76838301) at eval.c:2310 #10 0x0100b1a4 in Feval (form=74475181) at eval.c:2421 #11 0x0100b66f in Fprogn (args=74475173) at eval.c:451 #12 0x0100b8d9 in funcall_lambda (fun=74473632, nargs=0, arg_vector=0x82eef0) at eval.c:3212 #13 0x0100b9dc in apply_lambda (fun=74473637, args=24815617, eval_flag=1) at eval.c:3143 #14 0x0100b0a4 in Feval (form=74441373) at eval.c:2423 #15 0x0100b650 in Fprogn (args=74441277) at eval.c:451 #16 0x0100d924 in Flet (args=74442597) at eval.c:1079 #17 0x0100b468 in Feval (form=74442581) at eval.c:2310 #18 0x0100b66f in Fprogn (args=74352941) at eval.c:451 #19 0x0108ffae in Fsave_current_buffer (args=74352941) at editfns.c:1021 #20 0x0100b468 in Feval (form=74352853) at eval.c:2310 #21 0x0100b1a4 in Feval (form=74442461) at eval.c:2421 #22 0x0100b66f in Fprogn (args=74442405) at eval.c:451 #23 0x0100b8d9 in funcall_lambda (fun=74441528, nargs=0, arg_vector=0x82f420) at eval.c:3212 #24 0x0100b9dc in apply_lambda (fun=74441533, args=24815617, eval_flag=1) at eval.c:3143 #25 0x0100b0a4 in Feval (form=74436645) at eval.c:2423 #26 0x0100b650 in Fprogn (args=74436653) at eval.c:451 #27 0x0100b468 in Feval (form=74436637) at eval.c:2310 #28 0x0100c470 in Funwind_protect (args=74436781) at eval.c:1343 #29 0x0100b468 in Feval (form=74436629) at eval.c:2310 #30 0x0100b66f in Fprogn (args=74438557) at eval.c:451 #31 0x0100d924 in Flet (args=74438493) at eval.c:1079 #32 0x0100b468 in Feval (form=74438453) at eval.c:2310 #33 0x0100b650 in Fprogn (args=74438429) at eval.c:451 #34 0x0100b8d9 in funcall_lambda (fun=74436920, nargs=0, arg_vector=0x82f9f4) at eval.c:3212 #35 0x0100bc54 in Ffuncall (nargs=1, args=0x82f9f0) at eval.c:3089 #36 0x0100d3bc in apply1 (fn=30817449, arg=24815617) at eval.c:2773 #37 0x0110a195 in Fcall_interactively (function=30817449, record_flag=24815617, keys=24849156) at callint.c:391 #38 0x0100be4e in Ffuncall (nargs=4, args=0x82fbd0) at eval.c:3038 #39 0x0100c026 in call3 (fn=25010177, arg1=30817449, arg2=24815617, arg3=24815617) at eval.c:2858 #40 0x01056f8e in Fcommand_execute (cmd=30817449, record_flag=24815617, keys=24815617, special=24815617) at keyboard.c:10470 #41 0x0105e702 in command_loop_1 () at keyboard.c:1917 #42 0x01009fd5 in internal_condition_case (bfun=0x105e39d <command_loop_1>, handlers=24879297, hfun=0x1057a01 <cmd_error>) at eval.c:1501 #43 0x01051baa in command_loop_2 () at keyboard.c:1374 #44 0x01009f0a in internal_catch (tag=24875369, func=0x1051b87 <command_loop_2>, arg=24815617) at eval.c:1237 #45 0x010519b7 in command_loop () at keyboard.c:1353 #46 0x01051a50 in recursive_edit_1 () at keyboard.c:962 #47 0x01051b71 in Frecursive_edit () at keyboard.c:1024 #48 0x01002a6b in main (argc=1, argv=0xfd8d60) at emacs.c:1784 (gdb) On Tue, Apr 15, 2008 at 1:54 PM, Jason Rumney <jasonr@gnu.org> wrote: > Claus wrote: > > > 0x0104977b in Fexpand_file_name (name=76847264, > > default_directory=33147443) at fileio.c:1402 > > 1402 fileio.c: No such file or directory. > > in fileio.c > > > > > Please run emacs under gdb from the src directory so that the source files > are picked up. > > I don't see any way that line 1402 of fileio.c in the current sources could > cause a segment violation, so it is likely that the source differs in your > environment for whatever reason. > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Recent trunk build crashes a lot under Win32 2008-04-15 15:18 ` Claus @ 2008-04-15 16:24 ` Claus 2008-04-15 22:07 ` Jason Rumney 0 siblings, 1 reply; 10+ messages in thread From: Claus @ 2008-04-15 16:24 UTC (permalink / raw) To: Emacs Devel I tried building again with --no-opt, now it crashes on a different line, again in fileio.c: [New thread 5592.0x159c] Error: dll starting at 0x22720000 not found. warning: reader_thread.SetEvent failed with 6 for fd -1 Program received signal SIGSEGV, Segmentation fault. [Switching to thread 5592.0x112c] 0x0107aecb in Fexpand_file_name (name=25063763, default_directory=32568883) at fileio.c:1468 1468 if (1 (gdb) backtrace #0 0x0107aecb in Fexpand_file_name (name=25063763, default_directory=32568883) at fileio.c:1468 #1 0x0107a88d in Fexpand_file_name (name=29520835, default_directory=29115939) at fileio.c:1143 #2 0x010911c7 in openp (path=39081013, str=29520835, suffixes=73251549, storeptr=0x82e58c, predicate=24332289) at lread.c:1434 #3 0x010903f3 in Fload (file=29520835, noerror=24332337, nomessage=24332337, nosuffix=24332289, must_suffix=24332337) at lread.c:1068 #4 0x010a3ed8 in Frequire (feature=30024233, filename=24332289, noerror=24332337) at fns.c:2964 #5 0x01022103 in Feval (form=71853725) at eval.c:2369 #6 0x0101f0b3 in Fand (args=71853773) at eval.c:372 #7 0x01021ed3 in Feval (form=71853717) at eval.c:2310 #8 0x0101f0ef in Fif (args=73251525) at eval.c:395 #9 0x01021ed3 in Feval (form=73251533) at eval.c:2310 #10 0x01022390 in Feval (form=71853709) at eval.c:2421 #11 0x0101f1e5 in Fprogn (args=71852157) at eval.c:451 #12 0x01023677 in funcall_lambda (fun=71852165, nargs=0, arg_vector=0x82eb60) at eval.c:3212 #13 0x010233ae in apply_lambda (fun=71852165, args=24332289, eval_flag=1) at eval.c:3143 #14 0x010223ba in Feval (form=71819901) at eval.c:2423 #15 0x0101f1e5 in Fprogn (args=71819909) at eval.c:451 #16 0x010202a4 in Flet (args=71821125) at eval.c:1079 #17 0x01021ed3 in Feval (form=71821109) at eval.c:2310 #18 0x0101f1e5 in Fprogn (args=73442485) at eval.c:451 #19 0x010a9896 in Fsave_current_buffer (args=73442525) at editfns.c:1021 #20 0x01021ed3 in Feval (form=73442533) at eval.c:2310 #21 0x01022390 in Feval (form=71820989) at eval.c:2421 #22 0x0101f1e5 in Fprogn (args=71820053) at eval.c:451 #23 0x01023677 in funcall_lambda (fun=71820061, nargs=0, arg_vector=0x82f1a0) at eval.c:3212 #24 0x010233ae in apply_lambda (fun=71820061, args=24332289, eval_flag=1) at eval.c:3143 #25 0x010223ba in Feval (form=71815173) at eval.c:2423 #26 0x0101f1e5 in Fprogn (args=71815181) at eval.c:451 #27 0x01021ed3 in Feval (form=71817189) at eval.c:2310 #28 0x010207bb in Funwind_protect (args=71815309) at eval.c:1343 #29 0x01021ed3 in Feval (form=71817181) at eval.c:2310 #30 0x0101f1e5 in Fprogn (args=71815421) at eval.c:451 #31 0x010202a4 in Flet (args=71817021) at eval.c:1079 #32 0x01021ed3 in Feval (form=71816981) at eval.c:2310 #33 0x0101f1e5 in Fprogn (args=71815429) at eval.c:451 #34 0x01023677 in funcall_lambda (fun=71815453, nargs=0, arg_vector=0x82f8b4) at eval.c:3212 #35 0x01023239 in Ffuncall (nargs=1, args=0x82f8b0) at eval.c:3089 #36 0x01022a65 in apply1 (fn=30290089, arg=24332289) at eval.c:2773 #37 0x0114cd38 in Fcall_interactively (function=30290089, record_flag=24332289, keys=24365828) at callint.c:391 #38 0x01022fd9 in Ffuncall (nargs=4, args=0x82fb10) at eval.c:3038 #39 0x01022b71 in call3 (fn=24526849, arg1=30290089, arg2=24332289, arg3=24332289) at eval.c:2858 #40 0x01014c03 in Fcommand_execute (cmd=30290089, record_flag=24332289, keys=24332289, special=24332289) at keyboard.c:10470 #41 0x010076a6 in command_loop_1 () at keyboard.c:1917 #42 0x01020b0a in internal_condition_case (bfun=0x1006036 <command_loop_1>, handlers=24395969, hfun=0x1005a32 <cmd_error>) at eval.c:1501 #43 0x01005d9b in command_loop_2 () at keyboard.c:1374 #44 0x010205fb in internal_catch (tag=24392041, func=0x1005d78 <command_loop_2>, arg=24332289) at eval.c:1237 #45 0x01005d51 in command_loop () at keyboard.c:1353 #46 0x0100564e in recursive_edit_1 () at keyboard.c:962 #47 0x010057b2 in Frecursive_edit () at keyboard.c:1024 #48 0x0100279f in main (argc=1, argv=0xfa8d60) at emacs.c:1784 HTH, Claus On Tue, Apr 15, 2008 at 5:18 PM, Claus <claus.klingberg@gmail.com> wrote: > OK, here we go (the crash-line looks harmless to me, but who knows...): > > [...] > [Switching to thread 4868.0xb0] > (gdb) c > Continuing. > > > Program received signal SIGSEGV, Segmentation fault. > [Switching to thread 4868.0x1188] > 0x0104977b in Fexpand_file_name (name=33140256, > > default_directory=33147443) at fileio.c:1402 > 1402 collapse_newdir = 0; > (gdb) backtrace > #0 0x0104977b in Fexpand_file_name (name=33140256, > > default_directory=33147443) at fileio.c:1402 > #1 0x01049504 in Fexpand_file_name (name=30126771, > default_directory=29673395) at fileio.c:1143 > #2 0x0107b9a9 in openp (path=39516501, str=30126771, > suffixes=76838269, storeptr=0x82e9a4, predicate=24815617) at > lread.c:1434 > #3 0x0107f290 in Fload (file=30126771, noerror=24815665, > > nomessage=24815665, nosuffix=24815617, must_suffix=24815665) at > lread.c:1068 > #4 0x0108b910 in Frequire (feature=30570025, filename=24815617, > > noerror=24815665) at fns.c:2964 > #5 0x0100b383 in Feval (form=74475197) at eval.c:2369 > #6 0x0100db89 in Fand (args=74475245) at eval.c:372 > #7 0x0100b468 in Feval (form=74475189) at eval.c:2310 > #8 0x0100db14 in Fif (args=76838309) at eval.c:395 > #9 0x0100b468 in Feval (form=76838301) at eval.c:2310 > #10 0x0100b1a4 in Feval (form=74475181) at eval.c:2421 > #11 0x0100b66f in Fprogn (args=74475173) at eval.c:451 > #12 0x0100b8d9 in funcall_lambda (fun=74473632, nargs=0, > > arg_vector=0x82eef0) at eval.c:3212 > #13 0x0100b9dc in apply_lambda (fun=74473637, args=24815617, > > eval_flag=1) at eval.c:3143 > #14 0x0100b0a4 in Feval (form=74441373) at eval.c:2423 > #15 0x0100b650 in Fprogn (args=74441277) at eval.c:451 > #16 0x0100d924 in Flet (args=74442597) at eval.c:1079 > #17 0x0100b468 in Feval (form=74442581) at eval.c:2310 > #18 0x0100b66f in Fprogn (args=74352941) at eval.c:451 > #19 0x0108ffae in Fsave_current_buffer (args=74352941) at editfns.c:1021 > #20 0x0100b468 in Feval (form=74352853) at eval.c:2310 > #21 0x0100b1a4 in Feval (form=74442461) at eval.c:2421 > #22 0x0100b66f in Fprogn (args=74442405) at eval.c:451 > #23 0x0100b8d9 in funcall_lambda (fun=74441528, nargs=0, > > arg_vector=0x82f420) at eval.c:3212 > #24 0x0100b9dc in apply_lambda (fun=74441533, args=24815617, > > eval_flag=1) at eval.c:3143 > #25 0x0100b0a4 in Feval (form=74436645) at eval.c:2423 > #26 0x0100b650 in Fprogn (args=74436653) at eval.c:451 > #27 0x0100b468 in Feval (form=74436637) at eval.c:2310 > #28 0x0100c470 in Funwind_protect (args=74436781) at eval.c:1343 > #29 0x0100b468 in Feval (form=74436629) at eval.c:2310 > #30 0x0100b66f in Fprogn (args=74438557) at eval.c:451 > #31 0x0100d924 in Flet (args=74438493) at eval.c:1079 > #32 0x0100b468 in Feval (form=74438453) at eval.c:2310 > #33 0x0100b650 in Fprogn (args=74438429) at eval.c:451 > #34 0x0100b8d9 in funcall_lambda (fun=74436920, nargs=0, > > arg_vector=0x82f9f4) at eval.c:3212 > #35 0x0100bc54 in Ffuncall (nargs=1, args=0x82f9f0) at eval.c:3089 > #36 0x0100d3bc in apply1 (fn=30817449, arg=24815617) at eval.c:2773 > #37 0x0110a195 in Fcall_interactively (function=30817449, > record_flag=24815617, keys=24849156) at callint.c:391 > #38 0x0100be4e in Ffuncall (nargs=4, args=0x82fbd0) at eval.c:3038 > #39 0x0100c026 in call3 (fn=25010177, arg1=30817449, arg2=24815617, > arg3=24815617) at eval.c:2858 > #40 0x01056f8e in Fcommand_execute (cmd=30817449, > record_flag=24815617, keys=24815617, special=24815617) at > keyboard.c:10470 > #41 0x0105e702 in command_loop_1 () at keyboard.c:1917 > #42 0x01009fd5 in internal_condition_case (bfun=0x105e39d > <command_loop_1>, handlers=24879297, hfun=0x1057a01 <cmd_error>) at > eval.c:1501 > #43 0x01051baa in command_loop_2 () at keyboard.c:1374 > #44 0x01009f0a in internal_catch (tag=24875369, func=0x1051b87 > <command_loop_2>, arg=24815617) at eval.c:1237 > #45 0x010519b7 in command_loop () at keyboard.c:1353 > #46 0x01051a50 in recursive_edit_1 () at keyboard.c:962 > #47 0x01051b71 in Frecursive_edit () at keyboard.c:1024 > #48 0x01002a6b in main (argc=1, argv=0xfd8d60) at emacs.c:1784 > (gdb) > > > > On Tue, Apr 15, 2008 at 1:54 PM, Jason Rumney <jasonr@gnu.org> wrote: > > Claus wrote: > > > > > 0x0104977b in Fexpand_file_name (name=76847264, > > > default_directory=33147443) at fileio.c:1402 > > > 1402 fileio.c: No such file or directory. > > > in fileio.c > > > > > > > > Please run emacs under gdb from the src directory so that the source files > > are picked up. > > > > I don't see any way that line 1402 of fileio.c in the current sources could > > cause a segment violation, so it is likely that the source differs in your > > environment for whatever reason. > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Recent trunk build crashes a lot under Win32 2008-04-15 16:24 ` Claus @ 2008-04-15 22:07 ` Jason Rumney 0 siblings, 0 replies; 10+ messages in thread From: Jason Rumney @ 2008-04-15 22:07 UTC (permalink / raw) To: Claus; +Cc: Emacs Devel Claus wrote: > I tried building again with --no-opt, now it crashes on a different > line, again in fileio.c: > > [New thread 5592.0x159c] > Error: dll starting at 0x22720000 not found. > warning: reader_thread.SetEvent failed with 6 for fd -1 > > > Program received signal SIGSEGV, Segmentation fault. > [Switching to thread 5592.0x112c] > 0x0107aecb in Fexpand_file_name (name=25063763, > default_directory=32568883) at fileio.c:1468 > 1468 if (1 > OK, the rest of that line of code is the first reference to nm since the DECODE_FILE in the block that deals with expansion of ~. Does the crash happen only when opening files in your home directory? Stefan's fix looks good to me, but I'm not sure how to force a situation where there is even the possibility of GC happening in DECODE_FILE, let alone forcing GC to definitely occur in there, so I can't test for sure. What is your locale-coding-system set to, and what path does HOME expand to? Also, do you use any arguments to configure or make, and have you set any gc or coding-system related variables in .emacs? Does the crash occur if you start Emacs with the -Q option? ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Recent trunk build crashes a lot under Win32 2008-04-15 11:16 Recent trunk build crashes a lot under Win32 Claus 2008-04-15 11:54 ` Jason Rumney @ 2008-04-15 15:07 ` Kyle M. Lee 2008-04-15 17:01 ` Stefan Monnier 2 siblings, 0 replies; 10+ messages in thread From: Kyle M. Lee @ 2008-04-15 15:07 UTC (permalink / raw) Cc: Emacs Devel Claus 写道: > > Hi, > > > > recent builds of current Emacs trunk (GNU Emacs 23.0.60.1 > > (i386-mingw-nt5.1.2600) of 2008-04-14) has been crashing a lot for me > > (under Windows Vista SP1). Emacs hangs 1~3 times everyday on my Windows XP. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Recent trunk build crashes a lot under Win32 2008-04-15 11:16 Recent trunk build crashes a lot under Win32 Claus 2008-04-15 11:54 ` Jason Rumney 2008-04-15 15:07 ` Kyle M. Lee @ 2008-04-15 17:01 ` Stefan Monnier 2008-04-16 0:41 ` YAMAMOTO Mitsuharu 2 siblings, 1 reply; 10+ messages in thread From: Stefan Monnier @ 2008-04-15 17:01 UTC (permalink / raw) To: Claus; +Cc: Emacs Devel > recent builds of current Emacs trunk (GNU Emacs 23.0.60.1 > (i386-mingw-nt5.1.2600) of 2008-04-14) has been crashing a lot for me > (under Windows Vista SP1). In yesterdays build I get right after > startup upon trying to open any file: I fixed a bug recently in this code due to the fact that DECODE_FILE can call GC which can relocate Lisp strings's data. I believe there are no such cases left in expand-file-name, but I wouldn't bet my life on it. Stefan ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Recent trunk build crashes a lot under Win32 2008-04-15 17:01 ` Stefan Monnier @ 2008-04-16 0:41 ` YAMAMOTO Mitsuharu 2008-04-18 2:26 ` Stefan Monnier 0 siblings, 1 reply; 10+ messages in thread From: YAMAMOTO Mitsuharu @ 2008-04-16 0:41 UTC (permalink / raw) To: Stefan Monnier; +Cc: Claus, Emacs Devel >>>>> On Tue, 15 Apr 2008 13:01:40 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said: >> recent builds of current Emacs trunk (GNU Emacs 23.0.60.1 >> (i386-mingw-nt5.1.2600) of 2008-04-14) has been crashing a lot for >> me (under Windows Vista SP1). In yesterdays build I get right after >> startup upon trying to open any file: > I fixed a bug recently in this code due to the fact that DECODE_FILE > can call GC which can relocate Lisp strings's data. I think you mean this part. 1392 if (!STRING_MULTIBYTE (tem)) 1393 { 1394 /* FIXME: DECODE_FILE may GC, which may move SDATA(name), 1395 after which `nm' won't point to the right place any more. */ 1396 int offset = nm - SDATA (name); 1397 hdir = DECODE_FILE (tem); 1398 newdir = SDATA (hdir); 1399 nm = SDATA (name) + offset; 1400 } But `nm' does not always point to the string data of `name' on some platforms. 1160 nm = SDATA (name); 1161 1162 #ifdef DOS_NT 1163 /* We will force directory separators to be either all \ or /, so make 1164 a local copy to modify, even if there ends up being no change. */ 1165 nm = strcpy (alloca (strlen (nm) + 1), nm); YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Recent trunk build crashes a lot under Win32 2008-04-16 0:41 ` YAMAMOTO Mitsuharu @ 2008-04-18 2:26 ` Stefan Monnier 2008-04-19 20:28 ` Claus 0 siblings, 1 reply; 10+ messages in thread From: Stefan Monnier @ 2008-04-18 2:26 UTC (permalink / raw) To: YAMAMOTO Mitsuharu; +Cc: Claus, Emacs Devel > I think you mean this part. > 1392 if (!STRING_MULTIBYTE (tem)) > 1393 { > 1394 /* FIXME: DECODE_FILE may GC, which may move SDATA(name), > 1395 after which `nm' won't point to the right place any more. */ > 1396 int offset = nm - SDATA (name); > 1397 hdir = DECODE_FILE (tem); > 1398 newdir = SDATA (hdir); > 1399 nm = SDATA (name) + offset; > 1400 } > But `nm' does not always point to the string data of `name' on some > platforms. > 1160 nm = SDATA (name); > 1161 > 1162 #ifdef DOS_NT > 1163 /* We will force directory separators to be either all \ or /, so make > 1164 a local copy to modify, even if there ends up being no change. */ > 1165 nm = strcpy (alloca (strlen (nm) + 1), nm); Good point. I hope I've fixed it now, Stefan ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Recent trunk build crashes a lot under Win32 2008-04-18 2:26 ` Stefan Monnier @ 2008-04-19 20:28 ` Claus 0 siblings, 0 replies; 10+ messages in thread From: Claus @ 2008-04-19 20:28 UTC (permalink / raw) To: Emacs Devel; +Cc: Stefan Monnier On Fri, Apr 18, 2008 at 4:26 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > > But `nm' does not always point to the string data of `name' on some > > platforms. > > > 1160 nm = SDATA (name); > > 1161 > > 1162 #ifdef DOS_NT > > 1163 /* We will force directory separators to be either all \ or /, so make > > 1164 a local copy to modify, even if there ends up being no change. */ > > 1165 nm = strcpy (alloca (strlen (nm) + 1), nm); > > Good point. I hope I've fixed it now, That seemed to do the trick. No more crashes for me - thanks! Claus ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2008-04-19 20:28 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-04-15 11:16 Recent trunk build crashes a lot under Win32 Claus 2008-04-15 11:54 ` Jason Rumney 2008-04-15 15:18 ` Claus 2008-04-15 16:24 ` Claus 2008-04-15 22:07 ` Jason Rumney 2008-04-15 15:07 ` Kyle M. Lee 2008-04-15 17:01 ` Stefan Monnier 2008-04-16 0:41 ` YAMAMOTO Mitsuharu 2008-04-18 2:26 ` Stefan Monnier 2008-04-19 20:28 ` Claus
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.