GNU bug report logs - #16615
24.3.50; Fatal error visiting a directory (same as #16132?)

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16615 in the body.
You can then email your comments to 16615 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: 24.3.50; Fatal error visiting a directory (same as #16132?)
Date: Sat, 1 Feb 2014 17:32:44 +0000

[Message part 1 (text/plain, inline)]

I'm getting the same symptoms as described in #16132.

From `emacs -Q': M-x find-file RET c:\temp RET

... results in the Emacs Abort Dialogue and the backtrace below.
When compiled with "-O0 -g3" or "-g3", the error doesn't occur. When
compiled with CFLAGS not set, the backtrace isn't very helpful:

(gdb) bt full
#0  0x76e3321a in KERNELBASE!DeleteAce () from
C:\Windows\syswow64\KernelBase.dll
No symbol table info available.
#1  0x0114ca82 in emacs_abort () at c:/emacs/trunk/src/w32fns.c:8443
        button = <optimized out>
#2  0x0109205c in terminate_due_to_signal (sig=sig <at> entry=11,
backtrace_limit=backtrace_limit <at> entry=40) at c:/emacs/trunk/src/emacs.c:378
No locals.
#3  0x010a7291 in handle_fatal_signal (sig=11) at
c:/emacs/trunk/src/sysdep.c:1628
No locals.
#4  deliver_thread_signal (sig=11, handler=<optimized out>) at
c:/emacs/trunk/src/sysdep.c:1602
        handler = 0x10a7172 <handle_fatal_signal>
#5  deliver_fatal_thread_signal (sig=11) at c:/emacs/trunk/src/sysdep.c:1640
No locals.
#6  0x010011ea in _gnu_exception_handler <at> 4 ()
No symbol table info available.
#7  0x772ffffb in KERNEL32!GetQueuedCompletionStatus () from
C:\Windows\syswow64\kernel32.dll
No symbol table info available.
#8  0x0088df18 in ?? ()
No symbol table info available.
#9  0x779674ff in ntdll!AlpcMaxAllowedMessageLength () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#10 0x0088df18 in ?? ()
No symbol table info available.
#11 0x77929f45 in ntdll!RtlpNtSetValueKey () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#12 0x011267be in sprintf (__stream=0x0, __format=0x1371be0 "Copying raw
data for %.8s...", __format=0x1371be0 "Copying raw data for %.8s...")
    at c:/mingw/bin/../lib/gcc/mingw32/4.7.2/../../../../include/stdio.h:269
        __retval = 6
        __local_argv = 0x88ffec ""
#13 0x7efde000 in ?? ()
No symbol table info available.
#14 0x00000000 in ?? ()
No symbol table info available.
(gdb) xbacktrace
Undefined command: "xbacktrace".  Try "help".
(gdb) quit

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 ()
(gdb) thread apply all bt full

Thread 4 (Thread 5320.0x1f88):
#0  0x767078d7 in USER32!IsDialogMessage () from
C:\Windows\syswow64\user32.dll
No symbol table info available.
#1  0x767078d7 in USER32!IsDialogMessage () from
C:\Windows\syswow64\user32.dll
No symbol table info available.
#2  0x7670790d in USER32!GetCursorPos () from C:\Windows\syswow64\user32.dll
No symbol table info available.
#3  0x6ec1fe74 in ?? ()
No symbol table info available.
#4  0x0114ff2c in w32_msg_pump (msg_buf=<optimized out>) at
c:/emacs/trunk/src/w32fns.c:2449
        msg = {hwnd = 0x22210f8, message = 1040, wParam = 0, lParam = 0,
time = 185904691, pt = {x = 500, y = 705}}
        result = <optimized out>
        focus_window = <optimized out>
#5  0x00000000 in ?? ()
No symbol table info available.

Thread 3 (Thread 5320.0xa4c):
#0  0x7790fd91 in ntdll!RtlFindSetBits () from C:\Windows\system32\ntdll.dll
No symbol table info available.
#1  0x7790fd91 in ntdll!RtlFindSetBits () from C:\Windows\system32\ntdll.dll
No symbol table info available.
#2  0x76e33bc8 in SleepEx () from C:\Windows\syswow64\KernelBase.dll
No symbol table info available.
#3  0x00000000 in ?? ()
No symbol table info available.

Thread 2 (Thread 5320.0x1e6c):
#0  0x7791015d in ntdll!RtlEnableEarlyCriticalSectionEventCreation () from
C:\Windows\system32\ntdll.dll
No symbol table info available.
#1  0x7791015d in ntdll!RtlEnableEarlyCriticalSectionEventCreation () from
C:\Windows\system32\ntdll.dll
No symbol table info available.
#2  0x77942f91 in ntdll!RtlWeaklyEnumerateEntryHashTable () from
C:\Windows\system32\ntdll.dll
No symbol table info available.
#3  0x00000003 in ?? ()
No symbol table info available.
#4  0x00cd1258 in ?? ()
No symbol table info available.
#5  0x772c336a in KERNEL32!BaseCleanupAppcompatCacheSupport () from
C:\Windows\syswow64\kernel32.dll
No symbol table info available.
#6  0x00000000 in ?? ()
No symbol table info available.

Thread 1 (Thread 5320.0x1a6c):
#0  0x03b19605 in __register_frame_info ()
No symbol table info available.
Cannot access memory at address 0x6
(gdb) quit

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2014-02-01 on 57172UHB
Repository revision: 116232 eliz <at> gnu.org-20140201115310-cjn5tvleyejff9dy
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix c:/emacs/emacs-116232
 --enable-locallisppath=%emacs_dir%/../site-lisp 'CPPFLAGS=-I
 G:/usr/include -I C:/GnuWin32/include' 'LDFLAGS=-L G:/usr/lib -L
 C:/GnuWin32/lib''

Important settings:
  value of $LANG: ENG
  locale-coding-system: cp1252

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x r - e - b <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns mail-prsvr mail-utils time-date tooltip electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp
w32-common-fns disp-table w32-win w32-vars tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew
greek romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process w32notify w32
multi-tty emacs)

[Message part 2 (text/html, inline)]

Message #8 received at 16615 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 16615 <at> debbugs.gnu.org
Subject: Re: bug#16615: 24.3.50;
 Fatal error visiting a directory (same as #16132?)
Date: Sat, 01 Feb 2014 20:11:49 +0200

> Date: Sat, 1 Feb 2014 17:32:44 +0000
> From: Richard Copley <rcopley <at> gmail.com>
> 
> I'm getting the same symptoms as described in #16132.

That one disappeared after bootstrapping.

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

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

Message #11 received at 16615 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16615 <at> debbugs.gnu.org
Subject: Re: bug#16615: 24.3.50;
 Fatal error visiting a directory (same as #16132?)
Date: Sat, 1 Feb 2014 19:09:01 +0000

[Message part 1 (text/plain, inline)]

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

> > Date: Sat, 1 Feb 2014 17:32:44 +0000
> > From: Richard Copley <rcopley <at> 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?

[Message part 2 (text/html, inline)]

Message #14 received at 16615 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16615 <at> debbugs.gnu.org
Subject: Re: bug#16615: 24.3.50;
 Fatal error visiting a directory (same as #16132?)
Date: Sat, 1 Feb 2014 19:34:00 +0000

[Message part 1 (text/plain, inline)]

On 1 February 2014 19:09, Richard Copley <rcopley <at> gmail.com> wrote:

>
> It looks to me as though "filename_to_utf16" is not returning utf16 data
> (which is what it sounds like it should do):
>
No, sorry. I didn't notice the L prefix:

> (gdb) p rootname_w
> $2 = L"c:\\\0[...]"
>
... which is correct.
Perhaps some problem with type-punning LARGE_INTEGER/ULARGE_INTEGER under
-fstrict-aliasing. I can't say I understand that stuff very well, and I
admit it doesn't seem very likely, but I'll see if I can get it to work
without the casting.

[Message part 2 (text/html, inline)]

Message #17 received at 16615 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16615 <at> debbugs.gnu.org
Subject: Re: bug#16615: 24.3.50;
 Fatal error visiting a directory (same as #16132?)
Date: Sat, 1 Feb 2014 20:05:56 +0000

[Message part 1 (text/plain, inline)]

On 1 February 2014 19:34, Richard Copley <rcopley <at> gmail.com> wrote:

> Perhaps some problem with type-punning LARGE_INTEGER/ULARGE_INTEGER under
> -fstrict-aliasing. I can't say I understand that stuff very well, and I
> admit it doesn't seem very likely, but I'll see if I can get it to work
> without the casting.
>

No, not that. It still crashes with the "*bytes" variables in
"Ffile_system_info" declared as ULARGE_INTEGER and the casts removed.

[Message part 2 (text/html, inline)]

Message #20 received at 16615 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 16615 <at> debbugs.gnu.org
Subject: Re: bug#16615: 24.3.50;
 Fatal error visiting a directory (same as #16132?)
Date: Sat, 01 Feb 2014 22:12:54 +0200

> Date: Sat, 1 Feb 2014 19:34:00 +0000
> From: Richard Copley <rcopley <at> gmail.com>
> Cc: 16615 <at> debbugs.gnu.org
> 
> Perhaps some problem with type-punning LARGE_INTEGER/ULARGE_INTEGER under
> -fstrict-aliasing.

I doubt that (but where would -fstrict-aliasing come from?).

Please try the latest trunk and see if its solves the problem.

Message #23 received at 16615 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16615 <at> debbugs.gnu.org
Subject: Re: bug#16615: 24.3.50;
 Fatal error visiting a directory (same as #16132?)
Date: Sat, 1 Feb 2014 20:43:54 +0000

[Message part 1 (text/plain, inline)]

On 1 February 2014 20:12, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Date: Sat, 1 Feb 2014 19:34:00 +0000
> > From: Richard Copley <rcopley <at> gmail.com>
> > Cc: 16615 <at> debbugs.gnu.org
> >
> > Perhaps some problem with type-punning LARGE_INTEGER/ULARGE_INTEGER under
> > -fstrict-aliasing.
>
> I doubt that (but where would -fstrict-aliasing come from?).
>

Yes, I doubted it too. "-fstrict-aliasing" is enabled at -O2 (
http://gcc.gnu.org/onlinedocs/gcc-4.7.3/gcc/Optimize-Options.html#index-O2-706
).

Please try the latest trunk and see if its solves the problem.
>

Tried r116235 with

  '/c/emacs/trunk/configure' --prefix c:/emacs/emacs-116235 --without-png
--without-jpeg --without-xpm --without-gif --without-tiff --without-gnutls
--without-xml2 --enable-locallisppath=%emacs_dir%/../site-lisp

Seems fixed, many thanks. I should rebuild with the libraries enabled to be
sure. I will let you know the result.

[Message part 2 (text/html, inline)]

Message #26 received at 16615 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16615 <at> debbugs.gnu.org
Subject: Re: bug#16615: 24.3.50;
 Fatal error visiting a directory (same as #16132?)
Date: Sat, 1 Feb 2014 21:52:07 +0000

>> > From: Richard Copley <rcopley <at> gmail.com>
>> > Perhaps some problem with type-punning LARGE_INTEGER/ULARGE_INTEGER under
>> > -fstrict-aliasing [...] I admit it doesn't seem very likely [...]
Impossible, actually, because LARGE_INTEGER and ULARGE_INTEGER are
"compatible types" for the purposes of the strict aliasing rules, as
they differ only in signedness
(http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html#compatible_type).
Nonetheless those casts in Ffile_system_info seem gratuitous.

On 1 February 2014 20:43, Richard Copley <rcopley <at> gmail.com> wrote:
>On 1 February 2014 20:12, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Please try the latest trunk and see if its solves the problem.
> Seems fixed, many thanks. I should rebuild with the libraries enabled to be sure. I will let you know the result.

Yes, still fixed. Thanks again.

Message #29 received at 16615 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Richard Copley <rcopley <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 16615 <at> debbugs.gnu.org
Subject: Re: bug#16615: 24.3.50;
 Fatal error visiting a directory (same as #16132?)
Date: Sat, 1 Feb 2014 23:48:17 +0100

On Sat, Feb 1, 2014 at 9:43 PM, Richard Copley <rcopley <at> gmail.com> wrote:

> --enable-locallisppath=%emacs_dir%/../site-lisp

That warms my heart. Apparently I'm not the only one who would've
liked to keep compatibility with the old Windows-specific load-path
behavior regarding site-lisp dirs.

     J

Message #32 received at 16615 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 16615 <at> debbugs.gnu.org
Subject: Re: bug#16615: 24.3.50;
 Fatal error visiting a directory (same as #16132?)
Date: Sat, 1 Feb 2014 23:03:11 +0000

I wanted it so much I contributed the fix that implements it (see bug
#14513, r112881).
So it's my heart that is warmed by your comment!

Message #35 received at 16615 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 16615 <at> debbugs.gnu.org
Subject: Re: bug#16615: 24.3.50;
 Fatal error visiting a directory (same as #16132?)
Date: Sun, 2 Feb 2014 00:18:27 +0100

On Sun, Feb 2, 2014 at 12:03 AM, Richard Copley <rcopley <at> gmail.com> wrote:
> I wanted it so much I contributed the fix that implements it (see bug
> #14513, r112881).

Yes, I remember. I participated in that bug thread.

> So it's my heart that is warmed by your comment!

And yet, load-path is still incompatible with previous Emacs releases
on Windows, and using %emacs_dir%/../site-lisp in
--enable-locallisppath is undocumented, I think. A pity. Apparently
you and I are the only ones who ever used the feature.

Message #38 received at 16615 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 16615 <at> debbugs.gnu.org
Subject: Re: bug#16615: 24.3.50;
 Fatal error visiting a directory (same as #16132?)
Date: Sat, 1 Feb 2014 23:24:22 +0000

I guess there aren't many users on Windows who build their own, so the
howls of pain won't be heard until the next release (assuming the
released Windows binary isn't going to be configured like that).

Message #41 received at 16615 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 16615 <at> debbugs.gnu.org
Subject: Re: bug#16615: 24.3.50;
 Fatal error visiting a directory (same as #16132?)
Date: Sun, 2 Feb 2014 00:33:17 +0100

> I guess there aren't many users on Windows who build their own

No, but there are quite a few that grab snapshot binaries if/when available.

>, so the
> howls of pain won't be heard until the next release (assuming the
> released Windows binary isn't going to be configured like that).

Well, I certainly would support the idea of using

-enable-locallisppath='%emacs_dir%/../site-lisp:%emacs_dir%/share/emacs/@VER@/site-lisp:%emacs_dir%/share/emacs/site-lisp'

to build the "official" Windows binary.

Message #46 received at 16615-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 16615-done <at> debbugs.gnu.org
Subject: Re: bug#16615: 24.3.50;
 Fatal error visiting a directory (same as #16132?)
Date: Sun, 02 Feb 2014 05:41:15 +0200

> Date: Sat, 1 Feb 2014 21:52:07 +0000
> From: Richard Copley <rcopley <at> gmail.com>
> Cc: 16615 <at> debbugs.gnu.org
> 
> On 1 February 2014 20:43, Richard Copley <rcopley <at> gmail.com> wrote:
> >On 1 February 2014 20:12, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >> Please try the latest trunk and see if its solves the problem.
> > Seems fixed, many thanks. I should rebuild with the libraries enabled to be sure. I will let you know the result.
> 
> Yes, still fixed. Thanks again.

Thanks, closing.

(It's amazing how long such a glaring mistake can go unnoticed:
omitting WINAPI from the function pointer declaration means that the
compiler uses the wrong calling convention for it -- cdecl instead of
stdcall -- which explains both the crash and the smashed stack that
prevented you from obtaining a useful backtrace.  This code was there
since 14 years ago.)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.