Closed Bug 188441 Opened 18 years ago Closed 18 years ago

_USE_BIG_FDS flag needed on HPUX 11i

Categories

(NSS :: Build, defect)

3.3.2
HP
HP-UX
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: sonja.mirtitsch, Assigned: wtc)

Details

Attachments

(1 file)

Directoryserver ran out of file descriptors on HPUX 11i. The problem went away
after they recompiled all their components with this flag.
Nobody ever narrowed down the problem to NSS, but it was suspected that NSPR,
DBM and NSS need this flag.

Sun's version of NSS 3.3.3 was build with this flag set as were the NSPR and DBM
versions it is based upon

From the HP-UX Release Notes: "This feature is optional because it will
not be often used and to minimize the impact on existing code.  An application
requiring more than 2048 file descriptors must be recompiled with the new symbol
_USE_BIG_FDS defined.  To do this, add the flag D_USE_BIG_FDS to the compile
command in the application's makefile.  Or, the symbol can be defined at the
beginning of every application source file (via #define _USE_BIG_FDS)...."



cvs server: Diffing .
Index: HP-UXB.11.11.mk
===================================================================
RCS file: /cvsroot/mozilla/security/coreconf/HP-UXB.11.11.mk,v
retrieving revision 1.1.2.1
diff -r1.1.2.1 HP-UXB.11.11.mk
38a39
> OS_CFLAGS               += -D_USE_BIG_FDS


see also bug #184514


I have been unable to get more information about the problem
I believe that this change would be a no-op for
NSS, JSS, and DBM (the current users of coreconf)
because none of them are using 'fd_set'.

I'm marking this WONTFIX unless someone can
explain how it's going to affect NSS, JSS, or
DBM.  Also, -D_USE_BIG_FDS should only be added
to the components that need it rather than to
coreconf because coreconf is intended to be
shared by multiple components.  -D_USE_BIG_FDS
may not be appropriate for some code.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WONTFIX
I build NSPR 4.1.3 and NSS 3.3.3 from sources that differ from the mozilla
version enough, that I recommend branching and checking the source into a sun
only repository on redbuild. 
I would like to re-open discussions on this subject, our customer will not
accept a version of NSS that was built without the flag set, since they ran out
of file descriptors when they did.

We build DBM 1.55 and 1.61 as well as JSS with a coreconf/HP-UXB.11.11.mk that
set the flag

I need to generate a solarispatch next week and I do not want to build this
version of NSS again from files that differ from the version that is checked in. 

> Also, -D_USE_BIG_FDS should only be added
> to the components that need it rather than to
> coreconf because coreconf is intended to be
> shared by multiple components.  -D_USE_BIG_FDS
> may not be appropriate for some code.

where would be a good place to add it then?

Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
To the best of my knowledge, the _USE_BIG_FDS macro
only affects the fd_set type (used by select()).  I
have searched the NSS and DBM source code and found
no use of fd_set.  This is why I believe recompiling
NSS and DBM with -D_USE_BIG_FDS has no effect.

If NSS needs -D_USE_BIG_FDS, we are supposed to add
a new file mozilla/security/nss/config/config.mk,
add -D_USE_BIG_FDS to that file, and have every NSS
makefile include that file.  (Every NSS makefile
contains an empty section "(3) Include 'component'
configuration information. (OPTIONAL)" for this
purpose.)  Obviously it is less work to just add
-D_USE_BIG_FDS to coreconf.
> To the best of my knowledge, the _USE_BIG_FDS macro
> only affects the fd_set type (used by select()).  I
> have searched the NSS and DBM source code and found
> no use of fd_set.  This is why I believe recompiling
> NSS and DBM with -D_USE_BIG_FDS has no effect.

Are you certain enough that you recommend we tell our customer their problem
can't be related to NSS and give them a version that we build directly off the
NSS_3_3_BRANCH without the USE_BIG_FDS modification? 
Since this is a preprocessor macro, couldn't we do one build without it, and one
with, and show that the NSS bits are exactly the same?
the name of the build machine is hploan1, if it doesn't let you log in let me
know, also let me know if you mean I should do this myself.
I am confident that your customer's problem can't
be related to NSS.  Fixing that PR_Poll bug or
recompiling NSPR with -D_USE_BIG_FDS should suffice.

We can compare the NSS binaries compiled with and
without -D_USE_BIG_FDS.  Just wanted to note that
some compilers embed compile timestamps in the
binaries, so you should first do two compiles of
the same source tree to see if the HP compiler does
that.
Ian are you going to build the 2 versions, or do you want me to do that? I can
build it, but I feel not competent to do the comparison.
I'll try it tomorrow.
Unfortunately, my suggestion won't work.  I did two builds on HP, without
changing anything between them, and there were differences.  I tried dumping the
binaries as hex to see if it was just a one-line diff that would be in the same
place (e.g., a timestamp), but there were actually a large number of
differences.  Maybe it timestamps each source file?  Dunno.
patch for coreconf on NSS_3_3_BRANCH
patch checked into NSS_3_3_BRANCH, marking fixed.  Will set milestone once I
have 3.3.4 in bugzilla.
Status: REOPENED → RESOLVED
Closed: 18 years ago18 years ago
Resolution: --- → FIXED
Whiteboard: fixed in 3.3.4
Whiteboard: fixed in 3.3.4
Target Milestone: --- → 3.3.4
You need to log in before you can comment on or make changes to this bug.