View Revisions: Issue #2489
[ Back to Issue ]
Summary | 0002489: Memory leaks | ||
---|---|---|---|
Revision | 2016-12-05 19:50 by Chris Young | ||
Additional Information | I've attached the full log. The leaks are at the very bottom and say they have been freed in stdlib_malloc.c (this is clib2's internal free of unfreed tracked memory) I will deal with the Amiga frontend ones. If I get to any "core" leaks I will update this report to show which have been fixed. The line numbers are correct as of git commit 54e31b65d14dd1e228106eae0c60ab42802a97ed |
||
Revision | 2016-12-05 19:54 by Chris Young | ||
Additional Information | I've attached the full log. The leaks are at the very bottom and say they have been freed in stdlib_malloc.c (this is clib2's internal free of unfreed tracked memory) I will deal with the Amiga frontend ones. If I get to any "core" leaks I will update this report to show which have been fixed. The entries with no "allocated at" information have come from a library which hasn't been built with the debug defines, I will report on those separately at a later date. The line numbers are correct as of git commit 54e31b65d14dd1e228106eae0c60ab42802a97ed |
||
Revision | 2016-12-05 19:50 by Chris Young | ||
Description | I've built the Amiga frontend of NetSurf with clib's memory debugging mode. This logs memory allocations and will note when they haven't been freed. The short version is that allocations on the following files/lines are failing to be freed on at least one occasion: utils/nsoption.c:485 utils/nsoption.c:497 utils/nsoption.c:131 utils/hashtable.c:81 utils/hashtable.c:89 utils/hashtable.c:135 utils/hashtable.c:145 utils/useragent.c:55 desktop/cookie_manager.c:451 |
||
Revision | 2016-12-05 19:55 by Chris Young | ||
Description | I've built the Amiga frontend of NetSurf with clib's memory debugging mode. This logs memory allocations and will note when they haven't been freed. The short version is that "core" allocations in the following files/lines are failing to be freed on at least one occasion: utils/nsoption.c:485 utils/nsoption.c:497 utils/nsoption.c:131 utils/hashtable.c:81 utils/hashtable.c:89 utils/hashtable.c:135 utils/hashtable.c:145 utils/useragent.c:55 desktop/cookie_manager.c:451 |
||
Revision | 2016-12-05 19:55 by Chris Young | ||
Additional Information | I've attached the full log. The leaks are at the very bottom and say they have been freed in stdlib_malloc.c (this is clib2's internal free of unfreed tracked memory) I will deal with the Amiga frontend ones. If I get to any "core" leaks I will update this report to show which have been fixed (I realise some of the "core" leaks might actually be the responsibility of the frontend to free!) The entries with no "allocated at" information have come from a library which hasn't been built with the debug defines, I will report on those separately at a later date. The line numbers are correct as of git commit 54e31b65d14dd1e228106eae0c60ab42802a97ed |
||
Revision | 2016-12-05 23:44 by Chris Young | ||
Description | I've built the Amiga frontend of NetSurf with clib's memory debugging mode. This logs memory allocations and will note when they haven't been freed. The short version is that "core" allocations in the following files/lines are failing to be freed on at least one occasion: utils/hashtable.c:81 utils/hashtable.c:89 utils/hashtable.c:135 utils/hashtable.c:145 utils/useragent.c:55 desktop/cookie_manager.c:451 |
||
Revision | 2016-12-05 23:44 by Chris Young | ||
Additional Information | I've attached the full log. The leaks are at the very bottom and say they have been freed in stdlib_malloc.c (this is clib2's internal free of unfreed tracked memory) I will deal with the Amiga frontend ones. If I get to any "core" leaks I will update this report to show which have been fixed (I realise some of the "core" leaks might actually be the responsibility of the frontend to free! - such as the nsoption ones I've now fixed) The entries with no "allocated at" information have come from a library which hasn't been built with the debug defines, I will report on those separately at a later date. The line numbers are correct as of git commit 2dd97b0b8e1f363542dddb403d515cce132b7f29 |