Closed Bug 628071 Opened 12 years ago Closed 12 years ago
Crash [@ `anonymous namespace''::Open
Database Helper::Get Success Result(JSContext*, unsigned __int64*) ] Inspecting IDBRequest(moz Indexed DB .open)
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9) Gecko/20100101 Firefox/4.0b9 Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9) Gecko/20100101 Firefox/4.0b9 Either using Firebug or the Web Console to inspect IDBRequest from a moxIndexedDB.open causes the browser to crash. Reproducible: Always Steps to Reproduce: In a console var x = mozIndexDB.open("bob"); // passes x; // crashes the browser Actual Results: Crashes Expected Results: Inspection of an empty object or the actual details of the IDBRequest object.
Please provide a crash id or stacktrace -> https://developer.mozilla.org/en/How_to_get_a_stacktrace_for_a_bug_report Does the issue occur with the latest nightly? http://nightly.mozilla.org/
Crash id -> db138893-4fb4-4ab0-8039-38e862110123 http://crash-stats.mozilla.com/report/index/db138893-4fb4-4ab0-8039-38e862110123
Yes, crashes with the nightly firefox-4.0b10pre.en-US.win32.installer.exe 23-Jan-2011 05:54
Status: UNCONFIRMED → NEW
Component: Developer Tools → DOM
Ever confirmed: true
Product: Firefox → Core
QA Contact: developer.tools → general
Summary: Inspecting IDBRequest(mozIndexedDB.open) causes browser to crash → Crash [@ `anonymous namespace''::OpenDatabaseHelper::GetSuccessResult(JSContext*, unsigned __int64*) ] Inspecting IDBRequest(mozIndexedDB.open)
I can't make this crash using the Web Console (indexedDB isn't allowed from the web console because that code executes in a sandbox). I also can't make this crash in a web page. Furthermore, the stack trace in bp-db138893-4fb4-4ab0-8039-38e862110123 indicates that you're at least calling "x.result", which I don't see in your sample code. Can you double check the exact syntax that crashes here?
Would like to confirm that this issue also arises on the most recent Linux nightly as well (See bp-0a5e316f-555b-47b7-8511-787232110124). It would seem that in both our cases, we are not directly calling x.result, but rather x.result is called indirectly when we attempt to inspect the request object with Firebug by expanding it in the script tag (in my case, with Firebug 1.7 alpha 9). Simple assignment doesn't seem to cause the error (see the attached example), but when Firebug is actively introspecting on the same code (i.e. setting a breakpoint on the first line and trying to step through the two lines) recreates the bug for me every time. I'm inclined to say it's a Firefox bug given the severity of the crash, but I have also opened a Firebug bug on this topic as well (Issue 3966: http://code.google.com/p/fbug/issues/detail?id=3966)
Attaching code which reproduces this bug (only when introspected in Firebug 1.7a6)
This seems like something that's likely to hit developers playing with new features. Blocking final+.
blocking2.0: --- → final+
blocking2.0: final+ → ---
> Johnny Stenback (:jst, firstname.lastname@example.org) 2011-01-24 15:59:48 PST > Blocking final+. Something seems to have happened to the blocking2.0 flag? Johnny?
blocking2.0: --- → ?
Cross reference, here is the related Firebug issue: http://code.google.com/p/fbug/issues/detail?id=3966 Honza
1039 nsRefPtr<IDBDatabase> db = 1040 IDBDatabase::Create(mRequest->ScriptContext(), mRequest->Owner(), dbInfo, 1041 mASCIIOrigin); i don't see anything ensuring mRequest isn't null...
Severity: normal → critical
Further testing suggests that it's probably some issue with incorrectly initialized values, as introspecting IDBRequest objects after their readyState has been set to DONE (when the request finishes) does not appear to cause a crash.
Patch coming soon, this is a bug in IndexedDB, not Firebug.
12 years ago
Assignee: nobody → bent.mozilla
Status: NEW → ASSIGNED
Whiteboard: [softblocker] → [softblocker][firebug-p1]
(In reply to comment #14) > Created attachment 506936 [details] [diff] [review] > Patch, v1 I know it's not bug in Firebug but, this bug causes Firebug to be unusable when helping developers to inspect IndexedDB on pages. Since the patch is already available I really hope to have this fix in final Fx4 (even if it's marked as soft-blocker). Honza
Forgot to qref :(
Attachment #507286 - Flags: review?(jonas) → review+
Oh, i forgot to mention. I have two nits: You're using NS_ASSERTION when you should use NS_PRECONDITION I saw at least once instance of: NS_ENSURE_SUCCESS(rv, rv); return NS_OK; which could just be return rv;
(In reply to comment #17) > You're using NS_ASSERTION when you should use NS_PRECONDITION Meh. All the indexedDB code does this except like one file that sdwilsh wrote. We could file a bug to change it all if you care. > I saw at least once instance of: Nah, I want the warning if rv is an error.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Tested with Firefox 4.0b11pre 2011-01-27 + Firebug 1.7a9 and works for me. Thanks! Hozna
I also confirm it works with Firefox 4.0b11pre 2011-01-28, and it also works in the Web Console.
Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110204 Firefox/4.0b12pre
Status: RESOLVED → VERIFIED
Whiteboard: [softblocker][firebug-p1] → [softblocker][firebug-p1][fx4-fixed-bugday]
Crash Signature: [@ `anonymous namespace''::OpenDatabaseHelper::GetSuccessResult(JSContext*, unsigned __int64*) ]
Component: DOM → DOM: IndexedDB
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.