View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000674 | LDMud | Runtime | public | 2009-09-16 05:33 | 2009-09-16 07:28 |
| Reporter | _xtian_ | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | new | Resolution | open | ||
| Summary | 0000674: memleak: copying self referencing mappings | ||||
| Description | Avalon is being plagued by a memleak and baba@avalon seems to have found its cause: copying a mapping that holds a self-reference. Now tracking memleaks is difficult, but I am appending some code in the hopes that you will be able to reproduce it in an isolated environment. | ||||
| Additional Information | // memleak.c mapping m; // global to not obfuscate my output void leak() { mapping n; printf("starting ...\n"); m=([]); m["self"]= m; // set self reference n= deep_copy(m); // this is the leak, leads to ref-counter being off } void pre() { printf("preparing ...\n"); efun::garbage_collection(); // clean slate } void post() { printf("post ...\n"); efun::garbage_collection("MEMLEAK"); printf("done.\n"); } void create() { pre(); leak(); post(); } | ||||
| Tags | No tags attached. | ||||
| External Data (URL) | |||||
|
|
After some discussion on d-chat: a) self-referencing in general is the problem b) there is no trivial way to efficiently check for self-refcounts when creating/deleting the self-referencing data, which I would need here (not at GC time!) c) Although Im still hoping that this may be adressed someday in the future, on the short-term we should not use self-referencing data in LPC |
