[prev in list] [next in list] [prev in thread] [next in thread]
List: ntop-dev
Subject: RE: [Ntop-dev] Ntop 3.1.1 and Freebsd 4.x Plugin Problem
From: "Burton Strauss" <Burton () ntopSupport ! com>
Date: 2005-02-28 22:13:25
Message-ID: 0MKz1m-1D5t8q1TOd-0004uq () mrelay ! perfora ! net
[Download RAW message or body]
Yeah, it doesn't build - I have patches, but I'm actually trying to finish
the thing instead of another band aid - anyone willing to test, let me know
off list.
As I said last time
(http://listgateway.unipi.it/pipermail/ntop-dev/2004-June/004677.html),
those are just pass-throughs from the dlsym() calls. You'll have to figure
out what is causing the OS to whine about that... From the 4.9 man page:
The dlsym() function returns the address binding of the symbol
described
in the null-terminated character string symbol, as it occurs in the
shared object identified by handle. The symbols exported by objects
added to the address space by dlopen() can be accessed only through
calls
to dlsym(). Such symbols do not supersede any definition of those sym-
bols already present in the address space when the object is loaded,
nor
are they available to satisfy normal dynamic linking references.
If dlsym() is called with the special handle NULL, it is interpreted as
a
reference to the executable or shared object from which the call is
being
made. Thus a shared object can reference its own symbols.
If dlsym() is called with the special handle RTLD_DEFAULT, the search
for
the symbol follows the algorithm used for resolving undefined symbols
when objects are loaded. The objects searched are as follows, in the
given order:
1. The referencing object itself (or the object from which the call
to
dlsym() is made), if that object was linked using the -Wsymbolic
option to ld(1).
2. All objects loaded at program start-up.
3. All objects loaded via dlopen() which are in needed-object DAGs
that
also contain the referencing object.
4. All objects loaded via dlopen() with the RTLD_GLOBAL flag set in
the
mode argument.
If dlsym() is called with the special handle RTLD_NEXT, then the search
for the symbol is limited to the shared objects which were loaded after
the one issuing the call to dlsym(). Thus, if the function is called
from the main program, all the shared libraries are searched. If it is
called from a shared library, all subsequent shared libraries are
searched. RTLD_NEXT is useful for implementing wrappers around library
functions. For example, a wrapper function getpid() could access the
``real'' getpid() with dlsym(RTLD_NEXT, "getpid").
If dlsym() is called with the special handle RTLD_SELF, then the search
for the symbol is limited to the shared object issuing the call to
dlsym() and those shared objects which were loaded after it.
The dlsym() function returns a null pointer if the symbol cannot be
found, and sets an error condition which may be queried with dlerror().
It's got to relate to your creation of the symbolic links, since that's the
only thing you are doing that seems outside the norm.
Permissions or some such... I note that on my box, those files are NOT
symlinks:
$ ls -l /usr/lib/ntop/plugins
total 1564
-rwxr-xr-x 1 ntop ntop 166375 Feb 28 12:31 icmpPlugin.so
-rwxr-xr-x 1 ntop ntop 159189 Feb 28 12:32 lastSeenPlugin.so
-rwxr-xr-x 1 ntop ntop 226551 Feb 28 12:32 netflowPlugin.so
-rwxr-xr-x 1 ntop ntop 156803 Feb 28 12:33 pdaPlugin.so
-rwxr-xr-x 1 ntop ntop 230969 Feb 28 12:33 rrdPlugin.so
-rwxr-xr-x 1 ntop ntop 281010 Feb 28 12:34 sflowPlugin.so
-rwxr-xr-x 1 ntop ntop 147144 Feb 28 12:33 snmpPlugin.so
-rwxr-xr-x 1 ntop ntop 148602 Feb 28 12:34 xmldumpPlugin.so
The code that does it is loadPlugin() in plugin.c ...
There's an old thread
http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg18291.html re the
rtld program...
The rtld code is here:
http://www.freebsd.org/cgi/cvsweb.cgi/src/libexec/rtld-elf/rtld.c
If you look there, dlcheck() is what's issuing the message, based on zero
ref counts. dlinfo() calls dlcheck(), and dlsym() is what calls dlinfo().
Since you're not getting "unable to load", the call to dlopen() is working,
but the subsequent call to dlsym() is failing.
So it seems as though it's calling dlsym().
You could try instrumenting the code, but I doubt it will show much since
you're already getting the reflected error.
-----Burton
-----Original Message-----
From: ntop-dev-bounces@unipi.it [mailto:ntop-dev-bounces@unipi.it] On Behalf
Of Cole
Sent: Monday, February 28, 2005 3:43 PM
To: ntop-dev@Unipi.IT
Subject: [Ntop-dev] Ntop 3.1.1 and Freebsd 4.x Plugin Problem
Hey.
I have a Freebsd server running freebsd-4.9-stable.
I cvsupped the ntop src last week for 3.1.1.
I then had no problems what so ever building ntop, except for the xml plugin
saying it was not built, cause it cannot find xmlversion.h, even though I
have libxml installed, and specified the right paths to the .h. But that is
not the problem.
Ntop runs and works fine on this box, not a single problem that I can see.
The problem is that, I have a few other servers, that I want to copy ntop
too, but dont want to build it on all those boxes. I created a tar with all
the ntop binaries, as well as all the libraries that its linked too, as well
as all the plugins that ntop uses from both the /usr/local/lib directory as
well as the plugins from the /usr/local/lib/ntop/plugins directory. I
rebuilt all the symbolic links for all the libraries and plugins and all the
files that ntop was linked too. I have also checked all the permissions on
all the files and they are all the same.
One other thing, the boxes that I am copying ntop to, are almost exact
duplicates of the first box that I built ntop on, and where it works fine.
The problem is, when running ntop on the boxes that I copied it to, after
checking all the permissions and links and everything, I get these errors
with regards to the plugins.
Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin
'/usr/local/lib/ntop/plugins/icmpPlugin.so' entry function [Invalid shared
object handle 0x29a14000] Tue Mar 1 05:37:16 2005 **WARNING** Unable to
locate plugin '/usr/local/lib/ntop/plugins/snmpPlugin.so' entry function
[Invalid shared object handle 0x29a16400] Tue Mar 1 05:37:16 2005
**WARNING** Unable to locate plugin
'/usr/local/lib/ntop/plugins/sflowPlugin.so' entry function [Invalid shared
object handle 0x29a19800] Tue Mar 1 05:37:16 2005 **WARNING** Unable to
locate plugin '/usr/local/lib/ntop/plugins/rrdPlugin.so' entry function
[Invalid shared object handle 0x29a1bc00] Tue Mar 1 05:37:16 2005
**WARNING** Unable to locate plugin
'/usr/local/lib/ntop/plugins/pdaPlugin.so' entry function [Invalid shared
object handle 0x2bcae400] Tue Mar 1 05:37:16 2005 **WARNING** Unable to
locate plugin '/usr/local/lib/ntop/plugins/netflowPlugin.so' entry function
[Invalid shared object handle 0x2d862800] Tue Mar 1 05:37:16 2005
**WARNING** Unable to locate plugin
'/usr/local/lib/ntop/plugins/lastSeenPlugin.so' entry function [Invalid
shared object handle 0x2d866c00] Tue Mar 1 05:37:16 2005 **WARNING**
Unable to locate plugin '/usr/local/lib/ntop/plugins/xmldumpPlugin.so' entry
function [Invalid shared object handle 0x2f697000]
I have absolutely no idea how this has happened, and I have had this problem
before, and not a single other person was able to help me in any regards
what so ever. I was hoping maybe someone would at least know what this error
even means, so that I have some idea of what I am meant to be doing to fix
this.
If anyone has any idea, I would gladly apprecaite any suggestions.
Thanks
/Cole
_______________________________________________
Ntop-dev mailing list
Ntop-dev@unipi.it
http://listgateway.unipi.it/mailman/listinfo/ntop-dev
_______________________________________________
Ntop-dev mailing list
Ntop-dev@unipi.it
http://listgateway.unipi.it/mailman/listinfo/ntop-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic