Re: IDS Crashes with LDAP on Solaris 10
Thomas J. Girsch wrote: > The question now is, since the library call works fine on Solaris 8 but > not on Solaris 10, is this a bug in Solaris or in IDS? Was IDS simply > "getting away with" a bad call on Solaris 8? Or did Sun change > something in Solaris 10 that IDS should have, but didn't, account for? > Or did Sun simply break something in Solaris 10? > Actually...you have dtrace on Solaris 10. Use truss -u to check the library call made and dtrace to check the parameters.
Unfortunately, our admins tell us that setting up dtrace to give us what we'd need would take some doing, but so far neither IBM nor Sun has requested any additional information. I suspect that IBM is waiting for more feedback from Sun, while Sun believes that since IBM has replicated, their portion is complete. I'll try to work up a truss -u, meanwhile here's the stack trace: # adb $INFORMIXDIR/bin/oninit core*0 core file = core.oninit.17070.hostname.0.111.1149525290 -- program `` $INFORMIXDIR/bin/oninit'' on platform SUNW,Sun-Fire-15000 SIGSEGV: Segmentation Fault $c libc.so.1`_postfork1_child+0x58(9, ffffffff7d9bf8dc, 0, 0, 0, 0) libc.so.1`close+0x5c(1011d2140, ffffffff7a1b6b28, 1011df778, 1011df770, ffffffff7daead50, 1011d2140) libsoftokn3.so`safe_popen+0x180(ffffffff7a1b6b2b, 10000, 800, 920, ffffffff7a1b42e0, 910) libsoftokn3.so`RNG_SystemInfoForRNG+0x270(948, 800, 950, 0, 1000, 1030) libsoftokn3.so`nsc_CommonInitialize+0xa8(110d7b558, 0, 0, 0, 0, 0) libsoftokn3.so`NSC_Initialize+0x38(110d7b558, 1011dd100, ffffffff7a1b7c20, 0, 0, 0) libnss3.so`SECMOD_LoadPKCS11Module+0x238(1011dd0d0, 110d7b560, ffffffff7a930778, ffffffff7a1b7c20, 0, ffffffff7aaa05e8) libnss3.so`SECMOD_LoadModule+0xcec(1011dd0d0, 1011d7990, 1011dd970, 1011dd8f0, 1011d1b80, 0) libnss3.so`SECMOD_LoadModule+0xd64(1011d7990, ffffffff7a034158, 1011d3670, 1011d77b0, 1011d1b50, 0) libnss3.so`nss_Init+0xa4c(1011d20c0, e0, 0, ffffffff7a99dcc0, a, 1011d6aa0) libnss3.so`NSS_Init+0x58(1011d20c0, 1c00, 118b28, ffffffff7f60512c, ffffffff7daeeec4, 0) libldap.so.5`ldapssl_clientauth_init+0x6c(1011d20c0, 1780, 10e744, 0, 0, 1400) libsldap.so.1`openConnection+0x130(110d7cb58, 1011d1ac0, 1011d3630, a, 1011d5ae0, 1) libsldap.so.1`makeConnection+0x21c(1, 1011d1ac0, 1011d3630, 110d7d53c, a, 1011d5ae0) libsldap.so.1`__s_api_getConnection+0x4a8(0, 110d7d448, 0, 110d7d53c, 0, 1011d5ae0) libsldap.so.1`get_current_session+0x34(1011d5a60, 1, ffffffff7b60ec60, 3, 1e8, ffffffffffffffff) libsldap.so.1`search_state_machine+0x198(1011d5a60, 1, 1011d5ac8, ffffffffffffff54, ffffffff7b728120, 0) libsldap.so.1`__ns_ldap_list+0x278(ffffffff7b914618, 110d7e19c, ffffffff7b80e5d4, ffffffff7b9139a0, 0, 1011d5a28) nss_ldap.so.1`_nss_ldap_lookup+0x44(1011d59f0, 110d7e700, ffffffff7b914618, 110d7e19c, 110d7dfc8, ffffffff7b80e5d4) nss_ldap.so.1`getbynam+0xb8(1011d59f0, 110d7e700, 110d7e09c, 1048a4, ffffffff7d965a54, ffffffff7b912000) libc.so.1`nss_search+0x23c(0, 1, ffffffff7db01110, 0, ffffffff7daeb250, ffffffff7daf3f08) nss_compat.so.1`_nss_compat_XY_all+0x110(1011cd990, 110d7e700, ffffffff7ba01c10, 4, 0, 11) libc.so.1`nss_search+0x23c(0, 1, ffffffff7db01010, 0, ffffffff7daeb250, ffffffff7daf3f08) libc.so.1`getspnam_r+0x68(1116253b8, 1011cd548, 1011cd578, 400, 2000, 0) 0x100a68f74(1116253b8, 110d7e8b0, 110d7e8e0, 7800, ff000000000000, 8080808080808080) __osgetspnam+0x24(1116253b8, 1116253d8, 100985b9c, 110d7ed20, 111d43390, 110d3eb28) 0x1009863a8(0, 1011a5b10, 1011927b0, 11001c198, 110d3eb90, 11001c120) 0x10098699c(110d3e8d0, 110d3e850, 44845d29, 110d3eb28, 110d3e850, 2000) startup+0xfc(1011a10a0, 7, 101194430, 11001bb70, 0, 11001baf8) 0x100984ed0(0, 0, 0, 0, 0, 0) david@smooth1.co.uk wrote: > Thomas J. Girsch wrote: >> The question now is, since the library call works fine on Solaris 8 but >> not on Solaris 10, is this a bug in Solaris or in IDS? Was IDS simply >> "getting away with" a bad call on Solaris 8? Or did Sun change >> something in Solaris 10 that IDS should have, but didn't, account for? >> Or did Sun simply break something in Solaris 10? >> > > Actually...you have dtrace on Solaris 10. > > Use truss -u to check the library call made and dtrace to check the > parameters. >
Thomas J. Girsch wrote: > > I'll try to work up a truss -u, meanwhile here's the stack trace: > > # adb $INFORMIXDIR/bin/oninit core*0 ... > libc.so.1`getspnam_r+0x68(1116253b8, 1011cd548, 1011cd578, 400, 2000, 0) ... We IDS is calling getspnam_r and the crash occurs inside this call. I suspect a Solaris bug but also:- 1. You do have the onconfig parameter PAM_STACKSIZE set to at least 128 do you? 2. Can you use adb to display the parameters to the getspnam_r call? David.
> 1. You do have the onconfig parameter PAM_STACKSIZE set to at least 128 do you? By default it's unset, but we've set it as high as 256, and it makes no difference. > 2. Can you use adb to display the parameters to the getspnam_r call? I don't know from debuggers. It took everything I had just to convince adb to give me a stack trace! :) david@smooth1.co.uk wrote: > Thomas J. Girsch wrote: >> I'll try to work up a truss -u, meanwhile here's the stack trace: >> >> # adb $INFORMIXDIR/bin/oninit core*0 > ... >> libc.so.1`getspnam_r+0x68(1116253b8, 1011cd548, 1011cd578, 400, 2000, 0) > ... > > We IDS is calling getspnam_r and the crash occurs inside this call. I > suspect > a Solaris bug but also:- > > > 1. You do have the onconfig parameter PAM_STACKSIZE set to at least 128 > > do you? > > 2. Can you use adb to display the parameters to the getspnam_r call? > > David. >