Menu
▾
▴
Re: [LTP] Ltp-list Digest, Vol 44, Issue 54
|
From: Garrett C. <yan...@gm...> - 2010-01-23 04:39:04
|
2010/1/22 lihuachen1985 <lih...@16...>: > It's really a issue for our test. Would this patch be applied to this ltp > version? > > > > 在2010-01-22 01:43:32，ltp...@li... 写道： >>Send Ltp-list mailing list submissions to >> ltp...@li... >> >>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...@li... >> >>You can reach the person managing the list at >> ltp...@li... >> >>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 <yan...@gm...> >>Subject: Re: [LTP] 2010-01-20 cvs build failed >>To: Mitani <mi...@ry...> >>Cc: ltp...@li... >>Message-ID: >> <364...@ma...> >>Content-Type: text/plain; charset=ISO-8859-1 >> >>On Wed, Jan 20, 2010 at 8:01 PM, Mitani <mi...@ry...> 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 <cro...@gm...> >>Subject: Re: [LTP] >> >> [patch]ltp-intermediate-20100119/testcases/kernel/mem/hugetlb/hugeshmget/hugeshmget01.c >> >>To: liubo <liu...@cn...> >>Cc: ltp...@li... >>Message-ID: >> <5a7...@ma...> >>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 <cro...@gm...> >> >>> 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 <liu...@cn...> >>> >>>> 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 <liu...@cn...> <liu...@cn...> >>>> >>>> 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 <cro...@gm...> <cro...@gm...> <cro...@gm...> <cro...@gm...> >>>> >>>> >>>> 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 lis...@li...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" <no...@so...> >>Subject: [LTP] [ ltp-Feature Requests-2927507 ] lcov: branch coverage >> in reports >>To: no...@so... >>Message-ID: <E1N...@h4...> >>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 |