Closed
Bug 141173
Opened 22 years ago
Closed 22 years ago
Map is crash happy. Let's blame TxObject
Categories
(Core :: XSLT, defect)
Core
XSLT
Tracking
()
VERIFIED
FIXED
People
(Reporter: axel, Assigned: axel)
Details
(Keywords: crash)
Attachments
(1 file)
1.44 KB,
patch
|
peterv
:
review+
jag+mozilla
:
superreview+
|
Details | Diff | Splinter Review |
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•22 years ago
|
||
Comment 2•22 years ago
|
||
Comment on attachment 81671 [details] [diff] [review] make TxObject::hashCode() return PRUint32 r=peterv
Attachment #81671 -
Flags: review+
Comment 3•22 years ago
|
||
Comment on attachment 81671 [details] [diff] [review] make TxObject::hashCode() return PRUint32 sr=jag
Attachment #81671 -
Flags: superreview+
Assignee | ||
Comment 5•22 years ago
|
||
let it crash.
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•22 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.
Description
•