Hi, On Thu, 2009-02-12 at 21:46 +0530, Subrata Modak wrote: > 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.
Could you kindly prefer to provide some feedback on the test case changes ? Regards-- Subrata > > 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 ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
