Tcl Source Code

View Ticket
Login
Ticket UUID: 82e7f673254fd008222f542bde322a0ebb856e3d
Title: SIGSEGV due to [string replace]
Type: Bug Version: 4492d3b64521aaee
Submitter: andy Created on: 2014-04-29 22:54:40
Subsystem: 47. Bytecode Compiler Assigned To: dkf
Priority: 9 Immediate Severity: Critical
Status: Closed Last Modified: 2014-05-01 09:04:51
Resolution: Fixed Closed By: dkf
    Closed on: 2014-05-01 09:04:51
Description:
Version [4492d3b64521aaee] introduced a SIGSEGV when the following code is executed:

apply {{} {string length [string replace ___! 0 2 ab]}}
User Comments: dkf added on 2014-05-01 09:04:51:

Not a problem, but I might look into other ways to generate the string to insert (so that it will stay unshared even if we optimise further).


andy added on 2014-04-30 21:48:41:
Well, that strange.  I apologize for the typo.  In the original ticket, I had meant to say [join {a b} {}] instead of simply ab.  The point was to get an unshared value.  Sorry again for the misdirection, and thanks for the fix.

dkf added on 2014-04-30 21:26:15:

We now have tests that check for both releasing the refcount too early, and also for not releasing the refcount at all (a memory leak) and we now pass those tests.


dkf added on 2014-04-30 20:58:14:

Your longer apply crashes for me (and will be a reasonable test case with adjustment). Your analysis is likely right too.


anonymous added on 2014-04-30 01:11:06:
apply {{} {
  set a [join {a b} {}]
  puts [string length [string replace ___! 0 2 $a]]  ;# doesn't crash
  puts [string length [string replace ___! 0 2 $a[unset a]]]  ;# crashes
}}

it looks like it can happen when the replacement is unshared (suggesting it's trying to edit in place?)

possible cause at tclExecute.c:5705 - the only way into that block is when value3Ptr is unshared, then it's used as the result, and the refcount is subsequently decremented, and the result obj gets freed.