Recursive Pike_error calls

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Recursive Pike_error calls

Stephen R. van den Berg
Any suggestions on how I can find out in this coredump where the
original exception was?  (i.e. which pike file and linenumber point
at the spot where we tried to access the variable in the destructed object).

Pike compiled with -O2 -g, no PIKE_DEBUG.

Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x7f67bf559700 (LWP 13931))]
(gdb) where
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007f67c5e6f537 in __GI_abort () at abort.c:79
#2  0x0000564c892d44cd in debug_va_fatal (fmt=<optimized out>,
    args=args@entry=0x7f67bf558828) at /home/srb/81pike/src/error.c:511
#3  0x0000564c892d471c in debug_fatal (
    fmt=fmt@entry=0x564c89425e60 "Recursive Pike_error() calls, original error: %s, new error: %s") at /home/srb/81pike/src/error.c:583
#4  0x0000564c892d4b6c in va_error (
    fmt=0x564c8942e1f0 "Cannot access variables in destructed object.\n",
    args=args@entry=0x7f67bf558928) at /home/srb/81pike/src/error.c:289
#5  0x0000564c892d4cac in Pike_error (
    fmt=fmt@entry=0x564c8942e1f0 "Cannot access variables in destructed object.\n") at /home/srb/81pike/src/error.c:332
#6  0x0000564c8932b190 in low_object_index_no_free (to=<optimized out>,
    o=<optimized out>, f=<optimized out>) at /home/srb/81pike/src/object.c:1373
#7  0x00007f67c45d37ec in ?? ()
#8  0x0000564c8d2c2e30 in ?? ()
#9  0x0000564c8aef2d88 in ?? ()
#10 0x0000000000000000 in ?? ()
(gdb)

--
Stephen.
Reply | Threaded
Open this post in threaded view
|

Recursive Pike_error calls

Martin Nilsson (Coppermist) @ Pike (-) developers forum
> Any suggestions on how I can find out in this coredump where the
> original exception was?  (i.e. which pike file and linenumber point
> at the spot where we tried to access the variable in the destructed object).

You didn't get a backtrace from debug_va_fatal()?

As far as I can see, the access to a variable in a destructed object
was from the error handling code (usually master()->handle_error()).

If you are able to trigger the bug again, I would recomend running it
in gdb and doing a

  (gdb) call gdb_backtraces()

when the abort is triggered.

Another approach could be to alter error.c:debug_va_fatal() to call
gdb_backtraces() when/if it fails to render a backtrace. I've now
modified it accordingly in Pike master.

        /grubba