bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Simon Stapleton
Subject: bug#15088: 24.3; Hard crash on OSX when editing header files
Date: Wed, 14 Aug 2013 20:23:35 +0200

Hi Jan

Nope, nothing at all.  So I started trying to track down what was causing the 
issue.  Starting from a virgin .emacs.d/ and .emacs, started re-adding packages 
to find out which one actually breaks things.

And, wouldn't you know it, I'm pretty much back to where I was before, and it 
no longer happens.  The only thing I haven't reinstalled thus far is quack, 
which appears to no longer be in elpa/melpa, and shouldn't be touching C-mode 
files anyway.

This confuses me no end, as I'd started from a virgin .emacs / emacs.d when I 
moved to 24.3, and re-zapped them a few times trying to get rid of this very 
problem.

I can drop a zip/tarball of my old .emacs stuff if it would help anyone 
figuring out what's going on.





On 13 Aug 2013, at 22:29, Jan Djärv <jan.h.d@swipnet.se> wrote:

> Hello.
> 
> 13 aug 2013 kl. 20:58 skrev Simon Stapleton <simon.stapleton@gmail.com>:
> 
>> Okay, quick rebuild and I can now get a full backtrace.  xbacktrace still 
>> fails, but it's failing because (I assume) it's had its stack smashed
>> 
>>> No symbol "ARRAY_MARK_FLAG" in current context. 
>> 
>> ARRAY_MARK_FLAG looks a lot like a garbage collection bug being tickled, 
>> double release going on somewhere maybe?
>> 
>> The source of the issue is almost certainly to do with pabbrev - commenting 
>> it out in my .emacs makes everything work.
> 
> A lisp package should not be able to crash Emacs.  You can try to set these 
> in your environment before starting Emacs from the command line:
> 
> export NSZombieEnabled=YES
> export MallocGuardEdges=1
> export MallocScribble=1
> export MallocErrorAbort=1
> export MallocCorruptionAbort=1
> export MallocCheckHeapStart=1000
> 
> Emacs will run very slowly, but hopefully it will print something useful if 
> it is a memory issue.
> 
>       Jan D.
> 
> 






reply via email to

[Prev in Thread] Current Thread [Next in Thread]