From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cyril Hrubis Date: Mon, 10 Oct 2016 15:15:29 +0200 Subject: [LTP] [PATCH] syscalls/signal06: fix test for regression with earlier version of gcc and kernel In-Reply-To: <57FB3DD2.1070809@cn.fujitsu.com> 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> Message-ID: <20161010131529.GA1684@rei> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ltp@lists.linux.it 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? > >> 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