User-Agent: Mozilla/5.0 (compatible; Konqueror/3.4; FreeBSD; X11; amd64) KHTML/3.4.1 (like Gecko) Build Identifier: The thread_id is assumed, for some reason, to be a 32-bit value. This is not true on 64-bit systems. There is a special type for thread-ids and that is what should be used. Reproducible: Always

This is a real bug, but we can't use your proposed fix. PR_GetThreadID is supposed to return a NSPR thread ID that is a 32-bit unsigned integer and that may not be related to the pthread or native thread ID. The correct fix is for NSPR to create and maintain a 32-bit unsigned thread ID, rather than casting pthread_t to PRUint32. Because of this bug, PR_GetThreadID is not usable. That's one reason it is a "private" (but exported) function.

=The correct fix is for NSPR to create and maintain a 32-bit unsigned thread ID Why can't it be a 64-bit value on 64-bit systems? =rather than casting pthread_t to PRUint32. My fix is not suggesting that. I suggest using pthread_t wherever thread ID is used. If need be, a PRThreadType or something can be introduced (which will be the same as pthread_t on pthread-using systems).

This bug is 5 years old. What's holding it up? Why is anyone worried for ABI-compatibility (on 64-bit systems), that would be broken by the proposed change, if the existing code never worked on 64-bit systems anyway>

(In reply to Mikhail Teterin from comment #4) > This bug is 5 years old. What's holding it up? Why is anyone worried for > ABI-compatibility (on 64-bit systems), that would be broken by the proposed > change, if the existing code never worked on 64-bit systems anyway> I suppose, patch should be updated and review flag set as explained in https://developer.mozilla.org/En/Developer_Guide/How_to_Submit_a_Patch#Getting_reviews

It should block bug 512076.