kmozillahelper crashing (Abort) Firefox when saving images

[biggestsonicfan]

Alright, so this issue has probably been going on for well over a year, but I could not pinpoint anything specifically. I even asked Mozilla support for help on this one. Until recently, Firefox would freeze when trying to save an image. This wasn't too much of a problem, as it was usually 1/100 chance of doing so. Then as time passed, it became a 1/10 chance. Debugging Firefox, running in the console, gdb, nothing was giving me any substance to report anything.

Then I made a revolutionary finding, I changed my entire KDE lineup from the openSUSE Tumbleweed repos to the KDE repos using this method here. After which, the crashes seemed to go away.

However, it did crash once after a very extended session. Perhaps after 1000 images were saved and generated this kcrash file: kmozillahelper-20210620-020232.zip

It was the first and only time KDE/Firefox decided to generate a crash report for this particular type of crash. I tried downloading as many debugging packages as I could, but sadly not all of them exist for tumbleweed's rolling release.

The crashes now occur again, maybe with a 1/50 chance, but no more crash dialog boxes appear. Would love to finally get this sorted.

[Vogtinator]

Hm, I've never seen this happen myself or any other reports of this.

However, it did crash once after a very extended session. Perhaps after 1000 images were saved and generated this kcrash file: kmozillahelper-20210620-020232.zip

This backtrace points either to memory corruption which could be anywhere (and is hard to track down without a way to reproduce it somewhat reliably) or caused by the recent enabling of the libimobiledevice backend in solid from last week. You might have an error message in your ~/.local/share/sddm/xorg-session.log which might be helpful.

[biggestsonicfan]

You might have an error message in your ~/.local/share/sddm/xorg-session.log which might be helpful.

The log consists mostly of

** (process:10865): WARNING **: 00:34:33.230: Unable to refresh system cache: The AppStream system cache was updated, but some components were ignored. Refer to the verbose log for more information.
Sandbox: attempt to open unexpected file /sys/devices/system/cpu/online
Sandbox: attempt to open unexpected file /proc/stat
Sandbox: attempt to open unexpected file /proc/net/unix
Sandbox: attempt to open unexpected file /proc/self/maps

with the /proc/net/unix and /proc/self/maps repeated extremely frequently.

And there are a few

###!!! [Parent][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost

mixed in there as well. Other than that, that's the entire xorg-session.log, and sadly, this is most likely not the same log from the uptime session of that particular crash.

or caused by the recent enabling of the libimobiledevice backend in solid from last week

That's an interesting working theory. I've never actually paid attention to see if my iphone was plugged into my computer at the time or not of any of the crashes... I'll do some testing.

[biggestsonicfan]

Managed to generate a second log. Again, crash immediately happened upon the "mouse up" of a click on the context menu's "Save Image As"

kmozillahelper-20210623-041111.zip

iPhone was not plugged in.

EDIT: xorg-session.log managed to output something relevant. Glad I didn't restart:

###!!! [Parent][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost

free(): invalid pointer
KCrash: Application 'kmozillahelper' crashing...
KCrash: Attempting to start /usr/lib64/libexec/drkonqi
/tmp/drkonqi.guaqfZ:2: Error in sourced command file:
No symbol "s_kcrashErrorMessage" in current context.
/tmp/drkonqi.YIgBUY:2: Error in sourced command file:
No symbol "s_kcrashErrorMessage" in current context.
Unable to start Dr. Konqi
Re-raising signal for core dump handling.

###!!! [Parent][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost

[Vogtinator]

iPhone was not plugged in.

That is very strange, because when there's no relevant device it should not even try to get into idevice code.

Did you start firefox before you unplugged it? If so, please unplug all iOS devices before starting firefox and try to reproduce the issue.

[biggestsonicfan]

Did you start firefox before you unplugged it?

Hmm, now that I can't be sure of. I guess I'm gonna have to not charge my iPhone via my close usb ports and plug it into a wall wart for a while until this decides to generate another crash file.

[Vogtinator]

If you have a way to reproduce it somewhat reliably, you can try this (as root) for more insight:

zypper install valgrind
mv /usr/lib/mozilla/kmozillahelper /usr/lib/mozilla/kmozillahelper.real
echo '#!/bin/sh\nexec valgrind --smc-check=all /usr/lib/mozilla/kmozillahelper.real "$@"' > /usr/lib/mozilla/kmozillahelper
chmod a+x /usr/lib/mozilla/kmozillahelper

This runs kmozillahelper in valgrind, so it'll be slower, but there'll be a lot of helpful output when you start firefox in a terminal.

To undo, just mv /usr/lib/mozilla/kmozillahelper.real /usr/lib/mozilla/kmozillahelper and optionally uninstall valgrind again.

[biggestsonicfan]

Did this, but now Firefox won't run kmozillahelper. It's using the default... whatever for dialog boxes now.

EDIT: I changed your new kmozillahelper generated file a bit to be:

#!/bin/sh
valgrind --smc-check=all /usr/lib/mozilla/kmozillahelper.real "$@"

I don't know if omitting \nexec affects how you would like to see the debug output, but as soon as I opened a save image dialog box, the terminal went crazy thing things like

==18486== Conditional jump or move depends on uninitialised value(s)
==18486==    at 0xFB79BB5: ??? (in /memfd:sljit (deleted))
==18486==    by 0xFE1A417: ???
==18486== 
==18486== Conditional jump or move depends on uninitialised value(s)
==18486==    at 0xFB78D05: ??? (in /memfd:sljit (deleted))
==18486==    by 0xFE1A417: ???
==18486== 
==18486== Conditional jump or move depends on uninitialised value(s)
==18486==    at 0xFB7A9AD: ??? (in /memfd:sljit (deleted))
==18486==    by 0xC607CB7: ???
==18486== 
==18486== Conditional jump or move depends on uninitialised value(s)
==18486==    at 0xFB79BB5: ??? (in /memfd:sljit (deleted))
==18486==    by 0xC607CB7: ???
==18486== 
==18486== Conditional jump or move depends on uninitialised value(s)
==18486==    at 0xFB7A9AD: ??? (in /memfd:sljit (deleted))
==18486==    by 0xBDE2437: ???
==18486== 
==18486== Conditional jump or move depends on uninitialised value(s)
==18486==    at 0xFB79BB5: ??? (in /memfd:sljit (deleted))
==18486==    by 0xBDE2437: ???
==18486== 

And once I exited Firefox, it gave me this. I was probably running Firefox for a total of 40 seconds and saved 1 image:

==18486== Warning: invalid file descriptor -1 in syscall close()
==18486== 
==18486== HEAP SUMMARY:
==18486==     in use at exit: 1,008,174 bytes in 12,569 blocks
==18486==   total heap usage: 3,053,324 allocs, 3,040,755 frees, 5,812,549,937 bytes allocated
==18486== 
==18486== LEAK SUMMARY:
==18486==    definitely lost: 5,088 bytes in 23 blocks
==18486==    indirectly lost: 75,689 bytes in 141 blocks
==18486==      possibly lost: 544 bytes in 2 blocks
==18486==    still reachable: 926,853 bytes in 12,403 blocks
==18486==                       of which reachable via heuristic:
==18486==                         newarray           : 4,264 bytes in 1 blocks
==18486==         suppressed: 0 bytes in 0 blocks
==18486== Rerun with --leak-check=full to see details of leaked memory
==18486== 
==18486== Use --track-origins=yes to see where uninitialised values come from
==18486== For lists of detected and suppressed errors, rerun with: -s
==18486== ERROR SUMMARY: 1349 errors from 796 contexts (suppressed: 0 from 0)

[Vogtinator]

Did this, but now Firefox won't run kmozillahelper. It's using the default... whatever for dialog boxes now.

EDIT: I changed your new kmozillahelper generated file a bit to be:

#!/bin/sh
valgrind --smc-check=all /usr/lib/mozilla/kmozillahelper.real "$@"

Right, looks like I forgot the -e parameter for echo.

I don't know if omitting \nexec affects how you would like to see the debug output, but as soon as I opened a save image dialog box, the terminal went crazy thing things like

Ok, that means it works! Once you can reproduce the issue, it should print the cause.

[biggestsonicfan]

Ok, that means it works! Once you can reproduce the issue, it should print the cause.

Uh, not necessarily....

==3716== 
==3716== More than 1000 different errors detected.  I'm not reporting any more.
==3716== Final error counts will be inaccurate.  Go fix your program!
==3716== Rerun with --error-limit=no to disable this cutoff.  Note
==3716== that errors may occur in your program without prior warning from
==3716== Valgrind, because errors are no longer being displayed.
==3716== 

I saved 2 images in this session and this popped up.... should I run with --error-limit=no?

[Vogtinator]

I assume all of the printed errors look similarly, if so they need to be ignored. Graphics drivers cause a very high rate of false positives.

[biggestsonicfan]

The crashes are prone to happening when I am saving a lot of images manually very fast. Probably close to 3-4 images per second.

This method allows me to save 0.7 images per minute. I don't think I can reproduce the conditions but I will try. I could switch KDE vendors back to OpenSUSE, which froze extremely frequently, but never prompted any crash dialogs.

EDIT: Added the parameter --undef-value-errors=no and it sped things up a bit as well as not printing so many errors that if a real error occurred it would be lost past the terminal scrolling point.

Not the crash error, but I did get this:

==5242== Syscall param waitid(infop) points to unaddressable byte(s)
==5242==    at 0x6455D6D: syscall (in /usr/lib64/libc-2.33.so)
==5242==    by 0x5DE370E: ??? (in /usr/lib64/libQt5Core.so.5.15.2)
==5242==    by 0x5DC6D29: ??? (in /usr/lib64/libQt5Core.so.5.15.2)
==5242==    by 0x4A4EF98: ??? (in /usr/lib64/libKF5KIOCore.so.5.83.0)
==5242==    by 0x4A4F186: ??? (in /usr/lib64/libKF5KIOCore.so.5.83.0)
==5242==    by 0x4A50918: KSambaShare::KSambaShare() (in /usr/lib64/libKF5KIOCore.so.5.83.0)
==5242==    by 0x4A50DCF: KSambaShare::instance() (in /usr/lib64/libKF5KIOCore.so.5.83.0)
==5242==    by 0x4A5CCF4: KFileItem::overlays() const (in /usr/lib64/libKF5KIOCore.so.5.83.0)
==5242==    by 0x495AD8B: KDirModel::data(QModelIndex const&, int) const (in /usr/lib64/libKF5KIOWidgets.so.5.83.0)
==5242==    by 0x5E1A910: QSortFilterProxyModel::data(QModelIndex const&, int) const (in /usr/lib64/libQt5Core.so.5.15.2)
==5242==    by 0x4914EC7: ??? (in /usr/lib64/libKF5KIOWidgets.so.5.83.0)
==5242==    by 0x49155BC: KFileItemDelegate::sizeHint(QStyleOptionViewItem const&, QModelIndex const&) const (in /usr/lib64/libKF5KIOWidgets.so.5.83.0)
==5242==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

[biggestsonicfan]

As expected, swapping from KDE back to OpenSUSE repos allowed Firefox to crash easier. Absolutely no console output before or during the crash. Firefox was just indefinitely frozen again. There is also nothing relevant in xorg-session.log.

EDIT: iphone was not plugged in.

[biggestsonicfan]

I've had 6 fatal crashes in the past hour trying to catch up on my work. I am going to have to remove kmozillahelper for the time being until this task I am working on is finished.

[biggestsonicfan]

For what it's worth, the issue also appears to be happening in Firefox without kmozillahelper. The freeze lasts anywhere from 5 to 10 seconds, but recovers and quickly catches up and the save file dialog box is shown. While Firefox is in this state, tab focus can be changed (something that can not be done with kmozillahelper). Perhaps during this time that Firefox is freezing, kmozillahelper is being launched too early and Firefox can not pass the data in time, thus locking the software?

[Vogtinator]

For what it's worth, the issue also appears to be happening in Firefox without kmozillahelper.

I suggest you bring that up in a Firefox bug report.

Perhaps during this time that Firefox is freezing, kmozillahelper is being launched too early and Firefox can not pass the data in time, thus locking the software?

Weird things can happen if you have multiple windows open at once (nested event loops).

[biggestsonicfan]

I could only get Firefox to blip like that twice, as opposed to the hundreds and hundreds of unrecoverable freezes I've had with kmozillahelper.

To try to further this along, I've installed OpenSUSE Tumbleweed in a VM and am trying to reproduce the issue to see if it's not machine specific. If I can't get it to happen in the VM, I'll try removing libimobiledevice as described earlier to see if that makes any changes.

[biggestsonicfan]

Any other thoughts? I am simply thinking of moving to Chrome. My love for Firefox is huge, and it will always be my favorite browser, but the amount of work and time lost due to these crashes has been too much for me to handle lately.

[biggestsonicfan]

The crashing has become too much. I can't handle it anymore. Between this and the KDE logging I just can't use this software until these issues are resolved. I will continue to attempt to figure out how to reproduce the issue in a virtual machine, but until then I will no longer be using kmozillahelper in conjunction with Firefox on my daily driver. I will report back if I find anything in VM.

[biggestsonicfan]

To see if core changes to other areas possibly assisted in resolving this issue I have with kmozillahelper since I last used it, I decided to reinstall it.

Firefox froze before I was able to save even 10 images.

[biggestsonicfan]

I noticed a change to KDE's dialog boxes in a recent update, and decided to give kmozillahelper another try. So far no problem, which is incredible because I am 100% positive I would have encountered the error by now. I will report back and close this issue if it continues to work fine.

Issue #29 still persists, however.

[biggestsonicfan]

While I don't know if the issue in the original post was causing the infinite Firefox hangs or not, the issue has appeared to have resolved itself (finally), so I will go ahead and close it now.