[Olsr-dev] olsrd-0.5.2 bmf segmentation fault

[Bernd Petrovitsch]

On Sun, 2007-07-29 at 16:16 +0200, Cédric Krier wrote:
> Hi,
> 
> I have a segmentation fault when I run olsrd with the bmf plugin.
> 
> 
> >---------- LOADING LIBRARY olsrd_bmf.so.1.5 ----------
> >OLSRD Basic Multicast Forwarding (BMF) plugin 1.5 (Jul 29 2007 13:57:36)
> >  (C) Thales Communications Huizen, Netherlands
> >    Erik Tromp ((spam-protected))
> >Checking plugin interface version:  4 - OK
> >
> >WARNING: YOU ARE USING AN OLD DEPRECATED PLUGIN INTERFACE!
> >DETECTED VERSION 4 AND THE CURRENT VERSION IS 5
> >PLEASE UPGRADE YOUR PLUGIN!
> >Segmentation fault
> 
> 
> Is there anybody who known how to fix it ?

JftSoC: I asked (and got) the olsrd.conf file and it happens here too
(Linux 2.6.9 on CentOS-4.5).

I just looked around and I have good and (for me) sad news:

Good news: The attached patch should fix it - it simply repairs the
basically broken olsr-current/Makefile.inc and enables the old version
of the plugin interface.
Side note: This is already fixed in CVS-HEAD (though differently).

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?

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services
-------------- next part --------------
A non-text attachment was scrubbed...
Name: olsrd-0.5.2-fix.patch
Type: text/x-patch
Size: 360 bytes
Desc: not available
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20070729/68525f50/attachment.bin>