public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Carl Love <cel@linux.ibm.com>
To: Tom Tromey <tom@tromey.com>, Tom de Vries <tdevries@suse.de>
Cc: gdb-patches@sourceware.org, Carl Love <cel@linux.ibm.com>
Subject: Re: [PATCH] [gdb/testsuite] Update xfail in gdb.threads/attach-many-short-lived-threads.exp
Date: Fri, 26 Jan 2024 08:13:48 -0800	[thread overview]
Message-ID: <47bfc265-583d-4d03-8558-f8c7ec555998@linux.ibm.com> (raw)
In-Reply-To: <f97d4bb6-0bf1-48af-9979-783c6a9e8890@linux.ibm.com>

Tom:

The test continues to be problematic on Power 10.  The number of failures seem to vary
from run to run.  I do see the number of failures on Power 9 vary, but most of the time the test passes.

                         Carl 

On 1/24/24 12:47, Carl Love wrote:
> Tom:
> 
> On 1/24/24 10:51, Carl Love wrote:
>> Tom:
>>
>> On 1/19/24 08:27, Tom Tromey wrote:
>>>>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:
>>>
>>> Tom> But since commit c6f7f9c80c3 ("Bail out of "attach" if a thread cannot be
>>> Tom> traced"), the warning has been changed into an error.
>>>
>>> Tom> Fix the FAIL by updating the test-case to expect an error instead of a
>>> Tom> warning.
>>>
>>> Thanks, this looks good to me.
>>> Approved-By: Tom Tromey <tom@tromey.com>
>>>
>>> Tom
>>
>> The patch fixes the issues on my Power 9 box running "Ubuntu 22.04.3 LTS.
>>
>> However, the Power 10 box running Fedora Linux 38 (Server Edition) still reports a lot of errors. I see the errors in the daily build on the machine.  I can reproduce the failures when running the test by itself with:
>>
>> make check RUNTESTFLAGS='GDB=/home/carll/bin/gdb gdb.threads/attach-many-short-lived-threads.exp '
>>
>> Here is some of the output from gdb.log:
>>
>> The program is not being run.
>> (gdb) file /home/carll/GDB/build-current/gdb/testsuite/outputs/gdb.threads/attach-many-short-lived-threads/attach-many-short-lived-threads
>> Reading symbols from /home/carll/GDB/build-current/gdb/testsuite/outputs/gdb.threads/attach-many-short-lived-threads/attach-many-short-lived-threads...
>> (gdb) builtin_spawn /home/carll/GDB/build-current/gdb/testsuite/outputs/gdb.threads/attach-many-short-lived-threads/attach-many-short-lived-threads
>> attach 3385832
>> Attaching to program: /home/carll/GDB/build-current/gdb/testsuite/outputs/gdb.threads/attach-many-short-lived-threads/attach-many-short-lived-threads, process 3385832
>> Cannot attach to lwp 3513884: Operation not permitted (1)
>> (gdb) XFAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 1: attach (EPERM)
>> attach 3385832
>> Attaching to program: /home/carll/GDB/build-current/gdb/testsuite/outputs/gdb.threads/attach-many-short-lived-threads/attach-many-short-lived-threads, process 3385832
>> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 2: attach (timeout)
>> info threads
>> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 2: no new threads (timeout)
>> set breakpoint always-inserted on
>> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 2: set breakpoint always-inserted on (timeout)
>> break break_fn
>> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 2: break break_fn (timeout)
>> continue
>> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 2: break at break_fn: 1 (timeout)
>> continue
>> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 2: break at break_fn: 2 (timeout)
>> continue
>> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 2: break at break_fn: 3 (timeout)
>> print again = 1
>> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 2: reset timer in the inferior (timeout)
>> print seconds_left
>> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 2: print seconds_left (timeout)
>> detach
>> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 2: detach (timeout)
>> set breakpoint always-inserted off
>> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 2: set breakpoint always-inserted off (timeout)
>> delete breakpoints
>> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 2: delete all breakpoints in delete_breakpoints (timeout)
>> ERROR: breakpoints not deleted
>> attach 3385832
>> UNRESOLVED: gdb.threads/attach-many-short-lived-threads.exp: iter 3: attach (timeout)
>> info threads
>> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 3: no new threads (timeout)
>> set breakpoint always-inserted on
>> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 3: set breakpoint always-inserted on (timeout)
>> break break_fn
>> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 3: break break_fn (timeout)
>> continue
>>
>> etc.
>>
>> closing exp10
>> waiting for exp10
>> testcase /home/carll/GDB/build-current/gdb/testsuite/../../../binutils-gdb-current/gdb/testsuite/gdb.threads/attach-many-short-lived-threads.exp completed in 1910 seconds
>>
>>                  === gdb Summary ===
>>
>> # of expected passes            1
>> # of unexpected failures        98
>> # of expected failures          1
>> # of unresolved testcases       8
>>
>>
>>
>> Not sure if the failures are specific to the Distro/OS or not.  But I will try testing on a Power 10 system with other distros and let you know.  Please let me know if you have any ideas on how to fix these errors on Power 10.
> 
> I tried running the test on various Power 10 systems with varying results:
> 
> Ubuntu 22.04.3 LTS
> 
>                 === gdb Summary ===
> 
> # of expected passes            34
> # of expected failures          7
> 
> ---------------------------
> Red Hat Enterprise Linux 9.3 (Plow)
> 
> # of unsupported tests          1    Seems really odd, will have to look into this more
> 
> --------------------------
> SUSE Linux Enterprise Server 15 SP5
>                 === gdb Summary ===
> 
> # of expected passes            109
> 
> --------------------------
> Fedora Linux 38 (Server Edition)
> 
>                 === gdb Summary ===   I get inconsistent results
> 
> # of expected passes            56
> # of unexpected failures        32
> # of expected failures          2
> # of unresolved testcases       2
> 
>                 === gdb Summary ===
> 
> # of expected passes            109    I have run this test multiple times and had failures.
>                                        Now it is running without any errors???  Not sure what
>                                        has changed.
> 
> I will keep an eye on this to see if things change again.
> 
>                  Carl
> 
> 
> 
> 
> 
> 
> 
> 

  reply	other threads:[~2024-01-26 16:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-15 23:18 Tom de Vries
2024-01-19 16:27 ` Tom Tromey
2024-01-24 18:51   ` Carl Love
2024-01-24 20:47     ` Carl Love
2024-01-26 16:13       ` Carl Love [this message]
2024-01-29 17:04         ` Tom Tromey
2024-01-29 18:13           ` Carl Love
2024-02-06 19:03             ` Carl Love

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47bfc265-583d-4d03-8558-f8c7ec555998@linux.ibm.com \
    --to=cel@linux.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tdevries@suse.de \
    --cc=tom@tromey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).