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
