178314 - Nightly QA as well as Tinderbox on 'diffie' failing - 11/4/2002

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P1)

Description

[Bishakha Banerjee]

Nightly QA has failed for the past three days (Saturday, Sunday and Monday) on
'diffie', our OSF/1 machine. 

NSS tip builds are also failing on diffie on the BlueBird Tinderbox page.
Tinderbox page does not show any checkins around the time it happened (Friday,
5:50 pm) 

Attaching the log and results.

Comment 1

[Bishakha Banerjee]

Attachment: output log

Comment 2

[Bishakha Banerjee]

Attachment: results.html

Comment 3

[Sonja Mirtitsch]

This looks like a failed build to me, do you have the build logs?

Comment 4

[Bishakha Banerjee]

yes, NSS tip builds are failing on the Bluebird page.

This is from a recent build log:
diffie.mcom.com[robobld]:/usr/nsstip_tbx/nss_tbx_osf1/logs/tinderbox/OSF1> !!
tail gmake-full-domestic.log.1
cc: Error: sha512.c, line 1005: In this statement, "H384" is not declared. (unde
clared)
    memcpy(H, H384, sizeof H384);
--------------^
gmake[2]: *** [OSF1V5.0_DBG.OBJ/sha512.o] Error 1
gmake[2]: Leaving directory `/usr/nsstip_tbx/nss_tbx_osf1/builds/tinderbox/OSF1/
mozilla/security/nss/lib/freebl'
gmake[1]: *** [libs] Error 2
gmake[1]: Leaving directory `/usr/nsstip_tbx/nss_tbx_osf1/builds/tinderbox/OSF1/
mozilla/security/nss/lib'
gmake: *** [libs] Error 2
Elapsed Time = 00:01:10
Mon 4 Nov 2002 14:58:51

Comment 5

[Bishakha Banerjee]

Sorry, changing the Component did not automatically do the reassigning of the bug.

Reassigning to wtc to assign as appropriate 

Comment 6

[Bishakha Banerjee]

Attachment: build error log

checking in the gmake error log from 'diffie'

Comment 7

[Robert Relyea]

I looks like it's a problem in the new sha1 code. Do we have a link to the
bluebird tinderbox, or is there a way to get the OSF/1 platform to show up on
our normal tinderbox page?

bob

Comment 8

[Bishakha Banerjee]

Here's the link to the BlueBird page:

http://tinderbox.mozilla.org/showbuilds.cgi?tree=BlueBird

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

Taking bug.

There seems to be a problem with the c preprocessor on this platform.

Given the following macro:
    #define ULLC(hi,lo) 0x ## hi ## lo ## UL
and the following line of c code:
    ULLC(428a2f98,d728ae22), ULLC(71374491,23ef65cd),
the preprocessor emits this line:
     0x428a2f98d728ae22UL ,  0x7137449123e f65cdUL ,
Notice the extra blank -------------------^
The extra blank causes the problem.  

The ULLC macro works fine on all our other platforms.  

If we cannot get a patch to fix the compiler, then I guess I'll have to change 
the source to hold 3 copies of the tables of 64-bit constants, one in each of 
the 3 formats, with the right one conditionally compiled.  

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

The person who formerly provided support for Dec's OSF/1 for mozilla/Netscape
is apparently no longer with us.  So, I have checked in a workaround.
If this bug is ever fixed in the affected compiler, I hope to remove this
workaround.

Comment 11

[Wan-Teh Chang]

I believe Nelson has removed his workaround because we installed
the latest compiler on "diffie" and "sbsdec1".

I just landed NSS 3.8 on the Mozilla trunk, and this bug is causing
the "dec1" Mozilla tinderbox to fail:
http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey-Ports

If we can't get the compiler on "dec1" upgraded, we'll need to
re-open this bug and restore Nelson's workaround.

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Might the compiler bug in question be avoided by removing the spaces and using
#define ULLC(hi,lo) 0x##hi##lo##UL
instead of
#define ULLC(hi,lo) 0x ## hi ## lo ## UL
?

Comment 13

[Wan-Teh Chang]

The change that David Baron suggested doesn't work.

The file now requires one of these compilers on OSF1:
Compaq C V6.3-132  or Compaq C V6.4-214 (dtk)

Comment 14

[Wan-Teh Chang]

I've determined by experiments what the C preprocessor bug is.
It has nothing to do with the concatenation operator ##.  The
C preprocessor has problem with macro arguments of this pattern:

one or more digits, followed by e or E, followed by a non-digit.

Knowing this, we have a viable workaround.  We could change the
ULLC macro from something like:

  #define ULLC(hi,lo) 0x ## hi ## lo ## UL
  ULLC(71374491,23ef65cd)

to

  #define ULLC(hi,lo) ((hi ## UL << 32) + lo ## UL)
  ULLC(0x71374491,0x23ef65cd)

By having 0x at the beginning of macro arguments, we work around
this C preprocessor bug.

Here is a simple test to demonstrate the C preprocessor bug.

dec1:/u/wtc/nss-tip/mozilla/security/nss/lib/freebl 112% cc -V | grep UNIX
Compaq C V6.1-023 on Compaq Tru64 UNIX V5.0A (Rev. 1094)
        Tru64 UNIX Compiler Driver 5.0
dec1:/u/wtc/nss-tip/mozilla/security/nss/lib/freebl 113% cat foo.c
#define FOO(x) x

FOO(0ex)
FOO(0e0)
FOO(ex)
FOO(xex)
dec1:/u/wtc/nss-tip/mozilla/security/nss/lib/freebl 114% cc -E foo.c
# 1 "foo.c"


 0e x
 0e0
 ex
 xex

Comment 15

[Shanmugavelu Shanmuganathan (gone)]

The compiler on dec1.mcom.com is now upgraded to 
Compaq C V6.4-214 (dtk).