git master HEAD crashes emacs

git master HEAD crashes emacs

[Steinar Bang]

I've had two emacs crashes when running gnus today.
Both have happened with using `n' to go to the next unread in
gmane.discuss on the news.gmane.org NNTP server.

Re: git master HEAD crashes emacs

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> I've had two emacs crashes when running gnus today.
> Both have happened with using `n' to go to the next unread in
> gmane.discuss on the news.gmane.org NNTP server.

I'm unable to reproduce that with bzr Emacs.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: git master HEAD crashes emacs

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> I'm unable to reproduce that with bzr Emacs.

I'm using Emacs 23.2.1.

I'm not able to reproduce it in a predictable fashion, either.

Re: git master HEAD crashes emacs

[Steinar Bang]

>>>>> Steinar Bang <sb@dod.no>:

> I'm not able to reproduce it in a predictable fashion, either.

Happened again today.  Not quite the HEAD of git, but nearly (updated
yesterday afternoon).

debian testing (squeeze), and GNU Emacs 23.2.1.

What I did was to read articles in a group on the primary server (a
non-gmane NNTP server, specifically news.get.no).  They were fairly old
articles, and I was reading them out of order.

Re: git master HEAD crashes emacs

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> What I did was to read articles in a group on the primary server (a
> non-gmane NNTP server, specifically news.get.no).  They were fairly old
> articles, and I was reading them out of order.

Would it be possible for you to run Emacs under gdb?  That would give
you a backtrace when Emacs crashes.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: git master HEAD crashes emacs

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Would it be possible for you to run Emacs under gdb?  That would give
> you a backtrace when Emacs crashes.

Possible, but cumbersome.  Especially since the emacs crashes happens so
seldom and unpredicably.

Is there a way to make emacs do core dumps, like it (and other programs)
used to do, back in the nineties?

That should be sufficient to get a stack trace, shouldn't it?

I'll research the core dump possibilities...

Re: git master HEAD crashes emacs

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> Possible, but cumbersome.  Especially since the emacs crashes happens so
> seldom and unpredicably.

Yeah, those rare crashes are a pain to track down.

> Is there a way to make emacs do core dumps, like it (and other programs)
> used to do, back in the nineties?

If you find out, let me know.  :-)  I tried once a few years ago and
just gave up.  It's apparently controlled by the shell or something.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: git master HEAD crashes emacs

[Andreas Schwab]

Steinar Bang <sb@dod.no> writes:

> Is there a way to make emacs do core dumps, like it (and other programs)
> used to do, back in the nineties?

It dumps core like any other program.  But running under a debugger is
much more efficient.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: git master HEAD crashes emacs

[Steinar Bang]

>>>>> Andreas Schwab <schwab@linux-m68k.org>:

> Steinar Bang <sb@dod.no> writes:
>> Is there a way to make emacs do core dumps, like it (and other programs)
>> used to do, back in the nineties?

> It dumps core like any other program.  But running under a debugger is
> much more efficient.

I may have had to build my own kernel to get core dumps (the google hits
were inconclusive.  It may be that it would be enough to edit
limits.conf...?

But at the end of the day it was simpler to start emacs in gdb.  So
that's what I'm doing.

Re: git master HEAD crashes emacs

[Dan Christensen]

Steinar Bang <sb@dod.no> writes:

> I may have had to build my own kernel to get core dumps (the google hits
> were inconclusive.  It may be that it would be enough to edit
> limits.conf...?

If you are using bash,

  ulimit -c

will show the current soft limit for core file size and 

  ulimit -c -H

will show the hard limit (the maximum you can raise the soft limit
too).  If the hard limit allows it, you can raise the soft limit
using

  ulimit -c 200000

(as an example, the units are 512-byte disk blocks, so that would be
100MB) or even

  ulimit -c unlimited

The setting only applies to the current shell, and once set, you
can only decrease it.

Dan

Re: git master HEAD crashes emacs

[Steinar Bang]

Thanks!  

All I know about cores is that once upon a time all unixen and linuxen
dumped cores, and then the linuxen stopped, and I never bothered
figuring out why, because the cores were mostly a nuisance to clean
up...:-)


(but I think I'll continue with the gdb approach)

Re: git master HEAD crashes emacs

[Steinar Bang]

>>>>> Steinar Bang <sb@dod.no>:

> (but I think I'll continue with the gdb approach)

Got a crash today.  The backtrace wasn't very useful... no debug info in
neither emacs, nor the libraries it was linked with,  I guess...?

(gdb) backtrace
#0  0x081791f1 in ?? ()
#1  0x0818e575 in ?? ()
#2  0x0818f689 in ?? ()
#3  0x0811152b in ?? ()
#4  0x0808e90d in ?? ()
#5  0x080907b3 in ?? ()
#6  0x0818ccc7 in ?? ()
#7  0x0807bdaf in ?? ()
#8  0x080924a0 in ?? ()
#9  0x08092f37 in ?? ()
#10 0x0805979e in ?? ()
#11 0x0818e714 in ?? ()
#12 0x081c6a41 in ?? ()
#13 0x0818e204 in ?? ()
#14 0x0818e523 in ?? ()
#15 0x081c6a41 in ?? ()
#16 0x0818e204 in ?? ()
#17 0x0818e523 in ?? ()
#18 0x0818fb0f in ?? ()
#19 0x0818e796 in ?? ()
#20 0x081c6a41 in ?? ()
#21 0x0818dd98 in ?? ()
#22 0x08190342 in ?? ()
#23 0x081c5c9a in ?? ()
#24 0x0818e204 in ?? ()
#25 0x0818e523 in ?? ()
#26 0x0818f689 in ?? ()
#27 0x08126c76 in ?? ()
#28 0x08126f3b in ?? ()
#29 0x0812a6bf in ?? ()
#30 0x0812a8e7 in ?? ()
#31 0x081ce3f5 in ?? ()
#32 0x0812b860 in ?? ()
#33 0x0812d62e in ?? ()
#34 0x0812f97b in ?? ()
#35 0x0818cdc1 in ?? ()
#36 0x08128cd5 in ?? ()
#37 0x0818cea1 in ?? ()
#38 0x0812963f in ?? ()
#39 0x081299da in ?? ()
#40 0x08129b02 in ?? ()
#41 0x0811e18d in ?? ()
#42 0xb725dc76 in __libc_start_main () from /lib/i686/cmov/libc.so.6
#43 0x080567b1 in ?? ()

Oh well... I guess there isn't any point going through the trouble of
running emacs from gdb anymore...?

Re: git master HEAD crashes emacs

[Alberto Luaces]

Steinar Bang writes:

>>>>>> Steinar Bang <sb@dod.no>:
>
>> (but I think I'll continue with the gdb approach)
>
> Got a crash today.  The backtrace wasn't very useful... no debug info in
> neither emacs, nor the libraries it was linked with,  I guess...?
>
> (gdb) backtrace

[...]

> #42 0xb725dc76 in __libc_start_main () from /lib/i686/cmov/libc.so.6
> #43 0x080567b1 in ?? ()
>
> Oh well... I guess there isn't any point going through the trouble of
> running emacs from gdb anymore...?

To get the calling stack you have to use debugging information. To do
that, configure first with

configure CPPFLAGS=-g

and then make & make install.

-- 
Alberto