11058 2017-02-15 17:12:41 +0000 Debugging with GDB causes Segmentation Fault 2017-02-16 14:41:02 +0000 1 1 7 Build System, Metadata & Runtime OE-Core devtools / tool chain unspecified Other arm RESOLVED OBSOLETE Undecided critical --- 1 olddudealex bluelightning meta.mr.watcher meta.watcher --- --- Don't know oldest_to_newest 70717 0 olddudealex 2017-02-15 17:12:41 +0000 I cross-compiled the app,that uses boost::asio library, and tested it on my target system. It works properly. But when I try to debug my app with gdb, I get this message in gdb-console: ************************************************** Program received signal SIGSEGV, Segmentation fault. _dl_debug_initialize (ldbase=4294967292, ns=1996288212) at dl-debug.c:55 55 if (r->r_map == NULL || ldbase != 0) ************************************************** The result is the same for remote and native debugging, and for several other boost libraries (but not for all). After searching any information, that could be helpful, I found similar problem in this doc (p.63): http://support.garz-fricke.com/products/Santaro/Linux-Yocto/Releases/Yocto-jethro-5.1-r6859-0/GUF-Yocto-jethro-5.1-r6859-0-IMX6GUF-Manual.pdf As said in document the problem can be caused by "Static instanciation in implicitly implemented C++ methods" and is connected to glibc. So I tried to reproduce this bug by this approach with code: ************************************************* #include <iostream> using namespace std; class AClass { public: void foo() { static int NmbOfInvokes = 0; NmbOfInvokes++; cout << NmbOfInvokes << endl; } }; int main(void) { cout << "Hello World" << endl; AClass anInstance; anInstance.foo(); anInstance.foo(); return 0; } ************************************************* This program works properly, but in debugging fails with the same SIGSEGV error. To fix it enough to rewrite class AClass in this way: ************************************************* class AClass { public: void foo(); }; void AClass::foo() { static int NmbOfInvokes = 0; NmbOfInvokes++; cout << NmbOfInvokes << endl; } ************************************************* The compilation flags: ************************************************* arm-poky-linux-gnueabi-g++ -march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a7 --sysroot=/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa7hf-vfp-neon-poky-linux-gnueabi -DHAVE_CONFIG_H -I. -I.. --sysroot=/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa7hf-vfp-neon-poky-linux-gnueabi -g -O0 --sysroot=/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa7hf-vfp-neon-poky-linux-gnueabi -MT SegFault_Reproduce.o -MD -MP -MF .deps/SegFault_Reproduce.Tpo -c -o SegFault_Reproduce.o SegFault_Reproduce.cpp mv -f .deps/SegFault_Reproduce.Tpo .deps/SegFault_Reproduce.Po ../arm-poky-linux-gnueabi-libtool --tag=CXX --mode=link arm-poky-linux-gnueabi-g++ -march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a7 --sysroot=/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa7hf-vfp-neon-poky-linux-gnueabi -g -O0 --sysroot=/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa7hf-vfp-neon-poky-linux-gnueabi --sysroot=/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa7hf-vfp-neon-poky-linux-gnueabi -o SegFault_Reproduce SegFault_Reproduce.o arm-poky-linux-gnueabi-libtool: link: arm-poky-linux-gnueabi-g++ -march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a7 --sysroot=/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa7hf-vfp-neon-poky-linux-gnueabi -g -O0 --sysroot=/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa7hf-vfp-neon-poky-linux-gnueabi --sysroot=/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa7hf-vfp-neon-poky-linux-gnueabi -o SegFault_Reproduce SegFault_Reproduce.o ************************************************* I suppose that in some boost libraries are used similar static instanciation, because the symptoms are exactly the same. I use yocto 2.0.1 with gcc 5.2.0, gdb 7.9.1, boost 1.58 70737 1 olddudealex 2017-02-16 14:41:02 +0000 After updating GDB to 7.11.1 version the problem has gone.