Segmentation fault outside Qt Creator only

Texture

@mrjj Thank you for your answer! I will give this a try in a few near hours. But I did not have to do something like this when porting apps between desktop Xubuntu's distros, using only apt for install necessary libraries. Is it a feature of Raspbian Qt support?

Moreover, I am trying to launch my app on the same Raspberry Pi machine. Is deploying needed for this situation?

mrjj

Hi
if a distro supplies the right Qt libs/SO files. same version as used for app. then
all be will be ok. Since it can find them in the system, so to speak.

However, it must be the exact version (to some degree) so often you still need your version of the SO files.

You can use ldd on your exe and see what is loaded and from where.

Texture

@mrjj I have tried aforementioned way to deploy (however, with using patchelf):

patchelf --set-rpath '$ORIGIN' ./myExec

and copied all files that ldd shows me for my exec in the same folder:

ldd myExec | grep "=> /" | awk '{print $3}' | xargs -I '{}' cp -v '{}' ./

Nothing changed. I think my problem could be connected with specific Raspberry GLES and EGL libs, could not it? Strange magic, but I was trying different configurations of my pro-file and only one time my application was started from the terminal after rebuilding. It was only once and has not repeated yet for the same configuration. Are you sure that the problem could be in the deploying if I could not start my application on the same machine?

mrjj

Hi
Ok, so now all SO files are loaded from "ORIGIN" when you ldd it ?
Sounds pretty ok.
You seems very good with linux scripting so i wonder if you can dump ldd recursive so you can also check the SO files dependencies and see if it find something in
the system on load.

Yes it could very well be something else with GLES/EGL if a normal standard GUI project just runs on your device. I read " (as well as clean start QT project) " that you tested once with clean project and it had same issue ?

Texture

@mrjj Hello!

@mrjj said in Segmentation fault outside Qt Creator only:

Yes it could very well be something else with GLES/EGL if a normal standard GUI project just runs on your device. I read " (as well as clean start QT project) " that you tested once with clean project and it had same issue ?

Yep, the same problem appears for a clean project. For this clean project I have tried to make deploying as I described above. So I took clean project, built it and moved libraries to exec folder (using patchelf previously). Now I look at new ldd's output and it says me that exec wants 3 more libraries from other directories:

linux-vdso.so.1 (0x7ef92000)
/usr/lib/arm-linux-gnueabihf/libarmmem.so (0x76ed4000)
/lib/ld-linux-armhf.so.3 (0x76eea000)

As far as I understand, the first one is virtual library, but the others have already placed in the same directory..

And excuse me, I didn't fully understand your sugesstion about scripting :) Do you mean comparing dependencies of the certain executable and its existence in the system?

SGaist

Hi,

Can you show the backtrace of the segmentation fault ?

Texture

@SGaist
Hello there!

While preparing to get a backtracke, my app starts normally first time. Second launch gave me next traceback:

./myApp(_Z7handleri+0x18)[0x15430]
/lib/arm-linux-gnueabihf/libc.so.6(__default_sa_restorer+0x0)[0x75b696b0]

And the same backtrace for clean app but with locating lib.so.6 in the same dir:

./testApp(_Z7handleri+0x28)[0x12900]
/home/pi/testProject/build-untitled-Desktop-Debug/libc.so.6(__default_sa_restorer+0x0)[0x75e136b0]

But in the last case (with libc.so.6 in app dir) it could not be launched even from QtCreator.

SGaist

Did you use your device root filesystem as sysroot to cross-compile Qt ?

Texture

@SGaist Nope, I have installed Qt Creator and Qt libraries with apt from repositories on my RasPi and do some magic with linking EGLFS, something like this:
https://www.raspberrypi.org/forums/viewtopic.php?t=191857

So I don't use cross-compile at all.

Now I found from backtrace in gdb that problem is in /opt/vc/lib/libbrcmEGL.so

#0  0x75456624 in platform_get_handle () from /opt/vc/lib/libbrcmEGL.so
#1  0x7544bf30 in eglCreateWindowSurface () from /opt/vc/lib/libbrcmEGL.so
#2  0x730c6004 in ?? ()
   from /usr/lib/arm-linux-gnueabihf/qt5/plugins/xcbglintegrations/libqxcb-egl-integration.so
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Moreover, I could find that my problem is the same with the following post with no answers:
https://forum.qt.io/topic/85511/segmentation-fault-trying-to-display-camera-feed

EDIT
Looks like solution was found. I had to replace this alternative libs with native from

/usr/lib/arm-linux-gnueabihf/

I will make a stress test for this trick and give a little report.

Texture

This post is deleted!

Texture

Hello all!

Now after some testing days and so on I could finally find that the problem is in libbrcmGLESv2.so
To solve this issue this file should be copy from

/usr/lib/arm-linux-gnueabihf/

Looks like QtCreator anyway takes this file without dependencies and links that should be done to make QtCreator running on Raspbian 9 (Stretch) (i.e. as described here: https://www.raspberrypi.org/forums/viewtopic.php?t=191857).

This solved my problem of running Qt compiled apps on RasPi outside Qt Creator.

Ben.Kluwe

@Texture I just ran into the same problem using the latest raspbian stretch OS on a raspberry pi 3. My application makes use of libbrcmGLESv2.so and libbrcmEGL.so, but the application failed using libqxcb-egl-integration.so. So to enhance your answer with specific files and locations: since this is a plugin to qt you can simply remove it from the folder

/usr/lib/arm-linux-gnueabihf/qt5/plugins/xcbglintegrations/

and qt won't load it, thus solving the issue. Use

sudo find / -iname 'libqxcb-egl-integration.so'

to find it if qt plugins aren't in that directory.