Last Comment Bug 200561 - Cannot load NSS programs due to libnspr.so failure on AIX platform
: Cannot load NSS programs due to libnspr.so failure on AIX platform
Status: RESOLVED FIXED
:
Product: NSPR
Classification: Components
Component: NSPR (show other bugs)
: 4.3
: Other AIX
: P1 critical (vote)
: 4.4
Assigned To: Wan-Teh Chang
: Wan-Teh Chang
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-03 16:06 PST by Bishakha Banerjee
Modified: 2003-11-26 16:33 PST (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
NSS 3.8 QA output log of Backward Compatibility testing (14.71 KB, text/plain)
2003-04-03 16:07 PST, Bishakha Banerjee
no flags Details
Proposed workaround: do not include <string.h> in AIX optimized builds (862 bytes, patch)
2003-04-08 19:17 PDT, Wan-Teh Chang
no flags Details | Diff | Splinter Review

Description Bishakha Banerjee 2003-04-03 16:06:13 PST
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 2003-04-03 16:07:57 PST
Created attachment 119365 [details]
NSS 3.8 QA output log of Backward Compatibility testing
Comment 2 Sonja Mirtitsch 2003-04-03 16:32:34 PST
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 2003-04-03 17:32:51 PST
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 2003-04-03 17:37:44 PST
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 2003-04-03 17:41:07 PST
It should be

#if !(defined(AIX) && !defined(DEBUG))
#include <string.h>
#endif
Comment 6 Wan-Teh Chang 2003-04-08 19:17:19 PDT
Created attachment 119910 [details] [diff] [review]
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 2003-04-08 19:23:12 PDT
I checked in the workaround on the NSPR TIP and
NSPRPUB_PRE_4_2_CLIENT_BRANCH.

Note You need to log in before you can comment on or make changes to this bug.