If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

nsHashTable.h is not 64-bit clean with Sun Forte 6.0 Update 2 compiler




17 years ago
8 years ago


(Reporter: Ted Cabeen, Unassigned)




Firefox Tracking Flags

(Not tracked)



(1 attachment)



17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/4.7 [en] (X11; U; SunOS 5.8 sun4u)
BuildID:    20010221

When building mozilla with the Sun Forte 6.0 Update 2 (prerelease) compiler for
64-bit architecture, you get get casting errors in dist/include/nsHashtable.h. 
However, if you use an identical command line with the 64-bit enabling options
removed, it compiles fine and outputs a 32-bit output file.  

Reproducible: Always
Steps to Reproduce:
1. configure with the following command line:
CXX=CC CXXFLAGS="-xarch=v9a" CFLAGS="-xarch=v9a" CC=cc ./configure
--prefix=/opt/pkgs/mozilla-0.8 --with-x --disable-mailnews --with-jpeg
--with-zlib --with-png --disable-debug --enable-ultrasparc
--enable-optimize="-fast -xarch=v9a" --disable-tests --enable-strib-libs
2. run make
3. manually compile those few times where CFLAGS is ignored.
4. continue make until the following compilation line:
CC -library=iostream -o nsErrorService.o -c -DOSTYPE=\"SunOS5\" -DOJI
-D_IMPL_NS_COM   -I../../dist/include -I../../dist/include     
-I/usr/openwin/include   -KPIC  -xarch=v9a -mt -fast -xarch=v9a  -DNDEBUG
-DMOZ_USER_DIR=\".mozilla\" -DMOZ_DLL_SUFFIX=\".so\" -DXP_UNIX=1

Actual Results:  An error from the compiler is returned:
"../../dist/include/nsHashtable.h", line 190: Error: Cannot cast from
nsISupports*const to unsigned.
"../../dist/include/nsHashtable.h", line 219: Error: Cannot cast from void*const
to unsigned.
2 Error(s) detected.

Expected Results:  It should have successfully compiled the code.  The code does
compile in 32-bit mode though.  This strongly suggests a 64-bit cleanliness


17 years ago
Assignee: scc → cls
Component: XPCOM → Build Config
Ever confirmed: true
QA Contact: kandrot → granrose

Comment 1

17 years ago
Marking NEW after talking to Asa.

Comment 2

17 years ago
Bouncing to xpcom.
Assignee: cls → scc
Component: Build Config → XPCOM
QA Contact: granrose → kandrot
The casting problem has been solved by bug 20860 but I still think that
nsHashTable is not 64-bit clean.  For the HashCode of nsISupportsKey &
nsVoidKey, it casts the void * of the key object to 32 bits which I think is
causing problems in the nsObserverService code.

Keywords: 64bit
Summary: nsnsHashTable.h is not 64-bit clean with Sun Forte 6.0 Update 2 compiler → nsHashTable.h is not 64-bit clean with Sun Forte 6.0 Update 2 compiler

Comment 4

16 years ago
Looking at http://lxr.mozilla.org/seamonkey/source/nsprpub/lib/ds/plhash.h#46
What about getting the following _quick_ workaround implemented:
-- snip --
#ifdef USE_64BITS
typedef PRUint64 PLHashNumber;
#define PL_HASH_BITS 64  /* Number of bits in PLHashNumber */
typedef PRUint32 PLHashNumber;
#define PL_HASH_BITS 32  /* Number of bits in PLHashNumber */
-- snip --

I know that this is silly, but it provides a clean workaround without
introducing other side-effects (except that hash tables take twice the memory)

Comment 5

16 years ago
Stealing from scc ...
Assignee: scc → Roland.Mainz

Comment 6

16 years ago
there may be un-obvious ramifications from a change like this, but it's
certainly with trying as an experiment.  You'll want to look at places where
hashes are generated to see how many obey this macro.

Comment 7

16 years ago
Created attachment 58086 [details] [diff] [review]
Patch for mozilla/nsprpub/lib/ds/plhash.h - changing |PLHashNumber| to |PRUint64| on 64bit platforms

Comment 8

16 years ago
Comment on attachment 58086 [details] [diff] [review]
Patch for mozilla/nsprpub/lib/ds/plhash.h - changing |PLHashNumber| to |PRUint64| on 64bit platforms

Unfortunately it does not fix assertions like:
-- snip --
* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE)
[nsIObserverService.addObserver]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)" 
location: "JS frame :: chrome://communicator/content/utilityOverlay.js ::
utilityOnLoad :: line 406"  data: no]
-- snip -- 


Any ideas ?
Attachment #58086 - Flags: needs-work+
Does that PLHashNumber change fix anything?  It would surprise me if it does,
since that should only controls the number of bits in the result of hash functions.

seawood - In what way do you think nsISupportsKey and nsVoidKey aren't 64-bit
clean?  Using the low 32 bits for a hash code should be perfectly clean.  Having
the same hash code doesn't guaranteed that the values are the same -- it only
strongly suggests it, yielding a performance optimization (that would still be
just as good even if it's only based on the low 32 bits of the pointer).

Comment 10

15 years ago
A fix for the assertion shown in comment 8 is described in Bug 178499 - boolean
values are not being passed correctly in 64-bit mode.
You'll want to ensure that the multiplicative hash uses a 64-bit multiply, to
take advantage of this wider size.  But as dbaron points out, there is likely to
be no gain in hash function effectiveness for commonly-hashed pointer types.



12 years ago
QA Contact: kandrot → nobody
Assignee: roland.mainz → nobody
QA Contact: nobody → xpcom


8 years ago
Last Resolved: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.