Recent trunk build crashes a lot under Win32

Recent trunk build crashes a lot under Win32

[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). 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

Re: Recent trunk build crashes a lot under Win32

[Jason Rumney]

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.

Re: Recent trunk build crashes a lot under Win32

[Kyle M. Lee]

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.

Re: Recent trunk build crashes a lot under Win32

[Claus]

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.
>

Re: Recent trunk build crashes a lot under Win32

[Claus]

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.
>  >

Re: Recent trunk build crashes a lot under Win32

[Stefan Monnier]

> 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

Re: Recent trunk build crashes a lot under Win32

[Jason Rumney]

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?

Re: Recent trunk build crashes a lot under Win32

[YAMAMOTO Mitsuharu]

>>>>> 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

Re: Recent trunk build crashes a lot under Win32

[Stefan Monnier]

> 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

Re: Recent trunk build crashes a lot under Win32

[Claus]

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