mtest06 failures

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

index 5f13d48..2e9883c 100644
@@ -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
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

Hi!

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
[email protected]

------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list