Ville Syrjälä wrote:
On Thu, May 07, 2009 at 04:29:24PM +0200, Sven Neumann wrote:
Hi,
On Thu, 2009-05-07 at 15:56 +0200, Denis Oliver Kropp wrote:
I think I already reported this here quite a while ago, but the change
was never committed and still sits in my local tree. Please review and
tell me if it is OK to push this change to the git repository.
You should at least make sure that multiple interface implementations
in one shared module or linked statically into the application binary
are still working. There was a double free issue when one dynamic lib
(un)registered multiple interfaces.
I didn't check that and I am not sure how to check that. However
valgrind showed a memory leak and if you look at the code you will see
that impl is freed a few lines below. Shouldn't we also free the
filename field of impl then?
The fix is somewhat academic at this point though since AFAICS there is
no way to unload interface implementations so this code should only run
on program exit, but at least it would eliminate some noise from
valgrind output.
I agree, I checked the patch and it looks ok.
I don't immediately see any double free problem with this code but I do
see other problems with having multiple interface implemenations in one
module. dlopen() will call the constructors for all the impls so all of
them will be added to the list but then the code only checks the last
one added to the list. So it seems that if the first dynamically loaded
interface implemenation that the program wants to use is not the last
implementation registered by one module then the program will not find
the implemenation. Or did I miss something?
Didn't realize this, but yes, I think you are correct.
So, we're lucky that all .so files contain at most one interface so far..
Funnily, I think a new call to 'GetInterface' will succeed, as well as
the case that the .so file got loaded earlier already due to another
GetInterface.
Greets
Niels
--
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
_______________________________________________
directfb-dev mailing list
directfb-dev@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
