public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Suzuki Poulose <suzuki@in.ibm.com>
To: renxiu liang <renxiu.liang@windriver.com>
Cc: ltp-list@lists.sourceforge.net
Subject: Re: [LTP] [Patch] Fix mtest06 failure: caught unexpected signal - 11 --- exiting
Date: Sun, 19 Sep 2010 12:47:24 +0530	[thread overview]
Message-ID: <4C95B904.3070404@in.ibm.com> (raw)
In-Reply-To: <4C95B7D9.5060801@in.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 4292 bytes --]

Here is a patch which I had, sometime back. It is on an older version of 
LTP.

Cheers

Suzuki


, Suzuki Poulose wrote:
> , renxiu liang wrote:
>> On Sun, 2010-09-19 at 12:06 +0530, Suzuki Poulose wrote:
>>> Hello Renxiu,
>>>
>>> Sorry for the late reply. Could you please resend the patch ? I don't
>>> find the patch in the e-mail.
>>>
>> Hi Suzuki
>>
>> attached failure logs on different archs and patch for you.
>
> I don't understand why there should be ACCERR. The mmap is done with
> PROT_WRIT|PROT_READ. Could we get more info on which condition triggers
> this ?
>
> You may use GDB to break for the ACCERR case and take a look at the
> instruction which triggers this.
>
> Coming back to your patch :
>
> I think we should ensure the si_addr is within the map. (map_address,
> map_address+mapsize-1) ? We should not let the other SIGSEGVs go through.
>
> It may be like :
>
> case SIGSEGV:
> if ((si_addr >= map_address) &&
> (si_addr < (map_address + map_size) ) {
> ...
> ..
> }
>
>
> Thanks
>
> Suzuki
>
>
>
>
>>
>> thanks for help review this.
>>
>> BR
>> Renxiu
>>> Thanks
>>>
>>> Suzuki
>>> , renxiu liang wrote:
>>>> On Wed, 2010-09-01 at 00:27 -0700, Garrett Cooper wrote:
>>>>> On Wed, Sep 1, 2010 at 12:26 AM, Garrett Cooper<yanegomi@gmail.com>
>>>>> wrote:
>>>>>> On Mon, Aug 30, 2010 at 6:51 PM, renxiu liang
>>>>>> <renxiu.liang@windriver.com> wrote:
>>>>>>> On Wed, 2010-08-25 at 20:36 -0700, Garrett Cooper wrote:
>>>>>>>> On Wed, Aug 18, 2010 at 12:33 AM, renxiu liang
>>>>>>>> <renxiu.liang@windriver.com> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> We met the mtest06 failure several times; this is because in
>>>>>>>>> mtest06/mmap1.c, when handling the signal 11 in sig_handler, it
>>>>>>>>> doesn't
>>>>>>>>> cover another two race conditions:
>>>>>>>>> one is si_code equals "SEGV_MAPERR" but si_address does not
>>>>>>>>> equal to
>>>>>>>>> map_address; and one is si_code equals to "SEGV_ACCERR";
>>>>>>>>>
>>>>>>>>> see below error log:
>>>>>>>>>
>>>>>>>>> <<<test_start>>>
>>>>>>>>> tag=mtest06 stime=1270902396
>>>>>>>>> cmdline=" mmap1 -x 0.05"
>>>>>>>>> contacts=""
>>>>>>>>> analysis=exit
>>>>>>>>> initiation_status="ok"
>>>>>>>>> <<<test_output>>>
>>>>>>>>> mmap1 0 INFO : pid[5456]: map, change contents, unmap files
>>>>>>>>> 1000 times
>>>>>>>>> mmap1 0 INFO : created thread[1216369840]
>>>>>>>>> mmap1 0 INFO : pid[5456] - read contents of memory 0x48002000
>>>>>>>>> 1000 times
>>>>>>>>> mmap1 0 INFO : page fault occurred at 0x48002000
>>>>>>>>> mmap1 0 INFO : page fault occurred at 0x48002000
>>>>>>>>> mmap1 0 INFO : page fault occurred at 0x48002000
>>>>>>>>> mmap1 0 INFO : page fault occurred at 0x48002000
>>>>>>>>> ......
>>>>>>>>> mmap1 0 INFO : page fault occurred at 0x48002000
>>>>>>>>> mmap1 0 INFO : page fault occurred at 0x48002000
>>>>>>>>> caught unexpected signal - 11 --- exiting
>>>>>>>>> <<<execution_status>>>
>>>>>>>>> duration=1 termination_type=exited termination_id=255 corefile=no
>>>>>>>>> cutime=0 cstime=4
>>>>>>>>> <<<test_end>>>
>>>>>>>>>
>>>>>>>>> I made a patch to cover all the three race conditions in one
>>>>>>>>> case in
>>>>>>>>> sig_handler(),
>>>>>>>>> then run mtest06 repeatedly on different archs, test will not
>>>>>>>>> fail by
>>>>>>>>> catching signal 11.
>>>>>>>>
>>>>>>>> Could you print out what the value of info->si_code and
>>>>>>>> info->si_addr
>>>>>>>> are at the time of the fault? Also, which architecture(s) are you
>>>>>>>> running into this issue on?
>>>>>>> Hi Garrett,
>>>>>>>
>>>>>>> Sorry for the late reply; See attached mtest06 logs, I printed
>>>>>>> out the
>>>>>>> values of si_code, si_addr, map_address;
>>>>>>> it is reproducible on arm, x86, ppc and mips; though it is not
>>>>>>> reproducible every time, but can be reproducible if run the case
>>>>>>> repeatedly.
>>>>>>
>>>>>> Nothing is jumping out at me as being incorrect, so I think it's best
>>>>>> that I bring in a better pair of eyes, just in case.
>>>>>>
>>>>>> Suzuki-san,
>>>>>> Could you please help review this patch?
>>>>>
>>>> Hi Garrett,
>>>> No reply from Suzuki-san after almost three weeks; I'm afraid
>>>> Suzuki-san
>>>> didn't catch the mail, could you find someone else to review the patch?
>>>> thanks!
>>>>
>>>> BR,
>>>> Renxiu
>>>>
>>>>> CCing Suzuki-san...
>>>>> -Garrett
>>>>
>>>
>>
>


[-- Attachment #2: mtest06-mmap1.diff --]
[-- Type: text/plain, Size: 1818 bytes --]

diff -Naur ltp-full-20091231.orig/testcases/kernel/mem/mtest06/mmap1.c ltp-full-20091231/testcases/kernel/mem/mtest06/mmap1.c
--- ltp-full-20091231.orig/testcases/kernel/mem/mtest06/mmap1.c	2009-10-13 19:30:46.000000000 +0530
+++ ltp-full-20091231/testcases/kernel/mem/mtest06/mmap1.c	2010-03-15 16:30:33.000000000 +0530
@@ -138,6 +138,7 @@
 int 	   verbose_print = FALSE;/* when called with -v print more info       */
 caddr_t    *map_address;	/* address of the file mapped.	              */
 sigjmp_buf jmpbuf;		/* argument to sigsetjmp and siglongjmp       */
+long	   map_len;
 
 char *TCID = "mmap1";
 int TST_TOTAL = 1;
@@ -168,14 +169,22 @@
              _exit(0);
 
         case SIGSEGV:
-             if (info->si_code == SEGV_MAPERR &&
-                      info->si_addr == map_address)
+             if ( info->si_addr == map_address ||
+		 (map_address && (info->si_addr >= (void*) map_address &&
+				 info->si_addr < (void *)((long)map_address + map_len))
+		  )
+		)
              {
                   tst_resm(TINFO,
                     "page fault occurred at %p",
                     map_address);
                   longjmp(jmpbuf, 1);
-             }
+             } else {
+            	  fprintf(stderr, "caught SIGSEGV at %p while mmap is (%p,%p) -  exiting\n",
+				info->si_addr, map_address, (void*)((long)map_address + map_len));
+		  _exit(-1);
+	     }
+		
         default:
             fprintf(stderr, "caught unexpected signal - %d --- exiting\n",
                      signal);
@@ -293,6 +302,9 @@
 		       (long *)args;
     long exit_val = 0;  /* exit value of the pthread		      */
 
+    /* The size of the map */
+    map_len = mwuargs[1];
+
     tst_resm(TINFO, "pid[%d]: map, change contents, unmap files %d times",
 		getpid(), (int)mwuargs[2]);
     if (verbose_print)

[-- Attachment #3: Type: text/plain, Size: 276 bytes --]

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev

[-- Attachment #4: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

  parent reply	other threads:[~2010-09-19  7:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-18  7:33 [LTP] [Patch] Fix mtest06 failure: caught unexpected signal - 11 --- exiting renxiu liang
2010-08-18  8:35 ` Garrett Cooper
2010-08-26  3:36 ` Garrett Cooper
2010-08-31  1:51   ` renxiu liang
2010-09-01  7:26     ` Garrett Cooper
2010-09-01  7:27       ` Garrett Cooper
     [not found]         ` <1284874992.12271.5.camel@PEK-RLIANG-D1>
     [not found]           ` <4C95AF8A.8000803@in.ibm.com>
     [not found]             ` <1284878205.12271.9.camel@PEK-RLIANG-D1>
     [not found]               ` <4C95B7D9.5060801@in.ibm.com>
2010-09-19  7:17                 ` Suzuki Poulose [this message]
2010-09-25  3:43                   ` renxiu liang
  -- strict thread matches above, loose matches on Subject: below --
2010-09-06 16:16 Subrata Modak
     [not found] <52CF90264091A14888078A031D780F4305936FA4@ism-mail03.corp.ad.wrs.com>
2010-08-17  5:57 ` Liang, RenXiu
2010-09-06 16:17   ` Subrata Modak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C95B904.3070404@in.ibm.com \
    --to=suzuki@in.ibm.com \
    --cc=ltp-list@lists.sourceforge.net \
    --cc=renxiu.liang@windriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox