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 <address@hidden> 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.
>