[RFC6 PATCH v6 00/21] ILP32 for ARM64 - LTP results
Andrew Pinski
pinskia at gmail.com
Wed Apr 27 14:15:30 PDT 2016
On Wed, Apr 27, 2016 at 12:30 AM, Andrew Pinski <pinskia at gmail.com> wrote:
> On Fri, Apr 22, 2016 at 8:37 PM, Zhangjian (Bamvor)
> <bamvor.zhangjian at 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 at 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 at 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 at entry=0xf77ec820, fs=fs at 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 at entry=0xf77ec820,
>> fs=fs at 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 at entry=0xf77ee580,
>> context=context at 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 at 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
>>>
>>
More information about the linux-arm-kernel
mailing list