Closed Bug 711568 Opened 13 years ago Closed 10 years ago

Crash [@ EMPTY: no crashing thread identified; corrupt dump ] & [ERROR_NO_MINIDUMP_HEADER] (unactionable)

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: marcia, Unassigned)

References

(Depends on 1 open bug)

Details

(4 keywords, Whiteboard: [unactionable])

Crash Data

Attachments

(1 file, 1 obsolete file)

WinDbg trace. I have cut the trace post access violation. If previous content is needed then let me know. It is more than 100MB in size.
14.82 KB, application/x-zip-compressed
Details
During a triage session yesterday, Sheila mentioned we should a bug on file for this stack since it is consistently the top crash in all releases. Even though we probably cannot do anything about these crashes, filing this for tracking. https://crash-stats.mozilla.com/report/list?signature=EMPTY:%20no%20crashing%20thread%20identified;%20corrupt%20dump
This Bug report might be linked to this link: https://bugzilla.mozilla.org/show_bug.cgi?id=703916
Request to merge this bug report in this: https://bugzilla.mozilla.org/show_bug.cgi?id=696637
Blocks: 716443
tracking-firefox9: --- → ?
Also occurs in Thunderbird, as document at: https://bugzilla.mozilla.org/show_bug.cgi?id=610551
No longer blocks: 716443
Also occurs in Fennec Native.
I don't believe tracking this for a single release is the right strategy here. A larger effort may be necessary. Do we have any leads about whose domain this falls under?
tracking-firefox9: ? → -
I agree. This is nothing new and right now it's not actionable. It's worth having it logged but tracking it to a particular release doesn't serve any value unless there is some clear regression/increase in these. We would log that separately.
Product: Firefox → Core
QA Contact: general → general
Version: 9 Branch → unspecified
Depends on: 587729
I Tried another link, Got crash but report different. http://crash-stats.mozilla.com/report/index/bp-e7981390-cf0f-45af-8138-03c632120315
This bug is here to make it show up in crash stats, but it won't be fixed. (In reply to TB from comment #9) > http://crash-stats.mozilla.com/report/index/bp-e7981390-cf0f-45af-8138- > 03c632120315 File a new bug for that.
Depends on: 743221
No longer depends on: 743221
The bug still exists in Firefox 12. Also, if it is there only for tracking purpose then it should show up in crash reports, with this signature, as a related bug. Here is one report where it doesn't show up: https://crash-stats.mozilla.com/report/index/bp-bd6aae72-6fd2-4ade-ad41-b9f392120428
It would be good if someone experiencing this bug could use WinDbg to get a stack trace and attach it to this bug: https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg
When I attach WinDbg I can't repro the crash. But Firefox allocates over 2GB of memory before this happens: http://dl.dropbox.com/u/5749744/Firefox/Firefox_nightly_CPU_mem_.png Process, Stack, Count, Flags, Commit Type, Reserve Type, Address, Thread, Desired Size, Committed Actual, Outstanding Committed, Reserved Actual, Outstanding Reserved, Event Time, Decommit Time, Release Time , | | | | | mozjs.dll!js::CrossCompartmentWrapper::get, 1941, , , , , , , 1696419840, 30441472, 1168113664, 62914560, , , , | | | | | |- mozjs.dll!JSCompartment::wrap, 1909, , , , , , , 1695424512, 30375936, 1168113664, 62914560, , , , | | | | | | |- mozjs.dll!js_NewStringCopyN, 1908, , , , , , , 1693327360, 30375936, 1166016512, 62914560, , , , | | | | | | | mozglue.dll!je_malloc, 1908, , , , , , , 1693327360, 30375936, 1166016512, 62914560, , , , | | | | | | | |- mozglue.dll!chunk_alloc_mmap, 817, , , , , , , 1166016512, 29999104, 1166016512, 62914560, , , js::CrossCompartmentWrapper::get calls JSCompartment::wrap which again calls js_NewStringCopyN and this allocates all memory for me. In some cases firefox calms down after 3 minutes but in this time it allocates and frees a lot of memory and sometimes it crashes with the empty thread report.
Nightly is currently unusable for me. It's crashed nine times alone today between 2pm and 3.30pm
(In reply to Paul [sabret00the] from comment #14) > Nightly is currently unusable for me. It's crashed nine times alone today > between 2pm and 3.30pm Nightly is unusable for everybody because of bug 756796, bug 756797, bug 756798, bug 756799, and this bug that are likely related. The bug that caused this regression is unknown. See bug 756796.
No longer depends on: 587729
Depends on: 587729
(In reply to Robin Whittleton from comment #16) > Everytime I get a crash with a corrupt dump it’s to do with WebM <video> > content. There are many causes for a corrupt dump. If you can reliably reproduce your crash, use the debugger to get a valid stack trace (see https://developer.mozilla.org/en/How_to_get_a_stacktrace_for_a_bug_report#Alternative_ways_to_get_a_stacktrace) and file a new bug.
I've been getting EMPTY: no crashing thread identified; corrupt dump errors for over a month. After trouble shooting today and UNCHECKED "Use hardware acceleration when available" per Firefox Option Advanced. Hope it works for some of you...
(In reply to roryh42 from comment #18) > I've been getting EMPTY: no crashing thread identified; corrupt dump errors > for over a month. After trouble shooting today and UNCHECKED "Use hardware > acceleration when available" per Firefox Option Advanced. Hope it works for > some of you... It worked for me. I have not had the error since.
roryh42, you probably hit bug 789260.
(In reply to Scoobidiver from comment #20) > roryh42, you probably hit bug 789260. Scoobidiver, I think your correct. Bug 789260 describes my problem exactly and I've not had a problem since taking corrective action.
Depends on: 797323
At least today this is appearing reproducible on my Default profile, does not happen on a fresh profile. As discussed above, crash is related to memory, FF18b crashes at around 900MB. 1. Setup: Win7Pro SP1 64-bit, NVidia GeForce210 graphics, HW Acceleration OFF (crashes when ON also!), default profile with ~10-20 add-ons, AMD Phenom II X4 B55 processor, 4GB memory. No other user applications open. Using Avast AV software, ZoneAlarm firewall, SpyBotSD. 2. Procedure: launch FF, only one tab, do Google search on "android phone", scroll down, click on "Show more results"... watch memory usage increase in Task Manager. 3. What the screenshot shows. Physical Memory Usage History for two back-to-back crashes 1 minute 34 seconds apart. FF memory usage increase is approx 20MB/second, from approx 150MB to approx 900MB before the crash. Notice that in first trial, memory usage goes up pretty much monotonically. In second trial there's a big drop in memory usage around the 600MB point, something recovering in FF ? but only temporarily. Because crash does not occur in Fresh Profile, I am imagining that my add-ons are to blame. While the obvious thing seems to be to take them out one by one, I am wondering if somewhere in Mozilla-land there is an article describing how best to go about this. I've had the random-crashing problem for a few months, in different scenarios. Another scenario is if a highlighter add-on has very many strings highlighted on a web page. Do not recall ever having had a crash that seemed related to video.
Continuing comment 22 Oops - forgot to mention couple of things: Both crashes have signature: "EMPTY: no crashing thread identified; corrupt dump" Crash UUIDs are: fcd489a1-b4af-4b42-a3c9-0746c2121206 582f4ba7-874a-4309-98ed-ae7272121206 And these are just two recorded out of six I did reproducibly this evening.
Comment 22 Errata Goodness, not having a good evening here! Left out one very salient piece of information - 2. Google IMAGE search for "android phone". Sorry!
rrr, this crash signature is a collection of unrelated issues so this bug is a meta one. If you have reliable steps to reproduce and a valid stack trace (see https://developer.mozilla.org/docs/How_to_get_a_stacktrace_with_WinDbg), please file a new bug.
Keywords: meta
Attachment #689095 - Attachment is obsolete: true
This crash gets me mad : since about two weeks, random crashes. Tried everything without success : reset profile, clean reinstall, hardware acceleration off, tested memory with memtest, avg antivirus, comodo firewall and windows 7 x64 pro are up to date, as well as graphic pilot for ati6790. I can't guess what i'm missing, i don't know what to try, i don't want to get rid of firefox that I use since the first versions, but I really really don't know what to try next except formating the system drive... (or may be : firefox is installed on the ssd system drive : better to put it on another HDD drive ?) I opened this bug https://bugzilla.mozilla.org/show_bug.cgi?id=856998
Whiteboard: [unactionable]
How would one go about getting the number of empty crashes reported per buildid for nightly? I expect landing bug 847223 should have removed most image related OOMs and I'd like to determine if that had any effect on the number of empty crash dumps.
We did some analysis in bug 837835 on volume of those crashes. As bug 847223 has only landed on 9/14, we only have very few days of nightlies with this in so far, so we probably need a few more days at least until we have useful data for this.
I've been getting a lot of this type of crash and at different points in time and doing different things with SeaMonkey. http://crash-stats.mozilla.com/report/index/bp-411fb6cf-d8e8-4cca-92e1-aa5472131101 http://crash-stats.mozilla.com/report/index/bp-f014707e-ffa6-48ba-8d37-b626b2131029 http://crash-stats.mozilla.com/report/index/bp-5f6f5203-fab3-4801-80a7-ffb292131017 Just to name a few. I would click on something, and boom, SeaMonkey closes. Scroll a bit, and it would crash. Even leaving it idle would crash.
WinDbg trace. I have cut the trace post access violation. If previous content is needed then let me know. It is more than 100MB in size. I also have minidump but I would not prefer to upload it unless absolutely necessary. Steps to reproduce is to just keep on opening many memory intensive tabs. I have around 200.
Crash Signature: [@ EMPTY: no crashing thread identified; corrupt dump ] → [@ EMPTY: no crashing thread identified; corrupt dump ] [@ EMPTY: no crashing thread identified; ERROR_NO_MINIDUMP_HEADER ]
I believe the bug #903842 is related to this one. Because the symptoms for me are the same: many open tabs, then browser windows start becoming black. If you create a new window from such a tab - the whole window becomes white and the browser soon crashes.
(In reply to Denis V from comment #31) > I believe the bug #903842 is related to this one. It might be or not. The bug here is only for tracking the signature, nobody is working on the actual issue here, so it's not useful to post about this here. The work on your issue, if possible, should happen in the bug you pointed to.
Seems this bug confuses reporters when it is open. Close it as "WONTFIX" like: https://bugzilla.mozilla.org/show_bug.cgi?id=683271
Status: NEW → RESOLVED
Closed: 10 years ago
tracking-firefox9: - → ---
Keywords: topcrash-win
Resolution: --- → WONTFIX
Summary: Firefox Crash Reports [@ EMPTY: no crashing thread identified; corrupt dump ] → Crash [@ EMPTY: no crashing thread identified; corrupt dump ] & [ERROR_NO_MINIDUMP_HEADER] (unactionable)
See Also: → 1360392
See Also: → 1245570
Duplicate of this bug: 633244
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: