bug#15834: Crash during bootstrap

[Andy Moreton <andrewjmoreton@gmail.com>]

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