Re: [master b3cf281] Unbreak the MinGW build

[Eli Zaretskii]

> From: Bruno Haible <address@hidden>
> Cc: address@hidden
> Date: Sat, 17 Dec 2016 00:17:31 +0100
> 
> 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?

Why would I need them?  The dumping code on Windows is just C code
that reads and writes a binary file, so GDB is good enough, it shows
exactly what causes the crash.  Except that what it told me made very
little sense, so I tried the "blame the last change" approach.  Which
worked, even though examining the source-level changes clearly
indicates that the new fpending.c does the same as the old one did, as
long as you compare the executable C code in the two versions.

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

I didn't ask to propagate the change back into Gnulib, that was Paul's
decision.  I understand his motivation, but I'm okay with anything you
decide about Gnulib.

I will try to look into this some more today, and see if I can unlock
the mystery.  It bothers me, too.

Thanks.