2019-12-11 04:33 UTC

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002490LibWapcaplet[All Projects] Generalpublic2019-09-07 14:01
ReporterChris Young 
Assigned ToDaniel Silverstone 
PrioritynormalSeverityminorReproducibilityN/A
StatusresolvedResolutionfixed 
PlatformAmigaOSAmigaOSOS Version3.5
Summary0002490: Memory leaks in libwapcaplet
DescriptionI'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.

See bug 2489 for more info.

For libwapcaplet, we have the following not freed:
src/libwapcaplet.c:58 (0002046:0000008 bytes)
src/libwapcaplet.c:66 (~16364 bytes)
Additional InformationRelevant part of the log:

[NetSurf] - 8 0x10814570 [allocated at src/libwapcaplet.c:58, freed at stdlib_malloc.c:399]
[NetSurf] - 16364 0x10814D7C [allocated at src/libwapcaplet.c:66, freed at stdlib_malloc.c:399]
TagsNo tags attached.
Fixed in CI build #
Reported in CI build #3794
Attached Files

-Relationships
related to 0002489resolvedChris Young NetSurf Memory leaks 
+Relationships

-Notes
Chris Young

~0001954

Chris Young (developer)

This is still true in the current version.
Daniel Silverstone

~0002052

Daniel Silverstone (administrator)

This looks like the core wapcaplet context which is, indeed, never freed.

If the iterator at the end of NetSurf doesn't list any strings, then we've not leaked wapcaplet strings, just the core hash table. Short of adding a 'lwc_closedown()` type function there's no easy way to clear this.
Daniel Silverstone

~0002087

Daniel Silverstone (administrator)

I decided to make lwc_iterate_strings() free the global context if no strings were found. This should resolve this.
+Notes

-Issue History
Date Modified Username Field Change
2016-12-05 23:47 Chris Young New Issue
2016-12-05 23:48 Chris Young Relationship added related to 0002489
2017-01-18 21:29 Vincent Sanders Status new => acknowledged
2019-06-09 19:22 Chris Young Note Added: 0001954
2019-08-01 11:06 Daniel Silverstone Assigned To => Daniel Silverstone
2019-08-01 11:06 Daniel Silverstone Status acknowledged => assigned
2019-08-01 11:06 Daniel Silverstone Note Added: 0002052
2019-08-01 11:06 Daniel Silverstone Status assigned => confirmed
2019-09-07 14:00 Daniel Silverstone Note Added: 0002087
2019-09-07 14:01 Daniel Silverstone Status confirmed => resolved
2019-09-07 14:01 Daniel Silverstone Resolution open => fixed
+Issue History