[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ltp-list
Subject:    Re: [LTP] Failing kernel/mem/mtest07/mallocstress (was: Re: [PATCH]
From:       Daniel Gollub <dgollub () suse ! de>
Date:       2008-10-24 13:32:09
Message-ID: 200810241532.09624.dgollub () suse ! de
[Download RAW message or body]

On Friday 24 October 2008 15:15:54 Jiří Paleček wrote:
> On Fri, 24 Oct 2008 14:16:29 +0200, Daniel Gollub <dgollub@suse.de> wrote:
> 
> > I'm looking right now also into the mallocstress testcase.
> > With more recent kernel I experience (e.g. 2.6.27) failing mallocstress  
> > on
> > x86_64. (Didn't tested different architectures yet).
> >
> > On which kernel did you test mallocstress?
> > 2.6.27? Or something different?
> 
> 2.6.27-rc8, i386. However, I didn't notice until you asked, that when I  
> tested the patch, the test actually succeeded, which is very weird.  
> Before, I got a message "malloc: Cannot allocate memory". I have a theory,  
> that it is caused by swapping of the semop() and malloc() calls (see the  
> patch). That means before, a thread first waited on the semaphore, and  
> when it got released, other threads might have been already stressing the  
> memory, so there wasn't any free and malloc() of the return variable would  
> fail. If that is really the case, the patch doesn't fix it, only lowers  
> the probablity of such behaviour. However, making a proper patch should be  
> easy in that case.

On x86_64 i get slightly different problem:

x86_64:~/:[1]# ulimit -c unlimited
x86_64:~/:[0]# ./mallocstress 
Aborted (core dumped)
x86_64:~/:[134]# uname -i
x86_64
x86_64:~/:[0]# uname -r
2.6.27.1-2-default
x86_64:~/:[0]# gdb mallocstress core.5217 
[[[[[ .. snipped the default amount of threads .... ]]]]]]
[New Thread 5221]
Core was generated by `./mallocstress'.
Program terminated with signal 6, Aborted.
#0  0x00007f641d5f4725 in *__GI_raise (sig=<value optimized out>)
   from /lib64/libc.so.6
(gdb) bt
#0  0x00007f641d5f4725 in *__GI_raise (sig=<value optimized out>)
   from /lib64/libc.so.6
#1  0x00007f641d5f5d13 in *__GI_abort () from /lib64/libc.so.6
#2  0x00007f641d6380b0 in malloc_printerr (action=2, 
    str=0x7f641d6e501b "free(): invalid pointer", ptr=0x1461)
   from /lib64/libc.so.6
#3  0x0000000000400e48 in allocate_free (repeat=100, scheme=0)
    at mallocstress.c:233
#4  0x0000000000400f4e in alloc_mem (threadnum=0x7fff25d57fb4)
    at mallocstress.c:281
#5  0x00007f641d925070 in start_thread (arg=<value optimized out>)
   from /lib64/libpthread.so.0
#6  0x00007f641d697a7d in clone () from /lib64/libc.so.6
#7  0x0000000000000000 in ?? ()
(gdb) 

The error is the same with or without your patch (applied in this backtrace).
I see this also on various vanilla kernels on x86_64 - started bisecting.
Will give it a try on i386 as well - thanks for the info.

best regards,
Daniel

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

[prev in list] [next in list] [prev in thread] [next in thread]