Map is crash happy. Let's blame TxObject

VERIFIED FIXED

Status

()

Core
XSLT
--
critical
VERIFIED FIXED
16 years ago
16 years ago

People

(Reporter: Axel Hecht, Assigned: Axel Hecht)

Tracking

({crash})

Trunk
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

16 years ago
Depending on how eagerly ones OS returns high value pointers, the following
code in Map blows:

    //-- compute hash for key
    PRInt32 hashCode = key->hashCode();

    //-- calculate index
    int idx = hashCode % numberOfBuckets;

    //-- fetch first item in bucket
    BucketItem* bktItem = elements[idx];

hashCode is signed -> idx is signed, negative indexes aren't fun.

Patch coming up.
(Assignee)

Comment 1

16 years ago
Created attachment 81671 [details] [diff] [review]
make TxObject::hashCode() return PRUint32
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
Keywords: crash
Comment on attachment 81671 [details] [diff] [review]
make TxObject::hashCode() return PRUint32

r=peterv
Attachment #81671 - Flags: review+

Comment 3

16 years ago
Comment on attachment 81671 [details] [diff] [review]
make TxObject::hashCode() return PRUint32

sr=jag
Attachment #81671 - Flags: superreview+
(Assignee)

Comment 4

16 years ago
fix landed on the trunk, mailed drivers
Keywords: approval
(Assignee)

Comment 5

16 years ago
let it crash.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Keywords: approval
Resolution: --- → FIXED
We have time for 1.0.1, so this bug has a chance to go there. Do you have a
testcase/platform where this occurs, or is this totally random? Are there
talkback reports on this? Does this cause any new compiler warnings? Are all the
users of this API and the new unsigned values prepared to deal with unsigned values?
(Assignee)

Comment 7

16 years ago
we didn't verify for a long time.
I really checked, so VERIFIED.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.