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
