All of lore.kernel.org
 help / color / mirror / Atom feed
* [LTP] mtest06 failures
       [not found] <214042481.9356038.1428054865150.JavaMail.zimbra@redhat.com>
@ 2015-04-03 10:04 ` Jan Stancek
  2015-04-07 13:15   ` Cyril Hrubis
  0 siblings, 1 reply; 2+ messages in thread
From: Jan Stancek @ 2015-04-03 10:04 UTC (permalink / raw)
  To: ltp-list

Hi,

I'm seeing mtest06 occasionally failing:

<<<test_start>>>
tag=mtest06 stime=1427900338
cmdline="  mmap1 -x 0.05"
contacts=""
analysis=exit
<<<test_output>>>
mmap1       0  TINFO  :  created writing thread[70366651085264]
mmap1       0  TINFO  :  [70366651085264] - map, change contents, unmap files 1000 times
mmap1       0  TINFO  :  created reading thread[70366642696656]
mmap1       0  TINFO  :  [70366642696656] - read contents of memory (nil) 1000 times
mmap1       1  TFAIL  :  mmap1.c:400: thread [70366642696656] - process exited with -1
<<<execution_status>>>
initiation_status="ok"
duration=1 termination_type=exited termination_id=1 corefile=no
cutime=23 cstime=46
<<<test_end>>>

ret code -1 indicates, that it hit:
    if (map_address[j] != 'a')
        pthread_exit((void *)-1);

I think what happens is that map_write_unmap() unmaps the memory,
and something else mmaps into the same location. gdb breakpoints on
mmap found couple places which could be responsible, pthread_exit()
was one of them.

2 ideas came to mind:
1. clear map_address after munmap
   This however seems to go against what the testcase is trying to do
2. make sure mmap for map_address happens in place which is less likely
   to be used in future mmaps

diff --git a/testcases/kernel/mem/mtest06/mmap1.c b/testcases/kernel/mem/mtest06/mmap1.c
index 5f13d48..2e9883c 100644
--- a/testcases/kernel/mem/mtest06/mmap1.c
+++ b/testcases/kernel/mem/mtest06/mmap1.c
@@ -64,6 +64,7 @@ static int verbose_print = 0;
 static char *volatile map_address;
 static jmp_buf jmpbuf;
 static volatile char read_lock = 0;
+static void *mmap_area;
 
 char *TCID = "mmap1";
 int TST_TOTAL = 1;
@@ -146,7 +147,7 @@ void *map_write_unmap(void *ptr)
 
        for (i = 0; i < args[2]; i++) {
 
-               map_address = mmap(0, (size_t) args[1], PROT_WRITE | PROT_READ,
+               map_address = mmap(mmap_area, (size_t) args[1], PROT_WRITE | PROT_READ,
                                   MAP_SHARED, (int)args[0], 0);
 
                if (map_address == (void *)-1) {
@@ -337,6 +338,13 @@ int main(int argc, char **argv)
                }
        }
 
+       mmap_area = mmap(0, 64*1024*1024, PROT_WRITE | PROT_READ, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
+       if (mmap_area == (void *)-1)
+               perror("mmap_area: mmap()");
+       if (munmap(mmap_area, (size_t) 64*1024*1024) == -1)
+               perror("mmap_area: munmap()");
+       mmap_area += 32*1024*1024;
+
        if (verbose_print)
                tst_resm(TINFO, "Input parameters are: File size:  %d; "
                         "Scheduled to run:  %lf hours; "

I tested option 2 and it seems to have fixed the failure for me.
Any thoughts or comments? Is anyone else seeing failures from mtest06?

Regards,
Jan

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [LTP] mtest06 failures
  2015-04-03 10:04 ` [LTP] mtest06 failures Jan Stancek
@ 2015-04-07 13:15   ` Cyril Hrubis
  0 siblings, 0 replies; 2+ messages in thread
From: Cyril Hrubis @ 2015-04-07 13:15 UTC (permalink / raw)
  To: Jan Stancek; +Cc: ltp-list

Hi!
> <<<test_start>>>
> tag=mtest06 stime=1427900338
> cmdline="  mmap1 -x 0.05"
> contacts=""
> analysis=exit
> <<<test_output>>>
> mmap1       0  TINFO  :  created writing thread[70366651085264]
> mmap1       0  TINFO  :  [70366651085264] - map, change contents, unmap files 1000 times
> mmap1       0  TINFO  :  created reading thread[70366642696656]
> mmap1       0  TINFO  :  [70366642696656] - read contents of memory (nil) 1000 times
> mmap1       1  TFAIL  :  mmap1.c:400: thread [70366642696656] - process exited with -1
> <<<execution_status>>>
> initiation_status="ok"
> duration=1 termination_type=exited termination_id=1 corefile=no
> cutime=23 cstime=46
> <<<test_end>>>
> 
> ret code -1 indicates, that it hit:
>     if (map_address[j] != 'a')
>         pthread_exit((void *)-1);
> 
> I think what happens is that map_write_unmap() unmaps the memory,
> and something else mmaps into the same location. gdb breakpoints on
> mmap found couple places which could be responsible, pthread_exit()
> was one of them.
> 
> 2 ideas came to mind:
> 1. clear map_address after munmap
>    This however seems to go against what the testcase is trying to do
> 2. make sure mmap for map_address happens in place which is less likely
>    to be used in future mmaps

I do not recall mtest06 failing this way, but it's quite possible that
something from libc will trigger mmap() to allocate memory.

The patch looks good to me.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2015-04-07 13:16 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <214042481.9356038.1428054865150.JavaMail.zimbra@redhat.com>
2015-04-03 10:04 ` [LTP] mtest06 failures Jan Stancek
2015-04-07 13:15   ` Cyril Hrubis

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.