Closed Bug 188441 Opened 18 years ago Closed 18 years ago
_BIG _FDS flag needed on HPUX 11i
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 188.8.131.52 diff -r184.108.40.206 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 ago → 18 years ago
Resolution: --- → FIXED
Whiteboard: fixed in 3.3.4
You need to log in before you can comment on or make changes to this bug.