Re: [pushed] [gdb/testsuite] Fix gdb.threads/schedlock.exp on fast cpu

[Tom de Vries <tdevries@suse.de>]

On 2/6/23 12:54, Tom de Vries via Gdb-patches wrote:
> Occasionally, I run into:
> ...
> (gdb) PASS: gdb.threads/schedlock.exp: schedlock=on: cmd=continue: \
>    set scheduler-locking on
> continue^M
> Continuing.^M
> PASS: gdb.threads/schedlock.exp: schedlock=on: cmd=continue: \
>    continue (with lock)
> [Thread 0x7ffff746e700 (LWP 1339) exited]^M
> No unwaited-for children left.^M
> (gdb) Quit^M
> (gdb) FAIL: gdb.threads/schedlock.exp: schedlock=on: cmd=continue: \
>    stop all threads (with lock) (timeout)
> ...
> 
> What happens is that this loop which is supposed to run "just short of forever":
> ...
>      /* Don't run forever.  Run just short of it :)  */
>      while (*myp > 0)
>        {
>          /* schedlock.exp: main loop.  */
>          MAYBE_CALL_SOME_FUNCTION(); (*myp) ++;
>        }
> ...
> finishes after 0x7fffffff iterations (when a signed wrap occurs), which on my
> system takes only about 1.5 seconds.
> 
> Fix this by:
> - changing the pointed-at type of myp from signed to unsigned, which makes the
>    wrap defined behaviour (and which also make the loop run twice as long,
>    which is already enough to make it impossible for me to reproduce the FAIL.
>    But let's try to solve this more structurally).
> - changing the pointed-at type of myp from int to long long, making the wrap
>    unlikely.
> - making sure the loop runs forever, by setting the loop condition to 1.
> - making sure the loop still contains different lines (as far as debug info is
>    concerned) by incrementing a volatile counter in the loop.
> - making sure the program doesn't run forever in case of trouble, by adding an
>    "alarm (30)".
> 
> Tested on x86_64-linux.
> 


Hmm, I just found out that this regresses the test-case with older 
compilers like 4.8 and 5, I'll need to fix that.

Thanks,
- Tom

> PR testsuite/30074
> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30074
> ---
>   gdb/testsuite/gdb.threads/schedlock.c | 11 +++++++----
>   1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/gdb/testsuite/gdb.threads/schedlock.c b/gdb/testsuite/gdb.threads/schedlock.c
> index 5422c64fd99..c4e77948ad4 100644
> --- a/gdb/testsuite/gdb.threads/schedlock.c
> +++ b/gdb/testsuite/gdb.threads/schedlock.c
> @@ -24,7 +24,7 @@ void *thread_function(void *arg); /* Pointer to function executed by each thread
>   
>   #define NUM 1
>   
> -unsigned int args[NUM+1];
> +unsigned long long int args[NUM+1];
>   
>   int main() {
>       int res;
> @@ -32,6 +32,8 @@ int main() {
>       void *thread_result;
>       long i;
>   
> +    alarm (30);
> +
>       for (i = 1; i <= NUM; i++)
>         {
>   	args[i] = 1;
> @@ -72,13 +74,14 @@ volatile int call_function = 0;
>   
>   void *thread_function(void *arg) {
>       int my_number =  (long) arg;
> -    int *myp = (int *) &args[my_number];
> +    unsigned long long int *myp = (unsigned long long int *) &args[my_number];
> +    volatile unsigned int cnt = 0;
>   
> -    /* Don't run forever.  Run just short of it :)  */
> -    while (*myp > 0)
> +    while (1)
>         {
>   	/* schedlock.exp: main loop.  */
>   	MAYBE_CALL_SOME_FUNCTION(); (*myp) ++;
> +	cnt++;
>         }
>   
>       pthread_exit(NULL);
> 
> base-commit: 023b960d59c25994da233ea371deb26105fbacc8