View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000348 | LDMud 3.3 | Runtime | public | 2005-01-18 03:50 | 2005-05-15 13:02 |
Reporter | Gnomi | Assigned To | |||
Priority | normal | Severity | major | Reproducibility | sometimes |
Status | closed | Resolution | fixed | ||
Platform | i686 | OS | Debian GNU/Linux | OS Version | 3.0 |
Product Version | 3.3 | ||||
Fixed in Version | 3.3 | ||||
Summary | 0000348: Destructed objects still leak their program name | ||||
Description | Hi, I haven't found a way to reopen a bug, so I'm reporting this as a new one. Bug 0000099 still exists in 3.3.660: 2005.01.18 10:18:40 --- Garbage Collection --- 2005.01.18 10:18:40 GC pass 1: Freed 1 objects. clearing M_REF in chunk 10280180, end 1428018c clearing M_REF in chunk 08234000, end 0824000c scanning chunk 10280180, end 1428018c for unref'd blocks freeing small block 0x1328752c (user 0x13287534) prolang.y 16333 By object: secure/master By program: secure/master.c (/secure/master/preload.inc) line:44 13287548: 15 00 00 00 00 00 72 6f 6f 6d 2f 72 61 74 68 61 ......room/ratha 13287558: 75 73 2f 67 69 6c 64 65 6e 2e 63 00 2c 75 28 13 us/gilden.c.,u(. 13287568: 0f 00 00 60 f0 92 4a 62 4c c4 b5 13 00 00 00 ...`ð.JbLĵ.... freeing small block 0x1329e344 (user 0x1329e34c) prolang.y 16333 By object: secure/master By program: secure/master.c (/secure/master/preload.inc) line:44 1329e360: 00 00 00 00 c8 04 00 00 48 75 28 13 0a 00 00 60 ....È...Hu(....` 1329e370: b6 a4 89 bd 74 e4 29 13 01 00 00 ¶¤.½tä).... scanning chunk 08234000, end 0824000c for unref'd blocks 2 small blocks freed 2005.01.18 10:18:40 GC freed 0 destructed objects. /room/rathaus/gilden was destructed by its cleanup routine. I think this is the first garbage collection after the object was destructed, because none auf the previous garbage collections tell that objects were freed. Is there anything I can do to hunt this thing down? Greetings, Gnomi | ||||
Tags | No tags attached. | ||||
|
Let's keep an eye on this: the program name reference might leak somewhere else, too. |
|
I may have found the reason for this leak. There are two important conditions. First this string is referenced only by one program as his name. And second this program has been swapped out. In the clear phase neither the reference count of the program (which is temporarily swapped in) nor the count of its name will be cleared. In the mark phase only the reference count of the program will be cleared (but then both incremented). So during every garbage collection the reference count of the program name will not be cleared but incremented by one. Greetings, Gnomi |
|
Sounds logical - 3.3.661 should fix it. |
Date Modified | Username | Field | Change |
---|---|---|---|
2005-01-18 03:50 | Gnomi | New Issue | |
2005-01-18 21:29 |
|
Note Added: 0000309 | |
2005-01-19 06:26 | Gnomi | Note Added: 0000311 | |
2005-01-19 23:30 |
|
Status | new => resolved |
2005-01-19 23:30 |
|
Fixed in Version | => 3.3 |
2005-01-19 23:30 |
|
Resolution | open => fixed |
2005-01-19 23:30 |
|
Assigned To | => lars |
2005-01-19 23:30 |
|
Note Added: 0000312 | |
2005-05-15 13:02 |
|
Status | resolved => closed |