bug#15088: 24.3; Hard crash on OSX when editing header files

["Jan Djärv" <jan.h.d@swipnet.se>]

Hello.

13 aug 2013 kl. 18:01 skrev Simon Stapleton <simon.stapleton@gmail.com>:

> This bug report will be sent to the Bug-GNU-Emacs mailing list
> and the GNU bug tracker at debbugs.gnu.org.  Please check that
> the From: line contains a valid email address.  After a delay of up
> to one day, you should receive an acknowledgment at that address.
> 
> Please write in English if possible, as the Emacs maintainers
> usually do not have translators for other languages.
> 
> Please describe exactly what actions triggered the bug, and
> the precise symptoms of the bug.  If you can, give a recipe
> starting from `emacs -Q':
> 
> I'm seeing repeatable crashes when editing header files, specifically
> when adding include guards.
> 
> Recipe :
> 
> - start emacs
> c-x c-f /tmp/foo.h
> #ifndef FOO_H
> 
> <crash>
> 

I can't repeat this with trunk or 24.3.

> If I manage to get in fast enough to add a #endif afterwards, the crash
> doesn't happen (to get this to work I usually have to reopen emacs, do a
> M-x recover-this-file, type *really fast*, suffer another crash anyway,
> and I can then restart emacs, M-x recover-this-file and I'm away.
> 
> Running under gdb, I get the following backtrace.
> 
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000030
> 0x00000001001691a1 in add_properties ()
...
> (gdb) xbacktrace
> Undefined command: "xbacktrace".  Try "help".
> 
> xbacktrace doesn't do anything on my gdb.  Go figure.

You have to be in the emacs source src/ directory, and do
% gdb ../nextstep/Emacs.app/Contents/MacOS/Emacs

or otherwise make gdb read the .gdbinit in the src/ directory.

> 
> My suspicion is that pabbrev is triggering the issue, but quite how, I don't know.
> 

How would that be involved if you started with -Q?

	Jan D.