I decided to merge this patch, hoping that you do not have any issue with the solution proposed. However, i would also hope that better solution from some of you will come in future.
On Wed, 2009-02-18 at 13:51 +0530, Subrata Modak wrote: > 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 The test would remain in LTP as the set/combination/scenarios/functionality it is testing still exists in kernel. The only problem is we do not know how best to fix this issue(s). Regards-- Subrata > > > 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 ------------------------------------------------------------------------------ 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
