bug#16615: 24.3.50; Fatal error visiting a directory (same as #16132?)

[Richard Copley <rcopley@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5689 bytes --]

On 1 February 2014 18:11, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Sat, 1 Feb 2014 17:32:44 +0000
> > From: Richard Copley <rcopley@gmail.com>
> >
> > 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=<optimized out>) 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 <http://gnu.org/licenses/gpl.html
>
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:
<http://www.gnu.org/software/gdb/bugs/>.


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

[-- Attachment #2: Type: text/html, Size: 7103 bytes --]