libQT5WebEngine seems faulty

A particular AppImage “GoPanda” connects to a server as a client. Itsimply stopped working after a major update. This happened on two machines. The AppImage worked fine on an un-updated machine until I updated one package using YaST GUI

It looks like libQT5WebEngine has a problem

There are no error messages, the App just does not connect any more.

I don’t have another similar apps to compare but on the third machine this single package update caused the problem.

Any thoughts gratefully received

I’ve installed another AppImage which is a local application and it works - I suppose another way of asking for help is how do I roll back libQt5-qtwebengine, please?

Previous versions can be found at:

There is a known problem with qtwebengine at the moment, related to the version of harfbuzz you are using, that may (?) be relevant.

Details here:

I may be misinterpreting this, in which case I apologise, but the only recommended way to update a TW system is by the use of “zypper dup”, not via the YaST GUI.

Thank you for the information.

I understand your point about YaST. It was an accidental update as I thought I was working on the laptop with the already broken AppImage and was looking for inspiration.

The earliest version of libqt5-qtwebengine I can identify is 5.15.5-2.1 with a filestamp of 16th August and that doesn’t work

The problem only arose a few days ago so I’m now wondering if I am diagnosing correctly

Unfortunately I’m unable to offer any further real suggestions, GoPanda is not a piece of software I’m familiar with, and I don’t use any application(s) that are provided in appimage format.

You wrote in your initial post:

Did you mean there are no error messages issued when the application launches, or there are no errors logged, did you check in the journal?

If you are using BTRFS you could possible rollback to a prior state, then just update qtwebengine to confirm if that is in fact the culprit. If so, then a bug report may not go amiss.

Thank you for your help. I’ve been in contact with the developer who suggested a few things, but in truth the only thing that has changes is Tumbleweed.

Regarding error messages Cntl + Shift + i launches a console when the app is running properly. .

Launching the app from the command line is similarly unresponsive.

I’ll try BTRFS (never used it)

Regarding filing a bug - I would, if I knew what to file it against. There’s no qtengine category in

But are there any errors being logged in the system journal? Try the following.

Prior to attempting to launch the application:

switch to a virtual terminal using “ctrl-alt-F2”
login as your normal user
then issue the command “sudo journalctl -f” (this will “follow” new entries to the journal)

now switch to a second virtual terminal using “ctrl-alt-F3”
login as your normal user
attempt to launch the application

switch back to the first virtual terminal using “ctrl-alt-F2”
are there any error messages now logged relating to the attempted launch of the application?

terminate journal “following” by using the command “ctrl-c”
exit the virtual terminals by using the command “exit”

I’ll try BTRFS (never used it)

You may have misunderstood(?). BTRFS is the underlying file system, normally used by default on openSUSE. Then if “snapper” has been setup it is possible to “roll-back” to a previous state.

Take a look here for a brief overview.

Regarding filing a bug - I would, if I knew what to file it against. There’s no qtengine category in

If you are able to prove it due to qtwebengine then report to either openSUSE: using a generic category, or directly upstream to qt:

again, thank you for your continued help and patience

second point first: more accurately “I have never used the features of BTRFS, such as roll back”
using virtual terminals (big linux tutorial going on here)

error messages

Oct 09 13:02:40 Unknown-b4-2e-99-e9-04-99 kernel: gopanda2[2569]: segfault at 208 ip 000056319a122e83 sp 00007ffe7dd72a90 error 4 in gopanda2[56319458d000+5caf000]
Oct 09 13:02:40 Unknown-b4-2e-99-e9-04-99 kernel: Code: 55 41 54 53 50 83 7f 78 00 0f 85 a6 00 00 00 49 89 fe b9 01 00 00 00 31 c0 f0 0f b1 4f 78 85 c0 0f 85 8f 00 00 00 49 8b 46 08 <44> 8b  a0 08 02 00 00 41 83 fc ff 74 0f 41 bf 01 00 00 4c 8d 2d 
Oct 09 13:02:40 Unknown-b4-2e-99-e9-04-99 systemd[1]: tmp-.mount_GoPandoiWUDW.mount: Deactivated successfully.

further research provides error 4 “the application is trying to access a memory area that belongs to the OS or some other program. The memory management unit in the CPU stops the operation and triggers an exception. The standard segfault exception handler in the kernel kills the program”
so I have supplied the information back to the app developer.


Indeed, GoPanda segfaults. (Error 4 as you have found, indicates the application is attempting to access a memory area other than its own.)

I’m sorry, but I don’t believe I’m able to progress this any further, hopefully others more knowledgeable than I will step up and assist in your debugging of this issue.

As an aside, I’ve only just noticed you’re new to the forum. A belated welcome.

you have been very helpful, I’m not new here but a rare visitor and was unable to remember/recover my password, henceforth I will be GoPanda,

the curiosity is that until the Tumbleweed update GoPanda worked fine (for years) it didn’t help that qtengine was playing up, either…

In the “Audacity” thread you posted:

The following 6 packages are going to be upgraded:

glibc glibc-extra glibc-lang glibc-locale glibc-locale-base

At the start of this thread you said your issues began “after a major update” - I’m guessing that was snapshot 20210920 which was a complete rebuild of all packages because of the glibc update.

Possibly (the appimage) gopanda2 needs to be rebuilt against the latest glibc. Although it was my understanding that glibc was backwards compatible, ie an application built with an eariler version will work correctly with a later.

Probably worth passing on the fact that an update to glibc appears to have broken gopanda2 to the gopanda2 developers.

It looks like glibc is the culprit, I had my report

marked as duplicate of this