On 08/23/2012 09:09 AM, Jan Stancek wrote: > > > ----- Original Message ----- >> From: "Kang Kai" >> To: "Jan Stancek" , gaowanlong@cn.fujitsu.com >> Cc: ltp-list@lists.sourceforge.net, "Zhenfeng Zhao" >> Sent: Thursday, 23 August, 2012 8:21:43 AM >> Subject: Re: [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault >> >> On 2012年08月22日 22:20, Jan Stancek wrote: >>> On 08/22/2012 10:58 AM, Jan Stancek wrote: >>>> >>>> ----- Original Message ----- >>>>> From: "Kang Kai" >>>>> To: "Jan Stancek" >>>>> Cc: gaowanlong@cn.fujitsu.com, ltp-list@lists.sourceforge.net, >>>>> "Zhenfeng Zhao" >>>>> Sent: Wednesday, 22 August, 2012 10:28:59 AM >>>>> Subject: Re: [LTP] [PATCH] pthread_detach/4-3: workaround for >>>>> segment fault >>>>> Hi Jan, >>>>> >>>>>> Is the above output from mips or x86_64? >>>>>> Are you running it as root user? >>>>> This was tested on x86_64 with unprivileged user. I retest it >>>>> with >>>>> root >>>>> and test passes. >>>> Your unprivileged user is hitting some resource limit, I'd be >>>> interested >>>> to see how many threads are actually running at the same time. >>>> >>>>> It passes on routerstation(mips) with your patch too. >>>>> So it looks like a race condition issue about stack attribute >>>>> between >>>>> threads, right? >>>> I think so. We can try different way of signalling when threaded() >>>> is done >>>> and try it again with all scenarios. >>> I think this testcase is broken in more than 1 way. At least on my >>> setup, I don't see >>> a single pthread_detach() while signals are firing - which is >>> exactly goal of this test. >>> >>> With following change: >>> >>> diff --git >>> a/testcases/open_posix_testsuite/conformance/interfaces/pthread_detach/4-3.c >>> b/testcases/open_posix_testsuite/conforman >>> index dfa6e19..48e1343 100644 >>> --- >>> a/testcases/open_posix_testsuite/conformance/interfaces/pthread_detach/4-3.c >>> +++ >>> b/testcases/open_posix_testsuite/conformance/interfaces/pthread_detach/4-3.c >>> @@ -277,6 +276,7 @@ int main(int argc, char *argv[]) >>> do_it1 = 0; >>> } while (do_it1); >>> >>> + output(" %d thread detached while signals were firing.\n", >>> count_ope); >>> sleep(1); >>> >>> do { >>> >>> I get: >>> [16:11:23] 1 thread detached while signals are firing. >>> [16:11:24]Test executed successfully. >>> [16:11:24] 77865 thread detached. >>> >>> and that reported "1" is how many threads attempted to call >>> pthread_detach, not how many actually >>> succeeded. Signals are firing so frequently that threaded() can't >>> progress at all. > >> Then how do we fix this case? sync sending the signals with >> pthread_detach? > > I was thinking usleep(sleep_time) that progressively increases. So it > starts firing signals as quickly as it can and slows down over time. > Each pthread_detach() would reset the sleep_time. > > As for our original issue, idea I'm playing with is: > > main (procA) - do_child (procB) - send_sig (thread) > \ > test (thread) - threaded (detached thread) > > - turn 'while' in test() to single 'for' loop > - loop in main, fork and call do_child, wait for child to finish Hi, attached is v1 of the idea above. I ran it 100x times on various setups as root and unprivileged user. Kai, would you like to give a try? Regards, Jan > > This way we can be sure, that we don't reuse same stack for multiple threads, > and we can also be sure, there won't be more than NSCENAR threads, so unprivileged > user should not run out of resources. > > Regards, > Jan > >> >> Wanlong, any comments? >> >> Thanks, >> Kai >> >>> >>> Regards, >>> Jan >>> >> >> > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Ltp-list mailing list > Ltp-list@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ltp-list