[ORLinux] Unaligned access exception in Linux 2.6.39 kernel

[Jeremy Bennett]

On Wed, 2011-06-01 at 16:19 +0300, Jonas Bonn wrote: 
> On Wed, 2011-06-01 at 12:12 +0100, Jeremy Bennett wrote:
> > I've now updated uClibc library, and this test is failing with a SEGV. I
> > didn't see any reference to oom-kill however. My output was
> > 
> 
> With 128 MB memory I'm not seeing the OOM reaper anymore either.
> 
> >         Mismatch: data4 = "", res = -98
> >         Mismatch: data4 = "", res = -98
> >         Mismatch: data4 = "", res = -98
> >         Mismatch: data4 = "", res = -98
> >         Mismatch: data4 = "", res = -98
> >         Mismatch: data4 = "", res = -98
> >         Mismatch: data4 = "", res = -98
> >         Mismatch: data4 = "", res = -98
> >         Segmentation fault
> >         /home # 
> > 
> > The mismatches are the error this test was originally designed for. They
> > are a global variable (of class __gnu_cxx::rope<char,
> > std::allocator<char> >) which is being set before the threads are
> > created and is not being correctly picked up by the threads.
> 
> Is this an expected failure?  Or does this indicate a threading
> issue...?

It is not an expected failure. It is based on one of the libstdc++-v3
tests of pthread (the only one which currently fails). This problem
originally started, because I was trying to track down the cause of this
last regression failure.

> > I'll investigate further. gdbserver should be able to show where the
> > SEGV is occurring. I'll also see if I can generate the error with a
> > simpler class than the GNU rope class.
> 
> Did you see my earlier post?  The SEGV is the result of an inability to
> expand the stack due to a resource limit set by the kernel... for some
> reason, the maximum stack size is 0x1fc000 bytes, for some reason this
> is being exceeded, and for some reason ulimit doesn't bite...

Yes - I have now seen this.

> > The original test I took this from had a comment regarding a memory leak
> > in the rope class, so this could be the reason for others running out of
> > memory (I'm running with 128MB).
> 
> OK, the memory leak is definitely worth investigating to try to figure
> out if it's user space or kernel leaking... the odd thing is that the
> memory does not seem to get freed when the process is killed which would
> seem to indicate a kernel leak.  Any indication from your side would be
> appreciated though.

I'm still investigating. More news when I have it.

-- 
Tel:      +44 (1590) 610184
Cell:     +44 (7970) 676050
SkypeID: jeremybennett
Email:   jeremy.bennett at embecosm.com
Web:     www.embecosm.com