View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000725 | LDMud 3.3 | Runtime | public | 2010-02-13 03:55 | 2010-07-14 16:31 |
| Reporter | zesstra | Assigned To | zesstra | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | resolved | Resolution | fixed | ||
| Platform | i686 | OS | GNU/Linux | OS Version | 4.0 |
| Product Version | 3.3.719 | ||||
| Target Version | 3.3.720 | Fixed in Version | 3.3.720 | ||
| Summary | 0000725: 'dumpallobj' crashes in svalue_size() on strings with 0 refs. | ||||
| Description | svalue_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.) | ||||
| Tags | No tags attached. | ||||
|
|
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... |
|
|
I commited a fix for the immediate problem with strings in r2849 and r2848. Concerning the other types I wait for comments. |
|
|
Any opinions? Should I check for ref==0 just in case we change something somewhere else and forget about this? |
|
|
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). |
|
|
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. |
|
|
Ok, I changed svalue_size() to check for ref!=0 for all entities with ref counters in r2927 and r2928. |
| 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 |
