Closed Bug 628071 Opened 12 years ago Closed 12 years ago

Crash [@ `anonymous namespace''::OpenDatabaseHelper::GetSuccessResult(JSContext*, unsigned __int64*) ] Inspecting IDBRequest(


(Core :: Storage: IndexedDB, defect)

Windows 7
Not set



Tracking Status
blocking2.0 --- final+


(Reporter: hungry.rahly, Assigned: bent.mozilla)


(Keywords: crash, Whiteboard: [softblocker][firebug-p1][fx4-fixed-bugday])

Crash Data


(2 files, 1 obsolete file)

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 causes the browser to crash.

Reproducible: Always

Steps to Reproduce:
In a console

var x ="bob"); // passes
x; // crashes the browser

Actual Results:  

Expected Results:  
Inspection of an empty object or the actual details of the IDBRequest object.
Please provide a crash id or stacktrace ->

Does the issue occur with the latest nightly?
Keywords: crash, stackwanted
Version: unspecified → Trunk
Crash id -> db138893-4fb4-4ab0-8039-38e862110123
Yes, crashes with the nightly

firefox-4.0b10pre.en-US.win32.installer.exe	23-Jan-2011 05:54
Component: Developer Tools → DOM
Ever confirmed: true
Keywords: stackwanted
Product: Firefox → Core
QA Contact: → general
Summary: Inspecting IDBRequest( causes browser to crash → Crash [@ `anonymous namespace''::OpenDatabaseHelper::GetSuccessResult(JSContext*, unsigned __int64*) ] Inspecting IDBRequest(
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:
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+
Whiteboard: [softblocker]
No, this works in the web console as well.  Because of the inspecting, in both Firebug and the Web Console.  It iterates over the objects, thereby causing the error.  You can also do it with a simple web page as well.

if you click the button(surprisingly it doesn't crash doing a iteration over the object in sandboxed javascript), then open up firebug or web console, type "x" and press enter, firebug crashes, but in web console, if you click IDBRequest to "inspect" it.  Instant crash, every time.
blocking2.0: final+ → ---
> Johnny Stenback (:jst,      2011-01-24 15:59:48 PST
> Blocking final+.
Something seems to have happened to the blocking2.0 flag? Johnny?
blocking2.0: --- → ?
blocking2.0: ? → final+
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.
Assignee: nobody → bent.mozilla
Attached patch Patch, v1 (obsolete) — Splinter Review
Attachment #506936 - Flags: review?(jonas)
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).

Attached patch Patch, v1.1Splinter Review
Forgot to qref :(
Attachment #506936 - Attachment is obsolete: true
Attachment #507286 - Flags: review?(jonas)
Attachment #506936 - Flags: review?(jonas)
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:

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.
Closed: 12 years ago
Resolution: --- → FIXED
Tested with Firefox 4.0b11pre 2011-01-27 + Firebug 1.7a9 and works for me.

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