Closed Bug 1515069 Opened 10 months ago Closed 10 months ago
Crash in mozilla::dom::indexed
DB::(anonymous namespace)::Database Operation Base::Get Structured Clone Read Info From External Blob
This bug was filed from the Socorro interface and is report bp-75b2ca2e-7ef4-42e2-887f-82b9a0181217. ============================================================= Seen while looking at 64 Mac crashes - this is either a new crash or a signature change: https://bit.ly/2CljOIA. Google drive shows up in the URLs. One comment mentions the browser opens and then automatically closes. All versions of Mac are affected. Top 1 frames of crashing thread: 0 XUL mozilla::dom::indexedDB:: mfbt/RefPtr.h:307 =============================================================
Jan or Tom, can you take a look?
Priority: -- → P2
I can look into it next week or this Friday. Keep the ni flag to notify me. Jan, I assume you are busy with LocalStorage stuff right now, so I remove your flag. If you have time, please take it if you want to.
Yes, I'm still busy with LS work. Thanks for helping here.
Given the volume, I don't think we'll spin a new 64 release for a fix here.
start investigating it
Out of the blue, I am experiencing this crash. Firefox was working fine earlier today. I have tried reinstalling and starting in safe mode. Firefox would open and then crash immediately. Please let me know if I can be of any assistance. Crash IDs: bp-fea3a691-40a7-4f79-9105-6eccf0190102 bp-8215f54f-74be-460e-bb89-e5c910190102 bp-fb60a011-5bee-4f40-b37d-0e4d40190102 bp-b5a2c05a-6851-4987-b16c-7f3030190102 bp-fb60a011-5bee-4f40-b37d-0e4d40190102
I could find a useful clue for this issue by checking the crash report. It seems "fileInputStream" is the only RefPtr which being got in GetStructuredCloneReadInfoFromExternalBlob() . I couldn't reproduce it by visiting google drive, and Netflix (the two websites that were mentioned in the comments of crash reports), neither. Note that the reason of failure might be different from bug 1432133 because that issue seems to fail to get the "fileInfo" and the crash reports for that issue shows that the top of the stack is GetFileForFileInfo().  https://searchfox.org/mozilla-central/rev/3e7afaa5b57b3f8ed100cd1f13bb0a93b9b2cb99/dom/indexedDB/ActorsParent.cpp#17451 (In reply to Andrew Truong [:feer56] [:andrewtruong] [:atruong] from comment #6) Andrew, I'm sorry to hear that. Is the issue reproducible in your computer or notebook everytime when you visiting a certain website? If so, could you tell me the steps to reproduce that? (e.g. go to XXX website). Also, it would be really useful if you can send me your profile  of that website  privately. (Note that it's not necessary but that would be helpful for me to identify the real issue behind). If you want to get away from the issue on your side, I guess you could go to your profile directory and manually removing the breaking inedxedDB directory .  The directory of the profile can be found in "about:profiles"  The directory of the breaking folder should be "$profile/storage/defualt/$website/idb". Note the "$website" is, for instance, "https+++foo.com" (original is "https://foo.com" in your URL bar)
(In reply to Tom Tung [:tt, :ttung] from comment #7) > I could find a useful clue for this issue by checking the crash report. It *couldn't ...
Firefox would open for a few seconds but would then crash immediately right after. Firefox was able to load the "recovery tab" but once a new session was started, it would crash right after. There are no pinned tabs or anything, just the new tab page that opens. Creating a new profile did not crash Firefox. Did you want me to send my entire Firefox profile or certain files from it? Thanks! Latest crash ID: bp-f558a236-3f94-4bbc-b54d-e48e60190102
Flags: needinfo?(feer56) → needinfo?(shes050117)
(In reply to Andrew Truong [:feer56] [:andrewtruong] [:atruong] from comment #9) > Firefox would open for a few seconds but would then crash immediately right > after. Firefox was able to load the "recovery tab" but once a new session > was started, it would crash right after. There are no pinned tabs or > anything, just the new tab page that opens. Creating a new profile did not > crash Firefox. Did you want me to send my entire Firefox profile or certain > files from it? Thanks! > > Latest crash ID: bp-f558a236-3f94-4bbc-b54d-e48e60190102 Do you set your home page to a certain website? If so, could you help me to test: 1. Find the directory of the website  and copy it to your new profile (corresponding directory). 2. Open Firefox with the new profile and check if you get the same crash 3. If you get the crash please send me that directory. Thanks! Note: If you don't set any specific website page as your homepage, please check the "about+home" with above steps. If you cannot reproduce that by the above steps on your new profile, probably sending me your whole profile directory ($profile_dir/storage/) is the quickest way (if you wouldn't mind).  FYI, finding the storage directory of a website in your profile 1. Go to the "about:profiles" and find the directory of the broken profile. 2. Go to that directory and find the "storage" folder 3. Go to the "storage" folder and then find the "default" folder 4. Find the directory with a similar name to that website If you don't want to send your whole profile and it's hard to reproduce by the above steps, I could provide a debug build for you to debug the problematic directory. Thank you!
Flags: needinfo?(shes050117) → needinfo?(feer56)
There is no homepage set. On the old profile, if I set the home page to be a blank page, there is no crash, if it is set to "Firefox Home (default)", it would crash on startup for me. Setting the new tab to open a blank page is fine, but visiting about:home would also crash Firefox. I will send you an email regarding the storage/default folder in my profile.
I tried both Nightly and Release with the "about+home" directory of providing directory and only hit the crashes on Release. crash IDs: bp-e37c3671-e1cf-4434-b395-105770190103 bp-e6c7897c-70c1-4747-9924-c467a0190103 bp-e89ca240-f996-4565-afcd-2d20f0190103 That also matches the results on crash reports (only happen in Beta and Release).
By running the directory in debug build, the issue is the same as bug 1432133. FileInfo cannot be got from the FileManager. I'm going to mark this issue as duplicate and try to fix this issue in bug 1432133. I also check the table 'file' and 'object_data' table in the SQLite database and the files in the corresponding directory. Surprisingly, there are two files named: "56" and "57" in the directory, but "56" is recorded in the "file_ids" in the "object_data" table and "57" is recorded in the "id" field of the "file" table.
Status: ASSIGNED → RESOLVED
Closed: 10 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1432133
You need to log in before you can comment on or make changes to this bug.