Re: [Zope-dev] recipe for trapping SIGSEGV and SIGILL signals on solaris
At Tue, 11 Dec 2001 10:42:46 -0500, Matthew T. Kromer wrote:
#0 0xef5b9810 in _lwp_sema_wait () (gdb) info threads 19 Thread 10 0xef5b9810 in _lwp_sema_wait () 18 Thread 9 0xef5b9810 in _lwp_sema_wait () 17 Thread 8 0xef5b9810 in _lwp_sema_wait () 16 Thread 7 (LWP 8) subtract_refs (containers=0x13dec8) at ./Modules/gcmodule.c:166
Aha! See?
Matthew - I performed the operations that you recommended and here are the results (see below). The problem seems to be with the value of the tp_traverse field. I am not aware of any "T" type python object. I'm wondering if this is an extension class type (just a guess). I searched through all of the *.c files in zope, etc. but I as not able to find any type of name "T". I also ran across a bug posting at sourceforge ... http://sourceforge.net/tracker/?func=detail&atid=105470&aid=471942&group_id=... This bug report looks very similiar. - j #0 0xef5b9810 in _lwp_sema_wait () (gdb) info threads 19 Thread 10 0xef5b9810 in _lwp_sema_wait () 18 Thread 9 0xef5b9810 in _lwp_sema_wait () 17 Thread 8 0xef5b9810 in _lwp_sema_wait () 16 Thread 7 (LWP 8) subtract_refs (containers=0x13dec8) at ./Modules/gcmodule.c:166 15 Thread 6 0xef647cac in _swtch () 14 Thread 5 0xef5b9810 in _lwp_sema_wait () 13 Thread 4 (LWP 0) 0xef647b7c in _swtch () 12 Thread 3 0xef647cac in _swtch () 11 Thread 2 (LWP 2) 0xef5b9958 in _signotifywait () 10 Thread 1 (LWP 6) 0xef5b7488 in _poll () 9 LWP 9 0xef5b6a24 in door_restart () 8 LWP 8 subtract_refs (containers=0x13dec8) at ./Modules/gcmodule.c:166 7 LWP 7 0xef5b9810 in _lwp_sema_wait () 6 LWP 6 0xef5b7488 in _poll () 5 LWP 5 0xef5b9814 in _lwp_sema_wait () 4 LWP 4 0xef5b9810 in _lwp_sema_wait () 3 LWP 3 0xef5b9810 in _lwp_sema_wait () 2 LWP 2 0xef5b9958 in _signotifywait () * 1 LWP 1 0xef5b9810 in _lwp_sema_wait () (gdb) thread 16 [Switching to Thread 7 (LWP 8)] #0 subtract_refs (containers=0x13dec8) at ./Modules/gcmodule.c:166 ./Modules/gcmodule.c:166: No such file or directory. (gdb) print *((PyObject *) gc)->ob_type $1 = {ob_refcnt = 18213696, ob_type = 0x2d70b0, ob_size = 0, tp_name = 0x1 "T", tp_basicsize = 1328272, tp_itemsize = 4156348, tp_dealloc = 0x125865c, tp_print = 0x3c1b04, tp_getattr = 0, tp_setattr = 0, tp_compare = 0x29, tp_repr = 0x3adeb0, tp_as_number = 0xf66198, tp_as_sequence = 0xdf3fa0, tp_as_mapping = 0x0, tp_hash = 0x1, tp_call = 0x144490 <PyMethod_Type>, tp_str = 0x3f0a1c, tp_getattro = 0x125865c, tp_setattro = 0x3c1b04, tp_as_buffer = 0x0, tp_flags = 158561192, tp_doc = 0x29 "", tp_traverse = 0x4c4f4144, tp_clear = 0xd908c0, tp_richcompare = 0x1151300, tp_weaklistoffset = 0} (gdb) print *((PyObject *) 0x2d70b0)->ob_type $2 = {ob_refcnt = 2977968, ob_type = 0xff5b80, ob_size = 0, tp_name = 0x1 "T", tp_basicsize = 1328272, tp_itemsize = 4155228, tp_dealloc = 0x125865c, tp_print = 0x3c1b04, tp_getattr = 0, tp_setattr = 0, tp_compare = 0x29, tp_repr = 0, tp_as_number = 0x1212b48, tp_as_sequence = 0xbf8d30, tp_as_mapping = 0xffffffff, tp_hash = 0x1, tp_call = 0x144490 <PyMethod_Type>, tp_str = 0x4ab2cc, tp_getattro = 0x1089d5c, tp_setattro = 0x4ab30c, tp_as_buffer = 0x0, tp_flags = 0, tp_doc = 0x29 "", tp_traverse = 0, tp_clear = 0x122d140, tp_richcompare = 0x11ccd70, tp_weaklistoffset = -1} gdb) x 0x4c4f4144 0x4c4f4144: Cannot access memory at address 0x4c4f4144.
(gdb) print *((PyObject *) gc)->ob_type $1 = {ob_refcnt = 18213696, ob_type = 0x2d70b0, ob_size = 0, tp_name = 0x1 "T", tp_basicsize = 1328272, tp_itemsize = 4156348, tp_dealloc = 0x125865c, tp_print = 0x3c1b04, tp_getattr = 0, tp_setattr = 0, tp_compare = 0x29, tp_repr = 0x3adeb0, tp_as_number = 0xf66198, tp_as_sequence = 0xdf3fa0, tp_as_mapping = 0x0, tp_hash = 0x1, tp_call = 0x144490 <PyMethod_Type>, tp_str = 0x3f0a1c, tp_getattro = 0x125865c, tp_setattro = 0x3c1b04, tp_as_buffer = 0x0,
tp_flags = 158561192, tp_doc = 0x29 "", tp_traverse = 0x4c4f4144, tp_clear = 0xd908c0, tp_richcompare = 0x1151300, tp_weaklistoffset = 0} [...] gdb) x 0x4c4f4144 0x4c4f4144: Cannot access memory at address 0x4c4f4144.
0x4c4f4144 is big-endian ascii for "LOAD". Things were corrupted before... Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 10 http://nuxeo.com mailto:fg@nuxeo.com
Florent Guillaume wrote:
(gdb) print *((PyObject *) gc)->ob_type $1 = {ob_refcnt = 18213696, ob_type = 0x2d70b0, ob_size = 0, tp_name = 0x1 "T", tp_basicsize = 1328272, tp_itemsize = 4156348, tp_dealloc = 0x125865c, tp_print = 0x3c1b04, tp_getattr = 0, tp_setattr = 0, tp_compare = 0x29, tp_repr = 0x3adeb0, tp_as_number = 0xf66198, tp_as_sequence = 0xdf3fa0, tp_as_mapping = 0x0, tp_hash = 0x1, tp_call = 0x144490 <PyMethod_Type>, tp_str = 0x3f0a1c, tp_getattro = 0x125865c, tp_setattro = 0x3c1b04, tp_as_buffer = 0x0,
tp_flags = 158561192, tp_doc = 0x29 "", tp_traverse = 0x4c4f4144, tp_clear = 0xd908c0, tp_richcompare = 0x1151300, tp_weaklistoffset = 0}
[...]
gdb) x 0x4c4f4144 0x4c4f4144: Cannot access memory at address 0x4c4f4144.
0x4c4f4144 is big-endian ascii for "LOAD". Things were corrupted before...
Florent
Yes, the whole block is bad, so it probably isn't really a Python type object. The refcount is a bit high, the name is really low (0x01!) the basicsize and itemsize are extremely large, the compare function is too low, the hash function is too low -- ie it isn't a type object. So, I may have been telling him to get the wrong thing; the source code that he faulted in reads: /* Subtract internal references from gc_refs */ static void subtract_refs(PyGC_Head *containers) { traverseproc traverse; PyGC_Head *gc = containers->gc_next; for (; gc != containers; gc=gc->gc_next) { /* The next line is the line that was active at the time of his fault */ traverse = PyObject_FROM_GC(gc)->ob_type->tp_traverse; (void) traverse(PyObject_FROM_GC(gc), (visitproc)visit_decref, NULL); } } And PyObject_FROM_GC(gc) is either (gc) or ((PyObject *)(((PyGC_Head *)gc)+1)) depending on on whether or not WITH_CYCLE_GC is defined. I took the easy route and asked Joe to assume that the former was true. If the latter is true, then the type object is shifted upwards in memory by three words; the new first three fields are gc_next, gc_prev, and gc_refs. That means every value in the type header is off by three fields, if it isn't aligned, meaning the real type object would be: gc_next = 0x115eb40 gc_prev = 0x2d70b0 gc_refs = 0 ob_refcnt = 0x1 ob_type = 0x144490 (which we actually know is <PyMethod_Type> -- yay) ob_size = 0x3f6bbc (which is too large for my comfort) tp_name = 0x12865c (valid pointer but we dont know what it is) tp_basicsize=0x3c1b04 (seems high again, but is 0x350b8 less than ob_size) tp_itemsize = 0 tp_dealloc = 0 tp_print = 0x29 (boo!) tp_getattr = 0x3adeb0 tp_setattr = 0xf66198 tp_compare = 0xdf3fa0 tp_repr = 0 tp_as_number = 1 (boo!) tp_as_sequence = 0x144490 <PyMethod_Type> (boo!) etc... even shifting THESE values by 1 (assuming the compiler takes PyGC_Head which is three words and pads it up to 4 words for alignment) puts garbage values like 0x29 in tp_dealloc. Ergo, I'm pretty confident that the gc pointer itself is bad. If I was just a *wee* bit more familiar with how Solaris loaded segments, I'd be able to glean some more information from the addresses (ie are they code or data segment pointers). Normally I like seeing OS's use the high nybble or byte of an address as a segment number to make that sort of diagnosis easier. It actually looks like page zero is MAPPED on Solaris (I didnt think it was) which in my book is a baaad thing since it means a null pointer CAN be dereferenced.
participants (3)
-
Florent Guillaume -
Joseph Wayne Norton -
Matthew T. Kromer