Crash [@memmove | nsTArray_base::ShiftData(unsigned int, unsigned int, unsigned int, unsigned int) ]




9 years ago
8 years ago


(Reporter: cbook, Assigned: sicking)



1.9.1 Branch
Windows XP

Firefox Tracking Flags

(status1.9.1 wanted)


(crash signature)



9 years ago
filing from the topcrash stats:|%20nsTArray_base%3A%3AShiftData%28unsigned%20int%2C%20unsigned%20int%2C%20unsigned%20int%2C%20unsigned%20int%29

one comment mentioned "once I uploaded mozilla it says I don't have enough memory and then it stops. should I uninstall it because it has been nothing but problems." but not sure how to reproduce
Flags: blocking1.9.2?

Comment 1

9 years ago
this is something we need to have urls for ?
I'll take this
Assignee: nobody → jonas
status1.9.1: --- → wanted
Duplicate of this bug: 507114
There are different stacks involved in this crash. That's why I'm not sure if bug 507114 is really a dupe of this one. I filed bug 507114 on request of dbaron based on his comment on bug 494617 which also have a similar stack. I'm confused now.

Comment 5

9 years ago
Just crashed my SM2RC1 with this crash-report after two-times pressing "k" for ignore on mailnews

Comment 6

9 years ago
Once this signature is split up (bug 520678), will we just mark this bug as invalid?
Jonas, is this likely fixed by bug 494617?
Only partially. I think bug 507114 is a bigger contributor.

Also note that this bug will basically be split up into several once bug 520678 is fixed.


9 years ago
Last Resolved: 9 years ago
Resolution: --- → INVALID
Judging from the comments, a some or all of these crashes may be out-of-memory crashes.

Comment 10

9 years ago
This is currently ranked #56 overall top crash.  when we split this up into many signatures will all the new signatures scatter to the wind and be much harder to identify as a collective group of semi-related out-of-memory crashes?   I wonder if there is a way to hold on to this collective information and maybe use this as a tracking bug.

Comment 11

9 years ago
That's what bug 493779 is for.  We're also splitting "operator new" crashes in bug 511758, btw, and for the same reason: not all of them are due to high memory use.
Flags: blocking1.9.2?
Crash Signature: [@memmove | nsTArray_base::ShiftData(unsigned int, unsigned int, unsigned int, unsigned int) ]
You need to log in before you can comment on or make changes to this bug.