* bug#16615: 24.3.50; Fatal error visiting a directory (same as #16132?) @ 2014-02-01 17:32 Richard Copley 2014-02-01 18:11 ` Eli Zaretskii 0 siblings, 1 reply; 14+ messages in thread From: Richard Copley @ 2014-02-01 17:32 UTC (permalink / raw) To: 16615 [-- Attachment #1: Type: text/plain, Size: 6769 bytes --] 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@entry=11, backtrace_limit=backtrace_limit@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@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@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) [-- Attachment #2: Type: text/html, Size: 7551 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16615: 24.3.50; Fatal error visiting a directory (same as #16132?) 2014-02-01 17:32 bug#16615: 24.3.50; Fatal error visiting a directory (same as #16132?) Richard Copley @ 2014-02-01 18:11 ` Eli Zaretskii 2014-02-01 19:09 ` Richard Copley 0 siblings, 1 reply; 14+ messages in thread From: Eli Zaretskii @ 2014-02-01 18:11 UTC (permalink / raw) To: Richard Copley; +Cc: 16615 > 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. > 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.? ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16615: 24.3.50; Fatal error visiting a directory (same as #16132?) 2014-02-01 18:11 ` Eli Zaretskii @ 2014-02-01 19:09 ` Richard Copley 2014-02-01 19:34 ` Richard Copley 0 siblings, 1 reply; 14+ messages in thread From: Richard Copley @ 2014-02-01 19:09 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 16615 [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16615: 24.3.50; Fatal error visiting a directory (same as #16132?) 2014-02-01 19:09 ` Richard Copley @ 2014-02-01 19:34 ` Richard Copley 2014-02-01 20:05 ` Richard Copley 2014-02-01 20:12 ` Eli Zaretskii 0 siblings, 2 replies; 14+ messages in thread From: Richard Copley @ 2014-02-01 19:34 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 16615 [-- Attachment #1: Type: text/plain, Size: 543 bytes --] On 1 February 2014 19:09, Richard Copley <rcopley@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. [-- Attachment #2: Type: text/html, Size: 1220 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16615: 24.3.50; Fatal error visiting a directory (same as #16132?) 2014-02-01 19:34 ` Richard Copley @ 2014-02-01 20:05 ` Richard Copley 2014-02-01 20:12 ` Eli Zaretskii 1 sibling, 0 replies; 14+ messages in thread From: Richard Copley @ 2014-02-01 20:05 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 16615 [-- Attachment #1: Type: text/plain, Size: 451 bytes --] On 1 February 2014 19:34, Richard Copley <rcopley@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. [-- Attachment #2: Type: text/html, Size: 839 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16615: 24.3.50; Fatal error visiting a directory (same as #16132?) 2014-02-01 19:34 ` Richard Copley 2014-02-01 20:05 ` Richard Copley @ 2014-02-01 20:12 ` Eli Zaretskii 2014-02-01 20:43 ` Richard Copley 1 sibling, 1 reply; 14+ messages in thread From: Eli Zaretskii @ 2014-02-01 20:12 UTC (permalink / raw) To: Richard Copley; +Cc: 16615 > Date: Sat, 1 Feb 2014 19:34:00 +0000 > From: Richard Copley <rcopley@gmail.com> > Cc: 16615@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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16615: 24.3.50; Fatal error visiting a directory (same as #16132?) 2014-02-01 20:12 ` Eli Zaretskii @ 2014-02-01 20:43 ` Richard Copley 2014-02-01 21:52 ` Richard Copley 2014-02-01 22:48 ` Juanma Barranquero 0 siblings, 2 replies; 14+ messages in thread From: Richard Copley @ 2014-02-01 20:43 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 16615 [-- Attachment #1: Type: text/plain, Size: 911 bytes --] On 1 February 2014 20:12, Eli Zaretskii <eliz@gnu.org> wrote: > > Date: Sat, 1 Feb 2014 19:34:00 +0000 > > From: Richard Copley <rcopley@gmail.com> > > Cc: 16615@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. [-- Attachment #2: Type: text/html, Size: 1729 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16615: 24.3.50; Fatal error visiting a directory (same as #16132?) 2014-02-01 20:43 ` Richard Copley @ 2014-02-01 21:52 ` Richard Copley 2014-02-02 3:41 ` Eli Zaretskii 2014-02-01 22:48 ` Juanma Barranquero 1 sibling, 1 reply; 14+ messages in thread From: Richard Copley @ 2014-02-01 21:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 16615 >> > From: Richard Copley <rcopley@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@gmail.com> wrote: >On 1 February 2014 20:12, Eli Zaretskii <eliz@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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16615: 24.3.50; Fatal error visiting a directory (same as #16132?) 2014-02-01 21:52 ` Richard Copley @ 2014-02-02 3:41 ` Eli Zaretskii 0 siblings, 0 replies; 14+ messages in thread From: Eli Zaretskii @ 2014-02-02 3:41 UTC (permalink / raw) To: Richard Copley; +Cc: 16615-done > Date: Sat, 1 Feb 2014 21:52:07 +0000 > From: Richard Copley <rcopley@gmail.com> > Cc: 16615@debbugs.gnu.org > > On 1 February 2014 20:43, Richard Copley <rcopley@gmail.com> wrote: > >On 1 February 2014 20:12, Eli Zaretskii <eliz@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.) ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16615: 24.3.50; Fatal error visiting a directory (same as #16132?) 2014-02-01 20:43 ` Richard Copley 2014-02-01 21:52 ` Richard Copley @ 2014-02-01 22:48 ` Juanma Barranquero 2014-02-01 23:03 ` Richard Copley 1 sibling, 1 reply; 14+ messages in thread From: Juanma Barranquero @ 2014-02-01 22:48 UTC (permalink / raw) To: Richard Copley; +Cc: 16615 On Sat, Feb 1, 2014 at 9:43 PM, Richard Copley <rcopley@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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16615: 24.3.50; Fatal error visiting a directory (same as #16132?) 2014-02-01 22:48 ` Juanma Barranquero @ 2014-02-01 23:03 ` Richard Copley 2014-02-01 23:18 ` Juanma Barranquero 0 siblings, 1 reply; 14+ messages in thread From: Richard Copley @ 2014-02-01 23:03 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 16615 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! ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16615: 24.3.50; Fatal error visiting a directory (same as #16132?) 2014-02-01 23:03 ` Richard Copley @ 2014-02-01 23:18 ` Juanma Barranquero 2014-02-01 23:24 ` Richard Copley 0 siblings, 1 reply; 14+ messages in thread From: Juanma Barranquero @ 2014-02-01 23:18 UTC (permalink / raw) To: Richard Copley; +Cc: 16615 On Sun, Feb 2, 2014 at 12:03 AM, Richard Copley <rcopley@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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16615: 24.3.50; Fatal error visiting a directory (same as #16132?) 2014-02-01 23:18 ` Juanma Barranquero @ 2014-02-01 23:24 ` Richard Copley 2014-02-01 23:33 ` Juanma Barranquero 0 siblings, 1 reply; 14+ messages in thread From: Richard Copley @ 2014-02-01 23:24 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 16615 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). ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16615: 24.3.50; Fatal error visiting a directory (same as #16132?) 2014-02-01 23:24 ` Richard Copley @ 2014-02-01 23:33 ` Juanma Barranquero 0 siblings, 0 replies; 14+ messages in thread From: Juanma Barranquero @ 2014-02-01 23:33 UTC (permalink / raw) To: Richard Copley; +Cc: 16615 > 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2014-02-02 3:41 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-02-01 17:32 bug#16615: 24.3.50; Fatal error visiting a directory (same as #16132?) Richard Copley 2014-02-01 18:11 ` Eli Zaretskii 2014-02-01 19:09 ` Richard Copley 2014-02-01 19:34 ` Richard Copley 2014-02-01 20:05 ` Richard Copley 2014-02-01 20:12 ` Eli Zaretskii 2014-02-01 20:43 ` Richard Copley 2014-02-01 21:52 ` Richard Copley 2014-02-02 3:41 ` Eli Zaretskii 2014-02-01 22:48 ` Juanma Barranquero 2014-02-01 23:03 ` Richard Copley 2014-02-01 23:18 ` Juanma Barranquero 2014-02-01 23:24 ` Richard Copley 2014-02-01 23:33 ` Juanma Barranquero
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).