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)
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
pike-devel@lists.lysator.liu.se