From mboxrd@z Thu Jan 1 00:00:00 1970 From: Guangwen Feng Date: Tue, 11 Oct 2016 15:17:23 +0800 Subject: [LTP] [PATCH] syscalls/signal06: fix test for regression with earlier version of gcc and kernel In-Reply-To: <20161010131529.GA1684@rei> References: <1470380281-20334-1-git-send-email-fenggw-fnst@cn.fujitsu.com> <20161005134303.GA23476@rei.lan> <57F627EF.7070605@cn.fujitsu.com> <20161006111548.GA9711@rei> <57FB3DD2.1070809@cn.fujitsu.com> <20161010131529.GA1684@rei> Message-ID: <57FC9203.40804@cn.fujitsu.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ltp@lists.linux.it 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 >> 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: >> ... >> 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=, av=) 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