> From: Bruno Haible <br...@clisp.org> > Cc: bug-gnulib@gnu.org > 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.
