Greasemonkey: GM is Causing Firefox to Hang and then Crash When Closing

[GuardianMajor]

@arantius Starting about a week ago (around the 3.12) and subsequently since (including 3.13) when you close the browser, it will continue to run (hang) for about 30-60 seconds and then crashes throwing up the crashreporter.

Have gone over the crash reports, mini-dumps and the standard diagnostics to isolate the issue squarely with GM - disabling GM fixes the issue and enabling it results in it 100% - so there is no doubt the issue is caused by GM.

However, what I don't understand is that for nearly 2 years now there has been no actual code updates, just version bumps and I am on the 55.x stable (32 bit) which means there is no 57 issues to speak of and all the scripts are first-party and been running the same way for over a year without any modifications (and all but 2 of them don't even use the GM_ API, and disabling/removing them doesn't fix the problem so I doubt it's that) - so why is it suddenly causing this issue?

The expectation after 4 is released would be issues to be caused and I get that and accept it, but we are not on 4 yet and the existing 3.x running on stable non-57 should not be causing this out of the blue. So what changed to cause this? Currently this is hampering daily activity in a very critical manner, so how do we fix this issue? I have tried reading "related" issues that I felt might remotely resemble my issue but I am not seeing anything that addresses my case - unless I missed something.

Please advise, as I do NOT want to go to VM or TM and abandon GM for this issue, which frankly shouldn't be happening given that nothing has actually changed yet. Thank you.

[darkred]

I have tried reading "related" issues that I felt might remotely resemble my issue but I am not seeing anything that addresses my case - unless I missed something.

Duplicate of #2573 .
See https://github.com/greasemonkey/greasemonkey/issues/2573#issuecomment-331927903

[GuardianMajor]

@darkred I appreciate the link but the report has multiple instances, I do not, I only have the main one that never ends until it crashes.

As for the comment, reverting back to 3.11 did nothing to fix it and I am not sure why it worked for them as there has been no code changes (other than version bump) for two years, so rolling back to that wouldn't reasonably have an effect, so I wasn't surprised that it didn't make a difference in my case.

As I said, I have read everything already and didn't find any of them to resolve MY issue, so why I posted it, so thank for linking to these but doesn't address what I am experiencing. Thanks.

PS: To clarify, I am currently running 3.11 and the problem still persists, in case it wasn't clear. Thanks.

[jerone]

appreciate the link but the report has multiple instances, I do not, I only have the main one that never ends until it crashes.

I have the same issue, and I really think it's still related to https://github.com/greasemonkey/greasemonkey/issues/2573

PS: To clarify, I am currently running 3.11 and the problem still persists, in case it wasn't clear. Thanks.

To be sure, you fully restarted Firefox (forced shutdown all Firefox instances)?

And can you confirm that you have an UserScript with a data: URL for their @icon (see https://github.com/greasemonkey/greasemonkey/issues/2573#issuecomment-331927903)?

[darkred]

appreciate the link but the report has multiple instances, I do not, I only have the main one that never ends until it crashes.

The multiple instances in my report are simply because in my case electrolysis (e10s) is enabled.
In your case it obviously isn't enabled, but other that that, I'm definite that your issue is covered in #2573.
Please check the points that jerone asked.

[GuardianMajor]

@jerone

To be sure, you fully restarted Firefox (forced shutdown all Firefox instances)?

Cute, made me smile, yes of course.

And can you confirm that you have an UserScript with a data: URL for their @icon (see #2573 (comment))?

All our scripts have either no @icon or if they do, they are in the form of a data:image/png;base64 which is local only. To best of my understanding that is not the issue with what was discussed there or is it? because it is not requesting anything from anywhere.

@darkred Sure then, let's go with they are the same. And yes I can see it myself, I checked already and response to it is above.

[jerone]

To best of my understanding that is not the issue with what was discussed there.

Yes it was, and it is already fixed. I think a new version will be released soon.

[GuardianMajor]

@jerone I was in the middle of rewording my response but you jumped on it already, so fine then it is. But how is a local data that is not being fetched anywhere causing this then? They are in-place renders, they are using built-in browser rendering. Just trying to understand why this would cause the browser to hang.

EDIT: Ok, looking at the commits, it seems that it was a problem with how the scripts were being migrated and not the scripts themselves. Will try the update as soon as it is pushed and see how it goes, thanks.

[jerone]

But how is a local data that is not being fetched anywhere causing this then?

To my understanding it's trying to fetch the @icon, but it's not a valid URI, so it fails somehow. But if you want more details, you have to ask @arantius.

[arantius]

Exactly as @jerone said. And 3.14 was approved very quickly, so you can install and (hopefully) confirm the fix:

https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/versions/#version-3.14

[GuardianMajor]

@jerone Got it thanks.
@arantius Thank you, look forward to trying it.

[GuardianMajor]

@arantius I wanted to have a chance to work with it for a bit before reporting back and I am happy to say that the fixes worked. It now does close properly, although should be noted that while before it would completely close nearly instantly (few seconds) now it can as little as 30 seconds to as much as 60 seconds to close afterward but at least it IS properly closing now, thank you for the quick fix.