ldd is useless - it indicates what will be loaded based on external
references in the code (read man ldd, man ld.so and man ldconfig).

Great, except it ignores libraries not part of the executable, such as those
where ntop scans a directory to do true dynamic loads...

strace is good, but noisy...

ntop does test for the loading location - on platforms where we can - and
reports it on info.html/textinfo.html.  

ntop Version.....3.1.051 traceEventTemp
Configured on.....Aug  5 2005 16:21:10
Built on.....Aug  5 2005 16:42:28
OS.....i686-pc-linux-gnu
libpcap version.....libpcap version 0.8.3
Running from...../devel/bin
Libraries in...../devel/lib
Library path.....LD_LIBRARY_PATH
/devel/lib/ntop/:/devel/lib/ntop/plugins/:/devel/lib/plugins/
Instance.....devel
ntop Process Id.....13045
http Process Id.....13045

But I settle for testing ONE location not all of them.  Look at the utildl.c
code (it's a special routine because it is (1) gcc only and (2) requires a
different version of the header file from the normal one).

-----Burton 

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Kenneth Porter
Sent: Saturday, August 06, 2005 4:39 PM
To: [email protected]
Subject: RE: [Ntop] Fedora core buffer overflow

--On Saturday, August 06, 2005 2:51 PM -0500 Burton Strauss
<[EMAIL PROTECTED]> wrote:

> ntop uses the OS' standard facilities for finding it's executables and 
> library modules.  This typically is . (current directory) + a bunch of 
> OS/distro specific locations (path for executables, library path for 
> .so files, etc.)  So it may be that you have different ntop and 
> libntopxxxx files and are executing different ones depending upon where
you run from.

One can use ldd to check libraries linked at load time. Do you log the
locations of libraries found dynamically after the program is started? That
can be used to check for libraries loaded from unexpected locations.

Another trick is to strace ntop and look at the paths of all files loaded. 
I've done that with closed-source stuff (mostly commercial game server
binaries) to figure out its search rules.

But the best solution is still likely to be running under gdb (or its GUI
variations like ddd) to the crash and doing proper debugging.
_______________________________________________
Ntop mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop

_______________________________________________
Ntop mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop

Reply via email to