Menu
▾
▴
[Tcl-bugs] [ tcl-Bugs-3001438 ] [info frame -1] sigsegv under strange circumstances
|
From: SourceForge.net <no...@so...> - 2010-06-02 16:07:47
|
Bugs item #3001438, was opened at 2010-05-14 00:52 Message generated for change (Comment added) made by msofer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3001438&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 47. Bytecode Compiler Group: development: 8.6b1.1 Status: Open Resolution: None Priority: 9 Private: No Submitted By: Colin McCormack (coldstore) Assigned to: miguel sofer (msofer) Summary: [info frame -1] sigsegv under strange circumstances Initial Comment: Linux, HEAD as at 2pm 14Mar10, get a sigsegv: 0x001741e3 in TclInfoFrame (interp=0x8055fc8, framePtr=0x805e148) at /home/colin/Desktop/packages/tcl/generic/tclCmdIL.c:1374 Of note: (gdb) p *namePtr $15 = {nextPtr = 0x805e280, tablePtr = 0x0, hash = 0x805e310, clientData = 0x24be10, key = {oneWordValue = 0x80ff6f8 "\002", objPtr = 0x80ff6f8, words = {135263992}, string = "\370\366\017\b"}} (gdb) p namePtr->tablePtr $16 = (Tcl_HashTable *) 0x0 I haven't a short way to reproduce this error, but it seems it may be related to namePtr->tablePtr being NULL. Colin. ---------------------------------------------------------------------- >Comment By: miguel sofer (msofer) Date: 2010-06-02 13:07 Message: Renaming stuff around to make sure we know what's what: still crashing oo::class create Tuple { method fixup {tuple} { if {$tuple == 0} { my foo 1 } } method foo {{arg 0}} { my fixup $arg info frame -1 } } set x [Tuple new] $x foo ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2010-06-02 12:39 Message: Verified that HEAD is still crashing (with --enable-symbols=all) with both Colin's and my "minimal" scripts, and that my workaround fix (use a local buffer instead of something returned by TclStackAlloc in TclInfoFrame) makes the crash stop. ---------------------------------------------------------------------- Comment By: Colin McCormack (coldstore) Date: 2010-06-02 11:30 Message: Here's a more minimal script to cause the crash oo::class create Tuple { method fixup {tuple} { if {$tuple == 0} { my new 1 } } method new {{arg 0}} { my fixup $arg info frame -1 } } [Tuple new] new ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2010-06-01 13:58 Message: Ouch, this involves both oo and [info frame] :( Working through the core dumped by dkf's small crashing script: #0 0x400e604b in strlen () from /lib/tls/i686/cmov/libc.so.6 #1 0x0808e50d in Tcl_AppendLimitedToObj (objPtr=0x87ed050, bytes=0x74207765 <Address 0x74207765 out of bounds>, length=-1, limit=2147483647, ellipsis=0x0) at /home/CVS/tcl/generic/tclStringObj.c:1078 #2 0x0808e68a in Tcl_AppendToObj (objPtr=0x87ed050, bytes=0x74207765 <Address 0x74207765 out of bounds>, length=-1) at /home/CVS/tcl/generic/tclStringObj.c:1146 #3 0x080dbf58 in Tcl_GetCommandFullName (interp=0x87903b0, command=0x8797994, objPtr=0x87ed050) at /home/CVS/tcl/generic/tclBasic.c:2816 #4 0x080f4c2e in TclInfoFrame (interp=0x87903b0, framePtr=0x87977f4) at /home/CVS/tcl/generic/tclCmdIL.c:1381 #5 0x080f41a1 in InfoFrameCmd (dummy=0x0, interp=0x87903b0, objc=2, objv=0x87f0fd0) at /home/CVS/tcl/generic/tclCmdIL.c:1210 At frame 4, I see: *framePtr looks fine *framePtr->framePtr looks fine *framePtr->framePtr->procPtr looks fine (body seems ok too) * framePtr->framePtr->procPtr->cmdPtr looks NOT OK In particular: hPtr, nsPtr contain bad data, no proc/objProc/nreProc at all, ... Now: both *framePtr and *framePtr->framePtr are TclStackAlloc'ed ... but *procPtr is not. dkf: can you please check that *framePtr->framePtr->procPtr looks ok? Details require some knowledge about oo inner workings, I guess. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2010-05-20 11:52 Message: Assigning to Miguel because this looks like some kind of weird problem in TclStackAlloc. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2010-05-19 11:59 Message: Bug appears to be caused by the TclStackAlloc-ated space for the method frame somehow overlapping with the TclStackAlloc-ated space for the CmdFrame that is allocated inside of TclInfoFrame. No idea how that comes to pass! If I change TclInfoFrame to use a local variable (should be OK for 48 bytes that don't persist) then everything works. The following code is the test case (and isn't far off minimal): oo::class create Tuple { method fixup {x} { if {$x eq "conversion"} {my New type} } method New {x} { my fixup $x puts >[info frame -1] } constructor {args} {my New conversion} } set ts [Tuple new] ---------------------------------------------------------------------- Comment By: Colin McCormack (coldstore) Date: 2010-05-19 10:30 Message: I have attached a 50 line program which reliably reproduces the crash here. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2010-05-17 06:48 Message: I've changed the code to now use Tcl_GetCommandFullName. This *should* only move the location of the crash into that function. The problem – a hash entry with a null pointer to its table – is a Can't Happen case so far as I can see. :-( ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2010-05-16 19:08 Message: OK, but [info frame] is not really my backyard :} Reassigning to dkf based on ChangeLog comments. (Might also be aku, that's TIP 280 stuff -- feel free to reassign again). ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2010-05-14 05:32 Message: I suspect that it is trying to inspect a method or lambda. Neither of those have a conventional command table reference, though they should both have NULL procPtr->cmdPtr or procPtr->cmdPtr->hPtr fields. Hope this helps tracking this down. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3001438&group_id=10894 |