Access Violation crash [@ XPCSafeJSObjectWrapper::SJOWClass] in trunk

RESOLVED WORKSFORME

Status

()

Core
XPConnect
--
critical
RESOLVED WORKSFORME
8 years ago
6 years ago

People

(Reporter: morac, Unassigned)

Tracking

({crash, regression})

Trunk
x86
Windows XP
crash, regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
Created attachment 444259 [details]
Two Crash stacks and one hang stack

I'm seeing a fairly reproducible crash when using the DOM Inspector add-on in the nightly Trunk loads.  If I use DOM Inspector to search for a node id that doesn't exist Minefield crashes or hangs.  The crash does not occur in the 1.9.2 branch (Firefox 3.6.4b3), but Firefox hangs forever with the CPU usage at 100%.  In the 1.9.1 branch (Firefox 3.5.9) and earlier the search works as excepted.

Steps I used to reproduce this:
1. Search Google for "test"
2. Open DOM Inspector and search for ID of "navbar"

At this point Minefield will start to use 100% of the CPU and either crash or hang.  I reproduced this on two different Windows XP machines.  I disabled all add-ons and plugins and it was still reproducible.

For a while Minefield would open the crash reporter when the crash occurred, but it finally did do so twice.

Crash Reports:
http://crash-stats.mozilla.com/report/index/da456a58-2534-4f5a-9527-0d9162100508
http://crash-stats.mozilla.com/report/index/af2c2aee-c090-485b-af5b-993a22100508


I also used WinDbg to grab a couple of crash stacks and a hang stack which I attached.

Updated

8 years ago
Keywords: crash
Summary: Access Violation crash xul!XPCSafeJSObjectWrapper::SJOWClass in trunk → Access Violation crash [@ XPCSafeJSObjectWrapper::SJOWClass] in trunk
(Reporter)

Comment 1

8 years ago
DOM Inspector has been fixed to prevent the hang (bug 526939).  I'm guessing the crash won't be reproducible using DOM Inspector any more.  If the crash is actually caused by bug 526939, I guess that this should be duped to that, but that bug doesn't mention anything about crashing so I still think this bug is valid.
(Assignee)

Updated

7 years ago
Crash Signature: [@ XPCSafeJSObjectWrapper::SJOWClass]
(Changeset "ef14ce852082 Add documentation to TimeStamp comparing it to C++11's time_point. r=cjones", was attributed to this bug, but the correct bug number is bug 691852)

Comment 3

6 years ago
So comment #1 indicates that the DOM inspector has been fixed to not trigger this. We do not see this signature in crash stats on any FF version in the past 4 weeks. Resolving as works for me - for now.

If we still can find steps to reproduce, add those to the bug and reopen? We can add the reproducible keyword in this case as well.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.