Subject: Re: bug#16901: 24.3.50; emacs_backtrace.txt

From: Eli Zaretskii <[email-masked]>
Date: Sat, 01 Mar 2014 10:47:14 +0200

> Date: Fri, 28 Feb 2014 19:44:46 +0400
> From: Dmitry Antipov <[email-masked]>
> CC: [email-masked], [email-masked], 
>  Emacs development discussions <[email-masked]>
> 
> Now I have two crash reports to make me worry about GC. Both are
> irregular and looks hard to reproduce:
> 
>   - this bug (crash in compact_small_strings, MS-Windows only (?))
> 
>   - http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16817#11 - crash
>     marking C stack, OSX-only (?)
> 
> These crashes may be originated by the same bug (probably irregular
> heap corruption). It's known that GC-related crashes may be caused
> by freeing fonts during gc_sweep; this is
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16069, but it should
> not affect MS-Windows and OSX (and hopefully I'll fix it soon).
> 
> On GNU/Linux, valgrind makes great job in finding memory-related
> errors; if there are similar tools for other platforms, it would
> be nice to try. And what about using GCC and (sorry RMS) LLVM
> sanitizers?

This is exacerbated by the fact that Drew, who is the only one that
reports such assertion violations on Windows, doesn't build his Emacs.
So using temacs under valgrind-like tool is not an option in this
case.

I'm not aware of any tools comparable with valgrind that work on
Windows with GCC-generated symbol tables.  However, since Emacs on
Windows uses gmalloc, perhaps Juanma could build Emacs with GC_MCHECK
defined, which might catch the villain closer to the corruption locus.
Last time I hit a segfault in 'free', turning on these checks in
gmalloc allowed me to find the culprit in just a few minutes of
debugging, which is quite impressive for this sort of bugs.