1756741 - Firefox 99.0a1 Crash Report [@ shutdownhang | XPTC__InvokebyIndex ]

Status: RESOLVED FIXED

(Toolkit :: Data Sanitization, defect)

Description

[Giovanni [:Gioxx] (Mozilla Italia)]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0

Steps to reproduce:

Open Firefox Nightly / Close Firefox Nightly.

Actual results:

Firefox Crashes (since 14th of feb.).
https://crash-stats.mozilla.org/report/index/bp-552d2d78-d8eb-44a3-b9e5-a15dd0220214
https://crash-stats.mozilla.org/report/index/bp-9be477f2-0692-45b1-8303-62a8e0220214
https://crash-stats.mozilla.org/report/index/bp-7750f697-aed3-4add-bf89-7dd750220215
https://crash-stats.mozilla.org/report/index/bp-075fc358-f49d-4939-a1ca-260500220216
https://crash-stats.mozilla.org/report/index/bp-682ef8ab-3a37-44ed-bcb3-743a90220216
https://crash-stats.mozilla.org/report/index/bp-55557afb-d19e-47c4-90cc-ffcdd0220217
https://crash-stats.mozilla.org/report/index/bp-bf6fe957-8d19-4e30-9262-a92370220217
https://crash-stats.mozilla.org/report/index/bp-58056136-412b-4399-8384-6c2270220217
https://crash-stats.mozilla.org/report/index/bp-7164fbd0-67ad-4f8f-a5d1-c01ea0220218
https://crash-stats.mozilla.org/report/index/bp-3148d9e3-4c50-47a2-8b5c-6abdf0220218
https://crash-stats.mozilla.org/report/index/bp-1b364340-9492-414c-a11d-318a20220221
https://crash-stats.mozilla.org/report/index/bp-309bb785-3532-44a8-90fb-acab80220222
https://crash-stats.mozilla.org/report/index/bp-beff18e2-499f-4cfd-9823-26c770220222
https://crash-stats.mozilla.org/report/index/bp-9f056bdb-9fa1-47ca-ab70-b1f2f0220223

Expected results:

Firefox should open or close normally, running its updates, without crashing.

Comment 1

[Andrei Purice]

Hey Giovanni,
We tried reproducing this issue on the latest versions of Firefox Nightly 99.0a1 (2022-02-24), beta 98.0b8 and release 97.0.1 but didn't encounter the crash following your steps.

Can you test the issue while in Safe Mode? You can find helpful info here : https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode .
Testing with a fresh new profile could help. You can find more about creating a new profile here : https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems#w_6-create-a-new-firefox-profile .
If possible, you can test this issue on the nightly build as well. Download the build from : https://www.mozilla.org/en-US/firefox/nightly/all/ .

Comment 2

[Giovanni [:Gioxx] (Mozilla Italia)]

I can reproduce this bug since the 14th. of february, everyday, even several times a day if I wish to reproduce it again (simply closing and reopening Firefox), this is the profile I use everyday on my Nightly and before the 14th. of feb. i never had this problem.
This is the new crash: https://crash-stats.mozilla.org/report/index/8ad95be9-9908-4c34-b914-43daa0220224 and this is the profiler analysis: https://share.firefox.dev/3BKSbWB

Comment 3

[Mike Conley (:mconley) (:⚙️)]

Hi Gioxx,

Thanks for reporting. Does this issue only appear when there are updates to apply? Or every time you attempt to shutdown Firefox Nightly, even without pending updates?

Comment 4

[Giovanni [:Gioxx] (Mozilla Italia)]

Ciao Mike, everytime, with or without pending updates available.

Comment 5

[Andrew McCreight [:mccr8]]

A number of those crashes are happening while doing something with principals in the permissions manager.

Comment 6

[Giovanni [:Gioxx] (Mozilla Italia)]

Crash this morning (there were pending updates to run) and a short video capture of what happens in Task Manager when I close Firefox.
https://crash-stats.mozilla.org/report/index/238a64e5-d0e7-4bb1-b756-fbab30220225
https://capture.dropbox.com/GKgZo1AsgxwlvxAw

Comment 7

[Mike Conley (:mconley) (:⚙️)]

Hey valentin, the hang (at least in that last report) seems to ultimately be happening inside of nsStandardURL::Release... is this something for Necko to look at? Or Jens, is this more of a permission manager thing?

Comment 8

[Jens Stutte [:jstutte]]

I see in those stack traces often some frame with _tailMerge_d3dcompiler_47.dll, which I usually don't see in our stacks? Is that meaning something?

In any case Permission Manager is more Tim's playground.

Comment 9

[Valentin Gosu [:valentin] (he/him)]

This also crashes in nsStandardURL::SetSpec (the page URL seems to be gmail)
https://crash-stats.mozilla.org/report/index/309bb785-3532-44a8-90fb-acab80220222
I think there's a script running at shutdown (not sure why) that keeps creating and destroying URLs. d3dcompiler_47.dll could be involved.

Comment 10

[Mike Conley (:mconley) (:⚙️)]

Hm... d3dcompiler_47.dll is, I believe, part of Direct3D... jrmuizel, is the graphics layer somehow involved here?

Comment 11

[Jeff Muizelaar [:jrmuizel]]

I'm pretty sure the d3dcompiler stuff is not related here. I think it's just the nearest symbol or something.

Comment 12

[Andrew McCreight [:mccr8]]

Yeah, those looks like frames where we have JIT code or the weird XPCOM call stuff, so I'm pretty sure it is junk. You see the tailcall stuff fairly often in crash stacks.

Comment 13

[Jeff Muizelaar [:jrmuizel]]

Yeah, the offsets from _tailMerge_d3dcompiler_47.dll are two large to be reasonable. I've filed bug 1757217 about the unwinding/symbolicating issue.

Comment 14

[Tim Huang[:timhuang]]

It looks to me that something is trying to get all permissions during the shutdown. But it's hard to tell from stack traces of those crash reports because they all link to _tailMerge_d3dcompiler_47.dll and it doesn't seem to be the right symbol. We should wait for bug 1757890 to get more details regarding this crash.

Comment 15

[Paul Zühlcke [:pbz]]

We should check if this is a regression of Bug 1681701, also see Bug 1755190. For the exception support we do iterate over all permissions on shutdown. Hannah is currently looking into it.

Can we see if the affected profiles have either network.cookie.lifetimePolicy or privacy.sanitize.sanitizeOnShutdown enabled?

Comment 16

[Giovanni [:Gioxx] (Mozilla Italia)]

(In reply to Paul Zühlcke [:pbz] from comment #15)

We should check if this is a regression of Bug 1681701, also see Bug 1755190. For the exception support we do iterate over all permissions on shutdown. Hannah is currently looking into it.

Can we see if the affected profiles have either network.cookie.lifetimePolicy or privacy.sanitize.sanitizeOnShutdown enabled?

In my profile I have network.cookie.lifetimePolicy set to 0 and privacy.sanitize.sanitizeOnShutdown true.

Comment 17

[Hannah Peuckmann]

Thank you, could you do me a favor and try to reproduce this crash with privacy.sanitize.sanitizeOnShutdown set to false?

Comment 18

[Giovanni [:Gioxx] (Mozilla Italia)]

(In reply to [e-mail] from comment #17)

Thank you, could you do me a favor and try to reproduce this crash with privacy.sanitize.sanitizeOnShutdown set to false?

AH! With privacy.sanitize.sanitizeOnShutdown set to false Firefox closed correctly without generating crashes!

Comment 19

[Jens Stutte [:jstutte]]

(In reply to Paul Zühlcke [:pbz] from comment #15)

We should check if this is a regression of Bug 1681701, also see Bug 1755190. For the exception support we do iterate over all permissions on shutdown. Hannah is currently looking into it.

Based on this I think we can move this bug under that component for now.

Comment 20

[Hannah Peuckmann]

We created Bug 1759579 to refactor the method in the sanitizer that is recursively calling the permission manager to get all permissions. Refactoring this to call the permission manager only once might also fix this crash.
Until fixed, Giovanni you can try to clear your history through about:preferences#privacy Clear history..., this will give you the option to clear your history not on shutdown and except you select the time range 'everything', the recursive method calling the permission manager should not be triggered.

Comment 21

[Giovanni [:Gioxx] (Mozilla Italia)]

(In reply to [e-mail] from comment #20)

We created Bug 1759579 to refactor the method in the sanitizer that is recursively calling the permission manager to get all permissions. Refactoring this to call the permission manager only once might also fix this crash.
Until fixed, Giovanni you can try to clear your history through about:preferences#privacy Clear history..., this will give you the option to clear your history not on shutdown and except you select the time range 'everything', the recursive method calling the permission manager should not be triggered.

In the meantime I have created a clean profile from scratch, with my addons and my configurations and without the problem, but I also have the old profile I can use to make other tests to help you on "find and solve" the problem. Spring cleaning is sometimes good for the browser, especially when using Nightly :-)

Comment 22

[Hannah Peuckmann]

Hey Giovanni, I'm glad to hear you could fix this for your profile and thank you for offering your help with solving this. Could you help me out again? Could you check if you can still reproduce the issue with Nightly 100.0a1? We landed a small patch that has a positive impact on the performance of the shutdown data sanitization. If still crashing, could you try to make a performance profile of the shutdown? I actually don't know what happens to a shutdown performance profile if the shutdown crashes, but its worth a try.

Comment 23

[Giovanni [:Gioxx] (Mozilla Italia)]

(In reply to [e-mail] from comment #22)

Hey Giovanni, I'm glad to hear you could fix this for your profile and thank you for offering your help with solving this. Could you help me out again? Could you check if you can still reproduce the issue with Nightly 100.0a1? We landed a small patch that has a positive impact on the performance of the shutdown data sanitization. If still crashing, could you try to make a performance profile of the shutdown? I actually don't know what happens to a shutdown performance profile if the shutdown crashes, but its worth a try.

Ciao, no problem, but the question is: should I first change the status of privacy.sanitize.sanitizeOnShutdown back to true to make this test? At the moment is set to false.

Comment 24

[Hannah Peuckmann]

(In reply to Giovanni [:Gioxx] (Mozilla Italia) from comment #23)

(In reply to [e-mail] from comment #22)

Hey Giovanni, I'm glad to hear you could fix this for your profile and thank you for offering your help with solving this. Could you help me out again? Could you check if you can still reproduce the issue with Nightly 100.0a1? We landed a small patch that has a positive impact on the performance of the shutdown data sanitization. If still crashing, could you try to make a performance profile of the shutdown? I actually don't know what happens to a shutdown performance profile if the shutdown crashes, but its worth a try.

Ciao, no problem, but the question is: should I first change the status of privacy.sanitize.sanitizeOnShutdown back to true to make this test? At the moment is set to false.

Hey, please set privacy.sanitize.sanitizeOnShutdown back to true .

Comment 25

[Giovanni [:Gioxx] (Mozilla Italia)]

(In reply to [e-mail] from comment #24)

Hey, please set privacy.sanitize.sanitizeOnShutdown back to true .

Done! Nightly configuration modified on the "problematic profile", the browser closing without any crashes. I think this is a good news :-)

Comment 26

[Paul Zühlcke [:pbz]]

Thanks for confirming!

Comment 27

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1681701