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.
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.
(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)
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.