This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[regression/native-gdbserver][buildbot] Python testscases get staled (was: Re: [PATCH] skip "attach" tests when testing against stub-like targets)
- From: Sergio Durigan Junior <sergiodj at redhat dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: "Breazeal\, Don" <donb at codesourcery dot com>, Yao Qi <yao at codesourcery dot com>, gdb-patches at sourceware dot org
- Date: Sun, 11 Jan 2015 23:43:06 -0500
- Subject: [regression/native-gdbserver][buildbot] Python testscases get staled (was: Re: [PATCH] skip "attach" tests when testing against stub-like targets)
- Authentication-results: sourceware.org; auth=none
- References: <1418748834-27545-1-git-send-email-palves at redhat dot com> <1418748834-27545-6-git-send-email-palves at redhat dot com> <87wq5qsfaf dot fsf at codesourcery dot com> <54921989 dot 4060005 at redhat dot com> <54AADFA1 dot 9040003 at codesourcery dot com> <54AD5BFC dot 2030906 at redhat dot com> <54AFBA7B dot 6040403 at redhat dot com>
On Friday, January 09 2015, Pedro Alves wrote:
> On 01/07/2015 04:17 PM, Pedro Alves wrote:
>> On 01/05/2015 07:01 PM, Breazeal, Don wrote:
>>>> # Start a set of programs running and then wait for a bit, to be sure
>>>> # that they can be attached to. Return a list of the processes' PIDs.
>>>>
>>>> proc spawn_wait_for_attach { executable_list } {
>>>> set pid_list {}
>>>>
>>>> + if ![can_spawn_for_attach] {
>>>> + error "can't spawn for attach with this target/board"
>>>> + }
>>>
>>> Should this be calling "error", or should it call something like
>>> "untested" or "unsupported", since it isn't expected to work in these cases?
>>
>> The idea is that all .exp files that use spawn_wait_for_attach
>> would have already checked can_spawn_for_attach early, and skipped the
>> tests if false. That makes is a test bug to see a call to
>> spawn_wait_for_attach if can_spawn_for_attach is false.
>>
>> I should have really split those hunks out to a separate patch and
>> added calls to can_spawn_for_attach in all tests that are using
>> spawn_wait_for_attach already. Like below. WDYT?
>>
>> (There are probably other attach tests that don't use
>> spawn_wait_for_attach that need the can_spawn_for_attach too.
>> We can do this incrementally.)
>
> I went ahead and pushed this to unblock the parent series.
Hey Pedro,
Buildbot (which is running only internally so far, but will hopefully be
deployed this week) "caught" this when building in x86_64 (Fedora 21)
and testing the native-gdbserver variant (both x86_64 and x86). When
you run the test on the gdb.python/ directory, you see that it stales
when it reaches the gdb.python/py-section-script.exp testcase.
Buildbot's gdb.log specifically has:
Running ../../../binutils-gdb/gdb/testsuite/gdb.python/py-section-script.exp ...
ERROR: (timeout) GDB never initialized after 10 seconds.
ERROR: no fileid for gdbuild
ERROR: Couldn't send python print ('test') to GDB.
ERROR: no fileid for gdbuild
ERROR: Couldn't send python print (sys.version_info[0]) to GDB.
ERROR: no fileid for gdbuild
ERROR: Couldn't send python print (sys.version_info[1]) to GDB.
ERROR: no fileid for gdbuild
ERROR: no fileid for gdbuild
...
(this goes on and on, for several testcases)
I still did not debug this (intend to do so tomorrow, if you don't see
this before I start my day), but running a simple git-bisect showed me
that this specific commit is the culprit.
Cheers,
--
Sergio
GPG key ID: 0x65FC5E36
Please send encrypted e-mail if possible
http://sergiodj.net/