On 1 February 2014 18:11, Eli Zaretskii wrote: > > Date: Sat, 1 Feb 2014 17:32:44 +0000 > > From: Richard Copley > > > > I'm getting the same symptoms as described in #16132. > > That one disappeared after bootstrapping. > I build from a pristine working copy every time. > > When started from the debugger things are no better (no stack pointer?). > > (The result is similar if "\temp" is specified as a command line > argument.) > > > > C:\emacs>gdb --quiet --args c:\emacs\emacs-116232\bin\emacs.exe -Q > > Reading symbols from c:\emacs\emacs-116232\bin\emacs.exe...done. > > (gdb) run > > > > ;;; (Now type: M-x find-file RET \temp RET) > > > > Starting program: c:\emacs\emacs-116232\bin\emacs.exe -Q > > [New Thread 5320.0x1a6c] > > [New Thread 5320.0x1e6c] > > [New Thread 5320.0xa4c] > > [New Thread 5320.0x1f88] > > > > Program received signal SIGSEGV, Segmentation fault. > > 0x03b19605 in __register_frame_info () > > Put a breakpoint in Fdirectory_files_and_attributes and in > Ffile_system_info and, then invoke find-file, and step through them > line by line to see on which line where does SIGSEGV hit. It looks to me as though "filename_to_utf16" is not returning utf16 data (which is what it sounds like it should do): C:\emacs>gdb --quiet --args c:\emacs\emacs-116232\bin\emacs.exe -Q \temp\ Reading symbols from c:\emacs\emacs-116232\bin\emacs.exe...done. (gdb) break w32fns.c:7507 Breakpoint 1 at 0x1147ca1: file c:/emacs/trunk/src/w32fns.c, line 7507. (gdb) run Starting program: c:\emacs\emacs-116232\bin\emacs.exe -Q \temp\ [New Thread 7144.0x89c] [New Thread 7144.0x1fdc] [New Thread 7144.0x19e4] [New Thread 7144.0x1fc8] Breakpoint 1, Ffile_system_info (filename=) at c:/emacs/trunk/src/w32fns.c:7507 7507 filename_to_utf16 (rootname, rootname_w); (gdb) n 7511 if (have_pfn_GetDiskFreeSpaceEx) (gdb) p rootname $1 = "c:\\\000\036AR\005\002\000\000\000Ïá\017\001\b\000\000\000\002,³\003\"8±\003Òo\023\001\002,³\003.#Ö\003\061C¿\003é÷\377\377\061C¿\003\000\000\000\000ZBR\0 05\005-±\001\001\000\000\000\"8±\003\001\000\000\000\000-±\003p4À\003¢¡³\003\"8±\003Òo\023\001¢¡³\003\020/a\005\016\000\000\000\020¿\023\001\"8±\003\"8±\003\001 \000\000\000.\000\000\000\000-±\003\020C¿\003\017\000\000\000\v\000\000\000\"8±\003\020C¿\003\"8±\003\005-±\003p4À\003\016\000\000\000\000\000\000\000\020/a\005 \016\000\000\000\037\000\000\000°Ö\210\000\000\000\000\000\000\000\000\000*\023\065\001"... (gdb) p rootname_w $2 = L"c:\\\000\000\000\000\000\xdc88\210\002\000\003\000\xf796\433\xdc08\210\x6b7e\417\x19e9\450\x1a05\450\020\000\000\415\xef60\x5776\xdc08\210\xdc40\210\xa86 c\430\xdbb8\210\000\000\x2748\x552\x9d50\x55a\000\000\x52c2\000\003\000\000\000\x52c2\000\xdb98\000\x9cd0\465\000\000\x20fc\x561;\000\x2118\x561\xc12b\423\x4486 \x552\x4126\x552\x208c\x561\x2038\x561\000\000\003\000\x2054\x561\x8800\423F\000\x4128\x552\xde08\210\000\000\x208c\x561F\400\001\000\x4321\x3bf\x2054\x561\003\ 000\001\000\x2054\x561\x2038\x561\003\000\001\000\xd46b\423\000\000\x2038\x561\xdc68\210\001\000\x3822\x3b1\002\000\000\000\x43de\x552\x2134s\001\000\440\000\43 0\000\003\000\xdc9c\210\xdd58\210\x4321\x3bfF\000\x4128\x552\xde08\210\xf425\423\x4321\x3bf\000\000\x43de\x552\x4321\x3bf\xdcf4\210E\000\x4331\x3bf\xdf6a\417\x4 321\x3bf\x412e\x552\430\000\x3822\x3b1\001\000\002\000\x1550\x3eb\xee7b\415\004\000\000\000\r\000\005\000\000\000\x650\000\020\000\x1c04\415:\000\n\000\000\000F \000\x1550\x3eb\x4331\x3bf\xdcc0\210\000\000\xdd90\210\000\400\001\000\x4331\x3bf\x2f3e\453\x1999\400\x2f27\453\x4320\x3bfI\000I\000\xde08\210\xedc3\415\x3822\x 3b1\x40d6\x552I\000\xcfd9\417\xb979\433°\000\x16cc\x564\xe6b1\417" (gdb) n 7523 (ULARGE_INTEGER *)&freebytes); (gdb) n 7519 if (w32_unicode_filenames) (gdb) n 7523 (ULARGE_INTEGER *)&freebytes); (gdb) n 7522 (ULARGE_INTEGER *)&totalbytes, (gdb) n 7521 (ULARGE_INTEGER *)&availbytes, (gdb) n 7519 if (w32_unicode_filenames) (gdb) n 7520 result = pfn_GetDiskFreeSpaceExW (rootname_w, (gdb) n Program received signal SIGSEGV, Segmentation fault. 0x03b19608 in __register_frame_info () (gdb) > That should > at least give us a clue where to look. I guess the bug, whatever it > is, badly smashes the stack, or maybe it's some GCC misfeature in > optimized code that trips the debugger. (Which GDB version is that, > btw?) > > C:\emacs>gcc --version gcc (GCC) 4.7.2 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. C:\emacs>gdb --version GNU gdb (GDB) 7.5 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-mingw32". For bug reporting instructions, please see: . > Anyway, I tried to reproduce this, but couldn't. What version of GCC > do you have? Also, does the problem happen if you configure Emacs > without all the optional libraries, like image libraries, libxml, > gnutls, etc.? > Still want me to try that?