Making use of a coredump?

Hi!

I'm just wondering...

Not clear when and why, under Sparc/Solaris, ruby dies from time to
time, leaving a coredump.

Is there a way to get anything use of the core file? Is there a core
developer [pun] whom it could be sent, and then she/he could see what's
wrong?

Or should I just say "dammit", and delete the core file, and restart the
app?

Btw, s there a difference in usability of the core files in the various
platforms?

Csaba

Hi,

···

In message "Re: making use of a coredump?" on Fri, 18 Mar 2005 14:04:54 +0900, Csaba Henk <csaba@phony_for_avoiding_spam.org> writes:

Is there a way to get anything use of the core file? Is there a core
developer [pun] whom it could be sent, and then she/he could see what's
wrong?

When you have core

  % gdb ruby core
  (gdb) where

would print stack trace which might be helpful sometimes to track a
bug down.

              matz.

Hm, that's the top of it:

#0 0xff2a0190 in _libc_kill () from /usr/lib/libc.so.1
#1 0xff236ce0 in abort () from /usr/lib/libc.so.1
#2 0x945ac in rb_bug (fmt=0xac520 "Segmentation fault") at error.c:214
#3 0x74760 in sigsegv (sig=11) at signal.c:446
#4 <signal handler called>
#5 0xff2344e4 in strlen () from /usr/lib/libc.so.1
#6 0xff286c4c in _doprnt () from /usr/lib/libc.so.1
#7 0xff2888c8 in snprintf () from /usr/lib/libc.so.1
#8 0x259f0 in backtrace (lev=5390600) at eval.c:5959
#9 0x223a0 in rb_longjmp (tag=6, mesg=5369072) at eval.c:4309
#10 0x22428 in rb_exc_raise (mesg=5369072) at eval.c:4358
#11 0x95c64 in rb_sys_fail (mesg=0x51ecf0 "") at error.c:1121
#12 0x5ec24 in proc_wait (argc=2, argv=0xffbea2cc) at process.c:742
#13 0x5ec3c in proc_wait2 (argc=2, argv=0xffffffff) at process.c:772
#14 0x30940 in call_cfunc (func=0x5ec2c <proc_wait2>, recv=1024320,
len=-1, argc=1024320, argv=0xffbea5f0)
    at eval.c:5452
#15 0x24a2c in rb_call0 (klass=1024296, recv=1024320, id=8937, oid=8937,
argc=2, argv=0xffbea5f0, body=0xf9f60,
    nosuper=37) at eval.c:5522
#16 0x252ec in rb_call (klass=1024296, recv=1024320, mid=8937, argc=2,
argv=0xffbea5f0, scope=0) at eval.c:5743
#17 0x1fae8 in rb_eval (self=5429696, n=0x2) at ruby.h:631
#18 0x1fdcc in rb_eval (self=5429696, n=0xffbea9a8) at ruby.h:636

The bad thing happens in the backtrace function of eval.c,
when the backtrace info is to be printed:

    while (frame && (n = frame->node)) {
        if (frame->prev && frame->prev->last_func) {
            snprintf(buf, BUFSIZ, "%s:%d:in `%s'",
                     n->nd_file, nd_line(n),
                     rb_id2name(frame->prev->last_func));
        }
        else {
            snprintf(buf, BUFSIZ, "%s:%d", n->nd_file, nd_line(n));
        }

.... at the last sprintf. It happened with 1.8.2.

Csaba

···

On 2005-03-18, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

Hi,

In message "Re: making use of a coredump?" > on Fri, 18 Mar 2005 14:04:54 +0900, Csaba Henk <csaba@phony_for_avoiding_spam.org> writes:

Is there a way to get anything use of the core file? Is there a core
developer [pun] whom it could be sent, and then she/he could see what's
wrong?

When you have core

  % gdb ruby core
  (gdb) where

would print stack trace which might be helpful sometimes to track a
bug down.

              matz.