1402201 - Crash in shutdownhang | NtWaitForKeyedEvent | RtlSleepConditionVariableCS | SleepConditionVariableCS

Status: RESOLVED WONTFIX

(Core :: Graphics: Layers, defect, P2)

Description

[fireattack [:fireattack]]

This bug was filed from the Socorro interface and is 
report bp-01f2d2f5-415b-4c6c-aca3-b9fa30170922.
=============================================================

I thought it could be duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1389021, but people there said it's a new bug so I made this.

Comment 1

[fireattack [:fireattack]]

It looks the hang is caused by a GM script.

STR:

1. new profile
2. install Greasemonkey (https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/)
3. install https://sleazyfork.org/en/scripts/3575-better-better-booru (direct link: https://sleazyfork.org/scripts/3575-better-better-booru/code/better_better_booru.user.js)

You should already notice that the script install dialog popped out by Greasemonkey is already behavioring weird: even after you click confirm, it doesn't go way.

Now, try to close Firefox.

What happened: it hangs.

More crash reports:

https://crash-stats.mozilla.com/report/index/dee75707-6a2c-4dca-b6ea-126a41170922
https://crash-stats.mozilla.com/report/index/01f2d2f5-415b-4c6c-aca3-b9fa30170922
https://crash-stats.mozilla.com/report/index/af781936-9f62-4b52-9544-82aa70170922
https://crash-stats.mozilla.com/report/index/85e8ed57-45ee-4aba-82ae-630411170922
https://crash-stats.mozilla.com/report/index/efaf3519-1246-4768-9f25-9935c1170922

Comment 2

[fireattack [:fireattack]]

Can reproduce on 55.0.3 (64-bit) (newest release) as well.

I use this script for a while and didn't remember encounter this a few days ago.

Comment 3

[fireattack [:fireattack]]

Disabling that script doesn't help. You have to remove it totally (and if you use GM's script manager to do that, I still have to force close Firefox once).

Comment 4

[Andrew Osmond [:aosmond] (he/him)]

Hmm, this could be a result of bug 1401668. It was a risk when we landed the fix for *that* crash because it essentially undid a checkin which solved a shutdown hang.

Comment 5

[Andrew Osmond [:aosmond] (he/him)]

Thankfully I already know the proper solution to this. Make the parent own the shutdown process rather than depend on the child to close the protocol. I will also examine the code for anything that could fail to release the compositor thread for an ImageBridgeParent that was closed by the remote/child side.

Comment 6

[Andrew Osmond [:aosmond] (he/him)]

Bely my last 2 comments. I was monitoring for a new shutdown hang on 57.0b and 58.0a as a consequence of bug 1401668. I'm not sure what exactly is happening here -- presumably the content process is stuck by the addon somehow, and doesn't shutdown, so it keeps the parent process alive. It would be a similar fix however.

Does this addon / script cause the problem on nightly (58.0)?

Comment 7

[fireattack [:fireattack]]

Can't test since Greasemonkey is a legacy addon :/

Comment 8

[fireattack [:fireattack]]

Shouldn't we also fix 56 since it will still be in release channel for quite a while and it's a crash bug?

Comment 9

[fireattack [:fireattack]]

Apparently, not just that script. 

There are lots of people rushing Greasemonkey's AMO page to report the same:

https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/reviews/?src=api

Looks like a problem since 3.1.2 of GM?

Comment 10

[fireattack [:fireattack]]

See also: https://github.com/greasemonkey/greasemonkey/issues/2573

People there mentioned bug 1377277, not sure if dupe.

Comment 11

[Anthony Lieuallen]

FYI Greasemonkey is fixed, our very different bug, as alluded to above.

Comment 12

[Sylvestre Ledru [:Sylvestre]]

Closing because no crash reported since 12 weeks.