- From: Fox One <rockman66_1999@yahoo.com>
- Date: Thu, 6 Jul 2000 03:20:38 -0700 (PDT)
- To: www-amaya@w3.org
The following is a long and esoteric discussion of a bug hunt using the gnu debugger. The following bug does not allways occur. It takes several tries to evoke it. * Enter http://lists.w3.org in the url bar * hit enter to go the the web page * erase the default search string with the backspace key * enter "+document diff" as the new search string * double click the search button * select the second item in the list * (it might be a message with a subject of Extrnals.html) * click on the back button * click the back button again * (you are now back at the page: http://lists.w3.org/Archives/Public/www-lib/ , but the page's tables have been messed up; if the tables look okay, then go back to step 4 [enter a new search string]) * click on the back button * click on the forward button * click on the back button * click on the forward button * (continue to do this until the crash occurs) * (if you are lucky, Amaya crashes :-) GDB says the following: Program received signal SIGSEGV, Segmentation fault. IsParentBox (pAncestor=0x8d1aa90, pChild=0x1380) at ../../thotlib/view/boxmoves.c:171 171 pAb = pChild->BxAbstractBox; (gdb) list 166 if (pChild == NULL || pAncestor == NULL) 167 return (FALSE); 168 else 169 { 170 /* Look for pChild ancestors including itself */ 171 pAb = pChild->BxAbstractBox; 172 equal = FALSE; 173 while (!equal && pAb != NULL) 174 { 175 equal = pAb->AbBox == pAncestor; (gdb) frame 1 #1 0x80cc83c in DifferFormatting (table=0x8bb1be8, cell=0x0, frame=1) at ../../tablelib/tableH.c:102 102 else if (IsParentBox (table->AbBox, pLockRel->LockRTable[i]->AbBox)) (gdb) print table $1 = 0x8bb1be8 (gdb) print table->AbBox $2 = 0x8d1aa90 (gdb) print pLockRel $3 = 0x8e7c110 (gdb) print i $4 = 0 (gdb) print pLockRel->LockRTable $5 = {0x8bb8458, 0x8bb0f68, 0x0, 0x0, 0x0} (gdb) print pLockRel->LockRTable[0] $6 = 0x8bb8458 (gdb) print pLockRel->LockRTable[0]->AbBox $7 = 0x1380 (gdb) print pLockRel->LockRTable[1]->AbBox $8 = 0x6 The values 0x1380 and 0x6 are almost certainly invalid pointers. In previous debugging sessions I've found "pLockRel->LockRTable[0]->AbBox" to have values of 0x2, 0x5, and 0xd. "pLockRel->LockRTable[1]->AbBox" had a value of 0x3 at one time. I believe that some other function in Amaya is clobbering the data used by DifferFormatting() and IsParentBox(). Furthurmore, the function that does the clobbering is probably one that does something to structures of the type `struct _AbstractBox.' Why do I say this? Notice that the lock relations table's elements (the pointers to abstract boxes) are not clobbered, but the "AbBox" pointer elements (inside of `struct _AbstractBox') are. The following is more information useable mostly to gdb people: (gdb) print pLockRel->LockRTable[0]->AbElement $9 = 0x0 (gdb) print pLockRel->LockRTable[0]->AbEnclosing $10 = 0xa (gdb) print pLockRel->LockRTable[0]->AbNext $11 = 0x0 (gdb) print pLockRel->LockRTable[0]->AbPrevious $12 = 0x0 (gdb) print pLockRel->LockRTable[0]->AbFirstEnclosed $13 = 0xc (gdb) print pLockRel->LockRTable[0]->AbNextRepeated $14 = 0x0 (gdb) print pLockRel->LockRTable[0]->AbPreviousRepeated $15 = 0xa (gdb) print pLockRel->LockRTable[0]->AbPSchema $16 = 0x0 (gdb) print pLockRel->LockRTable[1]->AbElement $17 = 0x0 (gdb) print pLockRel->LockRTable[1]->AbEnclosing $18 = 0x71 (gdb) print pLockRel->LockRTable[1]->AbNext $19 = 0x0 (gdb) print pLockRel->LockRTable[1]->AbPrevious $20 = 0x8bb0f38 (gdb) print pLockRel->LockRTable[1]->AbFirstEnclosed $21 = 0x0 (gdb) print pLockRel->LockRTable[1]->AbNextRepeated $22 = 0x5 (gdb) print pLockRel->LockRTable[1]->AbPreviousRepeated $23 = 0x2 (gdb) print pLockRel->LockRTable[1]->AbPSchema $24 = 0x0 Since a `struct _AbstractBox' is a rather large and ungainly structure, I don't want to look at all of the elements. But it seems that the two structures above are pretty well clobbered. It could be that a pointer to a `struct _AbstractBox' is typecast to something else, and when that pointer is used, the AbstractBox is fowled up. Also, it could be that a union is used to overlay an AbstractBox with some other structure, but the type of the resulting union's elements isn't managed correctly. When trying to find the source of this bug, the Amaya team should examine typecasts and unions involving AbstractBox. __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/
Received on Thursday, 6 July 2000 06:21:10 UTC