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 <[email protected]> wrote: Hi Julio, > On 19 March 2016 at 12:40, Julio Cruz Barroso <[email protected]> > 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 -- _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
