3:10 p.m.
I must be msising something, but libwapcaplet allocates a "bucket" in
lwc__initialise(). As far as I can tell, this is never freed - as
there is no lwc__finalise or equivalent function?
The strings destroy themselves, but this doesn't free up the original
"bucket".
Chris
2:05 a.m.
On Mon, 2013-02-25 at 20:10 +0000, Chris Young wrote:
I must be msising something, but libwapcaplet allocates a
"bucket" in
lwc__initialise(). As far as I can tell, this is never freed - as
there is no lwc__finalise or equivalent function?
Correct -- this is expected. There's no safe way to do this without
adding a context to the lwc API. That introduces a significant amount of
pain in clients (as they have to pass the context around internally,
which is problematic when you have multiple things using it. Thus, the
root hash bucket is leaked, instead.
I guess we could free the bucket when there are no strings left in it,
however. Daniel: any thoughts?
J.
4:17 a.m.
On Tue, Feb 26, 2013 at 07:05:05AM +0000, John-Mark Bell wrote:
On Mon, 2013-02-25 at 20:10 +0000, Chris Young wrote:
> I must be msising something, but libwapcaplet allocates a "bucket" in
> lwc__initialise(). As far as I can tell, this is never freed - as
> there is no lwc__finalise or equivalent function?
Correct -- this is expected. There's no safe way to do this without
adding a context to the lwc API. That introduces a significant amount of
pain in clients (as they have to pass the context around internally,
which is problematic when you have multiple things using it. Thus, the
root hash bucket is leaked, instead.
I guess we could free the bucket when there are no strings left in it,
however. Daniel: any thoughts?
It seems a tad silly to add a check to *every* unref to decide if we can free
the root bucket. Esp. given that with all the libs in use, that root bucket
will only ever empty fully immediately before exit.
Perhaps in debug builds?
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
7:10 a.m.
On 26/02/2013 10:17, Daniel Silverstone wrote:
On Tue, Feb 26, 2013 at 07:05:05AM +0000, John-Mark Bell wrote:
> On Mon, 2013-02-25 at 20:10 +0000, Chris Young wrote:
>> I must be msising something, but libwapcaplet allocates a "bucket" in
>> lwc__initialise(). As far as I can tell, this is never freed - as
>> there is no lwc__finalise or equivalent function?
>
> Correct -- this is expected. There's no safe way to do this without
> adding a context to the lwc API. That introduces a significant amount of
> pain in clients (as they have to pass the context around internally,
> which is problematic when you have multiple things using it. Thus, the
> root hash bucket is leaked, instead.
>
> I guess we could free the bucket when there are no strings left in it,
> however. Daniel: any thoughts?
It seems a tad silly to add a check to *every* unref to decide if we can free
the root bucket. Esp. given that with all the libs in use, that root bucket
will only ever empty fully immediately before exit.
Or rather actually (hopefully) before unloading the library.
At least on BeOS we can in theory include NetSurf as a replicant, where
the binary is dlopen()ed and dlclosed() when removed, so using atexit()
would cause quite some trouble there.
Instead there are almost-standard hooks for use in libraries, though the
names differ between OSes they are usually always usable.
On ELF-based things it's usually _fini() though the dlopen man on linux
mentions them as deprecated in favor of __attribute__((destructor)).
François.
8:08 a.m.
On Tue, Feb 26, 2013 at 01:10:41PM +0100, François Revol wrote:
At least on BeOS we can in theory include NetSurf as a replicant,
where
the binary is dlopen()ed and dlclosed() when removed, so using atexit()
would cause quite some trouble there.
If this is *truly* a use-case we need to think about, I'll ponder making the
root somehow static so it gets unloaded automatically, although that might
complicate rehashing.
I'll think about it.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
8:11 a.m.
On Tue, Feb 26, 2013 at 01:08:33PM +0000, Daniel Silverstone wrote:
On Tue, Feb 26, 2013 at 01:10:41PM +0100, François Revol wrote:
> At least on BeOS we can in theory include NetSurf as a replicant, where
> the binary is dlopen()ed and dlclosed() when removed, so using atexit()
> would cause quite some trouble there.
If this is *truly* a use-case we need to think about, I'll ponder making the
root somehow static so it gets unloaded automatically, although that might
complicate rehashing.
The ugly destructor approach could be workable: if for some reason a
host's compiler doesn't support it, we can wrap it in a suitable #ifdef
and they can deal with the leak.
Or, perhaps we could have some C++ with a real destructor on a singleton
that calls the finialisation code? Not sure how this would interact
with multiple users an dlopen()ing of the whole thing.
B.
8:50 a.m.
On 26/02/2013 14:11, Rob Kendrick wrote:
On Tue, Feb 26, 2013 at 01:08:33PM +0000, Daniel Silverstone wrote:
> On Tue, Feb 26, 2013 at 01:10:41PM +0100, François Revol wrote:
>> At least on BeOS we can in theory include NetSurf as a replicant, where
>> the binary is dlopen()ed and dlclosed() when removed, so using atexit()
>> would cause quite some trouble there.
>
> If this is *truly* a use-case we need to think about, I'll ponder making the
> root somehow static so it gets unloaded automatically, although that might
> complicate rehashing.
The ugly destructor approach could be workable: if for some reason a
host's compiler doesn't support it, we can wrap it in a suitable #ifdef
and they can deal with the leak.
Or, perhaps we could have some C++ with a real destructor on a singleton
that calls the finialisation code? Not sure how this would interact
with multiple users an dlopen()ing of the whole thing.
Well, C++ dtors are usually called from this method anyway...
it's just more standardized at C++ level.
François.
3:30 p.m.
On Tue, 26 Feb 2013 13:11:01 +0000, Rob Kendrick wrote:
On Tue, Feb 26, 2013 at 01:08:33PM +0000, Daniel Silverstone wrote:
> If this is *truly* a use-case we need to think about, I'll ponder making the
> root somehow static so it gets unloaded automatically, although that might
> complicate rehashing.
The ugly destructor approach could be workable: if for some reason a
host's compiler doesn't support it, we can wrap it in a suitable #ifdef
and they can deal with the leak.
I would have thought a destructor would be the simplest option.
The reason I picked up on this is because I'm doing some experiments
with libwapcaplet and on-chip memory on the AMCC460ex (SAM460), as it
looked a prime candidate for getting a bit of a speed boost. I
quickly noticed that there was no freeing of the context and bucket,
and therefore no way I could ultimately free the OCM up so other
processes could use it.
I don't think we should be leaking memory at all (even if it is only
4K), but not being able to free a system resource is a major problem.
Chris
3746
days inactive
3747
days old
netsurf-dev@netsurf-browser.org
8 comments
5 participants
participants (5)
-
Chris Young -
Daniel Silverstone -
François Revol -
John-Mark Bell -
Rob Kendrick