* Re: [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault @ 2012-08-21 10:35 Jan Stancek 2012-08-22 2:29 ` Kang Kai 0 siblings, 1 reply; 24+ messages in thread From: Jan Stancek @ 2012-08-21 10:35 UTC (permalink / raw) To: Kang Kai; +Cc: ltp-list, Zhenfeng Zhao ----- Original Message ----- > From: "Kang Kai" <Kai.Kang@windriver.com> > To: "Jan Stancek" <jstancek@redhat.com> > Cc: gaowanlong@cn.fujitsu.com, ltp-list@lists.sourceforge.net, "Zhenfeng Zhao" <Zhenfeng.Zhao@windriver.com> > Sent: Tuesday, 21 August, 2012 11:59:19 AM > Subject: Re: [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault <snip> > Hi Jan, > > Thanks. > I am sorry that It doesn't work and still "segment fault". Maybe we can narrow it down by running only subset of scenarios. I would suggest trying to limit "sc" or "NSCENAR" and see which one triggers it. Another thing that looks suspicious are scenarios with altstack, there seems to be small window where more than 1 thread can use same altstack. Can you try to reproduce it without altstack scenarios? diff --git a/testcases/open_posix_testsuite/conformance/interfaces/pthread_detach/4-3.c b/testcases/open_posix_testsuite/conforman index 5c15e93..63b6ee7 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 @@ -162,6 +162,11 @@ static void *test(void *arg) output("Starting test with scenario (%i): %s\n", sc, scenarii[sc].descr); #endif + if (scenarii[sc].altstack) { + sc++; + sc %= NSCENAR; + continue; + } count_ope++; Regards, Jan > > Regards, > Kai > ------------------------------------------------------------------------------ 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 ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault 2012-08-21 10:35 [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault Jan Stancek @ 2012-08-22 2:29 ` Kang Kai 2012-08-22 7:06 ` Jan Stancek 0 siblings, 1 reply; 24+ messages in thread From: Kang Kai @ 2012-08-22 2:29 UTC (permalink / raw) To: Jan Stancek; +Cc: ltp-list, Zhenfeng, Zhao On 2012年08月21日 18:35, Jan Stancek wrote: > > ----- Original Message ----- >> From: "Kang Kai"<Kai.Kang@windriver.com> >> To: "Jan Stancek"<jstancek@redhat.com> >> Cc: gaowanlong@cn.fujitsu.com, ltp-list@lists.sourceforge.net, "Zhenfeng Zhao"<Zhenfeng.Zhao@windriver.com> >> Sent: Tuesday, 21 August, 2012 11:59:19 AM >> Subject: Re: [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault > <snip> > >> Hi Jan, >> >> Thanks. >> I am sorry that It doesn't work and still "segment fault". > Maybe we can narrow it down by running only subset of scenarios. > I would suggest trying to limit "sc" or "NSCENAR" and see which > one triggers it. > > Another thing that looks suspicious are scenarios with altstack, there seems > to be small window where more than 1 thread can use same altstack. > Can you try to reproduce it without altstack scenarios? > > diff --git a/testcases/open_posix_testsuite/conformance/interfaces/pthread_detach/4-3.c b/testcases/open_posix_testsuite/conforman > index 5c15e93..63b6ee7 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 > @@ -162,6 +162,11 @@ static void *test(void *arg) > output("Starting test with scenario (%i): %s\n", > sc, scenarii[sc].descr); > #endif Hi Jan, > + if (scenarii[sc].altstack) { > + sc++; > + sc %= NSCENAR; > + continue; > + } > It fails with another error randomly, and output is: [09:45:16]System abilities: [09:45:16] TSA: 200809 [09:45:16] TSS: 200809 [09:45:16] TPS: 200809 [09:45:16] pagesize: 4096 [09:45:16] min stack size: 16384 [09:45:16]WARNING: The TPS option is claimed to be supported but setscope fails [09:45:16]WARNING: The TPS option is claimed to be supported but setscope fails [09:45:16]WARNING: The TPS option is claimed to be supported but setscope fails [09:45:16]WARNING: The TPS option is claimed to be supported but setscope fails [09:45:16]WARNING: The TPS option is claimed to be supported but setscope fails [09:45:16]WARNING: The TPS option is claimed to be supported but setscope fails [09:45:16]WARNING: The TPS option is claimed to be supported but setscope fails [09:45:16]WARNING: The TPS option is claimed to be supported but setscope fails [09:45:16]WARNING: The TPS option is claimed to be supported but setscope fails [09:45:16]All 33 thread attribute objects were initialized [09:45:18]Test ../../../conformance/interfaces/pthread_detach/4-3.c unresolved: got 12 (Cannot allocate memory) on line 179 (Failed to create this thread) Regards, Kai > count_ope++; > > > Regards, > Jan > >> Regards, >> Kai >> > ------------------------------------------------------------------------------ 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault 2012-08-22 2:29 ` Kang Kai @ 2012-08-22 7:06 ` Jan Stancek 2012-08-22 8:28 ` Kang Kai 0 siblings, 1 reply; 24+ messages in thread From: Jan Stancek @ 2012-08-22 7:06 UTC (permalink / raw) To: Kang Kai; +Cc: ltp-list, Zhenfeng Zhao ----- Original Message ----- > From: "Kang Kai" <Kai.Kang@windriver.com> > To: "Jan Stancek" <jstancek@redhat.com> > Cc: gaowanlong@cn.fujitsu.com, ltp-list@lists.sourceforge.net, "Zhenfeng Zhao" <Zhenfeng.Zhao@windriver.com> > Sent: Wednesday, 22 August, 2012 4:29:25 AM > Subject: Re: [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault > > On 2012年08月21日 18:35, Jan Stancek wrote: > > > > ----- Original Message ----- > >> From: "Kang Kai"<Kai.Kang@windriver.com> > >> To: "Jan Stancek"<jstancek@redhat.com> > >> Cc: gaowanlong@cn.fujitsu.com, ltp-list@lists.sourceforge.net, > >> "Zhenfeng Zhao"<Zhenfeng.Zhao@windriver.com> > >> Sent: Tuesday, 21 August, 2012 11:59:19 AM > >> Subject: Re: [LTP] [PATCH] pthread_detach/4-3: workaround for > >> segment fault > > <snip> > > > >> Hi Jan, > >> > >> Thanks. > >> I am sorry that It doesn't work and still "segment fault". > > Maybe we can narrow it down by running only subset of scenarios. > > I would suggest trying to limit "sc" or "NSCENAR" and see which > > one triggers it. > > > > Another thing that looks suspicious are scenarios with altstack, > > there seems > > to be small window where more than 1 thread can use same altstack. > > Can you try to reproduce it without altstack scenarios? > > > > diff --git > > a/testcases/open_posix_testsuite/conformance/interfaces/pthread_detach/4-3.c > > b/testcases/open_posix_testsuite/conforman > > index 5c15e93..63b6ee7 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 > > @@ -162,6 +162,11 @@ static void *test(void *arg) > > output("Starting test with scenario (%i): %s\n", > > sc, scenarii[sc].descr); > > #endif > > Hi Jan, > > > + if (scenarii[sc].altstack) { > > + sc++; > > + sc %= NSCENAR; > > + continue; > > + } > > > > It fails with another error randomly, and output is: > > [09:45:16]System abilities: > [09:45:16] TSA: 200809 > [09:45:16] TSS: 200809 > [09:45:16] TPS: 200809 > [09:45:16] pagesize: 4096 > [09:45:16] min stack size: 16384 > [09:45:16]WARNING: The TPS option is claimed to be supported but > setscope fails > [09:45:16]WARNING: The TPS option is claimed to be supported but > setscope fails > [09:45:16]WARNING: The TPS option is claimed to be supported but > setscope fails > [09:45:16]WARNING: The TPS option is claimed to be supported but > setscope fails > [09:45:16]WARNING: The TPS option is claimed to be supported but > setscope fails > [09:45:16]WARNING: The TPS option is claimed to be supported but > setscope fails > [09:45:16]WARNING: The TPS option is claimed to be supported but > setscope fails > [09:45:16]WARNING: The TPS option is claimed to be supported but > setscope fails > [09:45:16]WARNING: The TPS option is claimed to be supported but > setscope fails > [09:45:16]All 33 thread attribute objects were initialized > > [09:45:18]Test ../../../conformance/interfaces/pthread_detach/4-3.c > unresolved: got 12 (Cannot allocate memory) on line 179 (Failed to > create this thread) Is the above output from mips or x86_64? Are you running it as root user? Regards, Jan > > > Regards, > Kai > > > count_ope++; > > > > > > Regards, > > Jan > > > >> Regards, > >> Kai > >> > > > > ------------------------------------------------------------------------------ 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault 2012-08-22 7:06 ` Jan Stancek @ 2012-08-22 8:28 ` Kang Kai 2012-08-22 8:58 ` Jan Stancek 0 siblings, 1 reply; 24+ messages in thread From: Kang Kai @ 2012-08-22 8:28 UTC (permalink / raw) To: Jan Stancek; +Cc: ltp-list, Zhenfeng, Zhao On 2012年08月22日 15:06, Jan Stancek wrote: > > ----- Original Message ----- >> From: "Kang Kai"<Kai.Kang@windriver.com> >> To: "Jan Stancek"<jstancek@redhat.com> >> Cc: gaowanlong@cn.fujitsu.com, ltp-list@lists.sourceforge.net, "Zhenfeng Zhao"<Zhenfeng.Zhao@windriver.com> >> Sent: Wednesday, 22 August, 2012 4:29:25 AM >> Subject: Re: [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault >> >> On 2012年08月21日 18:35, Jan Stancek wrote: >>> ----- Original Message ----- >>>> From: "Kang Kai"<Kai.Kang@windriver.com> >>>> To: "Jan Stancek"<jstancek@redhat.com> >>>> Cc: gaowanlong@cn.fujitsu.com, ltp-list@lists.sourceforge.net, >>>> "Zhenfeng Zhao"<Zhenfeng.Zhao@windriver.com> >>>> Sent: Tuesday, 21 August, 2012 11:59:19 AM >>>> Subject: Re: [LTP] [PATCH] pthread_detach/4-3: workaround for >>>> segment fault >>> <snip> >>> >>>> Hi Jan, >>>> >>>> Thanks. >>>> I am sorry that It doesn't work and still "segment fault". >>> Maybe we can narrow it down by running only subset of scenarios. >>> I would suggest trying to limit "sc" or "NSCENAR" and see which >>> one triggers it. >>> >>> Another thing that looks suspicious are scenarios with altstack, >>> there seems >>> to be small window where more than 1 thread can use same altstack. >>> Can you try to reproduce it without altstack scenarios? >>> >>> diff --git >>> a/testcases/open_posix_testsuite/conformance/interfaces/pthread_detach/4-3.c >>> b/testcases/open_posix_testsuite/conforman >>> index 5c15e93..63b6ee7 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 >>> @@ -162,6 +162,11 @@ static void *test(void *arg) >>> output("Starting test with scenario (%i): %s\n", >>> sc, scenarii[sc].descr); >>> #endif >> Hi Jan, >> >>> + if (scenarii[sc].altstack) { >>> + sc++; >>> + sc %= NSCENAR; >>> + continue; >>> + } >>> >> It fails with another error randomly, and output is: >> >> [09:45:16]System abilities: >> [09:45:16] TSA: 200809 >> [09:45:16] TSS: 200809 >> [09:45:16] TPS: 200809 >> [09:45:16] pagesize: 4096 >> [09:45:16] min stack size: 16384 >> [09:45:16]WARNING: The TPS option is claimed to be supported but >> setscope fails >> [09:45:16]WARNING: The TPS option is claimed to be supported but >> setscope fails >> [09:45:16]WARNING: The TPS option is claimed to be supported but >> setscope fails >> [09:45:16]WARNING: The TPS option is claimed to be supported but >> setscope fails >> [09:45:16]WARNING: The TPS option is claimed to be supported but >> setscope fails >> [09:45:16]WARNING: The TPS option is claimed to be supported but >> setscope fails >> [09:45:16]WARNING: The TPS option is claimed to be supported but >> setscope fails >> [09:45:16]WARNING: The TPS option is claimed to be supported but >> setscope fails >> [09:45:16]WARNING: The TPS option is claimed to be supported but >> setscope fails >> [09:45:16]All 33 thread attribute objects were initialized >> >> [09:45:18]Test ../../../conformance/interfaces/pthread_detach/4-3.c >> unresolved: got 12 (Cannot allocate memory) on line 179 (Failed to >> create this thread) 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. It passes on routerstation(mips) with your patch too. So it looks like a race condition issue about stack attribute between threads, right? Thanks a lot. Kai > > Regards, > Jan > >> >> Regards, >> Kai >> >>> count_ope++; >>> >>> >>> Regards, >>> Jan >>> >>>> Regards, >>>> Kai >>>> >> ------------------------------------------------------------------------------ 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault 2012-08-22 8:28 ` Kang Kai @ 2012-08-22 8:58 ` Jan Stancek 2012-08-22 14:20 ` Jan Stancek 0 siblings, 1 reply; 24+ messages in thread From: Jan Stancek @ 2012-08-22 8:58 UTC (permalink / raw) To: Kang Kai; +Cc: ltp-list, Zhenfeng Zhao ----- Original Message ----- > From: "Kang Kai" <Kai.Kang@windriver.com> > To: "Jan Stancek" <jstancek@redhat.com> > Cc: gaowanlong@cn.fujitsu.com, ltp-list@lists.sourceforge.net, "Zhenfeng Zhao" <Zhenfeng.Zhao@windriver.com> > 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. Regards, Jan > > Thanks a lot. > Kai > ------------------------------------------------------------------------------ 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault 2012-08-22 8:58 ` Jan Stancek @ 2012-08-22 14:20 ` Jan Stancek 2012-08-23 6:21 ` Kang Kai 0 siblings, 1 reply; 24+ messages in thread From: Jan Stancek @ 2012-08-22 14:20 UTC (permalink / raw) To: Kang Kai; +Cc: ltp-list, Zhenfeng Zhao On 08/22/2012 10:58 AM, Jan Stancek wrote: > > > ----- Original Message ----- >> From: "Kang Kai" <Kai.Kang@windriver.com> >> To: "Jan Stancek" <jstancek@redhat.com> >> Cc: gaowanlong@cn.fujitsu.com, ltp-list@lists.sourceforge.net, "Zhenfeng Zhao" <Zhenfeng.Zhao@windriver.com> >> 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. 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 ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault 2012-08-22 14:20 ` Jan Stancek @ 2012-08-23 6:21 ` Kang Kai 2012-08-23 7:09 ` Jan Stancek 0 siblings, 1 reply; 24+ messages in thread From: Kang Kai @ 2012-08-23 6:21 UTC (permalink / raw) To: Jan Stancek, gaowanlong; +Cc: ltp-list, Zhenfeng Zhao On 2012年08月22日 22:20, Jan Stancek wrote: > On 08/22/2012 10:58 AM, Jan Stancek wrote: >> >> ----- Original Message ----- >>> From: "Kang Kai"<Kai.Kang@windriver.com> >>> To: "Jan Stancek"<jstancek@redhat.com> >>> Cc: gaowanlong@cn.fujitsu.com, ltp-list@lists.sourceforge.net, "Zhenfeng Zhao"<Zhenfeng.Zhao@windriver.com> >>> 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? 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault 2012-08-23 6:21 ` Kang Kai @ 2012-08-23 7:09 ` Jan Stancek 2012-08-23 11:07 ` Jan Stancek 0 siblings, 1 reply; 24+ messages in thread From: Jan Stancek @ 2012-08-23 7:09 UTC (permalink / raw) To: Kang Kai; +Cc: ltp-list, Zhenfeng Zhao ----- Original Message ----- > From: "Kang Kai" <Kai.Kang@windriver.com> > To: "Jan Stancek" <jstancek@redhat.com>, gaowanlong@cn.fujitsu.com > Cc: ltp-list@lists.sourceforge.net, "Zhenfeng Zhao" <Zhenfeng.Zhao@windriver.com> > 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"<Kai.Kang@windriver.com> > >>> To: "Jan Stancek"<jstancek@redhat.com> > >>> Cc: gaowanlong@cn.fujitsu.com, ltp-list@lists.sourceforge.net, > >>> "Zhenfeng Zhao"<Zhenfeng.Zhao@windriver.com> > >>> 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 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault 2012-08-23 7:09 ` Jan Stancek @ 2012-08-23 11:07 ` Jan Stancek 2012-08-24 2:46 ` Kang Kai 0 siblings, 1 reply; 24+ messages in thread From: Jan Stancek @ 2012-08-23 11:07 UTC (permalink / raw) To: Kang Kai; +Cc: ltp-list, Zhenfeng Zhao [-- Attachment #1: Type: text/plain, Size: 4580 bytes --] On 08/23/2012 09:09 AM, Jan Stancek wrote: > > > ----- Original Message ----- >> From: "Kang Kai" <Kai.Kang@windriver.com> >> To: "Jan Stancek" <jstancek@redhat.com>, gaowanlong@cn.fujitsu.com >> Cc: ltp-list@lists.sourceforge.net, "Zhenfeng Zhao" <Zhenfeng.Zhao@windriver.com> >> 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"<Kai.Kang@windriver.com> >>>>> To: "Jan Stancek"<jstancek@redhat.com> >>>>> Cc: gaowanlong@cn.fujitsu.com, ltp-list@lists.sourceforge.net, >>>>> "Zhenfeng Zhao"<Zhenfeng.Zhao@windriver.com> >>>>> 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 [-- Attachment #2: 4-3.c --] [-- Type: text/x-csrc, Size: 8703 bytes --] /* * Copyright (c) 2004, Bull S.A.. All rights reserved. * Created by: Sebastien Decugis * * This program is free software; you can redistribute it and/or modify it * under the terms of version 2 of the GNU General Public License as * published by the Free Software Foundation. * * This program is distributed in the hope that it would be useful, but * WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. * * You should have received a copy of the GNU General Public License along * with this program; if not, write the Free Software Foundation, Inc., 59 * Temple Place - Suite 330, Boston MA 02111-1307, USA. * * This sample test aims to check the following assertion: * * The function does not return EINTR * * The steps are: * -> kill a thread which calls pthread_detach() * -> check that EINTR is never returned * */ #define _POSIX_C_SOURCE 200112L /* Some routines are part of the XSI Extensions */ #ifndef WITHOUT_XOPEN #define _XOPEN_SOURCE 600 #endif #include <sys/time.h> #include <sys/wait.h> #include <assert.h> #include <errno.h> #include <pthread.h> #include <sched.h> #include <semaphore.h> #include <signal.h> #include <stdarg.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include "../testfrmw/testfrmw.h" #include "../testfrmw/testfrmw.c" #define SAFE(op) if ((op) == -1) UNRESOLVED(errno, "unexpected failure"); #define SIGNALS_WITHOUT_DELAY 100 #ifndef VERBOSE #define VERBOSE 1 #endif #define WITH_SYNCHRO #define RUN_TIME_USEC 2*1000*1000 #include "../testfrmw/threads_scenarii.c" #ifdef WITH_SYNCHRO static sem_t semsig1; #endif static unsigned long count_sig; static volatile int do_it1 = 1; static unsigned long sleep_time; static unsigned long count_ope; static sigset_t usersigs; struct thestruct { int sig; #ifdef WITH_SYNCHRO sem_t *sem; #endif }; unsigned long current_time_usec() { struct timeval now; SAFE(gettimeofday(&now, NULL)); return now.tv_sec * 1000000 + now.tv_usec; } /* the following function keeps on sending the signal to the process */ static void *sendsig(void *arg) { struct thestruct *thearg = (struct thestruct *)arg; int ret; pid_t process; process = getpid(); /* We block the signals SIGUSR1 and SIGUSR2 for this THREAD */ ret = pthread_sigmask(SIG_BLOCK, &usersigs, NULL); if (ret != 0) UNRESOLVED(ret, "Unable to block SIGUSR1 and SIGUSR2" " in signal thread"); while (do_it1) { #ifdef WITH_SYNCHRO ret = sem_wait(thearg->sem); if (ret) UNRESOLVED(errno, "Sem_wait in sendsig"); if (!do_it1) break; count_sig++; #endif /* keep increasing sleeptime to make sure we progress * allow SIGNALS_WITHOUT_DELAY signals without any pause, * then start increasing sleep_time to make sure all threads * can progress */ sleep_time++; if (sleep_time / SIGNALS_WITHOUT_DELAY > 0) usleep(sleep_time / SIGNALS_WITHOUT_DELAY); ret = kill(process, thearg->sig); if (ret != 0) UNRESOLVED(errno, "Kill in sendsig"); } return NULL; } static void sighdl1(int sig) { #ifdef WITH_SYNCHRO if (sem_post(&semsig1)) UNRESOLVED(errno, "Sem_post in signal handler 1"); #endif } static void *threaded(void *arg) { int ret; /* We don't block the signals SIGUSR1 and SIGUSR2 for this THREAD */ ret = pthread_sigmask(SIG_UNBLOCK, &usersigs, NULL); if (ret != 0) UNRESOLVED(ret, "Unable to unblock SIGUSR1 and SIGUSR2" " in worker thread"); ret = pthread_detach(pthread_self()); if (ret == EINTR) FAILED("pthread_detach() returned EINTR"); /* Signal we're done */ do { ret = sem_post(&scenarii[sc].sem); } while ((ret == -1) && (errno == EINTR)); if (ret == -1) UNRESOLVED(errno, "Failed to wait for the semaphore"); return arg; } static void *test(void *arg) { int ret = 0; pthread_t child; /* We block the signals SIGUSR1 and SIGUSR2 for this THREAD */ ret = pthread_sigmask(SIG_BLOCK, &usersigs, NULL); if (ret != 0) UNRESOLVED(ret, "Unable to block SIGUSR1 and SIGUSR2" " in signal thread"); for (sc = 0; sc < NSCENAR; sc++) { #if VERBOSE > 5 output("-----\n"); output("Starting test with scenario (%i): %s\n", sc, scenarii[sc].descr); #endif /* reset sleep time for signal thread */ sleep_time = 0; /* thread which is already detached is not interesting * for this test, skip it */ if (scenarii[sc].detached == 1) continue; ret = pthread_create(&child, &scenarii[sc].ta, threaded, NULL); switch (scenarii[sc].result) { case 0: /* Operation was expected to succeed */ if (ret != 0) UNRESOLVED(ret, "Failed to create this thread"); break; case 1: /* Operation was expected to fail */ if (ret == 0) UNRESOLVED(-1, "An error was expected but the" " thread creation succeeded"); break; case 2: /* We did not know the expected result */ default: #if VERBOSE > 5 if (ret == 0) output("Thread has been created successfully" " for this scenario\n"); else output("Thread creation failed with the error:" " %s\n", strerror(ret)); #endif break; } if (ret == 0) { /* Just wait for the thread to terminate */ do { ret = sem_wait(&scenarii[sc].sem); } while ((ret == -1) && (errno == EINTR)); if (ret == -1) UNRESOLVED(errno, "Failed to wait for the" " semaphore"); } } return NULL; } void do_child() { struct thestruct arg1; pthread_t th_work, th_sig1; struct sigaction sa; int ret; /* We prepare a signal set which includes SIGUSR1 and SIGUSR2 */ sigemptyset(&usersigs); ret = sigaddset(&usersigs, SIGUSR1); /* ret |= sigaddset(&usersigs, SIGUSR2); */ if (ret != 0) UNRESOLVED(ret, "Unable to add SIGUSR1 or 2 to a signal set"); /* We now block the signals SIGUSR1 and SIGUSR2 for this THREAD */ ret = pthread_sigmask(SIG_BLOCK, &usersigs, NULL); if (ret != 0) UNRESOLVED(ret, "Unable to block SIGUSR1 and SIGUSR2" " in main thread"); /* We need to register the signal handlers for the PROCESS */ sigemptyset(&sa.sa_mask); sa.sa_flags = 0; sa.sa_handler = sighdl1; ret = sigaction(SIGUSR1, &sa, NULL); if (ret) UNRESOLVED(ret, "Unable to register signal handler1"); arg1.sig = SIGUSR1; #ifdef WITH_SYNCHRO if (sem_init(&semsig1, 0, 1)) UNRESOLVED(errno, "Semsig1 init"); arg1.sem = &semsig1; #endif count_sig = 0; ret = pthread_create(&th_sig1, NULL, sendsig, &arg1); if (ret) UNRESOLVED(ret, "Signal 1 sender thread creation failed"); ret = pthread_create(&th_work, NULL, test, NULL); if (ret) UNRESOLVED(ret, "Worker thread creation failed"); ret = pthread_join(th_work, NULL); if (ret) UNRESOLVED(ret, "Worker thread join failed"); /* to be extra safe unblock signals in this thread, * so signal thread won't get stuck on sem_wait */ ret = pthread_sigmask(SIG_UNBLOCK, &usersigs, NULL); if (ret != 0) UNRESOLVED(ret, "Failed to unblock signals"); do_it1 = 0; #ifdef WITH_SYNCHRO /* if it's already stuck on sem_wait, up the semaphore */ if (sem_post(&semsig1)) UNRESOLVED(errno, "Sem_post in do_child"); #endif ret = pthread_join(th_sig1, NULL); if (ret) UNRESOLVED(ret, "Worker thread join failed"); } void main_loop() { int child_count = 0; int stat_pipe[2]; int ret; int status; pid_t child; unsigned long usec_start, usec; unsigned long child_count_sig; usec_start = current_time_usec(); do { SAFE(pipe(stat_pipe)); child_count++; count_ope += NSCENAR; child = fork(); if (child == 0) { close(stat_pipe[0]); do_child(); SAFE(write(stat_pipe[1], &count_sig, sizeof(count_sig))); close(stat_pipe[1]); pthread_exit(0); UNRESOLVED(0, "Should not be reached"); exit(0); } close(stat_pipe[1]); SAFE(read(stat_pipe[0], &child_count_sig, sizeof(count_sig))); close(stat_pipe[0]); count_sig += child_count_sig; ret = waitpid(child, &status, 0); if (ret != child) UNRESOLVED(errno, "Waitpid returned the wrong PID"); if (!WIFEXITED(status)) { output("status: %d\n", status); FAILED("Child exited abnormally"); } if (WEXITSTATUS(status) != 0) { output("exit status: %d\n", WEXITSTATUS(status)); FAILED("An error occured in child"); } usec = current_time_usec(); } while ((usec - usec_start) < RUN_TIME_USEC); output("Test spawned %d child processes.\n", child_count); output("Test finished after %lu usec.\n", usec - usec_start); } int main(int argc, char *argv[]) { int ret; output_init(); scenar_init(); main_loop(); scenar_fini(); #if VERBOSE > 0 output("Test executed successfully.\n"); output(" %d threads detached.\n", count_ope); #ifdef WITH_SYNCHRO output(" %d signals were sent meanwhile.\n", count_sig); #endif #endif PASSED; } [-- Attachment #3: Type: text/plain, Size: 395 bytes --] ------------------------------------------------------------------------------ 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/ [-- Attachment #4: Type: text/plain, Size: 155 bytes --] _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault 2012-08-23 11:07 ` Jan Stancek @ 2012-08-24 2:46 ` Kang Kai 2012-08-28 8:37 ` Jan Stancek 0 siblings, 1 reply; 24+ messages in thread From: Kang Kai @ 2012-08-24 2:46 UTC (permalink / raw) To: Jan Stancek; +Cc: ltp-list, Zhenfeng Zhao On 2012年08月23日 19:07, Jan Stancek wrote: > On 08/23/2012 09:09 AM, Jan Stancek wrote: >> >> ----- Original Message ----- >>> From: "Kang Kai"<Kai.Kang@windriver.com> >>> To: "Jan Stancek"<jstancek@redhat.com>, gaowanlong@cn.fujitsu.com >>> Cc: ltp-list@lists.sourceforge.net, "Zhenfeng Zhao"<Zhenfeng.Zhao@windriver.com> >>> 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"<Kai.Kang@windriver.com> >>>>>> To: "Jan Stancek"<jstancek@redhat.com> >>>>>> Cc: gaowanlong@cn.fujitsu.com, ltp-list@lists.sourceforge.net, >>>>>> "Zhenfeng Zhao"<Zhenfeng.Zhao@windriver.com> >>>>>> 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. Hi Jan, Great! > Kai, would you like to give a try? I have test it on routerstation, x86_64(ubuntu11.10 & redhat 5.3) and x86(redhat 5.3) each 100+ times, and all PASS. Regards, Kai > > 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 ------------------------------------------------------------------------------ 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault 2012-08-24 2:46 ` Kang Kai @ 2012-08-28 8:37 ` Jan Stancek 2012-08-29 8:57 ` Kang Kai 0 siblings, 1 reply; 24+ messages in thread From: Jan Stancek @ 2012-08-28 8:37 UTC (permalink / raw) To: Kang Kai; +Cc: ltp-list, Zhenfeng Zhao ----- Original Message ----- > From: "Kang Kai" <Kai.Kang@windriver.com> > To: "Jan Stancek" <jstancek@redhat.com> > Cc: ltp-list@lists.sourceforge.net, "Zhenfeng Zhao" <Zhenfeng.Zhao@windriver.com> > Sent: Friday, 24 August, 2012 4:46:58 AM > Subject: Re: [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault > >> 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. > > Hi Jan, > > Great! > > Kai, would you like to give a try? > I have test it on routerstation, x86_64(ubuntu11.10 & redhat 5.3) and > x86(redhat 5.3) each 100+ times, and all PASS. > Hi, I'm still looking at this testcase. I have been testing v1 more on different releases and arches and I'm hitting an issue on ppc64 RHEL6.3. I'm getting abort from gcc_assert. The most interesting thing is that thread, which aborts shouldn't exist, because for this scenario pthread_create returns 1 (EPERM). (gdb) bt #0 0x0000008066374e50 in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x0000008066376de4 in abort () at abort.c:92 #2 0x000000806687e504 in _Unwind_SetSpColumn (context=0xfff97a0df58, outer_cfa=0xfff97a0e610, outer_ra=0x8066548904) at ../../../gcc/unwind-dw2.c:1265 #3 uw_init_context_1 (context=0xfff97a0df58, outer_cfa=0xfff97a0e610, outer_ra=0x8066548904) at ../../../gcc/unwind-dw2.c:1472 #4 0x000000806687ebe0 in _Unwind_ForcedUnwind (exc=0xfff97a0f670, stop=@0x8066560ad8: 0x8066545660 <unwind_stop>, stop_argument=0xfff97a0e880) at ../../../gcc/unwind.inc:201 #5 0x0000008066548904 in _Unwind_ForcedUnwind (exc=<value optimized out>, stop=<value optimized out>, stop_argument=<value optimized out>) at ../nptl/sysdeps/pthread/unwind-forcedunwind.c:132 #6 0x0000008066545600 in __pthread_unwind (buf=<value optimized out>) at unwind.c:130 #7 0x0000008066545bac in __do_cancel () at pthreadP.h:265 #8 __pthread_enable_asynccancel () at cancellation.c:49 #9 0x000000806653c568 in start_thread (arg=0xfff97a0f200) at pthread_create.c:289 #10 0x000000806643a32c in .__clone () from /lib64/libc-2.12.so (gdb) frame 2 #2 0x000000806687e504 in _Unwind_SetSpColumn (context=0xfff97a0df58, outer_cfa=0xfff97a0e610, outer_ra=0x8066548904) at ../../../gcc/unwind-dw2.c:1265 1265 gcc_assert (size == sizeof(_Unwind_Word)); The arg in threaded() is not used for anything, so I passed scenario number as parameter. (gdb) p/x ((struct pthread *) 0xfff97a0f200)->arg $1 = 0x12 So it's thread for scenario 0x12. This scenario tries to set explicit scheduling with max priority. When you run this as unprivileged user, pthread_create gives you EPERM. This comment is interesting, same gcc_assert(), also power7: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839#c10 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault 2012-08-28 8:37 ` Jan Stancek @ 2012-08-29 8:57 ` Kang Kai 2012-08-29 9:21 ` Jan Stancek 0 siblings, 1 reply; 24+ messages in thread From: Kang Kai @ 2012-08-29 8:57 UTC (permalink / raw) To: Jan Stancek; +Cc: ltp-list, Zhenfeng Zhao On 2012年08月28日 16:37, Jan Stancek wrote: > > ----- Original Message ----- >> From: "Kang Kai"<Kai.Kang@windriver.com> >> To: "Jan Stancek"<jstancek@redhat.com> >> Cc: ltp-list@lists.sourceforge.net, "Zhenfeng Zhao"<Zhenfeng.Zhao@windriver.com> >> Sent: Friday, 24 August, 2012 4:46:58 AM >> Subject: Re: [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault >>>> 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. >> Hi Jan, >> >> Great! >>> Kai, would you like to give a try? >> I have test it on routerstation, x86_64(ubuntu11.10& redhat 5.3) and >> x86(redhat 5.3) each 100+ times, and all PASS. >> > Hi, > > I'm still looking at this testcase. I have been testing v1 more on different > releases and arches and I'm hitting an issue on ppc64 RHEL6.3. > > I'm getting abort from gcc_assert. The most interesting thing is that > thread, which aborts shouldn't exist, because for this scenario pthread_create > returns 1 (EPERM). > > (gdb) bt > #0 0x0000008066374e50 in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > #1 0x0000008066376de4 in abort () at abort.c:92 > #2 0x000000806687e504 in _Unwind_SetSpColumn (context=0xfff97a0df58, outer_cfa=0xfff97a0e610, outer_ra=0x8066548904) at ../../../gcc/unwind-dw2.c:1265 > #3 uw_init_context_1 (context=0xfff97a0df58, outer_cfa=0xfff97a0e610, outer_ra=0x8066548904) at ../../../gcc/unwind-dw2.c:1472 > #4 0x000000806687ebe0 in _Unwind_ForcedUnwind (exc=0xfff97a0f670, stop=@0x8066560ad8: 0x8066545660<unwind_stop>, stop_argument=0xfff97a0e880) at ../../../gcc/unwind.inc:201 > #5 0x0000008066548904 in _Unwind_ForcedUnwind (exc=<value optimized out>, stop=<value optimized out>, stop_argument=<value optimized out>) at ../nptl/sysdeps/pthread/unwind-forcedunwind.c:132 > #6 0x0000008066545600 in __pthread_unwind (buf=<value optimized out>) at unwind.c:130 > #7 0x0000008066545bac in __do_cancel () at pthreadP.h:265 > #8 __pthread_enable_asynccancel () at cancellation.c:49 > #9 0x000000806653c568 in start_thread (arg=0xfff97a0f200) at pthread_create.c:289 > #10 0x000000806643a32c in .__clone () from /lib64/libc-2.12.so > > (gdb) frame 2 > #2 0x000000806687e504 in _Unwind_SetSpColumn (context=0xfff97a0df58, outer_cfa=0xfff97a0e610, outer_ra=0x8066548904) at ../../../gcc/unwind-dw2.c:1265 > 1265 gcc_assert (size == sizeof(_Unwind_Word)); > > The arg in threaded() is not used for anything, so I passed scenario number as parameter. > (gdb) p/x ((struct pthread *) 0xfff97a0f200)->arg > $1 = 0x12 > > So it's thread for scenario 0x12. This scenario tries to set explicit scheduling with max > priority. When you run this as unprivileged user, pthread_create gives you EPERM. Is it proper for this case that limit only root can run? Regards, Kai > > This comment is interesting, same gcc_assert(), also power7: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839#c10 > > 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault 2012-08-29 8:57 ` Kang Kai @ 2012-08-29 9:21 ` Jan Stancek 0 siblings, 0 replies; 24+ messages in thread From: Jan Stancek @ 2012-08-29 9:21 UTC (permalink / raw) To: Kang Kai; +Cc: ltp-list, Zhenfeng Zhao ----- Original Message ----- > From: "Kang Kai" <Kai.Kang@windriver.com> > To: "Jan Stancek" <jstancek@redhat.com> > Cc: ltp-list@lists.sourceforge.net, "Zhenfeng Zhao" <Zhenfeng.Zhao@windriver.com> > Sent: Wednesday, 29 August, 2012 10:57:39 AM > Subject: Re: [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault > > On 2012年08月28日 16:37, Jan Stancek wrote: > > > > ----- Original Message ----- > >> From: "Kang Kai"<Kai.Kang@windriver.com> > >> To: "Jan Stancek"<jstancek@redhat.com> > >> Cc: ltp-list@lists.sourceforge.net, "Zhenfeng > >> Zhao"<Zhenfeng.Zhao@windriver.com> > >> Sent: Friday, 24 August, 2012 4:46:58 AM > >> Subject: Re: [LTP] [PATCH] pthread_detach/4-3: workaround for > >> segment fault > >>>> 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. > >> Hi Jan, > >> > >> Great! > >>> Kai, would you like to give a try? > >> I have test it on routerstation, x86_64(ubuntu11.10& redhat 5.3) > >> and > >> x86(redhat 5.3) each 100+ times, and all PASS. > >> > > Hi, > > > > I'm still looking at this testcase. I have been testing v1 more on > > different > > releases and arches and I'm hitting an issue on ppc64 RHEL6.3. > > > > I'm getting abort from gcc_assert. The most interesting thing is > > that > > thread, which aborts shouldn't exist, because for this scenario > > pthread_create > > returns 1 (EPERM). > > > > (gdb) bt > > #0 0x0000008066374e50 in raise (sig=<value optimized out>) at > > ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > > #1 0x0000008066376de4 in abort () at abort.c:92 > > #2 0x000000806687e504 in _Unwind_SetSpColumn > > (context=0xfff97a0df58, outer_cfa=0xfff97a0e610, > > outer_ra=0x8066548904) at ../../../gcc/unwind-dw2.c:1265 > > #3 uw_init_context_1 (context=0xfff97a0df58, > > outer_cfa=0xfff97a0e610, outer_ra=0x8066548904) at > > ../../../gcc/unwind-dw2.c:1472 > > #4 0x000000806687ebe0 in _Unwind_ForcedUnwind (exc=0xfff97a0f670, > > stop=@0x8066560ad8: 0x8066545660<unwind_stop>, > > stop_argument=0xfff97a0e880) at ../../../gcc/unwind.inc:201 > > #5 0x0000008066548904 in _Unwind_ForcedUnwind (exc=<value > > optimized out>, stop=<value optimized out>, stop_argument=<value > > optimized out>) at > > ../nptl/sysdeps/pthread/unwind-forcedunwind.c:132 > > #6 0x0000008066545600 in __pthread_unwind (buf=<value optimized > > out>) at unwind.c:130 > > #7 0x0000008066545bac in __do_cancel () at pthreadP.h:265 > > #8 __pthread_enable_asynccancel () at cancellation.c:49 > > #9 0x000000806653c568 in start_thread (arg=0xfff97a0f200) at > > pthread_create.c:289 > > #10 0x000000806643a32c in .__clone () from /lib64/libc-2.12.so > > > > (gdb) frame 2 > > #2 0x000000806687e504 in _Unwind_SetSpColumn > > (context=0xfff97a0df58, outer_cfa=0xfff97a0e610, > > outer_ra=0x8066548904) at ../../../gcc/unwind-dw2.c:1265 > > 1265 gcc_assert (size == sizeof(_Unwind_Word)); > > > > The arg in threaded() is not used for anything, so I passed > > scenario number as parameter. > > (gdb) p/x ((struct pthread *) 0xfff97a0f200)->arg > > $1 = 0x12 > > > > So it's thread for scenario 0x12. This scenario tries to set > > explicit scheduling with max > > priority. When you run this as unprivileged user, pthread_create > > gives you EPERM. > Is it proper for this case that limit only root can run? We could skip scenarios we know are going to fail for unprivileged user, it will likely avoid hitting that gcc_assert. Anyway, so far this looks like gcc/glibc issue, I created bug for it: Bug 852445 - gcc_assert failure in _Unwind_SetSpColumn() on ppc64 https://bugzilla.redhat.com/show_bug.cgi?id=852445 Regards, Jan > > Regards, > Kai > > > > > This comment is interesting, same gcc_assert(), also power7: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839#c10 > > > > 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault @ 2012-08-14 9:00 Kang Kai 2012-08-18 22:58 ` Wanlong Gao 0 siblings, 1 reply; 24+ messages in thread From: Kang Kai @ 2012-08-14 9:00 UTC (permalink / raw) To: ltp-list; +Cc: Zhenfeng.Zhao This case fails randomly with "Segmentation fault". Reset VERBOSE to 6 can avoid this problem. Fix typo at same time. Signed-off-by: Kang Kai <kai.kang@windriver.com> --- .../conformance/interfaces/pthread_detach/4-3.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/testcases/open_posix_testsuite/conformance/interfaces/pthread_detach/4-3.c b/testcases/open_posix_testsuite/conformance/interfaces/pthread_detach/4-3.c index 5c15e93..23738dc 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 @@ -49,7 +49,7 @@ #include "../testfrmw/testfrmw.c" #ifndef VERBOSE -#define VERBOSE 1 +#define VERBOSE 6 #endif #define WITH_SYNCHRO @@ -281,7 +281,7 @@ int main(int argc, char *argv[]) do { do_it2 = 0; - } while (do_it2 = 0); + } while (do_it2); ret = pthread_join(th_sig1, NULL); if (ret) -- 1.7.5.4 ------------------------------------------------------------------------------ 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 ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault 2012-08-14 9:00 Kang Kai @ 2012-08-18 22:58 ` Wanlong Gao 2012-08-20 1:39 ` Kang Kai 0 siblings, 1 reply; 24+ messages in thread From: Wanlong Gao @ 2012-08-18 22:58 UTC (permalink / raw) To: Kang Kai; +Cc: ltp-list, Zhenfeng.Zhao On 08/14/2012 05:00 PM, Kang Kai wrote: > This case fails randomly with "Segmentation fault". Reset VERBOSE to 6 > can avoid this problem. Can you explain that why "reset VERBOSE" can avoid this "Seg Fault" problem? > > Fix typo at same time. The typo fix is OK. Thanks, Wanlong Gao > > Signed-off-by: Kang Kai <kai.kang@windriver.com> > --- > .../conformance/interfaces/pthread_detach/4-3.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/testcases/open_posix_testsuite/conformance/interfaces/pthread_detach/4-3.c b/testcases/open_posix_testsuite/conformance/interfaces/pthread_detach/4-3.c > index 5c15e93..23738dc 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 > @@ -49,7 +49,7 @@ > #include "../testfrmw/testfrmw.c" > > #ifndef VERBOSE > -#define VERBOSE 1 > +#define VERBOSE 6 > #endif > > #define WITH_SYNCHRO > @@ -281,7 +281,7 @@ int main(int argc, char *argv[]) > > do { > do_it2 = 0; > - } while (do_it2 = 0); > + } while (do_it2); > > ret = pthread_join(th_sig1, NULL); > if (ret) > ------------------------------------------------------------------------------ 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault 2012-08-18 22:58 ` Wanlong Gao @ 2012-08-20 1:39 ` Kang Kai 2012-08-20 2:01 ` Wanlong Gao 0 siblings, 1 reply; 24+ messages in thread From: Kang Kai @ 2012-08-20 1:39 UTC (permalink / raw) To: gaowanlong; +Cc: ltp-list, Zhenfeng.Zhao On 2012年08月19日 06:58, Wanlong Gao wrote: > On 08/14/2012 05:00 PM, Kang Kai wrote: >> This case fails randomly with "Segmentation fault". Reset VERBOSE to 6 >> can avoid this problem. > Can you explain that why "reset VERBOSE" can avoid this "Seg Fault" problem? It is a multi-thread issue. You can run it for less than 10 times, and it will fail with "Segmentation fault". It is hard to debug and I didn't find the root cause, but open the VERBOSE will avoid this situation. So it is a workaround. Regards, Kai > >> Fix typo at same time. > The typo fix is OK. > > Thanks, > Wanlong Gao > >> Signed-off-by: Kang Kai<kai.kang@windriver.com> >> --- >> .../conformance/interfaces/pthread_detach/4-3.c | 4 ++-- >> 1 files changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/testcases/open_posix_testsuite/conformance/interfaces/pthread_detach/4-3.c b/testcases/open_posix_testsuite/conformance/interfaces/pthread_detach/4-3.c >> index 5c15e93..23738dc 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 >> @@ -49,7 +49,7 @@ >> #include "../testfrmw/testfrmw.c" >> >> #ifndef VERBOSE >> -#define VERBOSE 1 >> +#define VERBOSE 6 >> #endif >> >> #define WITH_SYNCHRO >> @@ -281,7 +281,7 @@ int main(int argc, char *argv[]) >> >> do { >> do_it2 = 0; >> - } while (do_it2 = 0); >> + } while (do_it2); >> >> ret = pthread_join(th_sig1, NULL); >> if (ret) >> > ------------------------------------------------------------------------------ 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault 2012-08-20 1:39 ` Kang Kai @ 2012-08-20 2:01 ` Wanlong Gao 2012-08-20 2:21 ` Kang Kai 0 siblings, 1 reply; 24+ messages in thread From: Wanlong Gao @ 2012-08-20 2:01 UTC (permalink / raw) To: Kang Kai; +Cc: ltp-list, Zhenfeng.Zhao On 08/20/2012 09:39 AM, Kang Kai wrote: > On 2012年08月19日 06:58, Wanlong Gao wrote: >> On 08/14/2012 05:00 PM, Kang Kai wrote: >>> This case fails randomly with "Segmentation fault". Reset VERBOSE to 6 >>> can avoid this problem. >> Can you explain that why "reset VERBOSE" can avoid this "Seg Fault" problem? > It is a multi-thread issue. You can run it for less than 10 times, and it will fail with "Segmentation fault". I didn't see this on my side. > It is hard to debug and I didn't find the root cause, but open the VERBOSE will avoid this situation. So it is a workaround. I'd like to send a patch to fix this typo first. Thanks, Wanlong Gao > > Regards, > Kai > >> >>> Fix typo at same time. >> The typo fix is OK. >> >> Thanks, >> Wanlong Gao >> >>> Signed-off-by: Kang Kai<kai.kang@windriver.com> >>> --- >>> .../conformance/interfaces/pthread_detach/4-3.c | 4 ++-- >>> 1 files changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/testcases/open_posix_testsuite/conformance/interfaces/pthread_detach/4-3.c b/testcases/open_posix_testsuite/conformance/interfaces/pthread_detach/4-3.c >>> index 5c15e93..23738dc 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 >>> @@ -49,7 +49,7 @@ >>> #include "../testfrmw/testfrmw.c" >>> >>> #ifndef VERBOSE >>> -#define VERBOSE 1 >>> +#define VERBOSE 6 >>> #endif >>> >>> #define WITH_SYNCHRO >>> @@ -281,7 +281,7 @@ int main(int argc, char *argv[]) >>> >>> do { >>> do_it2 = 0; >>> - } while (do_it2 = 0); >>> + } while (do_it2); >>> >>> ret = pthread_join(th_sig1, NULL); >>> if (ret) >>> >> > > ------------------------------------------------------------------------------ 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault 2012-08-20 2:01 ` Wanlong Gao @ 2012-08-20 2:21 ` Kang Kai 2012-08-21 1:31 ` Kang Kai 0 siblings, 1 reply; 24+ messages in thread From: Kang Kai @ 2012-08-20 2:21 UTC (permalink / raw) To: gaowanlong; +Cc: ltp-list, Zhenfeng.Zhao On 2012年08月20日 10:01, Wanlong Gao wrote: > On 08/20/2012 09:39 AM, Kang Kai wrote: >> On 2012年08月19日 06:58, Wanlong Gao wrote: >>> On 08/14/2012 05:00 PM, Kang Kai wrote: >>>> This case fails randomly with "Segmentation fault". Reset VERBOSE to 6 >>>> can avoid this problem. >>> Can you explain that why "reset VERBOSE" can avoid this "Seg Fault" problem? >> It is a multi-thread issue. You can run it for less than 10 times, and it will fail with "Segmentation fault". > I didn't see this on my side. It fails both on mips and x86_64. On the x86_64, cpu: Intel I7 OS: Ubuntu 11.10 libc: eglibc 2.13 kernel: 3.0.0-12-generic How about try this script on a x86_64 machine: for i in $(seq 100); do echo $i; ./4-3.run-test ; ret=$?; if [ $ret -ne 0 ]; then echo $? ; break; fi; done > >> It is hard to debug and I didn't find the root cause, but open the VERBOSE will avoid this situation. So it is a workaround. > I'd like to send a patch to fix this typo first. Fine. Regards, Kai > > Thanks, > Wanlong Gao > >> Regards, >> Kai >> >>>> Fix typo at same time. >>> The typo fix is OK. >>> >>> Thanks, >>> Wanlong Gao >>> >>>> Signed-off-by: Kang Kai<kai.kang@windriver.com> >>>> --- >>>> .../conformance/interfaces/pthread_detach/4-3.c | 4 ++-- >>>> 1 files changed, 2 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/testcases/open_posix_testsuite/conformance/interfaces/pthread_detach/4-3.c b/testcases/open_posix_testsuite/conformance/interfaces/pthread_detach/4-3.c >>>> index 5c15e93..23738dc 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 >>>> @@ -49,7 +49,7 @@ >>>> #include "../testfrmw/testfrmw.c" >>>> >>>> #ifndef VERBOSE >>>> -#define VERBOSE 1 >>>> +#define VERBOSE 6 >>>> #endif >>>> >>>> #define WITH_SYNCHRO >>>> @@ -281,7 +281,7 @@ int main(int argc, char *argv[]) >>>> >>>> do { >>>> do_it2 = 0; >>>> - } while (do_it2 = 0); >>>> + } while (do_it2); >>>> >>>> ret = pthread_join(th_sig1, NULL); >>>> if (ret) >>>> >> > ------------------------------------------------------------------------------ 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault 2012-08-20 2:21 ` Kang Kai @ 2012-08-21 1:31 ` Kang Kai 2012-08-21 1:35 ` Wanlong Gao 0 siblings, 1 reply; 24+ messages in thread From: Kang Kai @ 2012-08-21 1:31 UTC (permalink / raw) To: Kang Kai; +Cc: ltp-list, Zhenfeng.Zhao On 2012年08月20日 10:21, Kang Kai wrote: > On 2012年08月20日 10:01, Wanlong Gao wrote: >> On 08/20/2012 09:39 AM, Kang Kai wrote: >>> On 2012年08月19日 06:58, Wanlong Gao wrote: >>>> On 08/14/2012 05:00 PM, Kang Kai wrote: >>>>> This case fails randomly with "Segmentation fault". Reset VERBOSE to 6 >>>>> can avoid this problem. >>>> Can you explain that why "reset VERBOSE" can avoid this "Seg Fault" problem? >>> It is a multi-thread issue. You can run it for less than 10 times, and it will fail with "Segmentation fault". >> I didn't see this on my side. Hi Wanlong, > It fails both on mips and x86_64. > On the x86_64, > cpu: Intel I7 > OS: Ubuntu 11.10 > libc: eglibc 2.13 > kernel: 3.0.0-12-generic > > How about try this script on a x86_64 machine: > for i in $(seq 100); do echo $i; ./4-3.run-test ; ret=$?; if [ $ret -ne > 0 ]; then echo $? ; break; fi; done Do you meet the "Segmentation Fault" yet? Regards, Kai >>> It is hard to debug and I didn't find the root cause, but open the VERBOSE will avoid this situation. So it is a workaround. >> I'd like to send a patch to fix this typo first. > Fine. > > Regards, > Kai > >> Thanks, >> Wanlong Gao >> >>> Regards, >>> Kai >>> >>>>> Fix typo at same time. >>>> The typo fix is OK. >>>> >>>> Thanks, >>>> Wanlong Gao >>>> >>>>> Signed-off-by: Kang Kai<kai.kang@windriver.com> >>>>> --- >>>>> .../conformance/interfaces/pthread_detach/4-3.c | 4 ++-- >>>>> 1 files changed, 2 insertions(+), 2 deletions(-) >>>>> >>>>> diff --git a/testcases/open_posix_testsuite/conformance/interfaces/pthread_detach/4-3.c b/testcases/open_posix_testsuite/conformance/interfaces/pthread_detach/4-3.c >>>>> index 5c15e93..23738dc 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 >>>>> @@ -49,7 +49,7 @@ >>>>> #include "../testfrmw/testfrmw.c" >>>>> >>>>> #ifndef VERBOSE >>>>> -#define VERBOSE 1 >>>>> +#define VERBOSE 6 >>>>> #endif >>>>> >>>>> #define WITH_SYNCHRO >>>>> @@ -281,7 +281,7 @@ int main(int argc, char *argv[]) >>>>> >>>>> do { >>>>> do_it2 = 0; >>>>> - } while (do_it2 = 0); >>>>> + } while (do_it2); >>>>> >>>>> ret = pthread_join(th_sig1, NULL); >>>>> if (ret) >>>>> > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault 2012-08-21 1:31 ` Kang Kai @ 2012-08-21 1:35 ` Wanlong Gao 2012-08-21 9:24 ` Kang Kai 0 siblings, 1 reply; 24+ messages in thread From: Wanlong Gao @ 2012-08-21 1:35 UTC (permalink / raw) To: Kang Kai; +Cc: ltp-list, Zhenfeng.Zhao On 08/21/2012 09:31 AM, Kang Kai wrote: > On 2012年08月20日 10:21, Kang Kai wrote: >> On 2012年08月20日 10:01, Wanlong Gao wrote: >>> On 08/20/2012 09:39 AM, Kang Kai wrote: >>>> On 2012年08月19日 06:58, Wanlong Gao wrote: >>>>> On 08/14/2012 05:00 PM, Kang Kai wrote: >>>>>> This case fails randomly with "Segmentation fault". Reset VERBOSE to 6 >>>>>> can avoid this problem. >>>>> Can you explain that why "reset VERBOSE" can avoid this "Seg Fault" problem? >>>> It is a multi-thread issue. You can run it for less than 10 times, and it will fail with "Segmentation fault". >>> I didn't see this on my side. > > Hi Wanlong, > >> It fails both on mips and x86_64. >> On the x86_64, >> cpu: Intel I7 >> OS: Ubuntu 11.10 >> libc: eglibc 2.13 >> kernel: 3.0.0-12-generic >> >> How about try this script on a x86_64 machine: >> for i in $(seq 100); do echo $i; ./4-3.run-test ; ret=$?; if [ $ret -ne >> 0 ]; then echo $? ; break; fi; done > > Do you meet the "Segmentation Fault" yet? Not yet. Thanks, Wanlong Gao > > Regards, > Kai > >>>> It is hard to debug and I didn't find the root cause, but open the VERBOSE will avoid this situation. So it is a workaround. >>> I'd like to send a patch to fix this typo first. >> Fine. >> >> Regards, >> Kai >> >>> Thanks, >>> Wanlong Gao >>> >>>> Regards, >>>> Kai >>>> >>>>>> Fix typo at same time. >>>>> The typo fix is OK. >>>>> >>>>> Thanks, >>>>> Wanlong Gao >>>>> >>>>>> Signed-off-by: Kang Kai<kai.kang@windriver.com> >>>>>> --- >>>>>> .../conformance/interfaces/pthread_detach/4-3.c | 4 ++-- >>>>>> 1 files changed, 2 insertions(+), 2 deletions(-) >>>>>> >>>>>> diff --git a/testcases/open_posix_testsuite/conformance/interfaces/pthread_detach/4-3.c b/testcases/open_posix_testsuite/conformance/interfaces/pthread_detach/4-3.c >>>>>> index 5c15e93..23738dc 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 >>>>>> @@ -49,7 +49,7 @@ >>>>>> #include "../testfrmw/testfrmw.c" >>>>>> >>>>>> #ifndef VERBOSE >>>>>> -#define VERBOSE 1 >>>>>> +#define VERBOSE 6 >>>>>> #endif >>>>>> >>>>>> #define WITH_SYNCHRO >>>>>> @@ -281,7 +281,7 @@ int main(int argc, char *argv[]) >>>>>> >>>>>> do { >>>>>> do_it2 = 0; >>>>>> - } while (do_it2 = 0); >>>>>> + } while (do_it2); >>>>>> >>>>>> ret = pthread_join(th_sig1, NULL); >>>>>> if (ret) >>>>>> >> >> ------------------------------------------------------------------------------ >> 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 > > ------------------------------------------------------------------------------ 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault 2012-08-21 1:35 ` Wanlong Gao @ 2012-08-21 9:24 ` Kang Kai 2012-08-21 9:24 ` Wanlong Gao 2012-08-21 9:45 ` Jan Stancek 0 siblings, 2 replies; 24+ messages in thread From: Kang Kai @ 2012-08-21 9:24 UTC (permalink / raw) To: gaowanlong; +Cc: ltp-list, Zhenfeng.Zhao On 2012年08月21日 09:35, Wanlong Gao wrote: > On 08/21/2012 09:31 AM, Kang Kai wrote: >> On 2012年08月20日 10:21, Kang Kai wrote: >>> On 2012年08月20日 10:01, Wanlong Gao wrote: >>>> On 08/20/2012 09:39 AM, Kang Kai wrote: >>>>> On 2012年08月19日 06:58, Wanlong Gao wrote: >>>>>> On 08/14/2012 05:00 PM, Kang Kai wrote: >>>>>>> This case fails randomly with "Segmentation fault". Reset VERBOSE to 6 >>>>>>> can avoid this problem. >>>>>> Can you explain that why "reset VERBOSE" can avoid this "Seg Fault" problem? >>>>> It is a multi-thread issue. You can run it for less than 10 times, and it will fail with "Segmentation fault". >>>> I didn't see this on my side. >> Hi Wanlong, >> >>> It fails both on mips and x86_64. >>> On the x86_64, >>> cpu: Intel I7 >>> OS: Ubuntu 11.10 >>> libc: eglibc 2.13 >>> kernel: 3.0.0-12-generic >>> >>> How about try this script on a x86_64 machine: >>> for i in $(seq 100); do echo $i; ./4-3.run-test ; ret=$?; if [ $ret -ne >>> 0 ]; then echo $? ; break; fi; done >> Do you meet the "Segmentation Fault" yet? Hi Wanlong, > Not yet. I test it on x86_64 with Redhat 5.3, it doesn't fail. I try to compare them to find why it fails with Ubuntu 11.10. Thanks, Kai > > Thanks, > Wanlong Gao > >> Regards, >> Kai >> >>>>> It is hard to debug and I didn't find the root cause, but open the VERBOSE will avoid this situation. So it is a workaround. >>>> I'd like to send a patch to fix this typo first. >>> Fine. >>> >>> Regards, >>> Kai >>> >>>> Thanks, >>>> Wanlong Gao >>>> >>>>> Regards, >>>>> Kai >>>>> >>>>>>> Fix typo at same time. >>>>>> The typo fix is OK. >>>>>> >>>>>> Thanks, >>>>>> Wanlong Gao >>>>>> >>>>>>> Signed-off-by: Kang Kai<kai.kang@windriver.com> >>>>>>> --- >>>>>>> .../conformance/interfaces/pthread_detach/4-3.c | 4 ++-- >>>>>>> 1 files changed, 2 insertions(+), 2 deletions(-) >>>>>>> >>>>>>> diff --git a/testcases/open_posix_testsuite/conformance/interfaces/pthread_detach/4-3.c b/testcases/open_posix_testsuite/conformance/interfaces/pthread_detach/4-3.c >>>>>>> index 5c15e93..23738dc 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 >>>>>>> @@ -49,7 +49,7 @@ >>>>>>> #include "../testfrmw/testfrmw.c" >>>>>>> >>>>>>> #ifndef VERBOSE >>>>>>> -#define VERBOSE 1 >>>>>>> +#define VERBOSE 6 >>>>>>> #endif >>>>>>> >>>>>>> #define WITH_SYNCHRO >>>>>>> @@ -281,7 +281,7 @@ int main(int argc, char *argv[]) >>>>>>> >>>>>>> do { >>>>>>> do_it2 = 0; >>>>>>> - } while (do_it2 = 0); >>>>>>> + } while (do_it2); >>>>>>> >>>>>>> ret = pthread_join(th_sig1, NULL); >>>>>>> if (ret) >>>>>>> >>> ------------------------------------------------------------------------------ >>> 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 >> > ------------------------------------------------------------------------------ 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault 2012-08-21 9:24 ` Kang Kai @ 2012-08-21 9:24 ` Wanlong Gao 2012-08-21 9:45 ` Jan Stancek 1 sibling, 0 replies; 24+ messages in thread From: Wanlong Gao @ 2012-08-21 9:24 UTC (permalink / raw) To: Kang Kai; +Cc: ltp-list, Zhenfeng.Zhao On 08/21/2012 05:24 PM, Kang Kai wrote: > On 2012年08月21日 09:35, Wanlong Gao wrote: >> On 08/21/2012 09:31 AM, Kang Kai wrote: >>> On 2012年08月20日 10:21, Kang Kai wrote: >>>> On 2012年08月20日 10:01, Wanlong Gao wrote: >>>>> On 08/20/2012 09:39 AM, Kang Kai wrote: >>>>>> On 2012年08月19日 06:58, Wanlong Gao wrote: >>>>>>> On 08/14/2012 05:00 PM, Kang Kai wrote: >>>>>>>> This case fails randomly with "Segmentation fault". Reset VERBOSE to 6 >>>>>>>> can avoid this problem. >>>>>>> Can you explain that why "reset VERBOSE" can avoid this "Seg Fault" problem? >>>>>> It is a multi-thread issue. You can run it for less than 10 times, and it will fail with "Segmentation fault". >>>>> I didn't see this on my side. >>> Hi Wanlong, >>> >>>> It fails both on mips and x86_64. >>>> On the x86_64, >>>> cpu: Intel I7 >>>> OS: Ubuntu 11.10 >>>> libc: eglibc 2.13 >>>> kernel: 3.0.0-12-generic >>>> >>>> How about try this script on a x86_64 machine: >>>> for i in $(seq 100); do echo $i; ./4-3.run-test ; ret=$?; if [ $ret -ne >>>> 0 ]; then echo $? ; break; fi; done >>> Do you meet the "Segmentation Fault" yet? > > Hi Wanlong, >> Not yet. > I test it on x86_64 with Redhat 5.3, it doesn't fail. > I try to compare them to find why it fails with Ubuntu 11.10. OK, please. Thanks, Wanlong Gao > > Thanks, > Kai > >> >> Thanks, >> Wanlong Gao >> >>> Regards, >>> Kai >>> >>>>>> It is hard to debug and I didn't find the root cause, but open the VERBOSE will avoid this situation. So it is a workaround. >>>>> I'd like to send a patch to fix this typo first. >>>> Fine. >>>> >>>> Regards, >>>> Kai >>>> >>>>> Thanks, >>>>> Wanlong Gao >>>>> >>>>>> Regards, >>>>>> Kai >>>>>> >>>>>>>> Fix typo at same time. >>>>>>> The typo fix is OK. >>>>>>> >>>>>>> Thanks, >>>>>>> Wanlong Gao >>>>>>> >>>>>>>> Signed-off-by: Kang Kai<kai.kang@windriver.com> >>>>>>>> --- >>>>>>>> .../conformance/interfaces/pthread_detach/4-3.c | 4 ++-- >>>>>>>> 1 files changed, 2 insertions(+), 2 deletions(-) >>>>>>>> >>>>>>>> diff --git a/testcases/open_posix_testsuite/conformance/interfaces/pthread_detach/4-3.c b/testcases/open_posix_testsuite/conformance/interfaces/pthread_detach/4-3.c >>>>>>>> index 5c15e93..23738dc 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 >>>>>>>> @@ -49,7 +49,7 @@ >>>>>>>> #include "../testfrmw/testfrmw.c" >>>>>>>> >>>>>>>> #ifndef VERBOSE >>>>>>>> -#define VERBOSE 1 >>>>>>>> +#define VERBOSE 6 >>>>>>>> #endif >>>>>>>> >>>>>>>> #define WITH_SYNCHRO >>>>>>>> @@ -281,7 +281,7 @@ int main(int argc, char *argv[]) >>>>>>>> >>>>>>>> do { >>>>>>>> do_it2 = 0; >>>>>>>> - } while (do_it2 = 0); >>>>>>>> + } while (do_it2); >>>>>>>> >>>>>>>> ret = pthread_join(th_sig1, NULL); >>>>>>>> if (ret) >>>>>>>> >>>> ------------------------------------------------------------------------------ >>>> 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 >>> >> > > ------------------------------------------------------------------------------ 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault 2012-08-21 9:24 ` Kang Kai 2012-08-21 9:24 ` Wanlong Gao @ 2012-08-21 9:45 ` Jan Stancek 2012-08-21 9:59 ` Kang Kai 1 sibling, 1 reply; 24+ messages in thread From: Jan Stancek @ 2012-08-21 9:45 UTC (permalink / raw) To: Kang Kai; +Cc: ltp-list, Zhenfeng.Zhao On 08/21/2012 11:24 AM, Kang Kai wrote: > On 2012年08月21日 09:35, Wanlong Gao wrote: >> On 08/21/2012 09:31 AM, Kang Kai wrote: >>> On 2012年08月20日 10:21, Kang Kai wrote: >>>> On 2012年08月20日 10:01, Wanlong Gao wrote: >>>>> On 08/20/2012 09:39 AM, Kang Kai wrote: >>>>>> On 2012年08月19日 06:58, Wanlong Gao wrote: >>>>>>> On 08/14/2012 05:00 PM, Kang Kai wrote: >>>>>>>> This case fails randomly with "Segmentation fault". Reset VERBOSE to 6 >>>>>>>> can avoid this problem. >>>>>>> Can you explain that why "reset VERBOSE" can avoid this "Seg Fault" problem? >>>>>> It is a multi-thread issue. You can run it for less than 10 times, and it will fail with "Segmentation fault". >>>>> I didn't see this on my side. >>> Hi Wanlong, >>> >>>> It fails both on mips and x86_64. >>>> On the x86_64, >>>> cpu: Intel I7 >>>> OS: Ubuntu 11.10 >>>> libc: eglibc 2.13 >>>> kernel: 3.0.0-12-generic >>>> >>>> How about try this script on a x86_64 machine: >>>> for i in $(seq 100); do echo $i; ./4-3.run-test ; ret=$?; if [ $ret -ne >>>> 0 ]; then echo $? ; break; fi; done >>> Do you meet the "Segmentation Fault" yet? > > Hi Wanlong, >> Not yet. > I test it on x86_64 with Redhat 5.3, it doesn't fail. I tried to reproduce it on x86_64 RHEL6/7 (real hw+kvm) and ubuntu-12.04-server (kvm), but without any luck. I spotted one possible issue: diff --git a/testcases/open_posix_testsuite/conformance/interfaces/pthread_detach/4-3.c b/testcases/open_posix_testsuite/conforman index 5c15e93..7b738e7 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 @@ -129,9 +129,13 @@ static void *threaded(void *arg) UNRESOLVED(ret, "Unable to unblock SIGUSR1 and SIGUSR2" " in worker thread"); - ret = pthread_detach(pthread_self()); - if (ret == EINTR) - FAILED("pthread_detach() returned EINTR"); + /* Attempting to detach an already detached thread results + * in unspecified behavior */ + if (scenarii[sc].detached != 1) { + ret = pthread_detach(pthread_self()); + if (ret == EINTR) + FAILED("pthread_detach() returned EINTR"); + } /* Signal we're done */ do { Regards, Jan > I try to compare them to find why it fails with Ubuntu 11.10. > > Thanks, > Kai > >> >> Thanks, >> Wanlong Gao >> >>> Regards, >>> Kai >>> >>>>>> It is hard to debug and I didn't find the root cause, but open the VERBOSE will avoid this situation. So it is a workaround. >>>>> I'd like to send a patch to fix this typo first. >>>> Fine. >>>> >>>> Regards, >>>> Kai >>>> >>>>> Thanks, >>>>> Wanlong Gao >>>>> >>>>>> Regards, >>>>>> Kai >>>>>> >>>>>>>> Fix typo at same time. >>>>>>> The typo fix is OK. >>>>>>> >>>>>>> Thanks, >>>>>>> Wanlong Gao >>>>>>> >>>>>>>> Signed-off-by: Kang Kai<kai.kang@windriver.com> >>>>>>>> --- >>>>>>>> .../conformance/interfaces/pthread_detach/4-3.c | 4 ++-- >>>>>>>> 1 files changed, 2 insertions(+), 2 deletions(-) >>>>>>>> >>>>>>>> diff --git a/testcases/open_posix_testsuite/conformance/interfaces/pthread_detach/4-3.c b/testcases/open_posix_testsuite/conformance/interfaces/pthread_detach/4-3.c >>>>>>>> index 5c15e93..23738dc 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 >>>>>>>> @@ -49,7 +49,7 @@ >>>>>>>> #include "../testfrmw/testfrmw.c" >>>>>>>> >>>>>>>> #ifndef VERBOSE >>>>>>>> -#define VERBOSE 1 >>>>>>>> +#define VERBOSE 6 >>>>>>>> #endif >>>>>>>> >>>>>>>> #define WITH_SYNCHRO >>>>>>>> @@ -281,7 +281,7 @@ int main(int argc, char *argv[]) >>>>>>>> >>>>>>>> do { >>>>>>>> do_it2 = 0; >>>>>>>> - } while (do_it2 = 0); >>>>>>>> + } while (do_it2); >>>>>>>> >>>>>>>> ret = pthread_join(th_sig1, NULL); >>>>>>>> if (ret) >>>>>>>> >>>> ------------------------------------------------------------------------------ >>>> 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 >>> >> > > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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 ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault 2012-08-21 9:45 ` Jan Stancek @ 2012-08-21 9:59 ` Kang Kai 0 siblings, 0 replies; 24+ messages in thread From: Kang Kai @ 2012-08-21 9:59 UTC (permalink / raw) To: Jan Stancek; +Cc: ltp-list, Zhenfeng.Zhao On 2012年08月21日 17:45, Jan Stancek wrote: > On 08/21/2012 11:24 AM, Kang Kai wrote: >> On 2012年08月21日 09:35, Wanlong Gao wrote: >>> On 08/21/2012 09:31 AM, Kang Kai wrote: >>>> On 2012年08月20日 10:21, Kang Kai wrote: >>>>> On 2012年08月20日 10:01, Wanlong Gao wrote: >>>>>> On 08/20/2012 09:39 AM, Kang Kai wrote: >>>>>>> On 2012年08月19日 06:58, Wanlong Gao wrote: >>>>>>>> On 08/14/2012 05:00 PM, Kang Kai wrote: >>>>>>>>> This case fails randomly with "Segmentation fault". Reset VERBOSE to 6 >>>>>>>>> can avoid this problem. >>>>>>>> Can you explain that why "reset VERBOSE" can avoid this "Seg Fault" problem? >>>>>>> It is a multi-thread issue. You can run it for less than 10 times, and it will fail with "Segmentation fault". >>>>>> I didn't see this on my side. >>>> Hi Wanlong, >>>> >>>>> It fails both on mips and x86_64. >>>>> On the x86_64, >>>>> cpu: Intel I7 >>>>> OS: Ubuntu 11.10 >>>>> libc: eglibc 2.13 >>>>> kernel: 3.0.0-12-generic >>>>> >>>>> How about try this script on a x86_64 machine: >>>>> for i in $(seq 100); do echo $i; ./4-3.run-test ; ret=$?; if [ $ret -ne >>>>> 0 ]; then echo $? ; break; fi; done >>>> Do you meet the "Segmentation Fault" yet? >> Hi Wanlong, >>> Not yet. >> I test it on x86_64 with Redhat 5.3, it doesn't fail. > I tried to reproduce it on x86_64 RHEL6/7 (real hw+kvm) and ubuntu-12.04-server (kvm), > but without any luck. > > I spotted one possible issue: > > diff --git a/testcases/open_posix_testsuite/conformance/interfaces/pthread_detach/4-3.c b/testcases/open_posix_testsuite/conforman > index 5c15e93..7b738e7 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 > @@ -129,9 +129,13 @@ static void *threaded(void *arg) > UNRESOLVED(ret, "Unable to unblock SIGUSR1 and SIGUSR2" > " in worker thread"); > > - ret = pthread_detach(pthread_self()); > - if (ret == EINTR) > - FAILED("pthread_detach() returned EINTR"); > + /* Attempting to detach an already detached thread results > + * in unspecified behavior */ > + if (scenarii[sc].detached != 1) { > + ret = pthread_detach(pthread_self()); > + if (ret == EINTR) > + FAILED("pthread_detach() returned EINTR"); > + } > Hi Jan, Thanks. I am sorry that It doesn't work and still "segment fault". Regards, Kai > /* Signal we're done */ > do { > > Regards, > Jan > >> I try to compare them to find why it fails with Ubuntu 11.10. >> >> Thanks, >> Kai >> >>> Thanks, >>> Wanlong Gao >>> >>>> Regards, >>>> Kai >>>> >>>>>>> It is hard to debug and I didn't find the root cause, but open the VERBOSE will avoid this situation. So it is a workaround. >>>>>> I'd like to send a patch to fix this typo first. >>>>> Fine. >>>>> >>>>> Regards, >>>>> Kai >>>>> >>>>>> Thanks, >>>>>> Wanlong Gao >>>>>> >>>>>>> Regards, >>>>>>> Kai >>>>>>> >>>>>>>>> Fix typo at same time. >>>>>>>> The typo fix is OK. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Wanlong Gao >>>>>>>> >>>>>>>>> Signed-off-by: Kang Kai<kai.kang@windriver.com> >>>>>>>>> --- >>>>>>>>> .../conformance/interfaces/pthread_detach/4-3.c | 4 ++-- >>>>>>>>> 1 files changed, 2 insertions(+), 2 deletions(-) >>>>>>>>> >>>>>>>>> diff --git a/testcases/open_posix_testsuite/conformance/interfaces/pthread_detach/4-3.c b/testcases/open_posix_testsuite/conformance/interfaces/pthread_detach/4-3.c >>>>>>>>> index 5c15e93..23738dc 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 >>>>>>>>> @@ -49,7 +49,7 @@ >>>>>>>>> #include "../testfrmw/testfrmw.c" >>>>>>>>> >>>>>>>>> #ifndef VERBOSE >>>>>>>>> -#define VERBOSE 1 >>>>>>>>> +#define VERBOSE 6 >>>>>>>>> #endif >>>>>>>>> >>>>>>>>> #define WITH_SYNCHRO >>>>>>>>> @@ -281,7 +281,7 @@ int main(int argc, char *argv[]) >>>>>>>>> >>>>>>>>> do { >>>>>>>>> do_it2 = 0; >>>>>>>>> - } while (do_it2 = 0); >>>>>>>>> + } while (do_it2); >>>>>>>>> >>>>>>>>> ret = pthread_join(th_sig1, NULL); >>>>>>>>> if (ret) >>>>>>>>> >>>>> ------------------------------------------------------------------------------ >>>>> 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 >> >> ------------------------------------------------------------------------------ >> 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 > ------------------------------------------------------------------------------ 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2012-08-29 9:21 UTC | newest] Thread overview: 24+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-08-21 10:35 [LTP] [PATCH] pthread_detach/4-3: workaround for segment fault Jan Stancek 2012-08-22 2:29 ` Kang Kai 2012-08-22 7:06 ` Jan Stancek 2012-08-22 8:28 ` Kang Kai 2012-08-22 8:58 ` Jan Stancek 2012-08-22 14:20 ` Jan Stancek 2012-08-23 6:21 ` Kang Kai 2012-08-23 7:09 ` Jan Stancek 2012-08-23 11:07 ` Jan Stancek 2012-08-24 2:46 ` Kang Kai 2012-08-28 8:37 ` Jan Stancek 2012-08-29 8:57 ` Kang Kai 2012-08-29 9:21 ` Jan Stancek -- strict thread matches above, loose matches on Subject: below -- 2012-08-14 9:00 Kang Kai 2012-08-18 22:58 ` Wanlong Gao 2012-08-20 1:39 ` Kang Kai 2012-08-20 2:01 ` Wanlong Gao 2012-08-20 2:21 ` Kang Kai 2012-08-21 1:31 ` Kang Kai 2012-08-21 1:35 ` Wanlong Gao 2012-08-21 9:24 ` Kang Kai 2012-08-21 9:24 ` Wanlong Gao 2012-08-21 9:45 ` Jan Stancek 2012-08-21 9:59 ` Kang Kai
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox