Re: IDS Crashes with LDAP on Solaris 10
Thomas J. Girsch reported IDS crashing with a SIGSEGV on Solaris 10 when using LDAP, and posted an adb stack trace through libnss3 and libsoftokn3 into close and fork code. Another poster suggested truss -u and dtrace, and asked about PAM_STACKSIZE of at least 128. Thomas said setting it as high as 256 made no difference and he could not use debugger parameters. Unresolved.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
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. >