#5041 multi-level return from source in safe interps

obsolete: 8.5.11
closed-duplicate
8
2012-06-11
2012-05-28
No

I was trying to ensure that [return -level 2] works inside a sourced script in a safe interpreter (created with safe::interpCreate so using some aliases, including for [source]) and I found that the test below caused a crash. The crash doesn't appear to be related to the implementation of the aliased version of [source]; I tried several and got a crash every time.

test safe-8.10 {safe source and return} -setup {
set returnScript [makeFile {return -level 2 "ok"} return.tcl]
catch {safe::interpDelete $i}
} -body {
safe::interpCreate $i
set token [safe::interpAddToAccessPath $i [file dirname $returnScript]]
$i eval [list apply {filename {
source $filename
error boom
}} $token/[file tail $returnScript]]
} -cleanup {
catch {safe::interpDelete $i}
removeFile $returnScript
} -result ok

I'm not 100% sure that the test is right, but I'm sure it shouldn't crash…

Discussion

  • Don Porter

    Don Porter - 2012-06-05

    No crash when the test is run alone. Crash is seen
    when combined with other tests, and only after the test
    is complete.

    When the test is run alone, it errors.

    ==== safe-8.10 safe source and return FAILED
    ==== Contents of test case:

    safe::interpCreate $i
    set token [safe::interpAddToAccessPath $i [file dirname $returnScript]]
    $i eval [list apply {filename {
    source $filename
    error boom
    }} $token/[file tail $returnScript]]

    ---- Test generated error; Return code was: 1
    ---- Return code should have been one of: 0 2
    ---- errorInfo: can't read "i": no such variable
    while executing
    "safe::interpCreate $i"
    ("uplevel" body line 2)
    invoked from within
    "uplevel 1 $script"
    ---- errorCode: TCL LOOKUP VARNAME i
    ==== safe-8.10 FAILED

    When run with some other safe-8* tests, it passes.

     
  • Don Porter

    Don Porter - 2012-06-05
    • milestone: 2101542 --> obsolete: 8.5.11
     
  • Don Porter

    Don Porter - 2012-06-05

    Same symptoms on tip of core-8-5-branch. Seeking
    a fix there first.

     
  • Don Porter

    Don Porter - 2012-06-05

    Program received signal SIGSEGV, Segmentation fault.
    0x00000000004e8dc2 in TclProcCleanupProc (procPtr=0x93d330)
    at /home/dgp/fossil/tcl8.5/unix/../generic/tclProc.c:2205
    2205 hePtr = Tcl_FindHashEntry(iPtr->linePBodyPtr, (char *) procPtr);
    (gdb) bt
    #0 0x00000000004e8dc2 in TclProcCleanupProc (procPtr=0x93d330)
    at /home/dgp/fossil/tcl8.5/unix/../generic/tclProc.c:2205
    #1 0x00000000004e90f2 in FreeLambdaInternalRep (objPtr=0x98f9c0)
    at /home/dgp/fossil/tcl8.5/unix/../generic/tclProc.c:2436
    #2 0x00000000004d3e41 in TclFreeObj (objPtr=0x9720a0)
    at /home/dgp/fossil/tcl8.5/unix/../generic/tclObj.c:1439

     
  • Don Porter

    Don Porter - 2012-06-05

    At this point iPtr->linePBodyPtr is NULL, so the
    Tcl_FindHashEntry() macro crashes.

     
  • Andreas Kupries

    Andreas Kupries - 2012-06-05

    That field for #280 support, associated proc bodies with line information.
    It is keyed by proc body pointers.
    However here the whole hashtable seems to not be initialized at all ?!
    An issue with safe interps ?

     
  • Don Porter

    Don Porter - 2012-06-05

    Trouble is rooted in a Lambda that manages to survive the
    death of its interp.

     
  • Don Porter

    Don Porter - 2012-06-05

    There's nothing in place to assure that procPtr->iPtr doesn't
    hold a (Tcl_Interp *) that's already been freed. Either something
    has to go in place to do that (don't think that's right), or all code
    that pulls a value from procPtr->iPtr has to be able to tolerate that
    value being an invalid pointer. Hmmmm....

     
  • Don Porter

    Don Porter - 2012-06-07
    • status: open --> closed-duplicate
     
  • Don Porter

    Don Porter - 2012-06-07

    Simple demo of the crash problem opened
    as ticket 3532959

     
  • Andreas Kupries

    Andreas Kupries - 2012-06-11

    Can this ticket be closed, now that ticket 3532959 is fixed?

     
  • Andreas Kupries

    Andreas Kupries - 2012-06-11
    • status: closed-duplicate --> open
     
  • Andreas Kupries

    Andreas Kupries - 2012-06-11
    • status: open --> closed-duplicate
     
  • Andreas Kupries

    Andreas Kupries - 2012-06-11

    Sorry, I had the bug open and missed that it is closed already.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks