View Issue Details

IDProjectCategoryView StatusLast Update
0000725LDMud 3.3Runtimepublic2010-07-14 16:31
Reporterzesstra Assigned Tozesstra  
PrioritynormalSeverityminorReproducibilityhave not tried
Status resolvedResolutionfixed 
Platformi686OSGNU/LinuxOS Version4.0
Product Version3.3.719 
Target Version3.3.720Fixed in Version3.3.720 
Summary0000725: 'dumpallobj' crashes in svalue_size() on strings with 0 refs.
Descriptionsvalue_size() in dumpstat.c takes into account any sharing of entities. In case of strings, its memory size will be divided by the number of its refcounts.

In case of strings with a refcount of 0, this will crash, because the function does not check the refcount before division. (Note: ref==0 for strings are perfectly valid, it marks the strings as 'permanent' and it is never free'd.)
TagsNo tags attached.

Activities

zesstra

2010-02-13 04:06

administrator   ~0001720

The same behaviour exists for symbols, mappings, arrays and quoted arrays, structs and closures.

Mappings are free'd for ref<=0, they don't this 'don't free marker'. Although a mapping with 0 refs may occur if somebody just uses deref_mapping() instead of free_mapping().

Structs, Arrays and Closures should currently also not have 0 refs.
But one question is, if we might want to introduce the 'no free for ref==0'-behaviour for them as well. The background for this behaviour of strings is that it serves as a protection against overflowing refcounters. Once this happens and ref==0, any refcounting will be disabled. This overflow can also happen for all other shared entities, although it seems unlikely to happen in reality.

In this respect, we might conservatively check for ref==0 in all this cases, 'dumpallobj' is anyway rarely executed and will stop the mud for some time anyway...

zesstra

2010-02-13 05:56

administrator   ~0001721

I commited a fix for the immediate problem with strings in r2849 and r2848.
Concerning the other types I wait for comments.

zesstra

2010-07-13 14:12

administrator   ~0001873

Any opinions? Should I check for ref==0 just in case we change something somewhere else and forget about this?

Gnomi

2010-07-13 15:47

manager   ~0001875

I think a ref of 0 nearly always indicates an overflow and should be handled as such (the initialization and destruction of a value are the only exceptions I know of).

zesstra

2010-07-13 16:06

administrator   ~0001877

Ok... Then I will change svalue_size() first to cope with zero refcounters.
In a second step we then have to look at the refcounting code for the other shared entities. I guess I will open a new issue for that.

zesstra

2010-07-14 16:31

administrator   ~0001880

Ok, I changed svalue_size() to check for ref!=0 for all entities with ref counters in r2927 and r2928.

Issue History

Date Modified Username Field Change
2010-02-13 03:55 zesstra New Issue
2010-02-13 03:55 zesstra Status new => assigned
2010-02-13 03:55 zesstra Assigned To => zesstra
2010-02-13 04:06 zesstra Note Added: 0001720
2010-02-13 05:56 zesstra Note Added: 0001721
2010-07-13 14:12 zesstra Note Added: 0001873
2010-07-13 14:12 zesstra Status assigned => feedback
2010-07-13 15:47 Gnomi Note Added: 0001875
2010-07-13 16:06 zesstra Note Added: 0001877
2010-07-14 16:31 zesstra Note Added: 0001880
2010-07-14 16:31 zesstra Status feedback => resolved
2010-07-14 16:31 zesstra Fixed in Version => 3.3.720
2010-07-14 16:31 zesstra Resolution open => fixed