[ORLinux] Unaligned access exception in Linux 2.6.39 kernel

[Jonas Bonn]

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...?

> 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...

> 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.

/Jonas