Very messy results from testsuite in GDB 8.1

Very messy results from testsuite in GDB 8.1

[Dennis Clarke]

I was saddened to see these results of the 8.1 testsuite :

                 === gdb Summary ===

# of expected passes            48036
# of unexpected failures        881
# of unexpected successes       2
# of expected failures          56
# of unknown successes          4
# of known failures             66
# of unresolved testcases       11
# of untested testcases         50
# of unsupported tests          213
/usr/local/build/gdb-8.1_4.13.0-1-powerpc64.001/gdb/gdb version  8.1 -nw 
-nx -data-directory 
/usr/local/build/gdb-8.1_4.13.0-1-powerpc64.001/gdb/testsuite/../data-directory 




This is an order of magnitude worse than a previous build for 8.0.1 :

                 === gdb Summary ===

# of expected passes            33093
# of unexpected failures        96
# of expected failures          58
# of known failures             65
# of unresolved testcases       3
# of untested testcases         56
# of unsupported tests          206
/usr/local/build/gdb-8.0.1_linux_3.16.0-4-powerpc64.001/gdb/testsuite/../../gdb/gdb 
version  8.0.1 -nw -nx -data-directory 
/usr/local/build/gdb-8.0.1_linux_3.16.0-4-powerpc64.001/gdb/testsuite/../data-directory 



Of course the kernel rev has changed since then, considerably, as well
as a number of tools in the system.  Nearly 900 unexpected test failures
is quite distressing. Certainly not a usable resultant binary.

There are a number of internal errors :


-bash-4.4$ grep "^FAIL" ../gdb-8.1_4.13.0-1-powerpc64.001.check.log | 
grep "internal error"
FAIL: gdb.base/multi-forks.exp: detach 2 (GDB internal error)
FAIL: gdb.base/multi-forks.exp: detach 3 (GDB internal error)
FAIL: gdb.base/multi-forks.exp: detach 4 (GDB internal error)
FAIL: gdb.base/multi-forks.exp: detach 5 (GDB internal error)
FAIL: gdb.threads/process-dies-while-detaching.exp: multi-process: 
detach: detach: detach child (GDB internal error)
FAIL: gdb.threads/process-dies-while-detaching.exp: multi-process: 
detach: watchpoint: detach child (GDB internal error)
FAIL: gdb.threads/process-dies-while-detaching.exp: multi-process: 
continue: detach: detach child (GDB internal error)
FAIL: gdb.threads/process-dies-while-detaching.exp: multi-process: 
continue: watchpoint: detach child (GDB internal error)
FAIL: gdb.threads/watchpoint-fork.exp: parent: singlethreaded: 
breakpoint after the first fork (GDB internal error)
FAIL: gdb.threads/watchpoint-fork.exp: parent: singlethreaded: 
breakpoint after the second fork (GDB internal error)
FAIL: gdb.threads/watchpoint-fork.exp: parent: multithreaded: breakpoint 
(A) after the first fork (GDB internal error)
FAIL: gdb.threads/watchpoint-fork.exp: child: singlethreaded: breakpoint 
after the first fork (GDB internal error)
FAIL: gdb.threads/watchpoint-fork.exp: child: singlethreaded: watchpoint 
after the first fork (GDB internal error)
FAIL: gdb.threads/watchpoint-fork.exp: child: multithreaded: breakpoint 
(A) after the first fork (GDB internal error)


I will move onwards to a Red Hat Enterprise Linux 7.4 system and see
what results happen there but for the moment I have to ask if other
people are seeing reasonable build and testsuite results?


Dennis Clarke

Re: Very messy results from testsuite in GDB 8.1

[Yao Qi]

On Mon, Feb 5, 2018 at 8:06 PM, Dennis Clarke <dclarke@blastwave.org> wrote:
> I was saddened to see these results of the 8.1 testsuite :
>
> I will move onwards to a Red Hat Enterprise Linux 7.4 system and see
> what results happen there but for the moment I have to ask if other
> people are seeing reasonable build and testsuite results?

We have buildbot ppc64 slaves.  I am not clear on these ppc64 machine
details, but the number of fails is similar to what you get now.
https://gdb-build.sergiodj.net/builders/CentOS-ppc64be-m64/builds/101/steps/regressions/logs/stdio

-- 
Yao (齐尧)

Re: Very messy results from testsuite in GDB 8.1

[Dennis Clarke]

On 05/02/18 05:20 PM, Yao Qi wrote:
> On Mon, Feb 5, 2018 at 8:06 PM, Dennis Clarke <dclarke@blastwave.org> wrote:
>> I was saddened to see these results of the 8.1 testsuite :
>>
>> I will move onwards to a Red Hat Enterprise Linux 7.4 system and see
>> what results happen there but for the moment I have to ask if other
>> people are seeing reasonable build and testsuite results?
> 
> We have buildbot ppc64 slaves.  I am not clear on these ppc64 machine
> details, but the number of fails is similar to what you get now.
> https://gdb-build.sergiodj.net/builders/CentOS-ppc64be-m64/builds/101/steps/regressions/logs/stdio


That causes me to think that I can not yet use gdb 8.1.x on ppc64.


Dennis

Re: Very messy results from testsuite in GDB 8.1

[Joel Brobecker]

> That causes me to think that I can not yet use gdb 8.1.x on ppc64.

Is there someone who actually maintains that target? Without it,
I don't think that things will improve in the future.

Also, numbers alone can be quite misleading. I would try determining
the list of tests that started failing, and the type of failure
they indicate. Sometimes, the situation is as dire as the numbers
indicate, and sometimes, we get huge numbers due to one error
cascading into zillion ones.

-- 
Joel

Re: Very messy results from testsuite in GDB 8.1

[Dennis Clarke]

On 05/02/18 11:18 PM, Joel Brobecker wrote:
>> That causes me to think that I can not yet use gdb 8.1.x on ppc64.
> 
> Is there someone who actually maintains that target? Without it,
> I don't think that things will improve in the future.

I would think there are a ton if interested people inside IBM given
that Red Hat releases a product for the IBM power based servers. The
differences between the POWER architecture and the PowerPC are not
as large as one would think. However, having said that, I will look
around and see if I can get an IBM POWER based system up and running
with Red Hat 7.4 and see what happens.


> Also, numbers alone can be quite misleading. I would try determining
> the list of tests that started failing, and the type of failure
> they indicate. Sometimes, the situation is as dire as the numbers
> indicate, and sometimes, we get huge numbers due to one error
> cascading into zillion ones.

I hope that is the case.

Dennis