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
next prev 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