Fwd: ARM FCSE - random programs segfaults

Martix martix.cz at gmail.com
Sat Apr 10 15:12:42 CEST 2010

---------- Forwarded message ----------
From: Gilles Chanteperdrix <gilles.chanteperdrix at xenomai.org>
Date: 2010/4/10
Subject: Re: ARM FCSE - random programs segfaults
To: Martix <martix.cz at gmail.com>

Gilles Chanteperdrix wrote:
> Martix wrote:
>>> Your processor seems as fine as mine with regard to LTP. I have one last
>>> trick to try (will send a patch tomorrow), and after that, we will have
>>> to really try and debug the issue (but it will be hard). Does the
>>> segfaulting application require some specific hardware, or can I run it
>>> on any hardware?
>> SHR-settings sources are here: http://git.shr-project.org/repo/shr-settings.git
>> It is python application, it depends on FSO (Freesmartphone.org)
>> framework and Elementary toolkit.
>> Segfaults are reproducible also with others applications.
>> I found simplest way to reproduce:
>> run Python 2.6.4
>>>>> import elementary
>>>>> import dbus
>> Segmentation fault
> Ok. Got the segfault, thanks for the simplistic test case. It happens
> with FCSE in "best effort" mode, but not in "guaranteed" mode, that is
> weird. Starting the debug now.

Found the bug. The problem is that this script maps so many libraries,
that its mappings prevent the stack from expanding, so what you get is
basically a stack overflow. What we can do is enforce the maximum size
for the stack space in the address space given by ulimit, but it means
that if you do not want most of your processes to be larger than 32MB,
you will have to control precisely stack sizes with ulimit -s.

Here a kernel trace added to debug the segmentation fault. You can see
that the stack pointer register (sp) is well below the stack limit.



More information about the openmoko-kernel mailing list