Closed Bug 110498 Opened 23 years ago Closed 23 years ago

3.3.2 certutil coredumps at Creating CA Cert

Categories

(NSS :: Tools, defect, P1)

Product:
NSS
Component:
Tools
Platform:
Sun
Solaris
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: sonja.mirtitsch, Assigned: wtc)

References

Details

Attachments

(3 files)

stack
1.59 KB, text/plain
Details
core
23 years ago
876.00 KB, application/octet-stream
Details
log
5.56 KB, text/plain
Details 
cert.sh: Creating CA Cert --------------------------
certutil -s "CN=NSS Test CA, O=BOGUS NSS, L=Mountain View, ST=California, C=US"
-S -n TestCA -t CTu,CTu,CTu -v 60 -x -d . -1 -2 -5 -f ../tests.pw.6544 -z
../tests_noise.6544


Generating key.  This may take a few moments...

Segmentation Fault - core dumped
cert.sh: Exit: 6 Fatal - failed to create CA cert


no coredump in the backwardcompatibility tests (running the 3.3.2 libs and the
3.2.2 binaries)

I'll attach a stacktrace and the core
What platform sonja?

bob
Summary: 3.3.2 certutil coredumps at Creating CA Cert → 3.3.2 certutil coredumps at Creating CA Cert
Attached file stack — 

    
    

    
  
oops... 8 - 64bit

    
    

    
  
kentuckyderby and rumraisin, you have the output.logs available on mozilla

    
    

    
  
coredumps still seen at Solaris 8 64 bit testing 64 bit optimized NSS 3.3.2
test hangs later in the stresstest and needs to be killed manually, will file a
seperate bug on this
Severity: normal → blocker
Priority: -- → P1
Target Milestone: --- → 3.3.2

    
    

    
  
Is there a reason why nobody is looking at this bug?

    
    

    
  
Bob, could you take a look at this bug?

This bug and bug 110845 are both crashing in PK11_GenerateKeyPair.
Assignee: wtc → relyea

    
    

    
  
I can't seem to reproduce this with my builds!

Here are my specifics:
spd04(139) uname -a
SunOS spd04 5.8 Generic_108528-02 sun4u sparc SUNW,Ultra-2
spd04(140) cc -V
cc: Sun WorkShop 6 update 2 C 5.3 2001/05/15
usage: cc [ options] files.  Use 'cc -flags' for details
spd04(141) ld -V
ld: Software Generation Utilities - Solaris-ELF (4.0)

help!

    
    

    
  
sorry no forte, switch to ws 5.0

    
    

    
  
Still can't get it to fail.....

What's different between spd04 and kentucky?

spd04(164) uname -a
SunOS spd04 5.8 Generic_108528-02 sun4u sparc SUNW,Ultra-2
spd04(165) cc -V
cc: WorkShop Compilers 5.0 98/12/15 C 5.0
usage: cc [ options] files.  Use 'cc -flags' for details
spd04(166) ld -V
ld: Software Generation Utilities - Solaris-ELF (4.0)


    
    

    
  
just double checking: you build the NSS_3_3_BRANCH with the NSS_3_3_BRANCH
coreconf, and do the 64 bit optimized build on spd04 with workshop 5.0, pulling
in 64 bit nspr and dbm that were build with ws5 (and probably mixed in ws4 objects)?
Do you do a nightly build of 3.3.2 that you could use?

    
    

    
  
I believe that's what Bob did.  I just followed your specifications
exactly and did a 3.3.2 build.  Then I ran all.sh a few times on four
machines and could not reproduce the core dumps.

I will email the certutil binary to you.  (We don't have NSS 3.3.2
nightly builds yet.)

    
    

    
  
Here is the environment of my 3.3.2 build.

Build commands:

% cvs -q co -r NSS_3_3_BRANCH mozilla/security/coreconf mozilla/security/nss
% setenv USE_64 1
% setenv BUILD_OPT 1
% cd mozilla/security/nss
% gmake nss_RelEng_bld

Build tools versions:

spd04:/u/wtc/nss-33branch/branch/mozilla/security/nss/tests 102% which cc
/tools/ns/workshop-5.0/bin/cc
spd04:/u/wtc/nss-33branch/branch/mozilla/security/nss/tests 103% cc -V
cc: WorkShop Compilers 5.0 98/12/15 C 5.0
usage: cc [ options] files.  Use 'cc -flags' for details
spd04:/u/wtc/nss-33branch/branch/mozilla/security/nss/tests 104% ld -V
ld: Software Generation Utilities - Solaris-ELF (4.0)

Build and test machine info:

SunOS spd04 5.8 Generic_108528-02 sun4u sparc SUNW,Ultra-2
SunOS worms 5.8 Generic_108528-09 sun4u sparc SUNW,Ultra-2
SunOS strange 5.8 Generic sun4u sparc SUNW,Ultra-5_10
SunOS euthyphro 5.8 Generic sun4u sparc SUNW,Ultra-5_10

    
    

    
  
I ran the certutil that you sent me and it was fine. Rebuilt NSS on
kentuckyderby which is at a different patchlevel than booboo our release build
machine, and had the same coredump. The only difference between your and our
build I see is the patchlevel (different files in /usr/include), I will try to
find a machine that is at an older level to see if that makes the problem go
away. I will attach a log of what I did so far.
main differences:
#mountain view build
<       in.h    1.26    99/10/25 SMI
<       netdb.h 1.23    99/12/06 SMI
<       NSS 3.3.2 Beta  Nov 21 2001 16:06:00
<       time.h  2.64    99/10/05 SMI

#kentuckyderby
>       in.h    1.31    00/10/28 SMI
>       netdb.h 1.25    01/05/08 SMI
>       NSS 3.3.2 Beta  Nov 26 2001 11:32:59
>       time.h  2.65    00/08/24 SMI

#iplanet release build
>       in.h    1.31    00/10/28 SMI
>       netdb.h 1.24    00/10/23 SMI
>       NSS 3.3.2 Beta  Nov 26 2001 00:30:53
>       time.h  2.66    01/01/17 SMI


    
    

    
  

      
      
      
      

        Attached file
          
        log 
        — 
      

    


  

    
  
Blocks: 110845

    
    

    
  
I tried on 2 other machines that matched the your /usr/include files better and
had the same coredump.
My builds used only Ultra-5_10 and Ultra-60, will now try to find Ultra-2 like
your build machine spd04 seems to be. 
I also build the NSS tip on booboo and y2sun2 and verified that there are no QA
problems on the tip.
Would it be possible for you to rebuild NSS 3.3.2 on strange or euthyphro, and
try again in case I can't find an Ultra 2 with Solaris 8?




    
    

    
  
I rebuilt NSS 3.3.2 on euthyphro and ran all.sh five times
without any coredumps.

Here are the compiler patches we have.  I am not sure if this
is the right command to get the compiler patch versions.
euthyphro:/tools/ns/workshop-5.0/bin 112% what * | grep WorkShop | grep Patch
        RELEASE VERSION WorkShop Compilers 5.0 99/09/16 C++ 5.0 Patch 107311-07
        RELEASE VERSION WorkShop Compilers 5.0 99/09/16 C++ 5.0 Patch 107311-07
        RELEASE VERSION WorkShop Compilers 5.0 99/09/16 C++ 5.0 Patch 107311-07
        RELEASE VERSION WorkShop Compilers 5.0 99/08/12 Compiler Common 5.0 Patc
h 107357-05
        RELEASE VERSION WorkShop Compilers 5.0 99/08/12 Compiler Common 5.0 Patc
h 107357-05

Since we don't use the C++ compiler, I think only Patch 107357-05
is relevant.

    
    

    
  
we are at an older compilerpatch level.
RELEASE VERSION WorkShop Compilers 5.0 99/04/15 Compiler Common 5.0 Patch 107357-02


    
    

    
  
Assuming this is a compiler optimization bug fixed in
Patch 107357-05, would you like to install the latest
compiler patch or try to find out what new code in
NSS 3.3.2 triggered the compiler bug?

    
    

    
  
yes, but I could not find the patch, and also I don't have write permission
where the compiler is installed. I am attempting a forte build instead.

    
    

    
  
forte 6 build passed QA on a release build (with DBM 1.6) as well as with a
regular build (DBM 1.55), I will talk to Laura tomorrow about the ws5 patch level.

 Maybe someone should talk to the Solaris people, so we can find out why this
bug shows up only at our patch level.

    
    

    
  
I reproduced the certutil core dump, with exactly the same
stack trace, on my desktop Solaris 7 machine (gandalf) with
a locally installed WorkShop 5.0 compiler, which doesn't seem
to have any patches installed.  I also verified that there is
no core dump if I compile with our centrally installed WorkShop
5.0 compiler (the compiler we use for our release builds). 


    
    

    
  
Since now we at the mercy of Sun IS for the compilerpatches, I would suggest to
build 3.3.2 64 bit for Solaris at Netscape with workshop 5 and the latest patch
level, put it on the ftp server to mozilla, and we QA it at iPlanet.
The other alternative would be to build with forte6. I think we already
determined that there are no "real" customers for the 64 bit builds anyway, so
it should not matter too much.

 

    
    

    
  
I did the same experiment (compile with both the
locally installed WorkShop 5.0 on gandalf and the
centrally installed WorkShop 5.0 at Netscape) on
NSS 3.3 and NSS 3.3.1 and got the same results.
This shows that the problem was definitely not
introduced in NSS 3.3.2 and is most likely a
compiler optimization bug fixed in Patch 107357-05
of WorkShop 5.0.


Assignee: relyea → wtc

    
    

    
  
cool. So as soon as we can get the compilier upgrade then we should be able to
close this bug and release 3.3.2? 

bob

    
    

    
  
I would like to review the diffs between 3.3.1 and 3.3.2
first.  We should also have two customers test a pre-release
build.

There are a couple of open 3.3.2 bugs that we should close
or defer, but there are no known 3.3.2 blocker bugs at this
moment.
Status: NEW → ASSIGNED

    
    

    
  
Bob,

> as soon as we can get the compilier upgrade...

Sun IS has already decided on the servicedesk ticket it was low priority to
install the patches, and a call there did not help.
As I previously asked, couldn't you just build in Mountain View, and we QA here?

Sonja


    
    

    
  
*** Bug 110845 has been marked as a duplicate of this bug. ***

    
    

    
  
Marked the bug fixed.  This has been determined to be
a WorkShop 5.0 compiler optimization bug.  The fix is
to install the approriate compiler patch.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: