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

[Chet Ramey]

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
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

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.

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.

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
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer

Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/