Re: [oe-core] ld segfault cant figure it out

[j <vwyodapink@gmail.com>]

On 04/17/2012 02:16 PM, j wrote:
> On 04/17/2012 01:17 PM, j wrote:
>> On 04/17/2012 12:49 PM, j wrote:
>>> On 04/17/2012 12:34 PM, Mark Hatle wrote:
>>>> On 4/17/12 2:09 PM, j wrote:
>>>>> On 04/17/2012 09:13 AM, J. L. wrote:
>>>>>> <snip>
>>>>>>
>>>>>>
>>>>>> <http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel> 
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> I went for a build on the borrowed machine again but this time I 
>>>>> did not
>>>>> go into X just stayed in RL3. Then ran bitbake perl, on a clean build
>>>>> dir. It is just about to finish building a few steps away but where I
>>>>> normally get the segfaults, it has not spit those out. There are 
>>>>> no QA
>>>>> logs being generated either. So looks like it had/has something to do
>>>>> with running X, both systems are running nvidia graphics cards. The
>>>>> laptop has a new mobile one, borrowed an old one that is nouveau
>>>>> compatible. So both open and closed nvidia drivers were tried. But
>>>>> something when in the graphical environment is giving the segfault
>>>>> issues I have been seeing. I have not yet verified if killing X on 
>>>>> the
>>>>> laptop builds and eliminates the issues as well.
>>>>>
>>>>> Will post back once I have built the kernel on both machines with 
>>>>> no X
>>>>> running.
>>>>
>>>> There is a known issue w/ nvidia drivers, segfaulting and QEMU.  Is 
>>>> something in perl (or elsewhere) trying to run qemu to finish up a 
>>>> task?
>>>>
>>>> --Mark
>>> Not that I can tell, but that does not mean it is not (still 
>>> learning things), but possible one of threads is working on 
>>> something perl related when it happens and I am not seeing it or 
>>> realizing it. If you are willing to post the commands I could run to 
>>> check, I can post the results. But when I do just a bitbake -c 
>>> compile perl on a clean build dir all I would see was the segfault 
>>> in dmesg and the results in QA log. Nothing would show up on the 
>>> command line that was not in the QA log, after doing each step one 
>>> by one.
>>>
>>> But it must be related to this known issue with nvidia. Should be a 
>>> couple hours before both machines finish building the kernel and 
>>> perl, will post the results after. But looks promising for my laptop 
>>> so far as no segfaults yet. Borrowed machine is on to building the 
>>> kernel now and nothing posted yet.
>>>
>>> Thank you for your response very appreciated. I will also read more 
>>> about the issue you stated.
>>>
>>>
>> From what I am reading about this is its related to libgl. But on the 
>> machine I borrowed I used nouveau driver's which uses the libgl that 
>> is expected not the nvidia's supplied version. So maybe that is not 
>> fully it. But still all seems related to being in an X environment 
>> for me when building. Which is at least easy to work around.
>>
>> Will post if it segfaults again on either machine once they are done.
>
> My borrowed machine segfaulted while finishing building perl. So I 
> guess that had nothing to do with the segfault issues. I ended up with 
> the same qa.log output and same type of output on dmesg relating to 
> libc and ld again.
>
> Laptop no X on that segfaulted in the normal places
>
> Should I try installing Ubuntu 10.04 on the borrowed machine and 
> seeing if the OS works on that machine? I am still lost as nothing 
> seems to really be telling me what is segfaulting. The rest of the 
> logs basically look the same as the series I posted earlier.
>

Well finally caught what I think is the package the segfault kicks on 
expat. Though not sure what I should look for to be able to sort it out 
but will see where I get.

Though I still get the gcc and bash messages in the QA log. If anyone is 
willing to share some info on what or how I can figure out how to find 
what causes the segfault in the recipe or if I am even catching the 
correct one.

Thank you