Eclipse GDB setup issues; can't determine cause for SIGSEGV

Eclipse GDB setup issues; can't determine cause for SIGSEGV

[Bryan Evenson]

All,

I have a AT91SAM9G25 system that has been idle for a couple years (running morty, yocto version 2.2.1) and I am working on updating to the latest Yocto production branch.  Before I get there, I'm trying to confirm the old setup and I'm having problems with remote debugging.  I know there have been changes since yocto version 2.7 for debugging support, so I want to make sure I can get the old setup to work first prior to changing everything.  I'm looking for assistance in tracking down my debug issues.

My stable production image is based off of core-image-minimal, with a few additional packages for our proprietary applications (proprietary applications are written in C).  I also have a development image, based off of our production image, with the following additions:

IMAGE_FEATURES += "package-management dev-pkgs eclipse-debug allow-empty-password empty-root-password"

IMAGE_INSTALL += " \
    #same additional packages as production image  \
    #"-dbg" version of proprietary applications \                               
    gdbserver \
"
# Strip python from the image to reduce the image size
PACKAGE_EXCLUDE = "python"

I have the Eclipse Yocto plugin installed and it is setup to use the SDK that I have built based on the development image.  I've confirmed that I can start a debug session on one of our proprietary applications.  I can set breakpoints and run the debugger.  However, the debugger always stops at the first call to uuid_compare with a  SIGSEGV.  The last line in the call stack states "<symbol is not available> 0x00000000".  From my understanding, the stack pointer is getting set to NULL when uuid_compare is getting called.  If I stop the debugger and just run the application on the hardware, the application runs without errors.  I have confirmed with syslog messages that I do not have the same NULL stack pointer issue when I run the application outside of the debugger.

Any suggestions on where to start looking?  I don't see any obvious possible causes and I don't know where to start looking for the problem.

Thanks,
Bryan

Re: Eclipse GDB setup issues; can't determine cause for SIGSEGV

[Bryan Evenson]

All,

> -----Original Message-----
> From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On
> Behalf Of Bryan Evenson via lists.yoctoproject.org
> Sent: Monday, June 1, 2020 11:16 AM
> To: yocto@lists.yoctoproject.org
> Subject: [yocto] Eclipse GDB setup issues; can't determine cause for SIGSEGV
> 
> All,
> 
> I have a AT91SAM9G25 system that has been idle for a couple years (running
> morty, yocto version 2.2.1) and I am working on updating to the latest Yocto
> production branch.  Before I get there, I'm trying to confirm the old setup
> and I'm having problems with remote debugging.  I know there have been
> changes since yocto version 2.7 for debugging support, so I want to make
> sure I can get the old setup to work first prior to changing everything.  I'm
> looking for assistance in tracking down my debug issues.
> 
> My stable production image is based off of core-image-minimal, with a few
> additional packages for our proprietary applications (proprietary applications
> are written in C).  I also have a development image, based off of our
> production image, with the following additions:
> 
> IMAGE_FEATURES += "package-management dev-pkgs eclipse-debug allow-
> empty-password empty-root-password"
> 
> IMAGE_INSTALL += " \
>     #same additional packages as production image  \
>     #"-dbg" version of proprietary applications \
>     gdbserver \
> "
> # Strip python from the image to reduce the image size
> PACKAGE_EXCLUDE = "python"
> 
> I have the Eclipse Yocto plugin installed and it is setup to use the SDK that I
> have built based on the development image.  I've confirmed that I can start a
> debug session on one of our proprietary applications.  I can set breakpoints
> and run the debugger.  However, the debugger always stops at the first call
> to uuid_compare with a  SIGSEGV.  The last line in the call stack states
> "<symbol is not available> 0x00000000".  From my understanding, the stack
> pointer is getting set to NULL when uuid_compare is getting called.  If I stop
> the debugger and just run the application on the hardware, the application
> runs without errors.  I have confirmed with syslog messages that I do not
> have the same NULL stack pointer issue when I run the application outside of
> the debugger.
> 
> Any suggestions on where to start looking?  I don't see any obvious possible
> causes and I don't know where to start looking for the problem.
> 

On a whim, I changed in my code:
    if(uuid_compare(uuid1, uuid2) == 0)

To:
    If(memcmp(uuid1, uuid2, 16) == 0)

After this change the problematic line of code worked just fine.  The debugger worked fine until I got to the next spot in my code that called uuid_compare.  At the next call to uuid_compare I got the same SIGSEGV error I had before.  Something is clearly a problem with calling uuid_compare.  However, I'm using several other functions from the uuid library (uuid_is_null, uuid_parse, uuid_unparse for a few) and none of them are causing problems.  I don't think it's a problem with the input parameters because I'm passing the same UUIDs to memcomp as I did to uuid_compare.  Has anyone ever seen only one function from a library cause problems like this?

> Thanks,
> Bryan