image-prelink (can) cause SIGSEGV on program startup (when run under GDB)

image-prelink (can) cause SIGSEGV on program startup (when run under GDB)

[Bjørn Forsman]

Hi all,

Just FYI, I spent 2 days debugging why my application would fail to
start when run under GDB (gdbserver). It received SIGSEGV _before_
entering main. Turns out that by removing "image-prelink" from
local.conf fixes it.

I don't know the right channel to discuss prelink issues, I just
thought I'd post it _somewhere_.

Best regards,
Bjørn Forsman

Re: image-prelink (can) cause SIGSEGV on program startup (when run under GDB)

[Christian Ege]

[-- Attachment #1: Type: text/plain, Size: 1221 bytes --]

Hi Bjørn,
Am 07.01.2016 9:57 vorm. schrieb "Bjørn Forsman" <bjorn.forsman@gmail.com>:
>
> Hi all,
>
> Just FYI, I spent 2 days debugging why my application would fail to
> start when run under GDB (gdbserver). It received SIGSEGV _before_
> entering main. Turns out that by removing "image-prelink" from
> local.conf fixes it.
>
From my experience image-prelink and using the OpenEmbedded SDKs is not
recommended. Maybe your SDK is older than your current rootfs this can
cause GDB to struggle.

Anyway we had big issues when we tried to analyse stack backtraces with our
rootfs and marching SDK. Because the libc in the SDK is not prelinked and
the checksum check in GDB is not passed GDB barked out some warning.

Maybe there is a magic knob to tune but we did not found it. But the last
time I checked was in an older Yocto/OpenEmbedded environment.

> I don't know the right channel to discuss prelink issues, I just
> thought I'd post it _somewhere_.
>
> Best regards,
> Bjørn Forsman
Regards,
Christian
> --
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale

[-- Attachment #2: Type: text/html, Size: 1623 bytes --]

Re: image-prelink (can) cause SIGSEGV on program startup (when run under GDB)

[Bjørn Forsman]

Hi Christian,

On 7 January 2016 at 10:40, Christian Ege <k4230r6@gmail.com> wrote:
> Hi Bjørn,
> Am 07.01.2016 9:57 vorm. schrieb "Bjørn Forsman" <bjorn.forsman@gmail.com>:
>>
>> Hi all,
>>
>> Just FYI, I spent 2 days debugging why my application would fail to
>> start when run under GDB (gdbserver). It received SIGSEGV _before_
>> entering main. Turns out that by removing "image-prelink" from
>> local.conf fixes it.
>>
> From my experience image-prelink and using the OpenEmbedded SDKs is not
> recommended. Maybe your SDK is older than your current rootfs this can cause
> GDB to struggle.

Thanks for the data point. The thing is, debugging worked fine for a
long time. But when I added another library dependency, things broke.

Unless the build system is completely borked, rootfs and SDK should be
in sync. I explicitly rebuilt and re-flashed exactly to eliminate that
kind of trouble.

> Anyway we had big issues when we tried to analyse stack backtraces with our
> rootfs and marching SDK. Because the libc in the SDK is not prelinked and
> the checksum check in GDB is not passed GDB barked out some warning.

I guess you mean warnings like:

(gdb) set sysroot
~/poky-toolchain/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi
warning: .dynamic section for
"/home/bfo/poky-toolchain/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/libQt5Multimedia.so.5"
is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for
"/home/bfo/poky-toolchain/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/libQt5Widgets.so.5"
is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for
"/home/bfo/poky-toolchain/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/libQt5Gui.so.5"
is not at the expected address (wrong library or version mismatch?)
...

The weird part is that these warnings seem to come no matter what
(prelink or not). (I guess I should triple check that...)

> Maybe there is a magic knob to tune but we did not found it. But the last
> time I checked was in an older Yocto/OpenEmbedded environment.

I'm on early Yocto 2.0 / Jethro. I plan on updating soon, there are
probably many fixes.

Best regards,
Bjørn Forsman

Re: image-prelink (can) cause SIGSEGV on program startup (when run under GDB)

[Christian Ege]

[-- Attachment #1: Type: text/plain, Size: 3371 bytes --]

Hi Bjørn,
> Am 07.01.2016 um 10:49 schrieb Bjørn Forsman <bjorn.forsman@gmail.com>:
> 
> Hi Christian,
> 
> On 7 January 2016 at 10:40, Christian Ege <k4230r6@gmail.com> wrote:
>> Hi Bjørn,
>> Am 07.01.2016 9:57 vorm. schrieb "Bjørn Forsman" <bjorn.forsman@gmail.com>:
>>> 
>>> Hi all,
>>> 
>>> Just FYI, I spent 2 days debugging why my application would fail to
>>> start when run under GDB (gdbserver). It received SIGSEGV _before_
>>> entering main. Turns out that by removing "image-prelink" from
>>> local.conf fixes it.
>>> 
>> From my experience image-prelink and using the OpenEmbedded SDKs is not
>> recommended. Maybe your SDK is older than your current rootfs this can cause
>> GDB to struggle.
> 
> Thanks for the data point. The thing is, debugging worked fine for a
> long time. But when I added another library dependency, things broke.
> 
> Unless the build system is completely borked, rootfs and SDK should be
> in sync. I explicitly rebuilt and re-flashed exactly to eliminate that
> kind of trouble.
We had trouble when stepping over some c library functions for example printf, one workaround 
was to copy the lib from the roof into the SDK.
> 
>> Anyway we had big issues when we tried to analyse stack backtraces with our
>> rootfs and marching SDK. Because the libc in the SDK is not prelinked and
>> the checksum check in GDB is not passed GDB barked out some warning.
> 
> I guess you mean warnings like:
> 
> (gdb) set sysroot
> ~/poky-toolchain/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi
> warning: .dynamic section for
> "/home/bfo/poky-toolchain/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/libQt5Multimedia.so.5"
> is not at the expected address (wrong library or version mismatch?)
> warning: .dynamic section for
> "/home/bfo/poky-toolchain/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/libQt5Widgets.so.5"
> is not at the expected address (wrong library or version mismatch?)
> warning: .dynamic section for
> "/home/bfo/poky-toolchain/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/libQt5Gui.so.5"
> is not at the expected address (wrong library or version mismatch?)
> ...
> 
> The weird part is that these warnings seem to come no matter what
> (prelink or not). (I guess I should triple check that…)
yes, those messages. They disappeared after removing the prelink. I’ll double check when I am in the office tomorrow.
What kind of Toolchain are you using?
When you are using bitbake meta-toolchain you may have to create a sys root from your roots:
http://www.yoctoproject.org/docs/2.0/adt-manual/adt-manual.html#extracting-the-root-filesystem <http://www.yoctoproject.org/docs/2.0/adt-manual/adt-manual.html#extracting-the-root-filesystem> 
Or consider to switch to 

bitbare <your image> -c populate_sdk
http://www.yoctoproject.org/docs/2.0/adt-manual/adt-manual.html#optionally-building-a-toolchain-installer <http://www.yoctoproject.org/docs/2.0/adt-manual/adt-manual.html#optionally-building-a-toolchain-installer>


> 
>> Maybe there is a magic knob to tune but we did not found it. But the last
>> time I checked was in an older Yocto/OpenEmbedded environment.
> 
> I'm on early Yocto 2.0 / Jethro. I plan on updating soon, there are
> probably many fixes.
> 
> Best regards,
> Bjørn Forsman

Regards,
Christian

[-- Attachment #2: Type: text/html, Size: 5057 bytes --]

Re: image-prelink (can) cause SIGSEGV on program startup (when run under GDB)

[Bjørn Forsman]

On 12 January 2016 at 21:44, Christian Ege <k4230r6@gmail.com> wrote:
> Hi Bjørn,
>
> Am 07.01.2016 um 10:49 schrieb Bjørn Forsman <bjorn.forsman@gmail.com>:
>> I guess you mean warnings like:
>>
>> (gdb) set sysroot
>> ~/poky-toolchain/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi
>> warning: .dynamic section for
>> "/home/bfo/poky-toolchain/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/libQt5Multimedia.so.5"
>> is not at the expected address (wrong library or version mismatch?)
>> warning: .dynamic section for
>> "/home/bfo/poky-toolchain/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/libQt5Widgets.so.5"
>> is not at the expected address (wrong library or version mismatch?)
>> warning: .dynamic section for
>> "/home/bfo/poky-toolchain/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/libQt5Gui.so.5"
>> is not at the expected address (wrong library or version mismatch?)
>> ...
>>
>> The weird part is that these warnings seem to come no matter what
>> (prelink or not). (I guess I should triple check that…)
>
> yes, those messages. They disappeared after removing the prelink. I’ll
> double check when I am in the office tomorrow.

I checked again, I still have those warning messages. That is, even
without "image-prelink". (But everything seems to work fine now.)

Exact list of warnings from this run:

warning: .dynamic section for
"/home/bfo/poky-toolchain/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/libthriftqt5-0.9.3.so"
is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for
"/home/bfo/poky-toolchain/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/libQt5Widgets.so.5"
is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for
"/home/bfo/poky-toolchain/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/libQt5Core.so.5"
is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for
"/home/bfo/poky-toolchain/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/lib/libcrypto.so.1.0.0"
is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for
"/home/bfo/poky-toolchain/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/libpulse.so.0"
is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for
"/home/bfo/poky-toolchain/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/pulseaudio/libpulsecommon-6.0.so"
is not at the expected address (wrong library or version mismatch?)


> What kind of Toolchain are you using?
> When you are using bitbake meta-toolchain you may have to create a sys root
> from your roots:
> http://www.yoctoproject.org/docs/2.0/adt-manual/adt-manual.html#extracting-the-root-filesystem
> Or consider to switch to
>
> bitbare <your image> -c populate_sdk
>
> http://www.yoctoproject.org/docs/2.0/adt-manual/adt-manual.html#optionally-building-a-toolchain-installer

Yes, I use "bitbake my-image -c populate_sdk". And because we use Qt
for application development, my-image.bb has "inherit
populate_sdk_qt5".

- Bjørn

Re: image-prelink (can) cause SIGSEGV on program startup (when run under GDB)

[Julio Cruz Barroso]

Hi Bjørn, Christian,

I'm trying to perform a remote debug with a Qt Application (as you described below).

The GDB (at QT Creator) show a Segmentation Fault at dl-debug.c [1]. Basically, the same situation.

I performed the following steps:

- Sync to the latest jethro revision
- Delete tmp directory
- Rebuild SD image
- Rebuild SDK installer (bitbake my-image -c populate_sdk). 'my-image' inherit populate_sdk_qt5

Some days ago, the remote debugging was working without problem. 

There is a current issue related with this? Any advices or suggestion?

Thanks for your help,

Julio

[1] SIGSEGV during remote debug: [dl-debug.c] Line 55: if (r->r_map == NULL || ldbase != 0)


-----Original Message-----
From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-bounces@yoctoproject.org] On Behalf Of Bjørn Forsman
Sent: Thursday, January 07, 2016 5:49 PM
To: Christian Ege
Cc: meta-freescale
Subject: Re: [meta-freescale] image-prelink (can) cause SIGSEGV on program startup (when run under GDB)

Hi Christian,

On 7 January 2016 at 10:40, Christian Ege <k4230r6@gmail.com> wrote:
> Hi Bjørn,
> Am 07.01.2016 9:57 vorm. schrieb "Bjørn Forsman" <bjorn.forsman@gmail.com>:
>>
>> Hi all,
>>
>> Just FYI, I spent 2 days debugging why my application would fail to 
>> start when run under GDB (gdbserver). It received SIGSEGV _before_ 
>> entering main. Turns out that by removing "image-prelink" from 
>> local.conf fixes it.
>>
> From my experience image-prelink and using the OpenEmbedded SDKs is 
> not recommended. Maybe your SDK is older than your current rootfs this 
> can cause GDB to struggle.

Thanks for the data point. The thing is, debugging worked fine for a long time. But when I added another library dependency, things broke.

Unless the build system is completely borked, rootfs and SDK should be in sync. I explicitly rebuilt and re-flashed exactly to eliminate that kind of trouble.

> Anyway we had big issues when we tried to analyse stack backtraces 
> with our rootfs and marching SDK. Because the libc in the SDK is not 
> prelinked and the checksum check in GDB is not passed GDB barked out some warning.

I guess you mean warnings like:

(gdb) set sysroot
~/poky-toolchain/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi
warning: .dynamic section for
"/home/bfo/poky-toolchain/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/libQt5Multimedia.so.5"
is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for
"/home/bfo/poky-toolchain/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/libQt5Widgets.so.5"
is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for
"/home/bfo/poky-toolchain/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/libQt5Gui.so.5"
is not at the expected address (wrong library or version mismatch?) ...

The weird part is that these warnings seem to come no matter what (prelink or not). (I guess I should triple check that...)

> Maybe there is a magic knob to tune but we did not found it. But the 
> last time I checked was in an older Yocto/OpenEmbedded environment.

I'm on early Yocto 2.0 / Jethro. I plan on updating soon, there are probably many fixes.

Best regards,
Bjørn Forsman
--
_______________________________________________
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale

Re: image-prelink (can) cause SIGSEGV on program startup (when run under GDB)

[Bjørn Forsman]

Hi Julio,

On 19 March 2016 at 12:40, Julio Cruz Barroso <julio.cruz@smartmatic.com> wrote:
> Hi Bjørn, Christian,
>
> I'm trying to perform a remote debug with a Qt Application (as you described below).
>
> The GDB (at QT Creator) show a Segmentation Fault at dl-debug.c [1]. Basically, the same situation.
>
> I performed the following steps:
>
> - Sync to the latest jethro revision
> - Delete tmp directory
> - Rebuild SD image
> - Rebuild SDK installer (bitbake my-image -c populate_sdk). 'my-image' inherit populate_sdk_qt5
>
> Some days ago, the remote debugging was working without problem.
>
> There is a current issue related with this? Any advices or suggestion?
>
> Thanks for your help,
>
> Julio
>
> [1] SIGSEGV during remote debug: [dl-debug.c] Line 55: if (r->r_map == NULL || ldbase != 0)

So it worked before you upgraded to latest jethro? Maybe you can roll
back and/or check the changelog (git log x..y) for the code you just
pulled in?

Also, isn't there a lot of state in build/ beyond build/tmp/ that can
trip up a build? To be really clean, I'd go for full "rm -rf build/".
I'm kind of paranoid about those things :-)

Btw, I'm currently on Yocto jethro branches from mid february, not the
very latest. So maybe there is a real bug in latest jethro...

Best regards,
Bjørn Forsman

Re: image-prelink (can) cause SIGSEGV on program startup (when run under GDB)

[Julio Cruz Barroso]

Hi Bjørn,

Thanks for your suggestion. 

That was working before. I perform many changes in my image, kernel and update to latest jethro. Not really sure where is the difference.

I will try as below:

1. Full remove of build
2. Go back in jethro and check changes

I let you know the results later.

If you have any chance to test the latest jethro will be appreciated.

Regards

Julio

On Mar 19, 2016, at 8:12 PM, Bjørn Forsman <bjorn.forsman@gmail.com> wrote:

Hi Julio,

> On 19 March 2016 at 12:40, Julio Cruz Barroso <julio.cruz@smartmatic.com> wrote:
> Hi Bjørn, Christian,
> 
> I'm trying to perform a remote debug with a Qt Application (as you described below).
> 
> The GDB (at QT Creator) show a Segmentation Fault at dl-debug.c [1]. Basically, the same situation.
> 
> I performed the following steps:
> 
> - Sync to the latest jethro revision
> - Delete tmp directory
> - Rebuild SD image
> - Rebuild SDK installer (bitbake my-image -c populate_sdk). 'my-image' inherit populate_sdk_qt5
> 
> Some days ago, the remote debugging was working without problem.
> 
> There is a current issue related with this? Any advices or suggestion?
> 
> Thanks for your help,
> 
> Julio
> 
> [1] SIGSEGV during remote debug: [dl-debug.c] Line 55: if (r->r_map == NULL || ldbase != 0)

So it worked before you upgraded to latest jethro? Maybe you can roll
back and/or check the changelog (git log x..y) for the code you just
pulled in?

Also, isn't there a lot of state in build/ beyond build/tmp/ that can
trip up a build? To be really clean, I'd go for full "rm -rf build/".
I'm kind of paranoid about those things :-)

Btw, I'm currently on Yocto jethro branches from mid february, not the
very latest. So maybe there is a real bug in latest jethro...

Best regards,
Bjørn Forsman

Re: image-prelink (can) cause SIGSEGV on program startup (when run under GDB)

[Julio Cruz Barroso]

Hi,

About the SIGSEGV, it's seem the problem come when I included a library in the image. The library is included in "packagegroup-qt5-toolchain-target.bbappend"

RDEPENDS_${PN} += " \
    libiio-dev \
"

This could be the right way?

Regards

Julio

-----Original Message-----
From: Julio Cruz Barroso 
Sent: Saturday, March 19, 2016 8:23 PM
To: Bjørn Forsman
Cc: Christian Ege; meta-freescale
Subject: Re: [meta-freescale] image-prelink (can) cause SIGSEGV on program startup (when run under GDB)

Hi Bjørn,

Thanks for your suggestion. 

That was working before. I perform many changes in my image, kernel and update to latest jethro. Not really sure where is the difference.

I will try as below:

1. Full remove of build
2. Go back in jethro and check changes

I let you know the results later.

If you have any chance to test the latest jethro will be appreciated.

Regards

Julio

On Mar 19, 2016, at 8:12 PM, Bjørn Forsman <bjorn.forsman@gmail.com> wrote:

Hi Julio,

> On 19 March 2016 at 12:40, Julio Cruz Barroso <julio.cruz@smartmatic.com> wrote:
> Hi Bjørn, Christian,
> 
> I'm trying to perform a remote debug with a Qt Application (as you described below).
> 
> The GDB (at QT Creator) show a Segmentation Fault at dl-debug.c [1]. Basically, the same situation.
> 
> I performed the following steps:
> 
> - Sync to the latest jethro revision
> - Delete tmp directory
> - Rebuild SD image
> - Rebuild SDK installer (bitbake my-image -c populate_sdk). 'my-image' 
> inherit populate_sdk_qt5
> 
> Some days ago, the remote debugging was working without problem.
> 
> There is a current issue related with this? Any advices or suggestion?
> 
> Thanks for your help,
> 
> Julio
> 
> [1] SIGSEGV during remote debug: [dl-debug.c] Line 55: if (r->r_map == 
> NULL || ldbase != 0)

So it worked before you upgraded to latest jethro? Maybe you can roll back and/or check the changelog (git log x..y) for the code you just pulled in?

Also, isn't there a lot of state in build/ beyond build/tmp/ that can trip up a build? To be really clean, I'd go for full "rm -rf build/".
I'm kind of paranoid about those things :-)

Btw, I'm currently on Yocto jethro branches from mid february, not the very latest. So maybe there is a real bug in latest jethro...

Best regards,
Bjørn Forsman

Re: image-prelink (can) cause SIGSEGV on program startup (when run under GDB)

[Julio Cruz Barroso]

Hi again,

The root cause of the SIGSEGV was a bad smart pointer in one application. After fixed it, the segmentation is gone.

However, another signal was received (and maybe others already received it) when trying to debug (GDB) something linked with openssl. 

According with [1], "OpenSSL adapts to processor it executes on and for this reason has to query its capabilities. Unfortunately on some processors the only way to achieve this for non-privileged code is to attempt instructions that can cause Illegal Instruction exceptions".

This generate a SIGILL when your application is linked with openssl (libcrypto.so). You could omit this and continue debugging or set an environmental variable (export OPENSSL_armcap=0).

To avoid this signal every time (during debugging) a variable is setup (in profile.d) with a "gdb_%.bbappend" similar to tslib.bb [2]. In this way, the variable is exported when GDB is installed (for the debug image) and is not set when the production image is created.

There is a better approach?

Thanks

Julio

[1] https://www.openssl.org/docs/faq.html#PROG17
[2] http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-graphics/tslib/tslib_1.0.bb?id=cdf878387ad460f7c6b7a58dcc996918bcd07a0a


 
-----Original Message-----
From: Julio Cruz Barroso 
Sent: Monday, March 21, 2016 3:08 PM
To: Bjørn Forsman
Cc: Christian Ege; meta-freescale
Subject: RE: [meta-freescale] image-prelink (can) cause SIGSEGV on program startup (when run under GDB)

Hi,

About the SIGSEGV, it's seem the problem come when I included a library in the image. The library is included in "packagegroup-qt5-toolchain-target.bbappend"

RDEPENDS_${PN} += " \
    libiio-dev \
"

This could be the right way?

Regards

Julio

-----Original Message-----
From: Julio Cruz Barroso
Sent: Saturday, March 19, 2016 8:23 PM
To: Bjørn Forsman
Cc: Christian Ege; meta-freescale
Subject: Re: [meta-freescale] image-prelink (can) cause SIGSEGV on program startup (when run under GDB)

Hi Bjørn,

Thanks for your suggestion. 

That was working before. I perform many changes in my image, kernel and update to latest jethro. Not really sure where is the difference.

I will try as below:

1. Full remove of build
2. Go back in jethro and check changes

I let you know the results later.

If you have any chance to test the latest jethro will be appreciated.

Regards

Julio

On Mar 19, 2016, at 8:12 PM, Bjørn Forsman <bjorn.forsman@gmail.com> wrote:

Hi Julio,

> On 19 March 2016 at 12:40, Julio Cruz Barroso <julio.cruz@smartmatic.com> wrote:
> Hi Bjørn, Christian,
> 
> I'm trying to perform a remote debug with a Qt Application (as you described below).
> 
> The GDB (at QT Creator) show a Segmentation Fault at dl-debug.c [1]. Basically, the same situation.
> 
> I performed the following steps:
> 
> - Sync to the latest jethro revision
> - Delete tmp directory
> - Rebuild SD image
> - Rebuild SDK installer (bitbake my-image -c populate_sdk). 'my-image' 
> inherit populate_sdk_qt5
> 
> Some days ago, the remote debugging was working without problem.
> 
> There is a current issue related with this? Any advices or suggestion?
> 
> Thanks for your help,
> 
> Julio
> 
> [1] SIGSEGV during remote debug: [dl-debug.c] Line 55: if (r->r_map == 
> NULL || ldbase != 0)

So it worked before you upgraded to latest jethro? Maybe you can roll back and/or check the changelog (git log x..y) for the code you just pulled in?

Also, isn't there a lot of state in build/ beyond build/tmp/ that can trip up a build? To be really clean, I'd go for full "rm -rf build/".
I'm kind of paranoid about those things :-)

Btw, I'm currently on Yocto jethro branches from mid february, not the very latest. So maybe there is a real bug in latest jethro...

Best regards,
Bjørn Forsman

Re: image-prelink (can) cause SIGSEGV on program startup (when run under GDB)

[Julio Cruz Barroso]

[-- Attachment #1: Type: text/plain, Size: 2773 bytes --]

Hi Cody,

I suggest to evaluate your debugger with a simple project and add your code gradually.

In my case, after isolating all the code, I found that the root cause was a bad definition of QSharePointer.

If you find with the same root cause, you could refer to the source code at https://github.com/jcsistemas2001/testQtPointer. A detailed description about this issue at https://forum.qt.io/topic/65422/qsharedpointer-qregistermetatype-gdb-and-slots/4

Regards

Julio

From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-bounces@yoctoproject.org] On Behalf Of Cody Tudor
Sent: Saturday, March 26, 2016 6:31 AM
To: meta-freescale@yoctoproject.org
Subject: [meta-freescale] image-prelink (can) cause SIGSEGV on program startup (when run under GDB)

Hello Julio,

> The root cause of the SIGSEGV was a bad smart pointer in one application. After fixed it, the segmentation is gone.

What was the end solution? Was it in your application or somewhere else?


> On 19 March 2016 at 12:40, Julio Cruz Barroso <julio.cruz at smartmatic.com<https://lists.yoctoproject.org/listinfo/meta-freescale>> wrote:

> Hi Bjørn, Christian,

>

> I'm trying to perform a remote debug with a Qt Application (as you described below).

>

> The GDB (at QT Creator) show a Segmentation Fault at dl-debug.c [1]. Basically, the same situation.

>

> I performed the following steps:

>

> - Sync to the latest jethro revision

> - Delete tmp directory

> - Rebuild SD image

> - Rebuild SDK installer (bitbake my-image -c populate_sdk). 'my-image'

> inherit populate_sdk_qt5

We have run into the same issue when remotely debugging our Qt app on a Jethro device with Qt 5.5.1. Qt Creator receives SIGSEGV from the device and breaks at line 51 in dl-debug.c because the pointer ‘r’ for structure type _r_debug is not to a valid structure pointer (i.e. the device tries to de-reference the pointer r which is invalid). All of this happens before main() is ever reached.

I cannot for the life of me find where this breaks in our Jethro build. If I roll back to Fido everything is peachy. Trying jethro-next branches where appropriate did not help.

Any help you could provide would be greatly appreciated.


> However, another signal was received (and maybe others already received it) when trying to debug (GDB) something linked with openssl.

If you are debugging using Qt Creator your can add: 'handle SIGILL pass nostop noprint' without the single quotes to the Additional Startup Commands in the Tools->Options->Debugger->GDB. This will skip over the SIGILL sent at start from libcrypto.so. It will also skip over any other SIGILL received so it is quite a dirty solution.

Regards,

-Cody Tudor




[-- Attachment #2: Type: text/html, Size: 11262 bytes --]

image-prelink (can) cause SIGSEGV on program startup (when run under GDB)

[Cody Tudor]

[-- Attachment #1: Type: text/plain, Size: 1998 bytes --]

Hello Julio,

> The root cause of the SIGSEGV was a bad smart pointer in one application.
After fixed it, the segmentation is gone.

What was the end solution? Was it in your application or somewhere else?


>* On 19 March 2016 at 12:40, Julio Cruz Barroso <julio.cruz at smartmatic.com <https://lists.yoctoproject.org/listinfo/meta-freescale>> wrote:
*>* Hi Bjørn, Christian,
*> >* I'm trying to perform a remote debug with a Qt Application (as
you described below).
*> >* The GDB (at QT Creator) show a Segmentation Fault at dl-debug.c
[1]. Basically, the same situation.
*> >* I performed the following steps:
*> >* - Sync to the latest jethro revision
*>* - Delete tmp directory
*>* - Rebuild SD image
*>* - Rebuild SDK installer (bitbake my-image -c populate_sdk). 'my-image'
*>* inherit populate_sdk_qt5*


We have run into the same issue when remotely debugging our Qt app on a
Jethro device with Qt 5.5.1. Qt Creator receives SIGSEGV from the device
and breaks at line 51 in dl-debug.c because the pointer ‘r’ for structure
type _r_debug is not to a valid structure pointer (i.e. the device tries to
de-reference the pointer r which is invalid). All of this happens before
main() is ever reached.


I cannot for the life of me find where this breaks in our Jethro build. If
I roll back to Fido everything is peachy. Trying jethro-next branches where
appropriate did not help.


Any help you could provide would be greatly appreciated.


> However, another signal was received (and maybe others already received it) when trying to debug (GDB) something linked with openssl.


If you are debugging using Qt Creator your can add: 'handle SIGILL pass
nostop noprint' without the single quotes to the Additional Startup
Commands in the Tools->Options->Debugger->GDB. This will skip over the
SIGILL sent at start from libcrypto.so. It will also skip over any other
SIGILL received so it is quite a dirty solution.


Regards,


-Cody Tudor

[-- Attachment #2: Type: text/html, Size: 4656 bytes --]