Re: lt_dlpreload_open ... BANG!

[Bob Friesenhahn]

(gdb) bt full
#0  0x77c436d0 in _libmsvcrt_a_iname ()
No symbol table info available.
#1  0x00404c6b in lt_dlpreload_open (originator=0x401bc8 "libltdlc",
    func=0x401ac0 <loader_init_callback>)
    at 
//scooby/bfriesen/src/gnu/libtool-branch-2-0/libltdl/loaders/preopen.c:322
        list = (symlist_chain *) 0x3d2de0
        errors = 0
        found = 0
        list = (symlist_chain *) 0x3d2de0
        errors = 0
        found = 0
#2  0x00401c5c in lt_dlinit ()
    at //scooby/bfriesen/src/gnu/libtool-branch-2-0/libltdl/ltdl.c:221
        errors = 0
#3  0x004019bb in main (argc=1, argv=0x3d2d10)
    at //scooby/bfriesen/src/gnu/libtool-branch-2-0/tests/mdemo/main.c:181
        argc = 1
        i = 2147348480
        ret = 0
(gdb)

Things would be a lot easier if source-level debug was available. 
Unfortunately, MinGW's gdb refuses to load source files using SMB 
paths.

Bob

On Mon, 11 Oct 2004, Ralf Wildenhues wrote:

> * Bob Friesenhahn wrote on Mon, Oct 11, 2004 at 02:17:00AM CEST:
> > MinGW crashes in the mdemo test while executing lt_dlpreload_open.
> > GDB reveals that the first element of preloaded_symlists contains a
> > symlist with null members:
> *snip trace*
> > Naturally, this causes an immediate crash in streq().
> >
> > Is it supposed to be possible for this condition to occur?  Why might
> > this condition occur for MinGW but not for other systems?  It does
> > work for Cygwin.
>
> Can you show the libtool-generated C file containing the symbols?
> (something like .libs/mdemoS.c, use RM=echo with the `libtool' call to
> keep that intermediate file).  If nothing conclusive shows up there,
> could you add the output of `bt full' and maybe `info globals' to your
> backtrace?
>
> Regards,
> Ralf

======================================
Bob Friesenhahn
address@hidden
http://www.simplesystems.org/users/bfriesen