Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1385567 > unrolled thread

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64 - LTP results

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64 - LTP results "Zhangjian (Bamvor)" <bamvor.zhangjian@huawei.com> - 2016-04-23 05:40 +0200
    Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64 - LTP results Andrew Pinski <pinskia@gmail.com> - 2016-04-27 09:40 +0200
      Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64 - LTP results Andrew Pinski <pinskia@gmail.com> - 2016-04-27 23:20 +0200

#1385567 — Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64 - LTP results

[Multipart message — attachments visible in raw view] — view raw

Hi, Yury

On 2016/4/6 6:44, Yury Norov wrote:
> There are about 20 failing tests of 782 in lite scenario.
> float_bessel
> float_exp_log
> float_iperb
> float_power
> float_trigo
> pipeio_1
> pipeio_3
> pipeio_5
> pipeio_8
> abort01
> clone02
> kill11
> mmap16
> open12
> pause01
> rename11
> rmdir02
> umount2_01
> umount2_02
> umount2_03
> utime06
> mtest06
>
> The list is rough because some tests fail not every time.
>
> Tests abort01 and kill11 fail for lp64 too, so maybe there's
> a reason unrelated to ilp32 itself.
>
> float_xxx tests fail because they call unwind() from signal context,
> and GCC for ilp32 has problem with it, as Andrew told.
Is there some progress about this issue. When we talk about unwind
functions, do you mean the function in libgcc?

We encountered another issue(abort not segfault) which also called
pthread_cancel(). The test code is in the attachment. Here is the
backtrace:

```
Program received signal SIGABRT, Aborted.
[Switching to Thread 0xf77ee330 (LWP 2958)]
0x000000000040f5bc in raise (sig=sig@entry=6)
     at ../sysdeps/unix/sysv/linux/raise.c:55
55      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x000000000040f5bc in raise (sig=sig@entry=6)
     at ../sysdeps/unix/sysv/linux/raise.c:55
#1  0x000000000040f884 in abort () at abort.c:89

#2  0x00000000004073b4 in uw_update_context_1 (
     context=context@entry=0xf77ec820, fs=fs@entry=0xf77ebec8)
at /home/GCC-Build/p660/p660_build_dir/src/gcc-4.9/libgcc/unwind-dw2.c:1430

#3  0x00000000004078c0 in uw_update_context (context=context@entry=0xf77ec820,
     fs=fs@entry=0xf77ebec8)
    at /home/GCC-Build/p660/p660_build_dir/src/gcc-4.9/libgcc/unwind-dw2.c:1506
#4  0x0000000000407a9c in uw_advance_context (fs=0xf77ebec8,
     context=0xf77ec820)
     at /home/GCC-Build/p660/p660_build_dir/src/gcc-4.9/libgcc/unwind-dw2.c:1529
#5  _Unwind_ForcedUnwind_Phase2 (exc=exc@entry=0xf77ee580,
     context=context@entry=0xf77ec820)
     at /home/GCC-Build/p660/p660_build_dir/src/gcc-4.9/libgcc/unwind.inc:185
#6  0x0000000000408228 in _Unwind_ForcedUnwind (exc=0xf77ee580,
     stop=stop@entry=0x405440 <unwind_stop>, stop_argument=0xf77eddd8)
     at /home/GCC-Build/p660/p660_build_dir/src/gcc-4.9/libgcc/unwind.inc:207
#7  0x00000000004055c4 in __pthread_unwind (buf=<optimized out>)
     at unwind.c:126
#8  0x00000000004050b4 in __do_cancel () at ./pthreadP.h:283
#9  sigcancel_handler (sig=<optimized out>, si=<optimized out>,
     ctx=<optimized out>) at nptl-init.c:225
---Type <return> to continue, or q <return> to quit---
#10 <signal handler called>

#11 0x0000000000000000 in ?? ()

#12 0x0000000000423084 in __select (nfds=-66661, readfds=<optimized out>,
     writefds=<optimized out>, exceptfds=<optimized out>, timeout=0x0)
     at ../sysdeps/unix/sysv/linux/generic/select.c:45
#13 0x0000000000400604 in TEST_TaskDelay (
     uiMillSecs=<error reading variable: can't compute CFA for this frame>)
     at test-cancel.c:18
#14 0x0000000000400680 in printids (
     s=<error reading variable: can't compute CFA for this frame>)
     at test-cancel.c:38
#15 0x00000000004006d0 in thr_fn (
     arg=<error reading variable: can't compute CFA for this frame>)
     at test-cancel.c:49
#16 0x0000000000401b28 in start_thread (arg=0x4a3000) at pthread_create.c:335
#17 0x0000000000401b28 in start_thread (arg=0x4a3000) at pthread_create.c:335
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
```

Such abort is raise by the following code:
```
static void
uw_update_context_1 (struct _Unwind_Context *context, _Unwind_FrameState *fs)
{
//...
   /* Compute this frame's CFA.  */
   switch (fs->regs.cfa_how)
     {
     case CFA_REG_OFFSET:
       cfa = _Unwind_GetPtr (&orig_context, fs->regs.cfa_reg);
       cfa += fs->regs.cfa_offset;
       break;

     case CFA_EXP:
       {
         const unsigned char *exp = fs->regs.cfa_exp;
         _uleb128_t len;

         exp = read_uleb128 (exp, &len);
         cfa = (void *) (_Unwind_Ptr)
           execute_stack_op (exp, exp + len, &orig_context, 0);
         break;
       }

     default:
       gcc_unreachable ();
     }
   context->cfa = cfa;
//...
}
``

Any suggestion is appreciated.

CC gcc mailing list. Sorry if it is off topic.

Regards

Bamvor



> pipeio_x tests are very unstable and may fail randomly. I strongly
> suspect race conditions, as they all work like a charm if pinned to
> single CPU with taskset. Probably, race is the reason of clone02 too.
> Though I'm not sure, is the race in kernel, glibc or test itself.
>
> But I know for sure that pause01 fails due to test design:
> 	if (setitimer(ITIMER_REAL, &it, NULL)) // For 1000us
> 		tst_brkm(TBROK | TERRNO, NULL, "setitimer() failed");
>
> 	TEST(pause());
>
> As setitimer() and pause() calls are not atomic, alarm may come before pause()
> is called, and be silently dropped by the handler. Next pause() call hangs
> test forever. I already reported to LTP list.
>
> open12, rename11, rmdir02, mmap16, mtest06 - all call mkfs tool, and it returns
> error code. I didn't investigate it much yet.
>
> umount02_x, utime06 - cannot reproduce out of scenario, even run it in infinite
> loop - they work fine.
>
> Full test log is attached.
>
> Yury
>

[toc] | [next] | [standalone]

#1388723

On Fri, Apr 22, 2016 at 8:37 PM, Zhangjian (Bamvor)
<bamvor.zhangjian@huawei.com> wrote:
> Hi, Yury
>
>
> On 2016/4/6 6:44, Yury Norov wrote:
>>
>> There are about 20 failing tests of 782 in lite scenario.
>> float_bessel
>> float_exp_log
>> float_iperb
>> float_power
>> float_trigo
>> pipeio_1
>> pipeio_3
>> pipeio_5
>> pipeio_8
>> abort01
>> clone02
>> kill11
>> mmap16
>> open12
>> pause01
>> rename11
>> rmdir02
>> umount2_01
>> umount2_02
>> umount2_03
>> utime06
>> mtest06
>>
>> The list is rough because some tests fail not every time.
>>
>> Tests abort01 and kill11 fail for lp64 too, so maybe there's
>> a reason unrelated to ilp32 itself.
>>
>> float_xxx tests fail because they call unwind() from signal context,
>> and GCC for ilp32 has problem with it, as Andrew told.
>
> Is there some progress about this issue. When we talk about unwind
> functions, do you mean the function in libgcc?
>
> We encountered another issue(abort not segfault) which also called
> pthread_cancel(). The test code is in the attachment. Here is the
> backtrace:

Yes this was a known issue I knew about.  I have a patch GCC to fix
this.  Basically REG_VALUE_IN_UNWIND_CONTEXT needs to be defined while
building libgcc to support the correct unwind information.
I will be posting a GCC patch to fix this tomorrow.  This was a bug
even in the original set of ilp32 patches.  I only finally was able to
sit down and fix it today.


Thanks,
Andrew

>
> ```
> Program received signal SIGABRT, Aborted.
> [Switching to Thread 0xf77ee330 (LWP 2958)]
> 0x000000000040f5bc in raise (sig=sig@entry=6)
>     at ../sysdeps/unix/sysv/linux/raise.c:55
> 55      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0  0x000000000040f5bc in raise (sig=sig@entry=6)
>     at ../sysdeps/unix/sysv/linux/raise.c:55
> #1  0x000000000040f884 in abort () at abort.c:89
>
> #2  0x00000000004073b4 in uw_update_context_1 (
>     context=context@entry=0xf77ec820, fs=fs@entry=0xf77ebec8)
> at /home/GCC-Build/p660/p660_build_dir/src/gcc-4.9/libgcc/unwind-dw2.c:1430
>
> #3  0x00000000004078c0 in uw_update_context
> (context=context@entry=0xf77ec820,
>     fs=fs@entry=0xf77ebec8)
>    at
> /home/GCC-Build/p660/p660_build_dir/src/gcc-4.9/libgcc/unwind-dw2.c:1506
> #4  0x0000000000407a9c in uw_advance_context (fs=0xf77ebec8,
>     context=0xf77ec820)
>     at
> /home/GCC-Build/p660/p660_build_dir/src/gcc-4.9/libgcc/unwind-dw2.c:1529
> #5  _Unwind_ForcedUnwind_Phase2 (exc=exc@entry=0xf77ee580,
>     context=context@entry=0xf77ec820)
>     at /home/GCC-Build/p660/p660_build_dir/src/gcc-4.9/libgcc/unwind.inc:185
> #6  0x0000000000408228 in _Unwind_ForcedUnwind (exc=0xf77ee580,
>     stop=stop@entry=0x405440 <unwind_stop>, stop_argument=0xf77eddd8)
>     at /home/GCC-Build/p660/p660_build_dir/src/gcc-4.9/libgcc/unwind.inc:207
> #7  0x00000000004055c4 in __pthread_unwind (buf=<optimized out>)
>     at unwind.c:126
> #8  0x00000000004050b4 in __do_cancel () at ./pthreadP.h:283
> #9  sigcancel_handler (sig=<optimized out>, si=<optimized out>,
>     ctx=<optimized out>) at nptl-init.c:225
> ---Type <return> to continue, or q <return> to quit---
> #10 <signal handler called>
>
> #11 0x0000000000000000 in ?? ()
>
> #12 0x0000000000423084 in __select (nfds=-66661, readfds=<optimized out>,
>     writefds=<optimized out>, exceptfds=<optimized out>, timeout=0x0)
>     at ../sysdeps/unix/sysv/linux/generic/select.c:45
> #13 0x0000000000400604 in TEST_TaskDelay (
>     uiMillSecs=<error reading variable: can't compute CFA for this frame>)
>     at test-cancel.c:18
> #14 0x0000000000400680 in printids (
>     s=<error reading variable: can't compute CFA for this frame>)
>     at test-cancel.c:38
> #15 0x00000000004006d0 in thr_fn (
>     arg=<error reading variable: can't compute CFA for this frame>)
>     at test-cancel.c:49
> #16 0x0000000000401b28 in start_thread (arg=0x4a3000) at
> pthread_create.c:335
> #17 0x0000000000401b28 in start_thread (arg=0x4a3000) at
> pthread_create.c:335
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> ```
>
> Such abort is raise by the following code:
> ```
> static void
> uw_update_context_1 (struct _Unwind_Context *context, _Unwind_FrameState
> *fs)
> {
> //...
>   /* Compute this frame's CFA.  */
>   switch (fs->regs.cfa_how)
>     {
>     case CFA_REG_OFFSET:
>       cfa = _Unwind_GetPtr (&orig_context, fs->regs.cfa_reg);
>       cfa += fs->regs.cfa_offset;
>       break;
>
>     case CFA_EXP:
>       {
>         const unsigned char *exp = fs->regs.cfa_exp;
>         _uleb128_t len;
>
>         exp = read_uleb128 (exp, &len);
>         cfa = (void *) (_Unwind_Ptr)
>           execute_stack_op (exp, exp + len, &orig_context, 0);
>         break;
>       }
>
>     default:
>       gcc_unreachable ();
>     }
>   context->cfa = cfa;
> //...
> }
> ``
>
> Any suggestion is appreciated.
>
> CC gcc mailing list. Sorry if it is off topic.
>
> Regards
>
> Bamvor
>
>
>
>
>> pipeio_x tests are very unstable and may fail randomly. I strongly
>> suspect race conditions, as they all work like a charm if pinned to
>> single CPU with taskset. Probably, race is the reason of clone02 too.
>> Though I'm not sure, is the race in kernel, glibc or test itself.
>>
>> But I know for sure that pause01 fails due to test design:
>>         if (setitimer(ITIMER_REAL, &it, NULL)) // For 1000us
>>                 tst_brkm(TBROK | TERRNO, NULL, "setitimer() failed");
>>
>>         TEST(pause());
>>
>> As setitimer() and pause() calls are not atomic, alarm may come before
>> pause()
>> is called, and be silently dropped by the handler. Next pause() call hangs
>> test forever. I already reported to LTP list.
>>
>> open12, rename11, rmdir02, mmap16, mtest06 - all call mkfs tool, and it
>> returns
>> error code. I didn't investigate it much yet.
>>
>> umount02_x, utime06 - cannot reproduce out of scenario, even run it in
>> infinite
>> loop - they work fine.
>>
>> Full test log is attached.
>>
>> Yury
>>
>

[toc] | [prev] | [next] | [standalone]

#1389590

On Wed, Apr 27, 2016 at 12:30 AM, Andrew Pinski <pinskia@gmail.com> wrote:
> On Fri, Apr 22, 2016 at 8:37 PM, Zhangjian (Bamvor)
> <bamvor.zhangjian@huawei.com> wrote:
>> Hi, Yury
>>
>>
>> On 2016/4/6 6:44, Yury Norov wrote:
>>>
>>> There are about 20 failing tests of 782 in lite scenario.
>>> float_bessel
>>> float_exp_log
>>> float_iperb
>>> float_power
>>> float_trigo
>>> pipeio_1
>>> pipeio_3
>>> pipeio_5
>>> pipeio_8
>>> abort01
>>> clone02
>>> kill11
>>> mmap16
>>> open12
>>> pause01
>>> rename11
>>> rmdir02
>>> umount2_01
>>> umount2_02
>>> umount2_03
>>> utime06
>>> mtest06
>>>
>>> The list is rough because some tests fail not every time.
>>>
>>> Tests abort01 and kill11 fail for lp64 too, so maybe there's
>>> a reason unrelated to ilp32 itself.
>>>
>>> float_xxx tests fail because they call unwind() from signal context,
>>> and GCC for ilp32 has problem with it, as Andrew told.
>>
>> Is there some progress about this issue. When we talk about unwind
>> functions, do you mean the function in libgcc?
>>
>> We encountered another issue(abort not segfault) which also called
>> pthread_cancel(). The test code is in the attachment. Here is the
>> backtrace:
>
> Yes this was a known issue I knew about.  I have a patch GCC to fix
> this.  Basically REG_VALUE_IN_UNWIND_CONTEXT needs to be defined while
> building libgcc to support the correct unwind information.
> I will be posting a GCC patch to fix this tomorrow.  This was a bug
> even in the original set of ilp32 patches.  I only finally was able to
> sit down and fix it today.

Here is the link to the GCC patch which I said was going to submit today:
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01726.html

Thanks,
Andrew

>
>
> Thanks,
> Andrew
>
>>
>> ```
>> Program received signal SIGABRT, Aborted.
>> [Switching to Thread 0xf77ee330 (LWP 2958)]
>> 0x000000000040f5bc in raise (sig=sig@entry=6)
>>     at ../sysdeps/unix/sysv/linux/raise.c:55
>> 55      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
>> (gdb) bt
>> #0  0x000000000040f5bc in raise (sig=sig@entry=6)
>>     at ../sysdeps/unix/sysv/linux/raise.c:55
>> #1  0x000000000040f884 in abort () at abort.c:89
>>
>> #2  0x00000000004073b4 in uw_update_context_1 (
>>     context=context@entry=0xf77ec820, fs=fs@entry=0xf77ebec8)
>> at /home/GCC-Build/p660/p660_build_dir/src/gcc-4.9/libgcc/unwind-dw2.c:1430
>>
>> #3  0x00000000004078c0 in uw_update_context
>> (context=context@entry=0xf77ec820,
>>     fs=fs@entry=0xf77ebec8)
>>    at
>> /home/GCC-Build/p660/p660_build_dir/src/gcc-4.9/libgcc/unwind-dw2.c:1506
>> #4  0x0000000000407a9c in uw_advance_context (fs=0xf77ebec8,
>>     context=0xf77ec820)
>>     at
>> /home/GCC-Build/p660/p660_build_dir/src/gcc-4.9/libgcc/unwind-dw2.c:1529
>> #5  _Unwind_ForcedUnwind_Phase2 (exc=exc@entry=0xf77ee580,
>>     context=context@entry=0xf77ec820)
>>     at /home/GCC-Build/p660/p660_build_dir/src/gcc-4.9/libgcc/unwind.inc:185
>> #6  0x0000000000408228 in _Unwind_ForcedUnwind (exc=0xf77ee580,
>>     stop=stop@entry=0x405440 <unwind_stop>, stop_argument=0xf77eddd8)
>>     at /home/GCC-Build/p660/p660_build_dir/src/gcc-4.9/libgcc/unwind.inc:207
>> #7  0x00000000004055c4 in __pthread_unwind (buf=<optimized out>)
>>     at unwind.c:126
>> #8  0x00000000004050b4 in __do_cancel () at ./pthreadP.h:283
>> #9  sigcancel_handler (sig=<optimized out>, si=<optimized out>,
>>     ctx=<optimized out>) at nptl-init.c:225
>> ---Type <return> to continue, or q <return> to quit---
>> #10 <signal handler called>
>>
>> #11 0x0000000000000000 in ?? ()
>>
>> #12 0x0000000000423084 in __select (nfds=-66661, readfds=<optimized out>,
>>     writefds=<optimized out>, exceptfds=<optimized out>, timeout=0x0)
>>     at ../sysdeps/unix/sysv/linux/generic/select.c:45
>> #13 0x0000000000400604 in TEST_TaskDelay (
>>     uiMillSecs=<error reading variable: can't compute CFA for this frame>)
>>     at test-cancel.c:18
>> #14 0x0000000000400680 in printids (
>>     s=<error reading variable: can't compute CFA for this frame>)
>>     at test-cancel.c:38
>> #15 0x00000000004006d0 in thr_fn (
>>     arg=<error reading variable: can't compute CFA for this frame>)
>>     at test-cancel.c:49
>> #16 0x0000000000401b28 in start_thread (arg=0x4a3000) at
>> pthread_create.c:335
>> #17 0x0000000000401b28 in start_thread (arg=0x4a3000) at
>> pthread_create.c:335
>> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>> ```
>>
>> Such abort is raise by the following code:
>> ```
>> static void
>> uw_update_context_1 (struct _Unwind_Context *context, _Unwind_FrameState
>> *fs)
>> {
>> //...
>>   /* Compute this frame's CFA.  */
>>   switch (fs->regs.cfa_how)
>>     {
>>     case CFA_REG_OFFSET:
>>       cfa = _Unwind_GetPtr (&orig_context, fs->regs.cfa_reg);
>>       cfa += fs->regs.cfa_offset;
>>       break;
>>
>>     case CFA_EXP:
>>       {
>>         const unsigned char *exp = fs->regs.cfa_exp;
>>         _uleb128_t len;
>>
>>         exp = read_uleb128 (exp, &len);
>>         cfa = (void *) (_Unwind_Ptr)
>>           execute_stack_op (exp, exp + len, &orig_context, 0);
>>         break;
>>       }
>>
>>     default:
>>       gcc_unreachable ();
>>     }
>>   context->cfa = cfa;
>> //...
>> }
>> ``
>>
>> Any suggestion is appreciated.
>>
>> CC gcc mailing list. Sorry if it is off topic.
>>
>> Regards
>>
>> Bamvor
>>
>>
>>
>>
>>> pipeio_x tests are very unstable and may fail randomly. I strongly
>>> suspect race conditions, as they all work like a charm if pinned to
>>> single CPU with taskset. Probably, race is the reason of clone02 too.
>>> Though I'm not sure, is the race in kernel, glibc or test itself.
>>>
>>> But I know for sure that pause01 fails due to test design:
>>>         if (setitimer(ITIMER_REAL, &it, NULL)) // For 1000us
>>>                 tst_brkm(TBROK | TERRNO, NULL, "setitimer() failed");
>>>
>>>         TEST(pause());
>>>
>>> As setitimer() and pause() calls are not atomic, alarm may come before
>>> pause()
>>> is called, and be silently dropped by the handler. Next pause() call hangs
>>> test forever. I already reported to LTP list.
>>>
>>> open12, rename11, rmdir02, mmap16, mtest06 - all call mkfs tool, and it
>>> returns
>>> error code. I didn't investigate it much yet.
>>>
>>> umount02_x, utime06 - cannot reproduce out of scenario, even run it in
>>> infinite
>>> loop - they work fine.
>>>
>>> Full test log is attached.
>>>
>>> Yury
>>>
>>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web