2010/1/22 lihuachen1985 <[email protected]>:
> It's really a issue for our test. Would this patch be applied to this ltp
> version?
>
>
>
> 在2010-01-22 01:43:32，[email protected] 写道：
>>Send Ltp-list mailing list submissions to
>> [email protected]
>>
>>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
>> [email protected]
>>
>>You can reach the person managing the list at
>> [email protected]
>>
>>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 <[email protected]>
>>Subject: Re: [LTP] 2010-01-20 cvs build failed
>>To: Mitani <[email protected]>
>>Cc: [email protected]
>>Message-ID:
>> <[email protected]>
>>Content-Type: text/plain; charset=ISO-8859-1
>>
>>On Wed, Jan 20, 2010 at 8:01 PM, Mitani <[email protected]> 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 <[email protected]>
>>Subject: Re: [LTP]
>>
>> [patch]ltp-intermediate-20100119/testcases/kernel/mem/hugetlb/hugeshmget/hugeshmget01.c
>>
>>To: liubo <[email protected]>
>>Cc: [email protected]
>>Message-ID:
>> <[email protected]>
>>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 <[email protected]>
>>
>>> 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 <[email protected]>
>>>
>>>> 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 <[email protected]> <[email protected]>
>>>>
>>>> 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 <[email protected]> <[email protected]> <[email protected]> <[email protected]>
>>>>
>>>>
>>>> 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 [email protected]https://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" <[email protected]>
>>Subject: [LTP] [ ltp-Feature Requests-2927507 ] lcov: branch coverage
>> in reports
>>To: [email protected]
>>Message-ID: <[email protected]>
>>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?
Hi,
Considering that this is a digest email, could you please comment
about what test you need fixed?
Thanks,
-Garrett
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
