(2013/02/01 0:41), ISHIKAWA, Chiaki wrote:
(2013/01/31 19:46), Neil wrote:
ishikawa wrote:
Neil wrote:
ISHIKAWA, Chiaki wrote:
I see some code most notably LDAP code in comm-central is not 64bit clean
Really? Thunderbird has been releasing 64-bit Mac and Linux code for some time
now...
Now I cannot seem to find the problematic code quickly enough in the latest
comm-central code.
I should have raised a flag when I was compiling 64 bit version myself and
noticed the problem.
I recall seeing that a hash table was accessed using a key that is calculated
using only lower 32 bits of address of
an inserted object.
I have skimmed the LDAP code for hashtables but I can only find one that uses a
32-bit key and it is inserting int
values, not pointers. If you should happen to trip over the code again, please
do not hesitate to file a bug, thanks!
Sorry, it may not have been ldap code (my memory is now hazy).
But please take a look at this code. I am using comm-central code
for development/debugging TB.
https://mxr.mozilla.org/comm-central/source/mozilla/security/nss/lib/base/hash.c#53
The code uses a lower 32 bit of address obviously.
And if I recall correctly, when I compiled TB under 64 bit and chased the
"warning: cast from pointer to integer of different size" (or vice versa?)
I found a place where the equality of the key valuex was considered the
equality of two hash entries (under 32 bit, I suppose this is correct.).
To its credit, the code clearly checks that the address space is 32 bits at
run-time.
If this piece of code is not used in the production version of TB, fine.
(Also, ldap may not be that widely used outside enterprise setting, so
I suspect hitting this bug may not be a high-probability event.)
Actually, when I tried to look at the different sizes of pointer and integer
issues, and
found this code, I gave up on compiling 64 bits.
Funny, I have no idea why I thought it was ldap. (could it be that
it uses this mozilla library [the libraries created below ./mozilla
subdirectory] somehow?)
I disabled ldap in MOZCONFIG and thought I would be OK...
Anyway, I will raise a flag when I notice the code
where equality of hash values is considered the equality of the hash entries.
I thought it was strange when I read the 64 bit version of TB was released, and
I assumed
that the offending code (which somehow I tought was ldap??) is not enabled.
But maybe the flaw in TB code was not noticed before ?
TIA
I suppose that nobody has hit the run-time assertion in the
said hash function suggests that it is dead code as far production TB is
concerned.
Also, I may have read the code incorrectly.
In any case, the incorrect use on 64 bit system would result in
runtime assertion failure (correct? Or is PR_ASSERT() just a slap on the hand
instead of real abort()?), we will know if this routine is misued on 64 bit.
So I suspect this is a low priority issue for now.
TIA
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
