Requesting your feedback on this test case scenario. As, i found you provided patch(s) to this test case in past, may be you all will be able to provide a better picture.
http://ltp.cvs.sourceforge.net/viewvc/ltp/ltp/testcases/kernel/mem/mtest06/shmat1.c, Regards-- Subrata On Wed, 2009-02-11 at 17:25 +0530, Sharyathi Nagesh wrote: > Description: > Shmat1.c(testcases/kernel/mem/mtest06) is a test case which tries > to > create 3 threads during its execution. One thread allocates shared > memory, second writes to the shared memory and the third reads from > the > shared memory. All the 3 threads are synchronized using a global > variable. In case of signal (sigsegv) sighandler will be called. The > current test case implementation is complete only for x86 arc and is > not > valid for other archs. > We have noticed various issues while executing this test case. > Test > case issues can be summarized as > 1. signals are masked once the signal handler is called > 2. comparison signal_context->edi == map address is dubious > leading to test case failures under x86 architecture > > Solution: > Issue 1: > This is due to calling siglongjmp() with in the signal handler. > Once > the signal handler is called all the signals will be masked. It wont > be > set back to the original value unless sigsetjmp() is called with a > non > zero second parameter. This was not happening earlier leading to > segmentation faults while executing the tests. > > Issue 2: In the x86 architecture source and destination index with in > the ES or DS segments are stored in esi and edi registers. While the > shared memory address is being written to edi will have the > map_address, > returned by shmget, while when the data is read from map_address: > will > be contained in esi register. So it is inappropriate to just compare > map_address to edi register. > > > Even after fixing these 2 issues I still see the test case failing > some > time with messages like: process exited with errors -1 etc > I wanted to know whether we should keep this test case in LTP suite > or > if there is a better way to fix the issues? > Whether comparing signal_context->edi (or esi) == map_address is it > the > right thing to do? > Attaching the patch to fix the issue > Thanks > Yeehaw > > > > > > > > > > text/x-diff > attachment > (shmat1_diff.patch) > > --- shmat1_orig.c 2009-02-11 05:18:25.000000000 -0600 > +++ shmat1.c 2009-02-11 05:48:41.000000000 -0600 > @@ -179,11 +179,19 @@ sig_handler(int signal, /* signal > numbe > "page fault at [%#lx] - ignore\n", scp->edi); > siglongjmp(jmpbuf, 1); > } > + else if (scp->esi == (int)map_address ) > + { > + fprintf(stdout, > + "page fault at [%#lx] - ignore\n", scp->esi); > + siglongjmp(jmpbuf, 1); > + } > else > { > - fprintf(stderr, "address at which sigfault occured: [% > #lx]\n" > - "address at which memory was shmat: [% > p]\n", > - scp->edi, map_address); > + fprintf(stderr, "address at which sigfault occured: [% > lx]\n" > + "address at which sigfault occured: [% > lx]\n" > + "address at which memory was shmat: [% > p]\n", > + (unsigned long)scp->edi,(unsigned long) > scp->esi, > + map_address); > fprintf(stderr, "bad page fault exit test\n"); > exit (-1); > } > @@ -362,7 +370,7 @@ write_to_mem(void *args) > while(!done_shmat) > usleep(0); > > - if (sigsetjmp(jmpbuf,0) == 1) > + if (sigsetjmp(jmpbuf,1) == 1) > { > fprintf(stdout, > "page fault ocurred due a write after an shmdt from > [%p]\n", > @@ -408,7 +416,7 @@ read_from_mem(void *args) > fprintf(stdout, > "%s[%#lx]: read_from_mem(): memory address: [%p]\n", > STR_READER, pthread_self(), map_address); > - if (sigsetjmp(jmpbuf,0) == 1) > + if (sigsetjmp(jmpbuf,1) == 1) > { > fprintf(stdout, > "page fault ocurred due a read after an shmdt from %p > \n", > ------------------------------------------------------------------------------ _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
