Re: bash cores if nscd disabled on Solaris LDAP sasl/gssapi client

[Serge Dussud]

Hi Chet,

thanks for the quick answer. More in-line:

On 10/ 3/08 10:52 PM, Chet Ramey wrote:
> Serge Dussud - Sun Microsystems wrote:
> > Hello bug-bash,
> >
> > please find attached a bashbug report. I am not sure how to follow-up
> > then, could you advise ?
>
> This is the appropriate venue for these reports.  I have a few questions

OK.

> about this one.
>
> 1.  The trace shows that the process is not, in fact, using the bash
>     malloc when it dies.  The traced _malloc_unlocked and cleanfree
>     functions are not in the bash malloc, but are present in libc.
>
>  ff137068 sigacthandler (efe08, f7065555, 0, f8ca0, 0, 0)
>  --- called from signal handler with signal 982536 (SIG Unknown) ---
>  ff0e62a4 cleanfree (0, 8, ff1e64f8, ff1de63c, f83ec, 2) + 58
>  ff0e53d8 _malloc_unlocked (20, f7065554, efe00, f7065555, ff1e0468,
> ffffffdf) + 104
>  ff0e52b8 malloc   (20, 0, 1, ff1de63c, f93c8, ff1e4864) + 48

I saw that, still, when I tried to analyze the core some while back, I 
had the feeling that debugger (mdb at the time ?) was confused with 
these malloc routines. That's when I realized about the malloc bash 
internal routines and tried compiling with --witthou-bash-malloc.

> 2.  What library installs the `sigacthandler'?  It's not a function in
>     bash.  It is a symbol in libc, but there's no indication which
>     library installs it as a signal handler.

I have just tried psig on on running bash (in another config), and see 
that the function that set signals handler for SIGV is indeed:

bash-3.2# pgrep bash
16384
bash-3.2# psig 16384 | grep "^SEGV"
SEGV    blocked,caught  termsig_sighandler      0 
HUP,INT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,VTALRM,XCPU,XFSZ,LOST
bash-3.2#

termsig_sighandler() is part bash source code (sig.c) if I am not mistaken.


> 3.  What does the traceback look like when bash is run under gdb and
>     allowed to fail?
>
> I suspect that the libraries are pre-bound to use the system's malloc,
> and the calls to different malloc libraries are causing the core dumps.
> Another possibility is that libc functions are using private pseudo-
> global libc malloc interfaces, causing the libc malloc to be linked in.
> Either way, the trace and library load address maps indicate that the
> process is dying in the libc malloc.  One way to confirm my suspicion
> is to start bash under gdb, set a breakpoint in malloc, and see where
> it stops.

OK, I'll try that and come back to you.

Thanks,
Serge

> If it's documented that applications on Solaris may no longer link
> with their own versions of malloc, that's fine -- I can arrange things
> so that bash doesn't try to use it's internal malloc on Solaris 10
> and 11.
>
> Chet