platform: windows2003
tcl: 8.4.6 compiled for thread support
itcl: 3.3
thread package: 2.5
I run multiple threads using Itcl and I get:
Itcl_ReleaseData can't find reference for 0x6d62528
and tcl crashes.
foreach Itcl_ReleaseData, there was a coresponding
Itcl_PreserveData. Any trace on where that's coming from
and how the logic isn't matching? Was this a double delete?
The only thing that's different under threads is Itcl's
global resource hash table is under a synclock.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In itcl_util.c there is a bug in Itcl_ReleaseData, for
some reason the mutex for the hash table is unlocked,
memory is freed, then relocked
I realize that there is performance implications for
unlocking the mutex so another thread can use the hash
table during this operation, the problem however is that
in the time you free memory and relock the table someone
else might have allocated that same memory location and
tried to put it in the hash table (keep in mind tcl
objects are a constant size, it's not uncommon to recycle
memory for something like this)
My advice would be
1) do not unlock the hash table in Itcl_ReleaseData (easy
fix)
2) rewrite this section of Itcl to use thread local
storage with each thread having its own hash table, this
prevents any resource contention between threads, and
would solve the performance issue with solution #1 (long
term solution)
I hope this helps someone as it's a significant issue for
anyone using threads with Itcl
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=7549
foreach Itcl_ReleaseData, there was a coresponding
Itcl_PreserveData. Any trace on where that's coming from
and how the logic isn't matching? Was this a double delete?
The only thing that's different under threads is Itcl's
global resource hash table is under a synclock.
Logged In: YES
user_id=1393747
In itcl_util.c there is a bug in Itcl_ReleaseData, for
some reason the mutex for the hash table is unlocked,
memory is freed, then relocked
I realize that there is performance implications for
unlocking the mutex so another thread can use the hash
table during this operation, the problem however is that
in the time you free memory and relock the table someone
else might have allocated that same memory location and
tried to put it in the hash table (keep in mind tcl
objects are a constant size, it's not uncommon to recycle
memory for something like this)
My advice would be
1) do not unlock the hash table in Itcl_ReleaseData (easy
fix)
2) rewrite this section of Itcl to use thread local
storage with each thread having its own hash table, this
prevents any resource contention between threads, and
would solve the performance issue with solution #1 (long
term solution)
I hope this helps someone as it's a significant issue for
anyone using threads with Itcl