0000099: Destructed objects leak their program name - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update

0000099	LDMud 3.3	Runtime	public	2004-07-21 22:49	2005-05-15 13:02

Reporter	~~lars~~	Assigned To	~~lars~~
Priority	normal	Severity	feature	Reproducibility	sometimes
Status	closed	Resolution	fixed
Fixed in Version	3.3

Summary	0000099: Destructed objects leak their program name
Description	After an object was destroyed I got the following message from the garbage collector: freeing small block 0x141e78d8 (user 0x141e78e0) prolang.y 16124 By object: secure/master By program: secure/master.c (/secure/master/preload.inc) line:44 141e78f4: 00 00 00 00 20 05 00 00 44 b4 20 14 0a 00 00 60 .... ...D´ ....` 141e7904: b6 a4 89 bd 88 7c 20 14 00 00 00 ¶¤.½.\| .... freeing small block 0x1420b428 (user 0x1420b430) prolang.y 16124 By object: secure/master By program: secure/master.c (/secure/master/preload.inc) line:44 1420b444: 0c 00 00 00 00 00 61 70 70 73 2f 77 68 6f 69 73 ......apps/whois 1420b454: 2e 63 00 14 0a 00 00 30 30 58 2a fc 18 0d 98 08 .c.....00X*ü.... 1420b464: 01 00 00 ... 2 small blocks freed I got it for other objects too. At one time I could reproduce it by just destroying an object that was loaded in the epilog, but that has gone after I restarted the driver. (But I got it also for objects which were not loaded by the master object.)
Additional Information	The first block is the management structure of the program name, the second the actual program name. The problem was found by Gnomi and Menaures with the crasher program.
Tags	No tags attached.

Gnomi 2005-01-17 07:50 manager ~0000305	I have to disappoint you, but this isn't related to 0000343 as I thought earlier. This leak is still there in 3.3.659: 2005.01.17 12:57:27 --- Garbage Collection --- 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 0x13528c38 (user 0x13528c40) prolang.y 16333 By object: secure/master By program: secure/master.c (/secure/master/preload.inc) line:44 13528c54: 15 00 00 00 00 00 72 6f 6f 6d 2f 72 61 74 68 61 ......room/ratha 13528c64: 75 73 2f 67 69 6c 64 65 6e 2e 63 00 38 8c 52 13 us/gilden.c.8.R. 13528c74: 0f 00 00 30 08 3c 09 71 f0 dd ff bf 00 00 00 ...0.<.qðÝÿ¿... freeing small block 0x1353cb34 (user 0x1353cb3c) prolang.y 16333 By object: secure/master By program: secure/master.c (/secure/master/preload.inc) line:44 1353cb50: 00 00 00 00 92 04 00 00 54 8c 52 13 0a 00 00 30 ........T.R....0 1353cb60: 30 58 2a fc f0 dd ff bf 00 00 00 0X*üðÝÿ¿... scanning chunk 08234000, end 0824000c for unref'd blocks 2 small blocks freed 2005.01.17 12:57:29 GC freed 0 destructed objects. Greetings, Gnomi

~~lars~~ 2005-01-17 15:10 reporter ~0000306	'Related to' in this case means that this problem might have a cause similar to 0000343. ...and indeed (I just tested it): using the same test code as for 0000343 and just replacing clone_object() with load_object(): object dest = load_object("/a"); mixed * x = ({ dest, 0 }); x[1] = x; destruct(dest) followed by two GCs produces exactly this GC log.

~~lars~~ 2005-01-17 16:32 reporter ~0000308	Like in Bug 0000343, the program's name's references weren't cleared if the only reference left was from a destructed object. Fixed in 3.3.660 .

Date Modified	Username	Field	Change
2004-07-21 22:49	~~lars~~	New Issue
2005-01-15 01:29	~~lars~~	Relationship added	related to 0000343
2005-01-17 07:50	Gnomi	Note Added: 0000305
2005-01-17 15:10	~~lars~~	Note Added: 0000306
2005-01-17 16:32	~~lars~~	Status	new => resolved
2005-01-17 16:32	~~lars~~	Fixed in Version	=> 3.3
2005-01-17 16:32	~~lars~~	Resolution	open => fixed
2005-01-17 16:32	~~lars~~	Assigned To	=> lars
2005-01-17 16:32	~~lars~~	Note Added: 0000308
2005-05-15 13:02	~~lars~~	Status	resolved => closed