Closed
Bug 1515069
Opened 6 years ago
Closed 6 years ago
Crash in mozilla::dom::indexedDB::(anonymous namespace)::DatabaseOperationBase::GetStructuredCloneReadInfoFromExternalBlob
Categories
(Core :: Storage: IndexedDB, defect, P2)
Tracking
()
RESOLVED
DUPLICATE
of bug 1432133
Tracking | Status | |
---|---|---|
firefox64 | --- | fix-optional |
firefox65 | --- | affected |
People
(Reporter: marcia, Assigned: tt)
References
Details
(Keywords: crash, regression)
Crash Data
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
=============================================================
Comment 1•6 years ago
|
||
Jan or Tom, can you take a look?
Flags: needinfo?(shes050117)
Flags: needinfo?(jvarga)
Priority: -- → P2
Assignee | ||
Comment 2•6 years ago
|
||
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.
Flags: needinfo?(jvarga)
Assignee | ||
Updated•6 years ago
|
Assignee: nobody → shes050117
Comment 3•6 years ago
|
||
Yes, I'm still busy with LS work. Thanks for helping here.
Comment 4•6 years ago
|
||
Given the volume, I don't think we'll spin a new 64 release for a fix here.
Assignee | ||
Updated•6 years ago
|
Status: NEW → ASSIGNED
Comment 6•6 years ago
|
||
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
Assignee | ||
Comment 7•6 years ago
|
||
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() [1]. 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().
[1] 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 [2] of that website [3] 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 [3].
[2] The directory of the profile can be found in "about:profiles"
[3] 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)
Flags: needinfo?(feer56)
Assignee | ||
Comment 8•6 years ago
|
||
(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 ...
Comment 9•6 years ago
|
||
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)
Assignee | ||
Comment 10•6 years ago
|
||
(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 [1] 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).
[1] 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)
Comment 11•6 years ago
|
||
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.
Flags: needinfo?(feer56)
Assignee | ||
Comment 12•6 years ago
|
||
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).
Assignee | ||
Comment 13•6 years ago
|
||
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: 6 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•