It's really a issue for our test. Would this patch be applied to this ltp version?
ÔÚ2010-01-22 01:43:32£¬ltp-list-request@lists.sourceforge.net дµÀ£º
>Send Ltp-list mailing list submissions to
> ltp-list@lists.sourceforge.net
>
>To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/ltp-list
>or, via email, send a message with subject or body 'help' to
> ltp-list-request@lists.sourceforge.net
>
>You can reach the person managing the list at
> ltp-list-owner@lists.sourceforge.net
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Ltp-list digest..."
>
>
>Today's Topics:
>
> 1. Re: 2010-01-20 cvs build failed (Garrett Cooper)
> 2. Re: [LTP]
> [patch]ltp-intermediate-20100119/testcases/kernel/mem/hugetlb/hugeshmget/hugeshmget01.c
> (Crossover Lonely)
> 3. [ ltp-Feature Requests-2927507 ] lcov: branch coverage in
> reports (SourceForge.net)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Wed, 20 Jan 2010 22:41:27 -0800
>From: Garrett Cooper <yanegomi@gmail.com>
>Subject: Re: [LTP] 2010-01-20 cvs build failed
>To: Mitani <mitani@ryobi.co.jp>
>Cc: ltp-list@lists.sourceforge.net
>Message-ID:
> <364299f41001202241u324d0298l605f8bb7122bda19@mail.gmail.com>
>Content-Type: text/plain; charset=ISO-8859-1
>
>On Wed, Jan 20, 2010 at 8:01 PM, Mitani <mitani@ryobi.co.jp> wrote:
>> Garrett,
>>
>>
>>>Solved. Typo that I didn't pick up earlier..
>>
>> I succeeded to build in RHEL5.4 system with 2010-01-21 cvs.
>>
>>>You have to use make all when compiling `all' with make instead of just
>> specifying `make' with 3.81 because make 3.80 doesn't have a concept of
>> default goals/targets.
>>
>> Thank you for your advice.
>> It was my mistake.
>> I succeeded to build in RHEL4.8 system by using "make3.80"!
>> Great!
>>
>>
>> Thank you--
>
> Np -- sometimes it takes a while to get to a proper solution, but
>once there is one and it's set in stone, it's done :).
>Cheers,
>-Garrett
>
>
>
>------------------------------
>
>Message: 2
>Date: Thu, 21 Jan 2010 15:37:09 +0800
>From: Crossover Lonely <crosslonelyover@gmail.com>
>Subject: Re: [LTP]
> [patch]ltp-intermediate-20100119/testcases/kernel/mem/hugetlb/hugeshmget/hugeshmget01.c
>
>To: liubo <liubo2009@cn.fujitsu.com>
>Cc: ltp-list@lists.sourceforge.net
>Message-ID:
> <5a774f4c1001202337p306b1f4bkd9406c6d6f32e87d@mail.gmail.com>
>Content-Type: text/plain; charset="iso-8859-1"
>
>Oh, I got it. There is some confusion.
>
>1) In hugeshmget01.c, setup() will call
> tst_sig(NOFORK, DEF_HANDLER, cleanup);
>2) In include/test.h:
> /* defines for unexpected signal setup routine (set_usig.c)
>*/
> #define FORK 1 /* SIGCLD is to be
>ignored */
> #define NOFORK 0 /* SIGCLD is to be caught */
> so here, hugeshmget01 want to catch SIGCLD.
>3) In lib/tst_gig.c:
> ...
> case SIGCLD:
> if (fork_flag == FORK || STD_COPIES > 1)
> continue;
>
> default:
> if (tst_setup_signal(sig, handler) == SIG_ERR)
> tst_resm(TWARN | TERRNO,
> "signal() failed for signal %d",
>sig);
> break;
> ...
>
>Here, if you donot use "-c Xnumber", the SIGCLD handler will be def_handler,
>which will rise
> "Unexpected signal %d received"
>when received signal SIGCLD
>But if you use "-c Xnumber", STD_COPIES > 1 will be true, so the handler to
>SIGCLD is default, "ignore".
>
>
>Confusion comes out:
> 1. tst_sig(NOFORK, DEF_HANDLER, cleanup); /* SIGCLD is to
>be caught */
> 2. -c Xnumber will lead to SIGCLD ignored
>Although the results are normal, but the code itself can lead to confusion.
>So I suggest use the following patch:
>
>--- hugeshmget01.c 2009-11-20 00:05:21.000000000 +0800
>+++ hugeshmget01_1.c 2010-01-21 08:41:56.350057513 +0800
>@@ -160,7 +160,7 @@
> setup(void)
> {
> /* capture signals */
>- tst_sig(NOFORK, DEF_HANDLER, cleanup);
>+ tst_sig(FORK, DEF_HANDLER, cleanup);
>
> /* Pause if that option was specified */
> TEST_PAUSE;
>
>
>
>
>
>2010/1/21 Crossover Lonely <crosslonelyover@gmail.com>
>
>> Hi,
>> I have tried "gdb ./hugeshmget01 -c 2" and "set follow-fork-mode
>> child".
>> Then I traced into the child thread, and got
>> "hugeshmget01 1 TBROK : Unexpected signal 17 received."
>>
>>
>>
>> 2010/1/21 liubo <liubo2009@cn.fujitsu.com>
>>
>>> Hi,
>>>
>>> The hugeshmget01 case is designed for testing standard SYSV shared
>>> memory system calls "shmget", and it do need a few concurrent copies
>>> in order to fulfill a multi-process memory-allocated environment.
>>>
>>> IMO, "-c Xnumber" is needed.
>>>
>>> Thanks,
>>> Liu Bo
>>>
>>>
>>>
>>> On 01/21/2010 10:14 AM, Crossover Lonely wrote:
>>>
>>> It works!
>>> But isn't weird? Why just use ./hugeshmget won't work?
>>> I traced it, and found it calls tsg_sig() in setup():
>>> tst_sig(NOFORK, DEF_HANDLER, cleanup);
>>> and in tsg_sig():
>>> ...
>>> case SIGCLD:
>>> if (fork_flag == FORK || STD_COPIES > 1)
>>> continue;
>>>
>>> default:
>>> if (tst_setup_signal(sig, handler) == SIG_ERR)
>>> tst_resm(TWARN | TERRNO,
>>> "signal() failed for signal %d", sig);
>>> break;
>>> ...
>>>
>>> so here hugeshmget set its action to SIGCLD to handler - here is
>>> def_handler(), which can
>>> rise "Unexpected signal %d received." message when recived SIGCLD.
>>> static void def_handler(int sig)
>>> {
>>> /*
>>> * Break remaining test cases, do any cleanup, then exit
>>> */
>>> tst_brkm(TBROK, 0, "Unexpected signal %d received.", sig);
>>>
>>> /* now cleanup and exit */
>>> if (T_cleanup)
>>> (*T_cleanup) ();
>>>
>>> tst_exit();
>>> }
>>>
>>> So I think it's better to correct it!
>>>
>>> Thanks and Best Regards,
>>> shenghui
>>>
>>> 2010/1/21 liubo <liubo2009@cn.fujitsu.com> <liubo2009@cn.fujitsu.com>
>>>
>>> Hi,
>>>
>>> In my box, I can add -c Xnumber to avoid the unexpect signal,
>>> for example, ./hugeshmget -c 10. Maybe you can try this as well.
>>>
>>> Thanks,
>>> Liu Bo
>>>
>>>
>>> On 01/21/2010 08:50 AM, Crossover Lonely wrote:
>>>
>>> For your convenience, I just made to patches against the signle file, not
>>> the whole directory.
>>>
>>> solution 1=======================
>>> --- hugeshmget01.c 2009-11-20 00:05:21.000000000 +0800
>>> +++ hugeshmget01_2.c 2010-01-21 08:43:11.790533086 +0800
>>> @@ -78,14 +78,14 @@
>>> tst_brkm(TBROK, cleanup, "OPTION PARSING ERROR - %s", msg);
>>> }
>>>
>>> - setup(); /* global setup */
>>> -
>>> /* The following loop checks looping state if -i option given */
>>> if ( get_no_of_hugepages() <= 0 || hugepages_size() <= 0 )
>>> tst_brkm(TBROK, cleanup, "Test cannot be continued owning to
>>> sufficient availability of Hugepages on the system");
>>> else
>>> huge_pages_shm_to_be_allocated = ( get_no_of_hugepages() *
>>> hugepages_size() * 1024) / 2 ;
>>>
>>> + setup(); /* global setup */
>>> +
>>> for (lc = 0; TEST_LOOPING(lc); lc++) {
>>> /* reset Tst_count in case we are looping */
>>> Tst_count = 0;
>>>
>>>
>>> solution 2=============================
>>> =
>>> --- hugeshmget01.c 2009-11-20 00:05:21.000000000 +0800
>>> +++ hugeshmget01_1.c 2010-01-21 08:41:56.350057513 +0800
>>> @@ -160,7 +160,7 @@
>>> setup(void)
>>> {
>>> /* capture signals */
>>> - tst_sig(NOFORK, DEF_HANDLER, cleanup);
>>> + tst_sig(FORK, DEF_HANDLER, cleanup);
>>>
>>> /* Pause if that option was specified */
>>> TEST_PAUSE;
>>>
>>>
>>> 2010/1/21 Crossover Lonely <crosslonelyover@gmail.com> <crosslonelyover@gmail.com> <crosslonelyover@gmail.com> <crosslonelyover@gmail.com>
>>>
>>>
>>> Hi all,
>>>
>>> When the hugeshmget01 runs, it gets unexpected signal SIGCHLD/SIGCLD,
>>> and thus stops immediately.
>>> I found two ways to resolve this problem. Please refer to the
>>> following for two kinds of patch.
>>> Well, according to other code structures of hugeshmget0*.c, solution 1
>>> is preferred. But for get_no_of_hugepages
>>> will call popen(), so I think the second solution is the right one.
>>> Will you please choose the right one to apply to
>>> ltp-intermediate-20100119 package?
>>> Looking forward to your confirmation!
>>>
>>> Thanks and Best Regards,
>>> shenghui
>>>
>>> Solution 1===============================================================
>>>
>>> diff -Nur
>>> ltp-intermediate-20100119-origin/testcases/kernel/mem/hugetlb/hugeshmget/hugeshmget01.c
>>> ltp-intermediate-20100119/testcases/kernel/mem/hugetlb/hugeshmget/hugeshmget01.c
>>> ---
>>> ltp-intermediate-20100119-origin/testcases/kernel/mem/hugetlb/hugeshmget/hugeshmget01.c
>>> 2010-01-21 07:51:55.926035076 +0800
>>> +++
>>> ltp-intermediate-20100119/testcases/kernel/mem/hugetlb/hugeshmget/hugeshmget01.c
>>> 2010-01-21 08:14:05.470032624 +0800
>>> @@ -78,14 +78,14 @@
>>> tst_brkm(TBROK, cleanup, "OPTION PARSING ERROR - %s", msg);
>>> }
>>>
>>> - setup(); /* global setup */
>>> -
>>> /* The following loop checks looping state if -i option given */
>>> if ( get_no_of_hugepages() <= 0 || hugepages_size() <= 0 )
>>> tst_brkm(TBROK, cleanup, "Test cannot be continued owning to
>>> sufficient availability of Hugepages on the system");
>>> else
>>> - huge_pages_shm_to_be_allocated = ( get_no_of_hugepages() *
>>> hugepages_size() * 1024) / 2 ;
>>> -
>>> + huge_pages_shm_to_be_allocated = ( get_no_of_hugepages() *
>>> hugepages_size() * 1024) / 2 ;
>>> +
>>> + setup(); /* global setup */
>>> +
>>> for (lc = 0; TEST_LOOPING(lc); lc++) {
>>> /* reset Tst_count in case we are looping */
>>> Tst_count = 0;
>>>
>>>
>>> Solution
>>> 2=========================================================================================
>>> diff -Nur
>>> ltp-intermediate-20100119-origin/testcases/kernel/mem/hugetlb/hugeshmget/hugeshmget01.c
>>> ltp-intermediate-20100119/testcases/kernel/mem/hugetlb/hugeshmget/hugeshmget01.c
>>> ---
>>> ltp-intermediate-20100119-origin/testcases/kernel/mem/hugetlb/hugeshmget/hugeshmget01.c
>>> 2010-01-21 07:51:55.926035076 +0800
>>> +++
>>> ltp-intermediate-20100119/testcases/kernel/mem/hugetlb/hugeshmget/hugeshmget01.c
>>> 2010-01-21 08:16:46.122032889 +0800
>>> @@ -160,7 +160,7 @@
>>> setup(void)
>>> {
>>> /* capture signals */
>>> - tst_sig(NOFORK, DEF_HANDLER, cleanup);
>>> + tst_sig(FORK, DEF_HANDLER, cleanup);
>>>
>>> /* Pause if that option was specified */
>>> TEST_PAUSE;
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> ------------------------------------------------------------------------------
>>> Throughout its 18-year history, RSA Conference consistently attracts the
>>> world's best and brightest in the field, creating opportunities for Conference
>>> attendees to learn about information security's most important issues through
>>> interactions with peers, luminaries and emerging and established companies.http://p.sf.net/sfu/rsaconf-dev2dev
>>>
>>> ------------------------------
>>>
>>> ______________________________
>>> _________________
>>> Ltp-list mailing listLtp-list@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/ltp-list
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>>
>>
>> Thanks and Best Regards,
>> shenghui
>>
>
>
>
>--
>
>
>Thanks and Best Regards,
>shenghui
>-------------- next part --------------
>An HTML attachment was scrubbed...
>
>------------------------------
>
>Message: 3
>Date: Thu, 21 Jan 2010 10:04:26 +0000
>From: "SourceForge.net" <noreply@sourceforge.net>
>Subject: [LTP] [ ltp-Feature Requests-2927507 ] lcov: branch coverage
> in reports
>To: noreply@sourceforge.net
>Message-ID: <E1NXttq-0004LT-2Z@h45xhf1.ch3.sourceforge.com>
>Content-Type: text/plain; charset="UTF-8"
>
>Feature Requests item #2927507, was opened at 2010-01-07 14:08
>Message generated for change (Comment added) made by oberpapr
>You can respond by visiting:
>https://sourceforge.net/tracker/?func=detail&atid=353382&aid=2927507&group_id=3382
>
>Please note that this message will contain a full copy of the comment thread,
>including the initial issue submission, for this request,
>not just the latest update.
>Category: Tools
>Group: None
>Status: Open
>Resolution: None
>Priority: 5
>Private: No
>Submitted By: Stefan Kost (ensonic)
>Assigned to: Nobody/Anonymous (nobody)
>Summary: lcov: branch coverage in reports
>
>Initial Comment:
>gcov -b can report branch coverage
>(http://gcc.gnu.org/onlinedocs/gcc/Invoking-Gcov.html#Invoking-Gcov)
>
>There is a feature request for this featue also in
>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413834
>
>
>----------------------------------------------------------------------
>
>Comment By: Peter Oberparleiter (oberpapr)
>Date: 2010-01-21 11:04
>
>Message:
>Assuming that branch coverage support would be implemented in lcov, could
>you test it?
>
>----------------------------------------------------------------------
>
>You can respond by visiting:
>https://sourceforge.net/tracker/?func=detail&atid=353382&aid=2927507&group_id=3382
>
>
>
>------------------------------
>
>------------------------------------------------------------------------------
>Throughout its 18-year history, RSA Conference consistently attracts the
>world's best and brightest in the field, creating opportunities for Conference
>attendees to learn about information security's most important issues through
>interactions with peers, luminaries and emerging and established companies.
>http://p.sf.net/sfu/rsaconf-dev2dev
>
>------------------------------
>
>_______________________________________________
>Ltp-list mailing list
>Ltp-list@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/ltp-list
>
>
>End of Ltp-list Digest, Vol 44, Issue 54
>****************************************