I've migrated a fairly complex application that was running fine under Pike 7.6 and am getting a number of different situations that cause segfaults.
I'm not able to completely rule out the possibility that there's a non-core pike c-module that may be to blame, but the module code has been running well and without any problems of this sort for a number of years.
The GDB backtraces look like this:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -145934672 (LWP 2582)] 0x081276e5 in low_object_index_no_free (to=0xffaaad58, o=0x88bfa78, f=67) at /root/Pike-v7.8.352/src/object.c:1252 1252 add_ref(to->u.dummy=dummy); (gdb) bt #0 0x081276e5 in low_object_index_no_free (to=0xffaaad58, o=0x88bfa78, f=67) at /root/Pike-v7.8.352/src/object.c:1252 #1 0x08133599 in index_no_free (to=0xffaaad58, what=0xf720f260, ind=0xffaaad60) at /root/Pike-v7.8.352/src/operators.c:87 #2 0x08076d57 in opcode_F_STRING_INDEX (arg1=702) at /home/zino/hack-local/Pike/7.8-distmaker/src/interpret_functions.h:1854 #3 0xf61c8a04 in ?? () #4 0x000002be in ?? () #5 0xf7610160 in __after_morecore_hook () from /lib/libc.so.6 #6 0xffaaad88 in ?? () #7 0x08a03870 in ?? () #8 0x00000000 in ?? ()
Any suggestions? This is 7.8.352 on an intel atom (64-bit debian).
Best,
Bill
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -145934672 (LWP 2582)] 0x081276e5 in low_object_index_no_free (to=0xffaaad58, o=0x88bfa78, f=67) at /root/Pike-v7.8.352/src/object.c:1252 1252 add_ref(to->u.dummy=dummy);
Looks like some kind of refcount error on the thing stored in identifier # 67 in the object o. I suggest you try to identify that thing and see if it's been in suspicious places. To begin with you can compile --with-rtldebug and use describe(o) to see what that object is and what the variable in identifier # 67 is.
Running with valgrind and/or --with-dmalloc-debug provides a sort of catch-all harness which may trig the error closer to the source, but both add a significant overhead.
pike-devel@lists.lysator.liu.se