311279 - crmftest core dumps on HP-UX

Status: RESOLVED FIXED

(NSS :: Test, defect, P1)

Description

[Jason Reid]

crmftest is core dumping on HP-UX. This failure first appeared
20050930.

crmftest -d ../bobdir -p Bob -e [e-mail] -s TestCA -P nss crmf decode
all.sh[100]: 26945 Memory fault(coredump)

(gdb) thread
[Current thread is 1 (system thread 3647440)]
(gdb) backtrace
#0  0xc01cd9ac in __regcomp10_std+0x1e0c () from /usr/lib/libc.2
#1  0x6f7a696c in ?? ()
#2  0xc2cd9140 in SECITEM_CopyItem (arena=Cannot access memory at address 0x312e30cd
) at secitem.c:240
Cannot access memory at address 0x312e30dd

Comment 1

[Robert Relyea]

Jason, do we have a debug build that can give us a slightly more useful
traceback, or does it only fail on optimized build?

bob

Comment 2

[Wan-Teh Chang]

We can't reproduce this crash on our HP-UX B.11.11
system here.  Could someone at Sun find a 32-bit debug
build core file and get a complete stack trace or confirm
that the incomplete stack trace is all we can get?  Thanks.

Comment 3

[Jason Reid]

This is all I can get. I used a DBG build.
The HPUX adb can not unwind the stack on the corefile.

Comment 4

[Wan-Teh Chang]

JR: on HP-UX please use /opt/langtools/bin/gdb on 32-bit
core files and /opt/langtools/bin/gdb64 on 64-bit core files.

It is possible that the stack was trashed, but please try
gdb on the core file.  Thanks.

Comment 5

[Saul Edwards]

The stack definitely looks trashed on the 32-bit build, but for some reason it
can unwind on the 64-bit build:

#0  0xc00000000036fb10 in strcpy+0x3c4 () from /usr/lib/pa20_64/libc.2
#1  0xc00000000020bee8 in SECITEM_CopyItem (arena=0x0, to=0x8000000100037528,
from=0x800003ffff7f12d8) at secitem.c:240
#2  0x400000000001b74c in crmf_create_cert_extension (poolp=0x0,
id=SEC_OID_X509_KEY_USAGE, isCritical=0, data=0x800003ffff7f12d8)
    at crmfreq.c:564
#3  0x400000000001b8ac in CRMF_CreateCertExtension (id=SEC_OID_X509_KEY_USAGE,
isCritical=0, data=0x800003ffff7f12d8) at crmfreq.c:592
#4  0x4000000000016350 in GetExtensions () at testcrmf.c:298
#5  0x4000000000016c4c in CreateCertRequest (pair=0x800003ffff7f0ef8,
inRequestID=251790084) at testcrmf.c:474
#6  0x4000000000018ef4 in MakeCertRequest (pair=0x800003ffff7f0ef8,
inPOPChoice=crmfSignature, inRequestID=251790084) at testcrmf.c:1387
#7  0x40000000000191dc in DoCRMFRequest (signPair=0x800003ffff7f0ef8,
cryptPair=0x800003ffff7f0f18) at testcrmf.c:1454
#8  0x4000000000019ab8 in main (argc=13, argv=0x800003ffff7f0ac8) at testcrmf.c:1637

Comment 6

[Jason Reid]

The trashed output is from gdb on a thirty-two bit build.

Comment 7

[Robert Relyea]

Attachment: Patch to try..

Jason, could you apply this patch to your HP build and try it.

Here's what I believe is happening: HP does not like code which assigns the
address of a stack variable in an initializer. The test program, crmftest, does
exactly that in it's 'GetExtensions' function. I believe we are passing
'data.data' with a bogus pointer, which finally blows up when we are in the
process of copying it.

The stack traceback helped immensely at gathering this theory. If this patch
solves the problem, it will verify the hypothesis.

bob

Comment 8

[Wan-Teh Chang]

Just in case this is a compiler issue, the HP-UX system and compiler
we have at Red Hat are:

typhoon[svrbld]:/home/svrbld> uname -a
HP-UX typhoon B.11.11 U 9000/785 2015658734 unlimited-user license
typhoon[svrbld]:/home/svrbld> which cc
/bin/cc
typhoon[svrbld]:/home/svrbld> what /bin/cc
/bin/cc:
         LINT A.11.01.20 CXREF A.11.01.20
        HP92453-01 A.11.01.20 HP C Compiler
         $ CUPI80_IC7  Jan  7 1999 11:20:34 $

Comment 9

[Wan-Teh Chang]

Comment on attachment 198861 [details] [diff] [review]
Patch to try..

r=wtc.

We can also try declaring the keyUsage with "static const".

Since you are assigning the fields of 'data', we should remove
its initializer ({0, NULL, 0}) and add "data.type = siBuffer;".

Comment 10

[Wan-Teh Chang]

Could someone at Sun please post the output of the
following two commands on your HP-UX release *build*
machine?

  uname -a
  what `which cc`

I posted the output of those two commands on our
HP-UX release build machine in comment 8. Thanks.

Comment 11

[Julien Pierre]

We have two build machines - one for 11.00 and one for 11i . But they are both
PA-RISC. I can't figure out HP marketing on that one. Anyway, the HP 11i build
machine is as follows :

% uname -a
HP-UX hploan1 B.11.11 U 9000/800 1547706547 unlimited-user license
% what `which cc`
/usr/bin/cc:
        LINT B.11.11.06 CXREF B.11.11.06
        HP92453-01 B.11.11.06 HP C Compiler
         $   Sep  8 2000 23:13:51 $ 

On HP 11.00 :

% uname -a
HP-UX smarch B.11.00 U 9000/800 1548706547 unlimited-user license

% what `which cc`
/usr/bin/cc:
         LINT B.11.11.02 CXREF B.11.11.02
        HP92453-01 B.11.11.02 HP C Compiler
         $   Sep  8 2000 23:13:51 $ 

Comment 12

[Wan-Teh Chang]

Jason, Christophe:

In comment 11, Julien posted the information of two HP
build machines.  Do you know which build machine (B.11.00
or B.11.11) produced the builds that crashed?

I'm trying to report this bug to HP.  I've sent email to
two of the HP developers I know.  Hopefully my email will
make it to the HP C Compiler team.

Bob, as far as we are concerned, this bug can be marked
fixed.

Comment 13

[Christophe Ravel]

(In reply to comment #12)
> Jason, Christophe:
> 
> In comment 11, Julien posted the information of two HP
> build machines.  Do you know which build machine (B.11.00
> or B.11.11) produced the builds that crashed?
> 
> I'm trying to report this bug to HP.  I've sent email to
> two of the HP developers I know.  Hopefully my email will
> make it to the HP C Compiler team.
> 
> Bob, as far as we are concerned, this bug can be marked
> fixed.


We are building NSS 3.11 on HP-UX 11.11 (hploan1 machine).