Re: [master b3cf281] Unbreak the MinGW build

[Bruno Haible <bruno@clisp.org>]

Eli Zaretskii wrote:
> > - How often have you tried to temacs+dump with and without the change?
> >   Once each? Twice each? 10 times each? If it's a small number, you may
> >   be seeing a random result and not realize it was random.
> 
> I did it in two separate branches, 3 times in each one.  The results
> are consistent.  This crash isn't random.
> 
> > - Did you run temacs in the same directory in both cases, or in different
> >   directories? Different directories could lead to a different memory
> >   layout in temacs, due to different filename lengths.
> 
> Same directory.
> 
> > - After determining that disabling the include would fix the crash, did
> >   you test whether reenable the include would reenable the crash?
> 
> Yes.

OK, that much for our "conventional" wisdom...

Since, as you say, the crash occurs during dumping, this is what I would
turn to now. Do you have a systematic approach for debugging crashes during
dump? If dump is based on malloc, does it help to set MALLOC_PERTURB_?
Can you use tools such as valgrind to debug it?

> Having
> uncommitted/unpushed changes in master means I need to jump through
> hoops each time I need to push a change upstream.

Yes, having to do
  $ git rebase -i HEAD~2
  $ git push origin HEAD~1:master
each time is extra work.

> > I wouldn't have applied this patch, as the cause of the crash is obviously
> > somewhere else.
> 
> I know.

Actually gnulib has a way to keep in your project changes relative to gnulib
that should not be pushed upstream: It's gnulib-tool's --local-dir option.
You would have had to create a small lib/stdio-impl.h.diff file that gets
applied on the fly each time you invoke gnulib-tool for emacs.

Bruno