* bug#15834: Crash during bootstrap @ 2013-11-08 14:33 Andy Moreton 2013-11-08 15:15 ` Eli Zaretskii 0 siblings, 1 reply; 9+ messages in thread From: Andy Moreton @ 2013-11-08 14:33 UTC (permalink / raw To: 15834 Bootstrapping a Windows msys build with bzr r115035 results in a crash when compiling lisp/net/tramp-smb.el: Lisp Backtrace: "Automatic GC" (0x14b050c) "byte-optimize-form" (0x88b79c) "mapcar" (0x88b8d8) "byte-optimize-form-code-walker" (0x88ba80) "byte-optimize-form" (0x88bc1c) "mapcar" (0x88bd58) "byte-optimize-form-code-walker" (0x88bf00) "byte-optimize-form" (0x88c0b0) "byte-optimize-body" (0x88c250) "byte-optimize-form-code-walker" (0x88c3f0) "byte-optimize-form" (0x88c5a0) "byte-optimize-body" (0x88c73c) "byte-optimize-form-code-walker" (0x88c8e0) "byte-optimize-form" (0x88ca90) "byte-optimize-form-code-walker" (0x88cc30) "byte-optimize-form" (0x88cde0) "byte-optimize-body" (0x88cf84) "byte-optimize-form-code-walker" (0x88d120) "byte-optimize-form" (0x88d2d0) "byte-optimize-body" (0x88d470) "byte-optimize-form-code-walker" (0x88d610) "byte-optimize-form" (0x88d7b8) "byte-optimize-form-code-walker" (0x88d960) "byte-optimize-form" (0x88db0c) "byte-compile-top-level" (0x88dcc8) "byte-compile-lambda" (0x88de8c) "byte-compile-file-form-defmumble" (0x88e030) 0x3dcfca0 PVEC_COMPILED 0x4062fd8 PVEC_COMPILED 0x4077f88 PVEC_COMPILED "byte-compile-file-form-defalias" (0x88e740) "byte-compile-file-form" (0x88e8cc) "byte-compile-toplevel-file-form" (0x88ea5c) 0x4084fd8 PVEC_COMPILED 0x403dc60 PVEC_COMPILED "funcall" (0x88ed70) "byte-compile-from-buffer" (0x88f078) "byte-compile-file" (0x88f218) 0x401d578 PVEC_COMPILED "funcall" (0x88f3a0) "batch-byte-compile-file" (0x88f680) "batch-byte-compile" (0x88f850) "command-line-1" (0x88f9e8) "command-line" (0x88fbac) "normal-top-level" (0x88fcf0) ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#15834: Crash during bootstrap 2013-11-08 14:33 bug#15834: Crash during bootstrap Andy Moreton @ 2013-11-08 15:15 ` Eli Zaretskii 2013-11-08 15:22 ` Eli Zaretskii 2013-11-10 12:23 ` Andy Moreton 0 siblings, 2 replies; 9+ messages in thread From: Eli Zaretskii @ 2013-11-08 15:15 UTC (permalink / raw To: Andy Moreton; +Cc: 15834 > From: Andy Moreton <andrewjmoreton@gmail.com> > Date: Fri, 08 Nov 2013 14:33:14 +0000 > > > Bootstrapping a Windows msys build with bzr r115035 results in a crash > when compiling lisp/net/tramp-smb.el: > > Lisp Backtrace: > "Automatic GC" (0x14b050c) Can you show a C backtrace? Also, can you try reverting 115033, and see if that helps? ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#15834: Crash during bootstrap 2013-11-08 15:15 ` Eli Zaretskii @ 2013-11-08 15:22 ` Eli Zaretskii 2013-11-10 12:23 ` Andy Moreton 1 sibling, 0 replies; 9+ messages in thread From: Eli Zaretskii @ 2013-11-08 15:22 UTC (permalink / raw To: andrewjmoreton; +Cc: 15834 > Date: Fri, 08 Nov 2013 17:15:38 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: 15834@debbugs.gnu.org > > > From: Andy Moreton <andrewjmoreton@gmail.com> > > Date: Fri, 08 Nov 2013 14:33:14 +0000 > > > > > > Bootstrapping a Windows msys build with bzr r115035 results in a crash > > when compiling lisp/net/tramp-smb.el: > > > > Lisp Backtrace: > > "Automatic GC" (0x14b050c) > > Can you show a C backtrace? > > Also, can you try reverting 115033, and see if that helps? Actually, it could be related to bug #15833: if I byte-compile that file (or any other file I tried, for that matter), I see these messages in *Messages*: Unable to load color "unspecified-fg" ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#15834: Crash during bootstrap 2013-11-08 15:15 ` Eli Zaretskii 2013-11-08 15:22 ` Eli Zaretskii @ 2013-11-10 12:23 ` Andy Moreton 2013-11-10 18:24 ` Eli Zaretskii 1 sibling, 1 reply; 9+ messages in thread From: Andy Moreton @ 2013-11-10 12:23 UTC (permalink / raw To: 15834 On Fri 08 Nov 2013, Eli Zaretskii wrote: >> From: Andy Moreton <andrewjmoreton@gmail.com> >> Date: Fri, 08 Nov 2013 14:33:14 +0000 >> >> >> Bootstrapping a Windows msys build with bzr r115035 results in a crash >> when compiling lisp/net/tramp-smb.el: >> >> Lisp Backtrace: >> "Automatic GC" (0x14b050c) > > Can you show a C backtrace? > > Also, can you try reverting 115033, and see if that helps? I tried bootstrapping on a different machine from r115032 without problems. Bootstrapping from a clean tree from r115053 gave the same crash in compiling tramp-smb.el. Backtrace is: Thread 1 (Thread 3308.0x1994): #0 0x7c90120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll No symbol table info available. #1 0x01196714 in emacs_abort () at ../../src/w32fns.c:7984 button = <optimized out> #2 0x010b5f24 in terminate_due_to_signal (sig=sig@entry=0xb, backtrace_limit=backtrace_limit@entry=0x28) at ../../src/emacs.c:377 No locals. #3 0x010cef1d in handle_fatal_signal (sig=0xb) at ../../src/sysdep.c:1624 No locals. #4 deliver_thread_signal (sig=0xb, handler=<optimized out>) at ../../src/sysdep.c:1598 handler = 0x10cedd2 <handle_fatal_signal> #5 deliver_fatal_thread_signal (sig=0xb) at ../../src/sysdep.c:1636 No locals. #6 0x010011ea in _gnu_exception_handler@4 () No symbol table info available. #7 0x7c864209 in UnhandledExceptionFilter () from C:\WINDOWS\system32\kernel32.dll No symbol table info available. #8 0x0082b0b4 in ?? () No symbol table info available. #9 0x7c84396a in ValidateLocale () from C:\WINDOWS\system32\kernel32.dll No symbol table info available. #10 0x00000000 in ?? () No symbol table info available. Lisp Backtrace: "Automatic GC" (0x14b050c) "byte-optimize-form" (0x82b7cc) "mapcar" (0x82b908) "byte-optimize-form-code-walker" (0x82bab0) "byte-optimize-form" (0x82bc4c) "mapcar" (0x82bd88) "byte-optimize-form-code-walker" (0x82bf30) "byte-optimize-form" (0x82c0e0) "byte-optimize-body" (0x82c280) "byte-optimize-form-code-walker" (0x82c420) "byte-optimize-form" (0x82c5d0) "byte-optimize-body" (0x82c76c) "byte-optimize-form-code-walker" (0x82c910) "byte-optimize-form" (0x82cac0) "byte-optimize-form-code-walker" (0x82cc60) "byte-optimize-form" (0x82ce10) "byte-optimize-body" (0x82cfb4) "byte-optimize-form-code-walker" (0x82d150) "byte-optimize-form" (0x82d300) "byte-optimize-body" (0x82d4a0) "byte-optimize-form-code-walker" (0x82d640) "byte-optimize-form" (0x82d7e8) "byte-optimize-form-code-walker" (0x82d990) "byte-optimize-form" (0x82db3c) "byte-compile-top-level" (0x82dcf8) "byte-compile-lambda" (0x82debc) "byte-compile-file-form-defmumble" (0x82e060) 0x42c0c78 PVEC_COMPILED 0x403bf88 PVEC_COMPILED 0x403bfa0 PVEC_COMPILED "byte-compile-file-form-defalias" (0x82e770) "byte-compile-file-form" (0x82e8fc) "byte-compile-toplevel-file-form" (0x82ea8c) 0x3ff1f80 PVEC_COMPILED 0x3ff1f98 PVEC_COMPILED "funcall" (0x82eda0) "byte-compile-from-buffer" (0x82f0a8) "byte-compile-file" (0x82f248) 0x401dbb0 PVEC_COMPILED "funcall" (0x82f3d0) "batch-byte-compile-file" (0x82f6b0) "batch-byte-compile" (0x82f880) "command-line-1" (0x82fa18) "command-line" (0x82fbdc) "normal-top-level" (0x82fd20) (gdb) ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#15834: Crash during bootstrap 2013-11-10 12:23 ` Andy Moreton @ 2013-11-10 18:24 ` Eli Zaretskii 2013-11-10 23:04 ` Andy Moreton 0 siblings, 1 reply; 9+ messages in thread From: Eli Zaretskii @ 2013-11-10 18:24 UTC (permalink / raw To: Andy Moreton; +Cc: 15834 > From: Andy Moreton <andrewjmoreton@gmail.com> > Date: Sun, 10 Nov 2013 12:23:52 +0000 > > > Also, can you try reverting 115033, and see if that helps? > > I tried bootstrapping on a different machine from r115032 without > problems. Bootstrapping from a clean tree from r115053 gave the same > crash in compiling tramp-smb.el. Strange. I've just bootstrapped r115054, both with and without optimizations, and didn't see any crashes, neither in tramp-smb, nor anywhere else. > Backtrace is: > > Thread 1 (Thread 3308.0x1994): > #0 0x7c90120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll > No symbol table info available. > #1 0x01196714 in emacs_abort () at ../../src/w32fns.c:7984 > button = <optimized out> > #2 0x010b5f24 in terminate_due_to_signal (sig=sig@entry=0xb, backtrace_limit=backtrace_limit@entry=0x28) at ../../src/emacs.c:377 > No locals. > #3 0x010cef1d in handle_fatal_signal (sig=0xb) at ../../src/sysdep.c:1624 > No locals. > #4 deliver_thread_signal (sig=0xb, handler=<optimized out>) at ../../src/sysdep.c:1598 > handler = 0x10cedd2 <handle_fatal_signal> > #5 deliver_fatal_thread_signal (sig=0xb) at ../../src/sysdep.c:1636 > No locals. > #6 0x010011ea in _gnu_exception_handler@4 () > No symbol table info available. > #7 0x7c864209 in UnhandledExceptionFilter () from C:\WINDOWS\system32\kernel32.dll > No symbol table info available. > #8 0x0082b0b4 in ?? () > No symbol table info available. > #9 0x7c84396a in ValidateLocale () from C:\WINDOWS\system32\kernel32.dll > No symbol table info available. > #10 0x00000000 in ?? () > No symbol table info available. > > Lisp Backtrace: > "Automatic GC" (0x14b050c) > "byte-optimize-form" (0x82b7cc) Is this when running Emacs under GDB, or did you attach GDB when the abort dialog appeared? Because this shows that the MinGW startup code caught some fatal exception, but doesn't give enough info about which Emacs code triggered that exception. If compiling tramp-smb consistently triggers this crash, even if invoked manually outside of the context of bootstrap, then please run the compilation command under GDB, type "set debugexceptions 1" before typing "run", and see if you get a better backtrace. Alternatively, perhaps you could pause the compilation (e.g., with "Ctrl-S") when it just begins, attach the debugger then, type "set debugexceptions 1", then continue the program -- this should also provide more info about the exception. yet another way is to hack lisp/Makefile such that compilation of tramp-smb is invoked by running Emacs under GDB (using the --args option of GDB). Failing all that, please try figuring out why this happens to you and (evidently) no one else, and why in tramp-smb? Do you have some SMB-related software or environment variables set up on that system, per chance? Perhaps see if removing some of the top-level forms from tramp-smb makes the problem go away. Also, what options do you pass to "configure" and "make", and which optional packages (image libraries etc.) do you have installed? Are you using GCC and runtime from mingw.org or from some other distribution? The fact that the backtrace mentions ValidateLocale hints that it's possible that the problem is specific to some locales. Not sure what that tells us, though. In any case, I cannot for the life of me see what could cache-long-scans have to do with fatal exceptions like this one. Ideas are welcome. ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#15834: Crash during bootstrap 2013-11-10 18:24 ` Eli Zaretskii @ 2013-11-10 23:04 ` Andy Moreton 2013-11-11 3:50 ` Eli Zaretskii 0 siblings, 1 reply; 9+ messages in thread From: Andy Moreton @ 2013-11-10 23:04 UTC (permalink / raw To: 15834 On Sun 10 Nov 2013, Eli Zaretskii wrote: >> From: Andy Moreton <andrewjmoreton@gmail.com> >> Date: Sun, 10 Nov 2013 12:23:52 +0000 >> >> > Also, can you try reverting 115033, and see if that helps? >> >> I tried bootstrapping on a different machine from r115032 without >> problems. Bootstrapping from a clean tree from r115053 gave the same >> crash in compiling tramp-smb.el. > > Strange. I've just bootstrapped r115054, both with and without > optimizations, and didn't see any crashes, neither in tramp-smb, nor > anywhere else. I found r115053 crashed compiling tramp-smb.el when bootstrapping from a clean tree with -O2, but not with -O0. Recompiling tramp-smb.el from the built emacs also did not have any problems in either case. [snipped backtrace] > Is this when running Emacs under GDB, or did you attach GDB when the > abort dialog appeared? Because this shows that the MinGW startup code > caught some fatal exception, but doesn't give enough info about which > Emacs code triggered that exception. If compiling tramp-smb > consistently triggers this crash, even if invoked manually outside of > the context of bootstrap, then please run the compilation command > under GDB, type "set debugexceptions 1" before typing "run", and see > if you get a better backtrace. Alternatively, perhaps you could pause > the compilation (e.g., with "Ctrl-S") when it just begins, attach the > debugger then, type "set debugexceptions 1", then continue the program > -- this should also provide more info about the exception. yet > another way is to hack lisp/Makefile such that compilation of > tramp-smb is invoked by running Emacs under GDB (using the --args > option of GDB). I attached gdb after the abort dialog appeared. The problem only appears to occur with a bootstrap from a clean tree with optimisations enabled. I'll try your suggestions to see if I can get a better C backtrace. > Failing all that, please try figuring out why this happens to you and > (evidently) no one else, and why in tramp-smb? Do you have some > SMB-related software or environment variables set up on that system, > per chance? Perhaps see if removing some of the top-level forms from > tramp-smb makes the problem go away. I've seen this issue on two different windows boxes, so it is repeatable. I don't have anything strange running on these machines, (and they have different anti-virus tools, so that seems uninvolved). I'll keep looking as I have time, but it may take a while to diagnose. > Also, what options do you pass to "configure" and "make", and which > optional packages (image libraries etc.) do you have installed? Are > you using GCC and runtime from mingw.org or from some other > distribution? GCC and runtime are from mingw.org, installed via mingw-get. I also use various image libraries, most of which are from your handy download page. I keep image libs etc in a separate tree from the mingw.org tools and pass appropriate options to configure so it can find the libs and headers. > In any case, I cannot for the life of me see what could > cache-long-scans have to do with fatal exceptions like this one. > Ideas are welcome. I think it is unlikely that that cache-long-scans is involved. It is more likely to be some interaction between my build script, and recent changes to path handling in the makefiles and configury. As it seems to require a clean tree to reproduce the problem, narrowing it down will be somewhat time consuming. AndyM ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#15834: Crash during bootstrap 2013-11-10 23:04 ` Andy Moreton @ 2013-11-11 3:50 ` Eli Zaretskii 2013-11-11 13:08 ` Andy Moreton 0 siblings, 1 reply; 9+ messages in thread From: Eli Zaretskii @ 2013-11-11 3:50 UTC (permalink / raw To: Andy Moreton; +Cc: 15834 > From: Andy Moreton <andrewjmoreton@gmail.com> > Date: Sun, 10 Nov 2013 23:04:15 +0000 > > I found r115053 crashed compiling tramp-smb.el when bootstrapping from a > clean tree with -O2, but not with -O0. Recompiling tramp-smb.el from the > built emacs also did not have any problems in either case. What if you copy the initial bootstrap-emacs.exe while it is compiling, and try compiling tramp-smb with that afterwards, does it crash? > I think it is unlikely that that cache-long-scans is involved. It is > more likely to be some interaction between my build script, and recent > changes to path handling in the makefiles and configury. Yes, maybe the special way you invoke MSYS triggers something. Try removing unneeded things from the shell environment, perhaps. > As it seems to require a clean tree to reproduce the problem, narrowing > it down will be somewhat time consuming. "bzr branch" produces a clean tree with almost no cost. ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#15834: Crash during bootstrap 2013-11-11 3:50 ` Eli Zaretskii @ 2013-11-11 13:08 ` Andy Moreton 2013-11-11 16:37 ` Eli Zaretskii 0 siblings, 1 reply; 9+ messages in thread From: Andy Moreton @ 2013-11-11 13:08 UTC (permalink / raw To: 15834 On Mon 11 Nov 2013, Eli Zaretskii wrote: >> From: Andy Moreton <andrewjmoreton@gmail.com> >> Date: Sun, 10 Nov 2013 23:04:15 +0000 >> >> I found r115053 crashed compiling tramp-smb.el when bootstrapping from a >> clean tree with -O2, but not with -O0. Recompiling tramp-smb.el from the >> built emacs also did not have any problems in either case. > > What if you copy the initial bootstrap-emacs.exe while it is > compiling, and try compiling tramp-smb with that afterwards, does it > crash? I tried running bootstrap-emacs.exe with a batch compile on the command line without problems. >> I think it is unlikely that that cache-long-scans is involved. It is >> more likely to be some interaction between my build script, and recent >> changes to path handling in the makefiles and configury. > > Yes, maybe the special way you invoke MSYS triggers something. Try > removing unneeded things from the shell environment, perhaps. After switching to using a non-interactive login msys shell, I can't reproduce this on one of the machines, so I think this problem is probably pilot error and and can be closed. ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#15834: Crash during bootstrap 2013-11-11 13:08 ` Andy Moreton @ 2013-11-11 16:37 ` Eli Zaretskii 0 siblings, 0 replies; 9+ messages in thread From: Eli Zaretskii @ 2013-11-11 16:37 UTC (permalink / raw To: Andy Moreton; +Cc: 15834-done > From: Andy Moreton <andrewjmoreton@gmail.com> > Date: Mon, 11 Nov 2013 13:08:09 +0000 > > After switching to using a non-interactive login msys shell, I can't > reproduce this on one of the machines, so I think this problem is > probably pilot error and and can be closed. OK, done. Thanks for persevering, and feel free to reopen if and when you have new data. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-11-11 16:37 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-11-08 14:33 bug#15834: Crash during bootstrap Andy Moreton 2013-11-08 15:15 ` Eli Zaretskii 2013-11-08 15:22 ` Eli Zaretskii 2013-11-10 12:23 ` Andy Moreton 2013-11-10 18:24 ` Eli Zaretskii 2013-11-10 23:04 ` Andy Moreton 2013-11-11 3:50 ` Eli Zaretskii 2013-11-11 13:08 ` Andy Moreton 2013-11-11 16:37 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.