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

Status: VERIFIED FIXED

(Core :: Storage: IndexedDB, defect)

Description

[Rahly]

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.

Comment 1

[Tim (fmdeveloper)]

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/

Comment 2

[Rahly]

Crash id -> db138893-4fb4-4ab0-8039-38e862110123

http://crash-stats.mozilla.com/report/index/db138893-4fb4-4ab0-8039-38e862110123

Comment 3

[Rahly]

Yes, crashes with the nightly

firefox-4.0b10pre.en-US.win32.installer.exe	23-Jan-2011 05:54

Comment 4

[Ben Turner (not reading bugmail, use the needinfo flag!)]

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?

Comment 5

[pipian]

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)

Comment 6

[pipian]

Attachment: Code which triggers this bug when introspected with Firebug.

Attaching code which reproduces this bug (only when introspected in Firebug 1.7a6)

Comment 7

[Johnny Stenback (:jst)]

This seems like something that's likely to hit developers playing with new features. Blocking final+.

Comment 8

[Rahly]

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.

http://dl748.com/crash.html

if you click the button(surprisingly it doesn't crash doing a for..in 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.

Comment 9

[Philip Chee]

> Johnny Stenback (:jst, [e-mail])      2011-01-24 15:59:48 PST
> Blocking final+.
Something seems to have happened to the blocking2.0 flag? Johnny?

Comment 10

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Cross reference, here is the related Firebug issue:
http://code.google.com/p/fbug/issues/detail?id=3966

Honza

Comment 11

[timeless]

1039   nsRefPtr<IDBDatabase> db =
1040     IDBDatabase::Create(mRequest->ScriptContext(), mRequest->Owner(), dbInfo,
1041                         mASCIIOrigin);

i don't see anything ensuring mRequest isn't null...

Comment 12

[pipian]

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.

Comment 13

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Patch coming soon, this is a bug in IndexedDB, not Firebug.

Comment 14

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Attachment: Patch, v1

Comment 15

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(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

Comment 16

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Attachment: Patch, v1.1

Forgot to qref :(

Comment 17

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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;

Comment 18

[Ben Turner (not reading bugmail, use the needinfo flag!)]

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

Comment 19

[Ben Turner (not reading bugmail, use the needinfo flag!)]

http://hg.mozilla.org/mozilla-central/rev/52aa9a2bc021

Comment 20

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Tested with Firefox 4.0b11pre 2011-01-27 + Firebug 1.7a9 and works for me.
Thanks!

Hozna

Comment 21

[Rahly]

I also confirm it works with Firefox 4.0b11pre 2011-01-28, and it also works in the Web Console.

Comment 22

[Steve Scott (pxbugz)]

Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110204 Firefox/4.0b12pre