bash cores if nscd disabled on Solaris LDAP sasl/gssapi client
Chet Ramey
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 ch...@case.edu http://cnswww.cns.cwru.edu/~chet/
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
Chet Ramey
> > 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.
It is, but that's not what shows up in the call trace. Is `sigacthandler'
part of the Solaris signal trampoline code?
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Chet Ramey, ITS, CWRU ch...@case.edu http://tiswww.tis.case.edu/~chet/
Serge Dussud
On 10/ 6/08 05:11 PM, Chet Ramey wrote:
>>> 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.
>
> It is, but that's not what shows up in the call trace. Is `sigacthandler'
> part of the Solaris signal trampoline code?
it's part of libc, sigaction() related code as far as I can tell:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/threads/sigaction.c#283
I am not very familiar with this part of Solaris code to be honest.
Serge
>
> Chet
>
Serge Dussud - Sun Microsystems
following-up on 3rd item:
[..]
>
>> 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.
So here's a cut & paste of my gdb session, showing that bash and libc
malloc routines are mixed (see below for possible explanation / fix):
$ gdb /usr/bin/bash
GNU gdb 6.3.50_2004-11-23-cvs
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.11"...
(no debugging symbols found)
(gdb) start
Breakpoint 1 at 0x2ece4
Starting program: /usr/bin/bash
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
warning: Lowest section in /lib/libdl.so.1 is .dynamic at 00000118
(no debugging symbols found)
(no debugging symbols found)
0x0002ece4 in main ()
(gdb) break soft_build_secret_key_object
Function "soft_build_secret_key_object" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (soft_build_secret_key_object) pending.
(gdb) continue
Continuing.
warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 000003bc
warning: Lowest section in /lib/libthread.so.1 is .dynamic at 00000478
warning: Lowest section in /lib/librt.so.1 is .dynamic at 000001b0
Breakpoint 3 at 0xfea9fac0
Pending breakpoint "soft_build_secret_key_object" resolved
Breakpoint 3, 0xfea9fac0 in soft_build_secret_key_object ()
from /usr/lib/security/pkcs11_softtoken.so
(gdb) break malloc
Breakpoint 4 at 0xba4a4
(gdb) continue
Continuing.
Breakpoint 4, 0x000ba4a4 in malloc ()
(gdb) where
#0 0x000ba4a4 in malloc ()
#1 0xff0d0bf0 in calloc () from /lib/libc.so.1
#2 0xfea9faec in soft_build_secret_key_object ()
from /usr/lib/security/pkcs11_softtoken.so
#3 0xfeaa0ea4 in soft_build_object ()
from /usr/lib/security/pkcs11_softtoken.so
#4 0xfeaa5474 in soft_add_object () from
/usr/lib/security/pkcs11_softtoken.so
#5 0xfea97c64 in C_CreateObject () from
/usr/lib/security/pkcs11_softtoken.so
#6 0xfe9b5de4 in init_key_uef () from /usr/lib/gss/mech_krb5.so
#7 0xfe9b4d34 in krb5_c_make_random_key () from /usr/lib/gss/mech_krb5.so
#8 0xfe9f19d8 in krb5_generate_subkey () from /usr/lib/gss/mech_krb5.so
#9 0xfe9f472c in krb5int_generate_and_save_subkey ()
from /usr/lib/gss/mech_krb5.so
#10 0xfe9f4960 in krb5_mk_req_extended () from /usr/lib/gss/mech_krb5.so
#11 0xfe9a5098 in make_ap_req_v1 () from /usr/lib/gss/mech_krb5.so
#12 0xfe9a55c8 in new_connection () from /usr/lib/gss/mech_krb5.so
#13 0xfe9a5f8c in krb5_gss_init_sec_context () from
/usr/lib/gss/mech_krb5.so
#14 0xfe9a2bbc in k5glue_init_sec_context () from /usr/lib/gss/mech_krb5.so
#15 0xfec84a4c in gss_init_sec_context () from /usr/lib/libgss.so.1
#16 0xfecc32f4 in gssapi_client_mech_step () from /usr/lib/sasl/gssapi.so.1
#17 0xfed173e4 in sasl_client_step () from /usr/lib/libsasl.so.1
#18 0xfed172b0 in sasl_client_start () from /usr/lib/libsasl.so.1
#19 0xfef1737c in nsldapi_sasl_do_bind () from /usr/lib/libldap.so.5
#20 0xfef17afc in ldap_sasl_interactive_bind_s () from /usr/lib/libldap.so.5
#21 0xfef6e478 in doSASLBind () from /usr/lib/libsldap.so.1
#22 0xfef6c880 in openConnection () from /usr/lib/libsldap.so.1
#23 0xfef6bcdc in makeConnection () from /usr/lib/libsldap.so.1
#24 0xfef6d234 in getConnection () from /usr/lib/libsldap.so.1
#25 0xfef6d38c in __s_api_getConnection () from /usr/lib/libsldap.so.1
#26 0xfef60048 in get_current_session () from /usr/lib/libsldap.so.1
#27 0xfef60f24 in search_state_machine () from /usr/lib/libsldap.so.1
#28 0xfef62158 in ldap_list () from /usr/lib/libsldap.so.1
#29 0xfef62264 in __ns_ldap_list () from /usr/lib/libsldap.so.1
#30 0xfefbbe88 in _nss_ldap_lookup () from /usr/lib/nss_ldap.so.1
#31 0xfefba124 in getbyuid () from /usr/lib/nss_ldap.so.1
#32 0xff0edb08 in nss_search () from /lib/libc.so.1
#33 0xff0da488 in getpwuid_r () from /lib/libc.so.1
#34 0x00030e88 in get_current_user_info ()
#35 0x000310c8 in get_current_user_info ()
#36 0x0002f178 in main ()
(gdb) continue
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0xff0e59c8 in realfree () from /lib/libc.so.1
(gdb) where
#0 0xff0e59c8 in realfree () from /lib/libc.so.1
#1 0xff0e62ac in cleanfree () from /lib/libc.so.1
#2 0xff0e53e0 in _malloc_unlocked () from /lib/libc.so.1
#3 0xff0e52c0 in malloc () from /lib/libc.so.1
#4 0xfea9d600 in get_bigint_attr_from_template ()
from /usr/lib/security/pkcs11_softtoken.so
#5 0xfea9fe80 in soft_build_secret_key_object ()
from /usr/lib/security/pkcs11_softtoken.so
#6 0xfeaa0ea4 in soft_build_object ()
from /usr/lib/security/pkcs11_softtoken.so
.......
I then noticed from compilation logs that pkcs11_softtoken.so is built
with -Bdirect ld(1) flag. I then recompile a bash using '-z interpose'
ld(1) flag and it looks better:
$ gdb ./bash
GNU gdb 6.3.50_2004-11-23-cvs
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.11"...
(gdb) start
Breakpoint 1 at 0x2ecc4
Starting program: /var/tmp/1-23961034/bash
warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)
warning: Lowest section in /lib/libdl.so.1 is .dynamic at 00000118
0x0002ecc4 in main ()
(gdb) break soft_build_secret_key_object
Function "soft_build_secret_key_object" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (soft_build_secret_key_object) pending.
(gdb) continue
Continuing.
warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 000003bc
warning: Lowest section in /lib/libthread.so.1 is .dynamic at 00000478
warning: Lowest section in /lib/librt.so.1 is .dynamic at 000001b0
Breakpoint 3 at 0xfea9fac0
Pending breakpoint "soft_build_secret_key_object" resolved
Breakpoint 3, 0xfea9fac0 in soft_build_secret_key_object ()
from /usr/lib/security/pkcs11_softtoken.so
(gdb) break malloc
Breakpoint 4 at 0xba484
(gdb) continue
Continuing.
Breakpoint 4, 0x000ba484 in malloc ()
(gdb) where
#0 0x000ba484 in malloc ()
#1 0xfea9d600 in get_bigint_attr_from_template ()
from /usr/lib/security/pkcs11_softtoken.so
#2 0xfea9fe80 in soft_build_secret_key_object ()
from /usr/lib/security/pkcs11_softtoken.so
#3 0xfeaa0ea4 in soft_build_object ()
from /usr/lib/security/pkcs11_softtoken.so
#4 0xfeaa5474 in soft_add_object () from
/usr/lib/security/pkcs11_softtoken.so
#5 0xfea97c64 in C_CreateObject () from
/usr/lib/security/pkcs11_softtoken.so
#6 0xfe9b5de4 in init_key_uef () from /usr/lib/gss/mech_krb5.so
#7 0xfe9b4d34 in krb5_c_make_random_key () from /usr/lib/gss/mech_krb5.so
#8 0xfe9f19d8 in krb5_generate_subkey () from /usr/lib/gss/mech_krb5.so
#9 0xfe9f472c in krb5int_generate_and_save_subkey ()
from /usr/lib/gss/mech_krb5.so
#10 0xfe9f4960 in krb5_mk_req_extended () from /usr/lib/gss/mech_krb5.so
#11 0xfe9a5098 in make_ap_req_v1 () from /usr/lib/gss/mech_krb5.so
#12 0xfe9a55c8 in new_connection () from /usr/lib/gss/mech_krb5.so
#13 0xfe9a5f8c in krb5_gss_init_sec_context () from
/usr/lib/gss/mech_krb5.so
#14 0xfe9a2bbc in k5glue_init_sec_context () from /usr/lib/gss/mech_krb5.so
#15 0xfec84a4c in gss_init_sec_context () from /usr/lib/libgss.so.1
#16 0xfecc32f4 in gssapi_client_mech_step () from /usr/lib/sasl/gssapi.so.1
#17 0xfed173e4 in sasl_client_step () from /usr/lib/libsasl.so.1
#18 0xfed172b0 in sasl_client_start () from /usr/lib/libsasl.so.1
#19 0xfef1737c in nsldapi_sasl_do_bind () from /usr/lib/libldap.so.5
#20 0xfef17afc in ldap_sasl_interactive_bind_s () from /usr/lib/libldap.so.5
#21 0xfef6e478 in doSASLBind () from /usr/lib/libsldap.so.1
#22 0xfef6c880 in openConnection () from /usr/lib/libsldap.so.1
#23 0xfef6bcdc in makeConnection () from /usr/lib/libsldap.so.1
#24 0xfef6d234 in getConnection () from /usr/lib/libsldap.so.1
#25 0xfef6d38c in __s_api_getConnection () from /usr/lib/libsldap.so.1
#26 0xfef60048 in get_current_session () from /usr/lib/libsldap.so.1
#27 0xfef60f24 in search_state_machine () from /usr/lib/libsldap.so.1
#28 0xfef62158 in ldap_list () from /usr/lib/libsldap.so.1
#29 0xfef62264 in __ns_ldap_list () from /usr/lib/libsldap.so.1
#30 0xfefbbe88 in _nss_ldap_lookup () from /usr/lib/nss_ldap.so.1
#31 0xfefba124 in getbyuid () from /usr/lib/nss_ldap.so.1
#32 0xff0edb08 in nss_search () from /lib/libc.so.1
#33 0xff0da488 in getpwuid_r () from /lib/libc.so.1
#34 0x00030e68 in get_current_user_info ()
#35 0x000310a8 in shell_initialize ()
#36 0x0002f158 in main ()
(gdb) continue
Continuing.
Breakpoint 4, 0x000ba484 in malloc ()
(gdb) where
#0 0x000ba484 in malloc ()
#1 0xfe9fece8 in krb5_copy_keyblock () from /usr/lib/gss/mech_krb5.so
#2 0xfe9f4768 in krb5int_generate_and_save_subkey ()
from /usr/lib/gss/mech_krb5.so
#3 0xfe9f4960 in krb5_mk_req_extended () from /usr/lib/gss/mech_krb5.so
#4 0xfe9a5098 in make_ap_req_v1 () from /usr/lib/gss/mech_krb5.so
#5 0xfe9a55c8 in new_connection () from /usr/lib/gss/mech_krb5.so
#6 0xfe9a5f8c in krb5_gss_init_sec_context () from
/usr/lib/gss/mech_krb5.so
#7 0xfe9a2bbc in k5glue_init_sec_context () from /usr/lib/gss/mech_krb5.so
#8 0xfec84a4c in gss_init_sec_context () from /usr/lib/libgss.so.1
#9 0xfecc32f4 in gssapi_client_mech_step () from /usr/lib/sasl/gssapi.so.1
#10 0xfed173e4 in sasl_client_step () from /usr/lib/libsasl.so.1
#11 0xfed172b0 in sasl_client_start () from /usr/lib/libsasl.so.1
#12 0xfef1737c in nsldapi_sasl_do_bind () from /usr/lib/libldap.so.5
#13 0xfef17afc in ldap_sasl_interactive_bind_s () from /usr/lib/libldap.so.5
#14 0xfef6e478 in doSASLBind () from /usr/lib/libsldap.so.1
#15 0xfef6c880 in openConnection () from /usr/lib/libsldap.so.1
#16 0xfef6bcdc in makeConnection () from /usr/lib/libsldap.so.1
#17 0xfef6d234 in getConnection () from /usr/lib/libsldap.so.1
#18 0xfef6d38c in __s_api_getConnection () from /usr/lib/libsldap.so.1
#19 0xfef60048 in get_current_session () from /usr/lib/libsldap.so.1
#20 0xfef60f24 in search_state_machine () from /usr/lib/libsldap.so.1
#21 0xfef62158 in ldap_list () from /usr/lib/libsldap.so.1
#22 0xfef62264 in __ns_ldap_list () from /usr/lib/libsldap.so.1
#23 0xfefbbe88 in _nss_ldap_lookup () from /usr/lib/nss_ldap.so.1
#24 0xfefba124 in getbyuid () from /usr/lib/nss_ldap.so.1
#25 0xff0edb08 in nss_search () from /lib/libc.so.1
#26 0xff0da488 in getpwuid_r () from /lib/libc.so.1
#27 0x00030e68 in get_current_user_info ()
#28 0x000310a8 in shell_initialize ()
#29 0x0002f158 in main ()
(gdb) clear malloc
Deleted breakpoint 4
(gdb) continue
Continuing.
Breakpoint 3, 0xfea9fac0 in soft_build_secret_key_object ()
from /usr/lib/security/pkcs11_softtoken.so
(gdb) clear soft_build_secret_key_object
Deleted breakpoint 3
(gdb) continue
Continuing.
bash-3.2$(gdb) clear malloc
Deleted breakpoint 4
(gdb) continue
Continuing.
Breakpoint 3, 0xfea9fac0 in soft_build_secret_key_object ()
from /usr/lib/security/pkcs11_softtoken.so
(gdb) clear soft_build_secret_key_object
Deleted breakpoint 3
(gdb) continue
Continuing.
bash-3.2$
From man page ld(1) (snv_99 box):
....
-B direct | nodirect
These options govern direct binding. -B direct estab-
lishes direct binding information by recording the rela-
tionship between each symbol reference together with the
dependency that provides the definition. In addition,
direct binding information is established between each
symbol reference and an associated definition within the
object being created. The runtime linker uses this
information to search directly for a symbol in the asso-
ciated object rather than to carry out a default symbol
search.
Direct binding information can only be established to
dependencies specified with the link-edit. Thus, you
should use the -z defs option. Objects that wish to
interpose on symbols in a direct binding environment
should identify themselves as interposers with the -z
interpose option. The use of -B direct enables -z lazy-
load for all dependencies.
The -B nodirect option prevents any direct binding to
the interfaces offered by the object being created. The
object being created can continue to directly bind to
external interfaces by specifying the -z direct option.
See Appendix D, Direct Bindings, in Linker and Libraries
Guide.
.....
-z interpose
Marks the object as an interposer. At runtime, an object
is identified as an explicit interposer if the object
has been tagged using the -z interpose option. An expli-
cit interposer is also established when an object is
loaded using the LD_PRELOAD environment variable. Impli-
cit interposition can occur because of the load order of
objects, however, this implicit interposition is unknown
to the runtime linker. Explicit interposition can ensure
that interposition takes place regardless of the order
in which objects are loaded. Explicit interposition also
ensures that the runtime linker searches for symbols in
any explicit interposers when direct bindings are in
effect.
.....
Could it be the explanation and a possible solution ?
Serge
Serge Dussud
Hi Chet,
any follow-up on this ?
tia,
Serge
[..]
Chet Ramey
>
> Hi Chet,
>
> any follow-up on this ?
Haven't looked at it yet, sorry.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Chet Ramey, ITS, CWRU ch...@case.edu http://cnswww.cns.cwru.edu/~chet/
Chet Ramey
> -z interpose
>
> .....
>
>
> Could it be the explanation and a possible solution ?
Well, let's try it.
Serge Dussud - Sun Microsystems
Chet Ramey wrote:
> Serge Dussud - Sun Microsystems wrote:
>
>
>> -z interpose
>>
>> .....
>>
>>
>> Could it be the explanation and a possible solution ?
>>
>
> Well, let's try it.
>
OK, great. Shall I understand that you're going to make a patch for
this, or is there something else ?
Serge
> Chet
>
Chet Ramey
>
>
> Chet Ramey wrote:
>> Serge Dussud - Sun Microsystems wrote:
>>
>>
>>> -z interpose
>>>
>>> .....
>>>
>>>
>>> Could it be the explanation and a possible solution ?
>>>
>>
>> Well, let's try it.
>>
> OK, great. Shall I understand that you're going to make a patch for
> this, or is there something else ?
I was not going to issue a patch to 3.2 for this, but the change to
configure.in will be in the next release.
Chget
Serge Dussud - Sun Microsystems
Chet Ramey wrote:
> Serge Dussud - Sun Microsystems wrote:
>
>> Chet Ramey wrote:
>>
>>> Serge Dussud - Sun Microsystems wrote:
>>>
>>>
>>>
>>>> -z interpose
>>>>
>>>> .....
>>>>
>>>>
>>>> Could it be the explanation and a possible solution ?
>>>>
>>>>
>>> Well, let's try it.
>>>
>>>
>> OK, great. Shall I understand that you're going to make a patch for
>> this, or is there something else ?
>>
>
> I was not going to issue a patch to 3.2 for this, but the change to
> configure.in will be in the next release.
>
ah OK, so I guess I need to work on a customized patched for 3.2 then.
Any ideas yet of what the exact change will be in configure.bin so that
I can apply to same in our deliveries ?
Also, do you or would you have a bug # for reference ?
TIA,
Serge
> Chget
>
>
Chet Ramey
> Any ideas yet of what the exact change will be in configure.bin so that
> I can apply to same in our deliveries ?
*** ../bash-3.2-patched/configure.in 2007-12-14 21:12:29.000000000 -0500
--- configure.in 2008-10-23 09:10:57.000000000 -0400
***************
*** 992,997 ****
--- 1009,1017 ----
sco3.2*) LOCAL_CFLAGS=-DMUST_UNBLOCK_CHLD ;;
sunos4*) LOCAL_CFLAGS=-DSunOS4 ;;
solaris2.5*) LOCAL_CFLAGS="-DSunOS5 -DSOLARIS" ;;
+ solaris2.8*) LOCAL_CFLAGS=-DSOLARIS LOCAL_LDFLAGS='-z interpose' ;;
+ solaris2.9*) LOCAL_CFLAGS=-DSOLARIS LOCAL_LDFLAGS='-z interpose' ;;
+ solaris2.10*) LOCAL_CFLAGS=-DSOLARIS LOCAL_LDFLAGS='-z interpose' ;;
solaris2*) LOCAL_CFLAGS=-DSOLARIS ;;
lynxos*) LOCAL_CFLAGS=-DRECYCLES_PIDS ;;
linux*) LOCAL_LDFLAGS=-rdynamic # allow dynamic loading
> Also, do you or would you have a bug # for reference ?
Sorry, I don't.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Chet Ramey, ITS, CWRU ch...@case.edu http://tiswww.tis.case.edu/~chet/
Serge Dussud
ok, thanks !
Serge
Serge Dussud
Hi Chet,
there've been follow-up discussions and reviews here with our linker
folks (see [1] for some details on the bug that was open to capture
those) and consensus is that best approach is to not compile with bash's
own malloc routines.
Indeed, ld(1)'s -z interpose option is a rather big hammer, as it
establishes that the application can interpose on *all* of the symbols
that it offers, rather than just the few related to malloc.
Hence, my question to you is: are there any real benefit these days of
using bash's own malloc function rather than the one from the system ?
or, otherwise said, what do bash lose when it's compiled with option
--without-bash-malloc ?
TIA,
Serge
[1] http://bugs.opensolaris.org/view_bug.do?bug_id=6778453
Chet Ramey
> Indeed, ld(1)'s -z interpose option is a rather big hammer, as it
> establishes that the application can interpose on *all* of the symbols
> that it offers, rather than just the few related to malloc.
That might be a problem if there are some public symbols in libc that
bash happens to use, but bash is pretty careful to replace libc
functions only if they're missing or somehow substandard.
> Hence, my question to you is: are there any real benefit these days of
> using bash's own malloc function rather than the one from the system ?
> or, otherwise said, what do bash lose when it's compiled with option
> --without-bash-malloc ?
The bash malloc is a lot faster than the Solaris malloc, and it performs
a lot more checking.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Chet Ramey, ITS, CWRU ch...@case.edu http://cnswww.cns.cwru.edu/~chet/
Serge Dussud
On 12/ 8/08 03:00 PM, Chet Ramey wrote:
> Serge Dussud wrote:
>
>> Indeed, ld(1)'s -z interpose option is a rather big hammer, as it
>> establishes that the application can interpose on *all* of the symbols
>> that it offers, rather than just the few related to malloc.
>
> That might be a problem if there are some public symbols in libc that
> bash happens to use, but bash is pretty careful to replace libc
> functions only if they're missing or somehow substandard.
OK. Not sure I am willing to take the risk at this point. Also, note
that the linker issue is being investigated at the moment.
>
>> Hence, my question to you is: are there any real benefit these days of
>> using bash's own malloc function rather than the one from the system ?
>> or, otherwise said, what do bash lose when it's compiled with option
>> --without-bash-malloc ?
>
> The bash malloc is a lot faster than the Solaris malloc, and it performs
indeed ? OK.
Thanks,
Serge
serge
Hi Chet,
Serge Dussud wrote:
>
>
> On 12/ 8/08 03:00 PM, Chet Ramey wrote:
>> Serge Dussud wrote:
>>
>>> Indeed, ld(1)'s -z interpose option is a rather big hammer, as it
>>> establishes that the application can interpose on *all* of the symbols
>>> that it offers, rather than just the few related to malloc.
>>
>> That might be a problem if there are some public symbols in libc that
>> bash happens to use, but bash is pretty careful to replace libc
>> functions only if they're missing or somehow substandard.
>
> OK. Not sure I am willing to take the risk at this point. Also, note
> that the linker issue is being investigated at the moment.
FYI, the linker issue [1] was the root cause of all this, and was fixed
in recent OpenSolaris build (snv_106). We're working on fixing it to
previous version of Solaris, when/if applicable.
Bottom line, we're not applying any patch to the way we build our bash
delivery bundled to [Open]Solaris :)
Thanks for the help/chat on this one,
serge