[LTP] [PATCH] syscalls/signal06: fix test for regression with earlier version of gcc and kernel

[Guangwen Feng <fenggw-fnst@cn.fujitsu.com>]

Hi!

On 10/10/2016 09:15 PM, Cyril Hrubis wrote:
> Hi!
>> Yes, I guess this is the kernel's bug, but sorry I didn't look into
>> the real reason of the segfault issue much.
>>
>> [root@RHEL5U11ga_Intel64 signal]# gdb ./signal06 core.18623 
>> GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-45.el5)
>> Copyright (C) 2009 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-redhat-linux-gnu".
>> For bug reporting instructions, please see:
>> <http://www.gnu.org/software/gdb/bugs/>...
>> Reading symbols from /root/ltp/testcases/kernel/syscalls/signal/signal06...done.
>> [New Thread 18623]
>> [New Thread 18625]
>> Reading symbols from /lib64/libpthread.so.0...(no debugging symbols found)...done.
>> [Thread debugging using libthread_db enabled]
>> Loaded symbols for /lib64/libpthread.so.0
>> Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done.
>> Loaded symbols for /lib64/libc.so.6
>> Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
>> Loaded symbols for /lib64/ld-linux-x86-64.so.2
>>
>> warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fffe3384000
>> Core was generated by `./signal06'.
>> Program terminated with signal 11, Segmentation fault.
>> #0  test (d=123.456) at signal06.c:71
>> 71		while (D == d && loop < LOOPS) {
>> (gdb) bt
>> #0  test (d=123.456) at signal06.c:71
>> #1  0x0000000000402bb7 in main (ac=<value optimized out>, av=<value optimized out>) at signal06.c:151
> 
> So it segfaults in the test() function, we aren't doing anything wrong
> there. So this really looks like a bug itself.
> 
> Supposedly this causes the test segfault on a system where the original
> bug cannot be reproduced, right?

Yes, the original bug should be reproduced by signal06 on this system.
but the segfault issue breaks the regression test.

> 
>>>> By current LOOPS(10000), most of the time, the buggy kernel can be
>>>> reproduced, but there is still a chance(about 0.5% in my environment)
>>>> to miss.
>>>
>>> Hmm, what about increasing it twice or four times? What is the
>>> probability of missing the bug then?
>>>
>>
>> 2 times(20000 loops):	99.9% reproducible
>> 4 times(40000 loops):	100% reproducible
>>
>> Is it acceptable to increase it four times?
> 
> That is 2.5 times better :)

So, may I just increase it to 4 times and send a v2?


Best Regards,
Guangwen Feng