Investigating crash (Bug#11395) on Mac OS

Investigating crash (Bug#11395) on Mac OS

[Chong Yidong]

Could someone who is running on Mac OS please help investigate the crash
reported at

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11395

?  It's claimed to be reproducible, but I can't get it to crash on my
end (x86_64-unknown-linux-gnu), so maybe some part of the Nextstep code
is not GC-safe.

Thanks.

Re: Investigating crash (Bug#11395) on Mac OS

[Liang Wang]

On Fri, May 4, 2012 at 10:32 AM, Chong Yidong <cyd@gnu.org> wrote:
> Could someone who is running on Mac OS please help investigate the crash
> reported at
>
>  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11395

I have experienced similar issue on Mac OS, but I haven't got crash either.

>
> ?  It's claimed to be reproducible, but I can't get it to crash on my
> end (x86_64-unknown-linux-gnu), so maybe some part of the Nextstep code
> is not GC-safe.
>
> Thanks.
>

Re: Investigating crash (Bug#11395) on Mac OS

[Ivan Andrus]

On May 4, 2012, at 4:32 AM, Chong Yidong wrote:

> Could someone who is running on Mac OS please help investigate the crash
> reported at
> 
>  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11395
> 
> ?  It's claimed to be reproducible, but I can't get it to crash on my
> end (x86_64-unknown-linux-gnu), so maybe some part of the Nextstep code
> is not GC-safe.
> 
> Thanks.

I was getting this quite regularly (about every 15 minutes) a week ago (from bzr head), but after I got done traveling (Tuesday) I updated and I haven't experienced it since.  I assumed someone had fixed it so I didn't bother reporting it.  In the past several years it has been very stable updating from bzr head every so often.  So at least for me it's been very version dependent.

When I debugged it once it was stuck in a loop with internal_condition_case returning 0 (instead of Qnil) or something like that.  I also remember one time when the window information got corrupted in some way so that point-min wasn't a marker.  The result was that I couldn't do anything including closing the window because it would error.

So it seems it's probably (random) memory corruption, but you probably knew that.  Why it's fixed now for me, I don't know.  If you would like I could try and bisect to see what changed. Hopefully it's not dependent on the phase of the moon. :-)  Is there anything else I could do to try and figure it out?  IIRC running it under valgrind, which would be my first instinct, isn't supported.

-Ivan

Re: Investigating crash (Bug#11395) on Mac OS

[Chong Yidong]

Ivan Andrus <darthandrus@gmail.com> writes:

> I was getting this quite regularly (about every 15 minutes) a week ago
> (from bzr head), but after I got done traveling (Tuesday) I updated
> and I haven't experienced it since.  I assumed someone had fixed it so
> I didn't bother reporting it.  In the past several years it has been
> very stable updating from bzr head every so often.  So at least for me
> it's been very version dependent.

If this is right, there may have been a fix committed to trunk but
missing from the release branch (since Bug#11395 was reported for the
24.0.96 pretest).

If you can, please try bisecting.  That would help tremendously.  The
(so far incomplete) recipe posted by Richard Stanton in the bug page for
Bug#11395 may help if you can reproduce it.

> IIRC running it under valgrind, which would be my first instinct,
> isn't supported.

Running `valgrind ./temacs -l loadup' works for me (apart from the usual
cloud of false positives due to GC).  But maybe it doesn't work on Mac
OS, I dunno.

Re: Investigating crash (Bug#11395) on Mac OS

[Glenn Morris]

Chong Yidong wrote:

> Could someone who is running on Mac OS please help investigate the crash
> reported at
>
>   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11395

Note that #11395 seems to be running the same pre-built binary as:

http://debbugs.gnu.org/11257

Both are running on 10.7.3, and using a binary apparently built on
10.6.8. #11257 said his issues went away when he compiled Emacs himself:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11257#52

Re: Investigating crash (Bug#11395) on Mac OS

[chad]

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]

I am unable to reproduce the bug on a locally-built macosx 10.7.3 machine.

*Chad

On May 4, 2012, at 9:50 AM, Glenn Morris wrote:
> 
> Note that #11395 seems to be running the same pre-built binary as:
> 
> http://debbugs.gnu.org/11257
> 
> Both are running on 10.7.3, and using a binary apparently built on
> 10.6.8. #11257 said his issues went away when he compiled Emacs himself:
> 
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11257#52
> 


[-- Attachment #2: Type: text/html, Size: 805 bytes --]

Re: Investigating crash (Bug#11395) on Mac OS

[Randal L. Schwartz]

>>>>> "Liang" == Liang Wang <netcasper@gmail.com> writes:

Liang> I have experienced similar issue on Mac OS, but I haven't got
Liang> crash either.

Ditto.  Recent builds seem to be occasionally just "freezing".

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion

Re: Investigating crash (Bug#11395) on Mac OS

[Chong Yidong]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

>>>>>> "Liang" == Liang Wang <netcasper@gmail.com> writes:
>
> Liang> I have experienced similar issue on Mac OS, but I haven't got
> Liang> crash either.
>
> Ditto.  Recent builds seem to be occasionally just "freezing".

Then please run Emacs under gdb and post a backtrace when the freeze
occurs.

Re: Investigating crash (Bug#11395) on Mac OS

[Felix Geller]

[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]

Hi,

perhaps this (cropped) trace helps: https://gist.github.com/2644938

(bt -100 after gdb -p 42)

I'm not very experienced with gdb and my Emacs has no symbol table for
debugging (bt full -100 is complaining). Any help on how to get the
symbol table would be great, then I could possibly provide more helpful
info.

I haven't encountered crashes so far, but after using Emacs for a day or
so, it often goes on short trips to GC nirvana for several seconds. My
version: 

GNU Emacs 24.1.50.2 (i386-apple-darwin11.3.0, NS apple-appkit-1138.32)
of 2012-05-04 on ryo.localdomain.de


Cheers,
Felix



On Tue, 08 May 2012 10:40:03 +0800, Chong Yidong <cyd@gnu.org> wrote:
> merlyn@stonehenge.com (Randal L. Schwartz) writes:
> 
> >>>>>> "Liang" == Liang Wang <netcasper@gmail.com> writes:
> >
> > Liang> I have experienced similar issue on Mac OS, but I haven't got
> > Liang> crash either.
> >
> > Ditto.  Recent builds seem to be occasionally just "freezing".
> 
> Then please run Emacs under gdb and post a backtrace when the freeze
> occurs.
> 

-- 
Felix Geller

[-- Attachment #2: Type: application/pgp-signature, Size: 242 bytes --]

Re: Investigating crash (Bug#11395) on Mac OS

[Ivan Andrus]

On May 4, 2012, at 12:38 PM, Chong Yidong wrote:

> Ivan Andrus <darthandrus@gmail.com> writes:
> 
>> I was getting this quite regularly (about every 15 minutes) a week ago
>> (from bzr head), but after I got done traveling (Tuesday) I updated
>> and I haven't experienced it since.  I assumed someone had fixed it so
>> I didn't bother reporting it.  In the past several years it has been
>> very stable updating from bzr head every so often.  So at least for me
>> it's been very version dependent.
> 
> If this is right, there may have been a fix committed to trunk but
> missing from the release branch (since Bug#11395 was reported for the
> 24.0.96 pretest).
> 
> If you can, please try bisecting.  That would help tremendously.  The
> (so far incomplete) recipe posted by Richard Stanton in the bug page for
> Bug#11395 may help if you can reproduce it.

My attempts at bisecting were an utter failure.  First I had problems building after using bzr bisect so I decided to bisect "manually".  I was able to easily reproduce the problem with some revisions e.g. 108034 by repeatedly exporting an org file to pdf (only required 3-5 exports).  I was unable (after 10-15 exports) to reproduce the problem with other revisions e.g. 108049.  I had to leave it though, and now that I come back to it I can't reproduce the problem with revision 108034.  So there's something weird going on.

FWIW I was trying to bisect "backwards" by finding the revision where it was fixed for me.  There were far fewer commits that way since I hadn't previously updated for about a month.

>> IIRC running it under valgrind, which would be my first instinct,
>> isn't supported.
> 
> Running `valgrind ./temacs -l loadup' works for me (apart from the usual
> cloud of false positives due to GC).  But maybe it doesn't work on Mac
> OS, I dunno.


That's good to know.  But `valgrind ./emacs` wouldn't work I assume?  Anyway, I'll try it later if I can reproduce the error.

-Ivan

Re: Investigating crash (Bug#11395) on Mac OS

[Chong Yidong]

Ivan Andrus <darthandrus@gmail.com> writes:

> I was able to easily reproduce the problem with some revisions
> e.g. 108034 by repeatedly exporting an org file to pdf (only required
> 3-5 exports).  I was unable (after 10-15 exports) to reproduce the
> problem with other revisions e.g. 108049.  I had to leave it though,
> and now that I come back to it I can't reproduce the problem with
> revision 108034.  So there's something weird going on.

Could you bisect using the emacs-24 branch rather than the trunk?  The
trunk will probably be "noiser" since there have been lots of changes
there since the freeze was lifted.