View Issue Details

IDProjectCategoryView StatusLast Update
0000099LDMud 3.3Runtimepublic2005-05-15 13:02
ReporterlarsAssigned Tolars 
PrioritynormalSeverityfeatureReproducibilitysometimes
Status closedResolutionfixed 
Fixed in Version3.3 
Summary0000099: Destructed objects leak their program name
DescriptionAfter 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 InformationThe 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.
TagsNo tags attached.

Relationships

related to 0000343 closedlars Garbage collection leaks object name 

Activities

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 .

Issue History

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