[patch] Fix watch_thread_num testcase for ppc32

[patch] Fix watch_thread_num testcase for ppc32

[Luis Machado]

[-- Attachment #1: Type: text/plain, Size: 301 bytes --]

Hi folks,

The watch_thread_num.exp testcase was timing out on a number of
iterations for PPC32, while giving a full pass for PPC64. Removing the
usleep(1) call fixed the problem. It gives full passes for both PPC
32/64.

Ok to commit?

-- 
Luis Machado
Software Engineer 
IBM Linux Technology Center

[-- Attachment #2: thread_num_test_fix.diff --]
[-- Type: text/x-patch, Size: 673 bytes --]

2008-01-09  Luis Machado  <luisgpm@br.ibm.com>

	* testsuite/gdb.base/watch_thread_num.c: Change shared_var to long
	and remove usleep call.

Index: gdb/testsuite/gdb.base/watch_thread_num.c
===================================================================
--- gdb.orig/testsuite/gdb.base/watch_thread_num.c	2008-01-08 19:21:06.000000000 -0800
+++ gdb/testsuite/gdb.base/watch_thread_num.c	2008-01-08 19:28:29.000000000 -0800
@@ -53,10 +53,7 @@
     int my_number = (long) arg;
     /* Don't run forever.  Run just short of it :)  */
     while (shared_var > 0)
-      {
         shared_var++;
-	usleep (1); /* Loop increment.  */
-      }
 
     pthread_exit (NULL);
 }

Re: [patch] Fix watch_thread_num testcase for ppc32

[Joel Brobecker]

> The watch_thread_num.exp testcase was timing out on a number of
> iterations for PPC32, while giving a full pass for PPC64. Removing the
> usleep(1) call fixed the problem. It gives full passes for both PPC
> 32/64.

Would you mind sending the log files when it times out? I don't
understand why removing the usleep fixes the problem. I'm a bit
concerned with removing this delay because the thread would then
be free to eat up all the CPU, and the test is creating quite a
number of them...

Thanks,
-- 
Joel

Re: [patch] Fix watch_thread_num testcase for ppc32

[Luis Machado]

On Tue, 2008-01-08 at 20:15 -0800, Joel Brobecker wrote:
> > The watch_thread_num.exp testcase was timing out on a number of
> > iterations for PPC32, while giving a full pass for PPC64. Removing the
> > usleep(1) call fixed the problem. It gives full passes for both PPC
> > 32/64.
> 
> Would you mind sending the log files when it times out? I don't
> understand why removing the usleep fixes the problem. I'm a bit
> concerned with removing this delay because the thread would then
> be free to eat up all the CPU, and the test is creating quite a
> number of them...
> 
> Thanks,

The test will create a max of five threads, that will keep updating a
shared variable.

The reason why it times out is not really clear, i'm still
investigating. When you hit continue in 32-bit, GDB seems to stand there
doing something. It occurs from time to time. Sometimes it will stop due
to the watchpoint, sometimes it will "lock". When you hit ctrl-C, it's
clear that GDB is still executing the "nanosleep" function. That's what
pointed me to usleep().

Regards,

-- 
Luis Machado
Software Engineer 
IBM Linux Technology Center

Re: [patch] Fix watch_thread_num testcase for ppc32

[Andreas Schwab]

Luis Machado <luisgpm@linux.vnet.ibm.com> writes:

> 2008-01-09  Luis Machado  <luisgpm@br.ibm.com>
>
> 	* testsuite/gdb.base/watch_thread_num.c: Change shared_var to long

I don't see this change in the patch.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [patch] Fix watch_thread_num testcase for ppc32

[Luis Machado]

> I don't see this change in the patch.
> 
> Andreas.
> 

Sorry, old version. This change shouldn't be there. I'll correct that.

-- 
Luis Machado
Software Engineer 
IBM Linux Technology Center

Re: [patch] Fix watch_thread_num testcase for ppc32

[Daniel Jacobowitz]

On Wed, Jan 09, 2008 at 07:38:19AM -0200, Luis Machado wrote:
> The test will create a max of five threads, that will keep updating a
> shared variable.

Five threads looping without a CPU delay really messes up interactive
performance; that's why I reduced the thread count for schedlock.exp
recently.

> The reason why it times out is not really clear, i'm still
> investigating. When you hit continue in 32-bit, GDB seems to stand there
> doing something. It occurs from time to time. Sometimes it will stop due
> to the watchpoint, sometimes it will "lock". When you hit ctrl-C, it's
> clear that GDB is still executing the "nanosleep" function. That's what
> pointed me to usleep().

Sounds to me like a bug in GDB, not a problem with the test.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [patch] Fix watch_thread_num testcase for ppc32

[Luis Machado]

> Five threads looping without a CPU delay really messes up interactive
> performance; that's why I reduced the thread count for schedlock.exp
> recently.

Sounds like a good reason to leave the delay there.

> Sounds to me like a bug in GDB, not a problem with the test.

Yes, probably. I believe there is a signal being missed somewhere.

If i use usleep(0) (calls sched_yield), the testcase runs just fine. But
switching to a delay eventually breaks the test.

Any ideas?

-- 
Luis Machado
Software Engineer 
IBM Linux Technology Center