View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000713||LDMud||Implementation||public||2010-01-18 02:42||2010-01-25 17:20|
|Summary||0000713: function names leaking in global string table?|
|Description||With the new string table allocator I get a lot of this in daily GC:|
tabled string ace9ca20 'trinke_com' was left unreferenced, freeing now.
(about 20-30 items per day). All of these are function names to add_actions(), so maybe there is some kind of memleak.
Of course, it could also be in our mudlib, but for now I prefer putting this here, because I wouldnt know where to start looking anyway.
|Tags||No tags attached.|
|External Data (URL)|
Uh, what new string allocator? AFAIR we didn't change anything in 3.5.
I believe, add_action() alone can not be the cause, I don't observe the issue in my testmud.
||Didn't you change the string allocator a while back? Or was it just the hash-function?|
||That was just the hash calculation and the length of the hashes and the max. no of chains in the table.|
Ok, strings don't have a user field and knowing the original allocator (from MALLOC_TRACE, MALLOC_LPC_TRACE) of a shared string may also be not too informative...
Can you tell if the strings are always the same strings or does it seem to be random?
||I can reproduce it. Add_action() keep doesn't free its reference to the function name.|
||Fixed in r2837.|
|2010-01-18 02:42||_xtian_||New Issue|
|2010-01-24 13:55||zesstra||Note Added: 0001698|
|2010-01-24 14:30||_xtian_||Note Added: 0001699|
|2010-01-24 14:42||zesstra||Note Added: 0001700|
|2010-01-24 16:23||zesstra||Note Added: 0001701|
|2010-01-24 17:17||Gnomi||Note Added: 0001702|
|2010-01-24 17:17||Gnomi||Assigned To||=> Gnomi|
|2010-01-24 17:17||Gnomi||Reproducibility||sometimes => always|
|2010-01-24 17:17||Gnomi||Status||new => acknowledged|
|2010-01-24 17:17||Gnomi||Status||acknowledged => confirmed|
|2010-01-25 17:20||Gnomi||Note Added: 0001703|
|2010-01-25 17:20||Gnomi||Status||confirmed => resolved|
|2010-01-25 17:20||Gnomi||Resolution||open => fixed|