On Sun, 2007-07-29 at 22:58 +0200, Bernd Petrovitsch wrote:
[...]
> Sad news (at least for me): Ido not understand why the SIGSEGV above
> occurs:
> - We do a dlopen(3) on the .so file of the plugin (in the olsr_load_dl()
>   function). And this succeeds (put printf(3)s in there to verify).
> - We get the function pointer with dlsym(3) to get the interface
>   version (in the olsr_add_dl() function). This succeeds too and
>   delivers "4" and so we know that it is the "old version". And we
>   return from there "-1" (since we do not support the old version with
>   the original Makefile.inc).
> - Back in olsr_load_dl(), we see the error and dlclose(3) the shared lib
>   again (since we can't use it).
>   And precisely that dlclose(3) call produces the SIGSEGV (put a
>   printf(3) before and after, look at it with ltrace). But the
>   "dlhandle" (and the pointer to it) there has the correct value (as
>   reported by the dlopen(3)) and I can't find or think of a reason why
>   something could break there with a SIGSEGV.
>   Don't get me wrong, if something is not correct dlclose(3) can (and
>   should) report errors, but simply dying on a SIGSEGV is strange (at
>   best).
> Any hints anyone?

Thanks for the 1st hint: Linking everything (and not only the bmf
plugin) against the pthread library doesn't help.

Next try: And not stripping the binary and plugins also didn't help.

And the SIGSEGV occurs with both gcc-3.4.6 and gcc-4.1.1 from
CentOS-4.5.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services




