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

[Cyril Hrubis]

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?

> >> 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 :)

-- 
Cyril Hrubis
chrubis@suse.cz