0

I am trying to understand why my app crashes in ubuntu 18.04, not just how to work around it, to better understand what is going on.

I have built a C++ application which uses boost in ubuntu 22.04 (using CMake) and I have packed my application into deb using CPack. Installing and running the application in another ubuntu 22.04 works well.

Installation on 18.04 works well but once I am running the application, it crashes with Segmentation fault before it even reaches main.

Running using GDB also with the message:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()

Stack trace (bt) doesn't provide much info (that at least I can figure out):

(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007ffff7a5aa99 in ?? ()
#2  0x0000000000000000 in ?? ()

I have brought all the dependencies into $ORIGIN/lib from the 22.04 and placed $ORIGIN/lib in the executable RPATH. The dependencies include libc, libc++ and boost *.so.

Using ldd on the executable everything looks fine and it seems all the dependencies are found using RPATH:

linux-vdso.so.1 (0x00007ffd37768000)
libboost_filesystem-mt-d-x64.so.1.79.0 => /opt/testapp/lib/libboost_filesystem-mt-d-x64.so.1.79.0 (0x00007f1e05673000)
libboost_program_options-mt-d-x64.so.1.79.0 => /opt/testapp/lib/libboost_program_options-mt-d-x64.so.1.79.0 (0x00007f1e055ff000)
libstdc++.so.6 => /opt/testapp/lib/libstdc++.so.6 (0x00007f1e0532a000)
libgcc_s.so.1 => /opt/testapp/lib/libgcc_s.so.1 (0x00007f1e055df000)
libc.so.6 => /opt/testapp/lib/libc.so.6 (0x00007f1e05102000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1e04d64000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1e05554000)

Does anyone have any idea why it crashes, or provide some hints on next steps?

Thanks!

TCS
  • 5,790
  • 5
  • 54
  • 86
  • Maybe you share your code? 0x000000000000 is a clear sign of accessing to nullptr. – 273K May 12 '23 at 08:41
  • I'm surprised it even runs at all, binaries aren't generally portable between linux distributions. With care code built on older distributions might work on newer ones but I doubt you'll be successful in reverse. I imagine your crash is due to using libc with an incompatible version of ld-linux: https://stackoverflow.com/questions/847179/multiple-glibc-libraries-on-a-single-host – Alan Birtles May 12 '23 at 08:46
  • @273K - I have cleared the whole "main()", it literally just returns 0. The crash is before the main. This is why I believe it has to do with dependencies. – TCS May 12 '23 at 08:49
  • @AlanBirtles - If that is true (and I think you are right!), wouldn't I need to see that using `ldd`? Sorry for the basic knowledge. I am mainly in windows. – TCS May 12 '23 at 08:53
  • 2
    The path of least resistance on Linux really is to rebuild your application from source for each distribution you want to use it on. Alternatives to that are linking everything statically (though see https://stackoverflow.com/questions/57476533/why-is-statically-linking-glibc-discouraged for issues with glibc). You can also build on the oldest distribution you want to support and generally that executable will then work on newer ones. Docker can make building and testing on multiple distributions easier – Alan Birtles May 12 '23 at 08:58
  • Just finished building using docker 18.04 and it works on both 18.04 and 22.04. Thanks @AlanBirtles. Can you please write an answer so I can check it? – TCS May 12 '23 at 09:14
  • @n.m that's why I said "generally", it depends on what your application does and how it's built, e.g. if it dynamically links to system libraries (e.g. boost as in this case) then it'll only work if a compatible version of those libraries are available on the newer distro. If you're only using libc and libstdc++ then yes, it should work – Alan Birtles May 12 '23 at 09:29
  • @AlanBirtles Yes I just noticed the dependency on boost. Boost and other "normal" libraries could be an issue but you can easily bring your own or link statically against those. The issue is with glibc. – n. m. could be an AI May 12 '23 at 09:40

0 Answers0