Embedded_linux [SOLVED]: Segmentation fault only during GDB debugging

Embedded_linux [SOLVED]: Segmentation fault only during GDB debugging

Home Forums Embedded Linux Embedded_linux [SOLVED]: Segmentation fault only during GDB debugging

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #4347

    Anonymous

    QuestionQuestion

    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 the 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.

    What can I do to receive the possibility of debugging boost applications?

    The versions of packages that I used: yocto 2.0.1, gcc 5.2.0, gdb 7.9.1, boost 1.58.

    #4348

    Anonymous

    Accepted AnswerAnswer

    But when I try to debug my app with gdb, I get this message

    This suggests a bug in GDB. Your version: 7.9.1 is almost 2 years old. Your first step should be to try a more recent GDB release.

    One difference between “under GDB” and “native” execution is that GDB disables ASLR.

    You can try (gdb) set disable-randomization off before running the program. But given the symptoms you described, I doubt that has anything to do with the problem.

    Source: http://stackoverflow.com/questions/42256374/segmentation-fault-only-during-gdb-debugging
    Author: Employed Russian
    Creative Commons License
    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Viewing 2 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic.