200561 - Cannot load NSS programs due to libnspr.so failure on AIX platform

Status: RESOLVED FIXED

(NSPR :: NSPR, defect, P1)

Description

[Bishakha Banerjee]

While running Backward Compatibility NSS 3.8 tests (against BC binaries of NSS
3.7) on AIX, failures to load NSS cmds were seen for the OPT build.

Log files report a libnspr4.so failure and are attached.

Comment 1

[Bishakha Banerjee]

Attachment: NSS 3.8 QA output log of Backward Compatibility testing

Comment 2

[Sonja Mirtitsch]

exactly the same failure is seen at Sun
AIX 43, 32 and 64 bit optimized builds only. 3/30 was the last time that we ran
backward compatibility tests on AIX 4.3, then they passed

init.sh init: Testing PATH
/share/builds/integration/nss/bc-cu/AIX4.3_OPT.OBJ/bin:/share/builds/mccrel3/nss/nsstip/../nss322/builds/20010820.1/y2sun2_Solaris8/mozilla/dist/../security/nss/tests:/share/builds/mccrel3/nss/nsstip/../nss322/builds/20010820.1/y2sun2_Solaris8/mozilla/dist/AIX4.3_OPT.OBJ/bin:.:/u/svbld/bin:/tools/ns/bin:/bin:/usr/bin:/usr/sbin:/usr/ccs/bin:/usr/dist/local/exe:/usr/bin/X11:/usr/audio/bin:/u/svbld/ns/securityqa:/tools/contrib/bin:/usr/local/bin
against LIB
/share/builds/mccrel3/nss/nsstip/builds/20030403.2/booboo_Solaris8/mozilla/dist/AIX4.3_OPT.OBJ/lib
which: 0652-141 There is no certutil in . /u/svbld/bin /tools/ns/bin /bin
/usr/bin /usr/sbin /usr/ccs/bin /usr/dist/local/exe /usr/bin/X11 /usr/audio/bin
/tools/contrib/bin /usr/local/bin.
cert.sh: Certutil Tests ===============================
cert.sh: Creating a CA Certificate ==========================
cert.sh: Creating CA Cert DB --------------------------
certutil -N -d . -f ../tests.pw.22100
exec(): 0509-036 Cannot load program certutil because of the following errors:
	0509-130 Symbol resolution failed for certutil because:
	0509-136   Symbol memcpy (number 45) is not exported from
		   dependent module
/share/builds/mccrel3/nss/nsstip/builds/20030403.2/booboo_Solaris8/mozilla/dist/AIX4.3_OPT.OBJ/lib/libnspr4.so.
	0509-192 Examine .loader section symbols with the
		 'dump -Tv' command.
cert.sh: Exit: 5 Fatal - failed to create CA
ssl.sh: SSL tests ===============================

Comment 3

[Wan-Teh Chang]

This problem was introduced by the fix for bug 192962.

In NSPR 4.3 Beta 1 or earlier, libnspr4.so exports memcpy
because it calls memcpy but does not include <string.h>.

The mere linking with libnspr4.so causes an executable
to resolve four libc symbols with libnspr4.so:

----------
spd12:/u/wtc/nspr-4.3b1/aix.opt/pr/tests 186% cat foo.c
int main() { return 0; }
spd12:/u/wtc/nspr-4.3b1/aix.opt/pr/tests 187% xlC_r -o foo foo.c -brtl -L../../d
ist/lib -lnspr4
spd12:/u/wtc/nspr-4.3b1/aix.opt/pr/tests 196% dump -Tv foo | grep libnspr4.so
[11]    0x00000000    undef      IMP     DS EXTref     libnspr4.so memcpy
[12]    0x00000000    undef      IMP     DS EXTref     libnspr4.so strcmp
[13]    0x00000000    undef      IMP     DS EXTref     libnspr4.so memmove
[14]    0x00000000    undef      IMP     DS EXTref     libnspr4.so bcopy
----------

So, there is nothing an app can do to prevent this.  As shown
above, foo.c does not call any functions.

Between NSPR 4.3 Beta 1 and RTM, I added the necessary #include
<string.h> to NSPR.  This caused libnspr4.so in NSPR 4.3 RTM to
not export memcpy.  Therefore, executables that were linked with
NSPR 4.3 Beta 1 or earlier get an unresolved memcpy reference
with the libnspr4.so in NSPR 4.3 RTM.

I can easily restore the accidental memcpy export by ifdef'ing
one of the #include <string.h> like this:

#ifndef AIX
#include <string.h>
#endif

But I need a better solution so that we don't remove the memcpy
export again in the future.

Comment 4

[Wan-Teh Chang]

Note that the workaround should be

#if !defined(AIX) && !defined(DEBUG)
#include <string.h>
#endif

because we were including <string.h> in debug builds.

Comment 5

[Wan-Teh Chang]

It should be

#if !(defined(AIX) && !defined(DEBUG))
#include <string.h>
#endif

Comment 6

[Wan-Teh Chang]

Attachment: Proposed workaround: do not include <string.h> in AIX optimized builds

I am not happy with this workaround, but I don't have time
to investigate this problem and come up with the right
solution.

Comment 7

[Wan-Teh Chang]

I checked in the workaround on the NSPR TIP and
NSPRPUB_PRE_4_2_CLIENT_BRANCH.