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