Closed Bug 893823 Opened 8 years ago Closed 8 years ago

[Windows] Shutdown crash after using contentEditable

Categories

(Core :: DOM: Editor, defect)

x86
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jruderman, Assigned: smaug)

References

(Blocks 2 open bugs)

Details

(Keywords: crash, regression, testcase)

Crash Data

Attachments

(2 files)

Attached file testcase
1. firefox.exe w.html
2. Shift+Up  (extend selection up)
3. Ctrl+X    (cut)
4. Ctrl+W    (close window)

Result: crash during shutdown

Seems to be Windows-only and debug-only.  Tested using Tinderbox debug builds e.g. https://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32-debug/1373889765/

Started around the time snow-white landed (bug 789919).
Attached file stack
Crash Signature: [@ PL_DHashTableEnumerate | nsTHashtable<nsBaseHashtableET<nsPtrHashKey<imgIRequest>,unsigned int> >::Clear()]
Null pointer cras.
Assignee: nobody → bugs
Any chance for a crash id?
I wasn't able to reproduce with a Nightly.  What can you do with a crash ID that you can't do with the stack trace I attached?
Maybe Scoobidiver can??
Blocks: fuzz-keys
(In reply to Jesse Ruderman from comment #5)
> Maybe Scoobidiver can??
I don't need a crash ID (the stack trace is enough).
crash id gives me link to the correct line.
Other option is that you provide that as mxr link (use the changeset thing at the bottom of the mxr pages) or hg link.
The stack I attached includes the changeset, filenames, and line numbers.

But this is WFM now.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.