Running B2G (which means multiprocess) with my Homescreen optimization [1] that renders icons into blobs and caches them in IndexedDB. So when we draw icons on the Homescreen, they're always <img> elements pointing to a 'blob:' URL that's *usually* backed by IndexedDB (when the app was *just* installed it can also be an in-memory blob.) When rearranging icons (long-press on an icon), we occasionally see this crash: I Gecko : [Child 320] ###!!! ABORT: [PBlobStreamChild] abort()ing as a result: file /Users/philipp/dev/mozilla/mc.hg/objdir-gonk/ipc/ipdl/PBlobStreamChild.cpp, line 364 It seems this has cropped up before in bug 805114 comment 21. I will try to narrow it down further and work on a testcase with better reproducibility. [1] https://github.com/mozilla-b2g/gaia/pull/6214

I found a reproducible test case and bent debugged this on my machine. Turns out, the blobs IndexedDB sends to the child process are lacking the FileInfo association with the database, so the next time they're written back to the DB, they're treated as foreign blob and deleted once written. Patch is coming up.

I can't get the test to actually crash the child process (without the fix to IDBObjectStore.cpp of course). Must not be pushing right buttons yet.

Never mind, we figured it out: we need to wait for the write transaction to finish so that the blobs are actually expired. The test case in the patch fails without the fix (crashes the content process), but passes with the fix.

Ben, maybe we should create a new nsDOMFileFile ctor which would take nsIFile* and FileInfo* and also set mStoredFile to true in it ? The mStoredFile flag is important for blob.slice() to work correctly, that is to create it as a stored file too (AddRef the FileInfo)

Address Jan's review comment and introduce a specialized constructor that sets mStoredFile to true.

Address janv's final review comments: no need for mutexed AddFileInfo in ctor.

Comment on attachment 680155 [details] [diff] [review] v3 Perfect, thanks

Nom'ing for basecamp: This blocks the Homescreen improvements from landing and has apparently also caused the Gallery to crash. Crashes should be fixed, in particular in core apps.

Try build: https://tbpl.mozilla.org/?tree=Try&rev=f921ac78297c

https://hg.mozilla.org/integration/mozilla-inbound/rev/590963fb0a3d I changed the commit message to something more descriptive. Keep in mind that they should be describing what the patch is doing, not restating the bug summary.

(In reply to Ryan VanderMeulen from comment #10) > https://hg.mozilla.org/integration/mozilla-inbound/rev/590963fb0a3d Thanks! > I changed the commit message to something more descriptive. Keep in mind > that they should be describing what the patch is doing, not restating the > bug summary. That sounds like a false dichotomy to me. If the bug summary isn't descriptive, let's change it. Note that I changed it as soon as we knew what was going on (comment 1) to describe both the symptom (for easier searching) and the reason (for better understanding). I'm not saying it's the best bug description ever, but it certainly makes more sense to me than the commit message (the transaction finish / blob expiry bit in comment 3 was a comment about the test case, not about the actual problem or the fix to it.)