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

Status: RESOLVED INVALID

(Core :: General, defect)

Description

[Carsten Book [:Tomcat]]

filing from the topcrash stats:

http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.5.3&query_search=signature&query_type=exact&query=&date=&range_value=1&range_unit=weeks&do_query=1&signature=memmove%20|%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

Comment 1

[Carsten Book [:Tomcat]]

this is something we need to have urls for ?

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'll take this

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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

[stefan.blumenrath]

Just crashed my SM2RC1 with this crash-report after two-times pressing "k" for ignore on mailnews
bp-33647aec-4c92-408e-aa5b-b9d872091012

Comment 6

[Jesse Ruderman]

Once this signature is split up (bug 520678), will we just mark this bug as invalid?

Comment 7

[Samuel Sidler (old account; do not CC)]

Jonas, is this likely fixed by bug 494617?

Comment 8

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Judging from the comments, a some or all of these crashes may be out-of-memory crashes.

Comment 10

[chris hofmann]

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

[Jesse Ruderman]

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.