Bugreport: Latest CVS checkout of sid: segfault with empty file w/o configuration(?)

Bugreport: Latest CVS checkout of sid: segfault with empty file w/o configuration(?)

[Onno Kortmann]

Hi,

I'm playing around with your SID framework. After successfully compiling the 
latest version (only some minor quirks) without the 'Build problems - 
libiberty/pic' I tried to run a sid with the following on-line input file:

load libmemory.la mem_component_library

But sid segfaults. I just started to use sid, so maybe this input file does 
not make a lot of sense. Anyway, I think that sid should not segfault :-)

Best regards,

Onno

Re: Bugreport: Latest CVS checkout of sid: segfault with empty file w/o configuration(?)

[Frank Ch. Eigler]

[-- Attachment #1: Type: text/plain, Size: 291 bytes --]

Hi -

> [...] I tried to run a sid with the following on-line input file:
> load libmemory.la mem_component_library
> But sid segfaults. [...]

Of course that shouldn't happen (and doesn't in my build).  You can
sic a debugger on the binary, and see what's up at the point of crash.

- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Bugreport: Latest CVS checkout of sid: segfault with empty file w/o configuration(?)

[Onno Kortmann]

Hi,
> > [...] I tried to run a sid with the following on-line input file:
> > load libmemory.la mem_component_library
> > But sid segfaults. [...]
>
> Of course that shouldn't happen (and doesn't in my build).  You can
> sic a debugger on the binary, and see what's up at the point of crash.
Ok, sorry, my bug report was a bit short, I just thought that I broke it by 
entering a very weird configuration :)

I have now debugged it (somehow the backtrace was of no help, lacked symbols 
and was messed up - so I got to this location iteratively!) until this line 
in compConfig.cxx:

bool
cfgroot_component::register_dso(const string& dso_name, const string& 
_symbol_name)
{
  lt_dlhandle dl_handle = 0;

  // Try ordinary dynamic linking
  dl_handle = lt_dlopen(dso_name.c_str());     <--------

The lt_dlopen segfaults when opening the memory component. For the 
configuration component, lt_dlopen(..) returns zero and the following peek 
into the sid executable itself succeeds.
I installed sid with the default prefix into /usr/local. I 
added /usr/local/sid/sidcomp to the LD_LIBRARY_PATH as a test - this did not 
help. I changed lt_dlopen to lt_dlopenext in this line, I changed the library 
in the configuration file to ".a", ".la", ".so" and even set the full path in 
the configuration file - didn't help either.
Replacing ltdl.c in component/cfgroot/... with a newer one from the debian 
archive (apt-get source libltdl, version 1.5.22) still segfaults.

My system is running kernel 2.6.12/i686 on Debian testing. Libc:
$ /lib/libc.so.6     
GNU C Library stable release version 2.3.5, by Roland McGrath et al.
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.0.3 20051023 (prerelease) (Debian 4.0.2-3).
Compiled on a Linux 2.6.13 system on 2005-11-13.
Available extensions:
        GNU libio by Per Bothner
        crypt add-on version 2.1 by Michael Glad and others
        GNU Libidn by Simon Josefsson
        linuxthreads-0.10 by Xavier Leroy
        BIND-8.2.3-T5B
        libthread_db work sponsored by Alpha Processor Inc
        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Thread-local storage support included.
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.

I installed sid systemwide by doing a make install in a checkout of your CVS, 
in the subdirectory src/sid.

Best regards,

Onno

Re: Bugreport: Latest CVS checkout of sid: segfault with empty file w/o configuration(?)

[Frank Ch. Eigler]

[-- Attachment #1: Type: text/plain, Size: 1222 bytes --]

Hi -

On Fri, Mar 31, 2006 at 10:10:16PM +0200, Onno Kortmann wrote:
> [...]
> I have now debugged it (somehow the backtrace was of no help, lacked symbols 
> and was messed up - so I got to this location iteratively!) until this line 
> in compConfig.cxx:
> 
> bool
> cfgroot_component::register_dso(const string& dso_name, const string& 
> _symbol_name)
> {
>   lt_dlhandle dl_handle = 0;
> 
>   // Try ordinary dynamic linking
>   dl_handle = lt_dlopen(dso_name.c_str());     <--------

Try recompiling the whole thing with "CFLAGS=-g CXXFLAGS=-g".  It may
help explain why lt_dlopen failed, if perhaps something is wrong with
dso_open.

Another fall-back option is to configure with "--disable-shared",
which will link in component libraries right into the sid binary.


> I installed sid with the default prefix into /usr/local. I added
> /usr/local/sid/sidcomp to the LD_LIBRARY_PATH as a test - this did
> not help. [...]

sid tries to locate its component shared libraries using several
means, including the SID_EXEC_PREFIX environment variable, and the
location of its own executable.  Because of the latter, it should
just work without additional environment settings.

- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Bugreport: Latest CVS checkout of sid: segfault with empty file w/o configuration(?)

[Onno Kortmann]

Hi,
> >   // Try ordinary dynamic linking
> >   dl_handle = lt_dlopen(dso_name.c_str());     <--------
>
> Try recompiling the whole thing with "CFLAGS=-g CXXFLAGS=-g".  It may
> help explain why lt_dlopen failed, if perhaps something is wrong with
> dso_open.
I did that already... I have a configurerc that is activated for all my own 
autotools projects. This was enabled for my build but I remembered this only 
now as I looked at the compiler flags...
I did compile it with '-g -Wall', but I'm sure the -Wall didn't hurt :-)

> Another fall-back option is to configure with "--disable-shared",
> which will link in component libraries right into the sid binary.
Well, this is one of the things which I tried already, but it did not change 
the behaviour.


Do you have any other ideas?


Best regards,

Onno