View Issue Details

IDProjectCategoryView StatusLast Update
0000713LDMudImplementationpublic2010-01-25 17:20
Reporter_xtian_ Assigned ToGnomi  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Summary0000713: function names leaking in global string table?
DescriptionWith 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.
TagsNo tags attached.
External Data (URL)

Activities

zesstra

2010-01-24 13:55

administrator   ~0001698

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.

_xtian_

2010-01-24 14:30

reporter   ~0001699

Didn't you change the string allocator a while back? Or was it just the hash-function?

zesstra

2010-01-24 14:42

administrator   ~0001700

That was just the hash calculation and the length of the hashes and the max. no of chains in the table.

zesstra

2010-01-24 16:23

administrator   ~0001701

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?

Gnomi

2010-01-24 17:17

manager   ~0001702

I can reproduce it. Add_action() keep doesn't free its reference to the function name.

Gnomi

2010-01-25 17:20

manager   ~0001703

Fixed in r2837.

Issue History

Date Modified Username Field Change
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