bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libtool 2.2.7a] testsuite: 69 100 failed


From: Ralf Wildenhues
Subject: Re: [libtool 2.2.7a] testsuite: 69 100 failed
Date: Tue, 12 Jan 2010 22:06:51 +0100
User-agent: Mutt/1.5.20 (2009-10-28)

Hi Bob,

* Bob Friesenhahn wrote on Tue, Jan 12, 2010 at 03:01:47AM CET:
> With git libtool just pulled, I am seeing two unexpected test
> failures under Solaris 10:
> 
>  69: syntax of .la files                             FAILED 
> (lalib-syntax.at:121)
> 100: Run tests with low max_cmd_len                  FAILED 
> (cmdline_wrap.at:43)
> 
> The failure 69 looks like the test is working (but the program is
> not).
> 
> #0  0xfeea5a5c in strlen () from /lib/libc.so.1
> (gdb) bt
> #0  0xfeea5a5c in strlen () from /lib/libc.so.1
> #1  0xfef00512 in _ndoprnt () from /lib/libc.so.1
> #2  0xfef031d0 in printf () from /lib/libc.so.1
> #3  0x08051b82 in main ()

> Note, that unlike Linux, Solaris printf will simply dump core rather
> than substituting a string like "(null)" if the supplied pointer is
> null.  Without engaging debugging, my first guess is that the crash
> occured due to this line of code:
> 
>   printf ("plugin failed to open: %s\n", lt_dlerror());
> 
> which will crash if lt_dlerror() returns null.

Thank you for testing.  The right fix here is not to avoid the NULL
dereference on Solaris, but to teach lt_dlopen to set error messages
in these code paths, and of course to expose this issue on glibc systems
as well.

The nontrivial part about this is that error message handling in ltdl
is not all that well-defined ...

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]