Last week: i686-pc-linux-gnu 'gdb.server' testsuite regressions

Thomas Schwinge thomas@codesourcery.com
Sat Apr 20 09:31:00 GMT 2019


Hi!

On Tue, 16 Apr 2019 11:56:21 +0200, I wrote:
> I'd like to highlight the following <gdb-testers@sourceware.org> report:
> 
> On Thu, 11 Apr 2019 00:50:50 -0400, sergiodj+buildbot@sergiodj.net wrote:
> > Buildslave:
> > 	fedora-x86-64-4
> > 
> > Full Build URL:
> > 	<http://gdb-build.sergiodj.net/builders/Fedora-x86_64-m32/builds/12207>
> > 
> > Commit(s) tested:
> > 	9d1447e09d4aa673826039321163b5a684e8e043
> > 
> > Author(s) (in the same order as the commits):
> > 	Sergio Durigan Junior <sergiodj@redhat.com>
> > 
> > Subject:
> > 	Destroy allocated values when exiting GDB

This one doesn't seem to be related, in fact.

> In
> d970ee2bae1925bb9265d37adef0b92e2678d666..02e902e1a1ec7b74125f329b3faef1992efb6d51
> (that is, basically, last week) I'm too seeing a good number of
> 'gdb.server' testsuite regressions in native i686-pc-linux-gnu testing:

These i686-pc-linux-gnu gdbserver regressions are caused by the commit
3f52fdbcb599f76b4838020721ca6c9f1cc28f84 "Fix amd64->i386 linux syscall
restart problem" changes to 'gdb/gdbserver/linux-x86-low.c'.  (The
'gdb/amd64-linux-nat.c' changes are not relevant in this
i686-pc-linux-gnu configuration -- do they need to be replicated to the
corresponding i686 GDB file, or do the gdbserver changes need to be
conditionalized on something?)

For reference:

>     Running [...]/gdb/testsuite/gdb.server/abspath.exp ...
>     {+FAIL: gdb.server/abspath.exp: continue to main+}
>     Running [...]/gdb/testsuite/gdb.server/connect-stopped-target.exp ...
>     Running [...]/gdb/testsuite/gdb.server/connect-with-no-symbol-file.exp ...
>     Running [...]/gdb/testsuite/gdb.server/connect-without-multi-process.exp ...
>     {+FAIL: gdb.server/connect-without-multi-process.exp: multiprocess=off: continue to main+}
>     {+FAIL: gdb.server/connect-without-multi-process.exp: multiprocess=auto: continue to main+}
>     Running [...]/gdb/testsuite/gdb.server/ext-attach.exp ...
>     Running [...]/gdb/testsuite/gdb.server/ext-restart.exp ...
>     {+FAIL: gdb.server/ext-restart.exp: run to main+}
>     {+FAIL: gdb.server/ext-restart.exp: restart: run to main+}
>     Running [...]/gdb/testsuite/gdb.server/ext-run.exp ...
>     {+FAIL: gdb.server/ext-run.exp: continue to main+}
>     Running [...]/gdb/testsuite/gdb.server/ext-wrapper.exp ...
>     {+FAIL: gdb.server/ext-wrapper.exp: run to marker+}
>     {+FAIL: gdb.server/ext-wrapper.exp: print d+}
>     {+FAIL: gdb.server/ext-wrapper.exp: restart: run to marker+}
>     {+FAIL: gdb.server/ext-wrapper.exp: restart: print d+}
>     Running [...]/gdb/testsuite/gdb.server/extended-remote-restart.exp ...
>     Running [...]/gdb/testsuite/gdb.server/file-transfer.exp ...
>     Running [...]/gdb/testsuite/gdb.server/no-thread-db.exp ...
>     {+FAIL: gdb.server/no-thread-db.exp: continue to breakpoint: after tls assignment+}
>     Running [...]/gdb/testsuite/gdb.server/non-existing-program.exp ...
>     Running [...]/gdb/testsuite/gdb.server/reconnect-ctrl-c.exp ...
>     {+FAIL: gdb.server/reconnect-ctrl-c.exp: first: stop with control-c+}
>     {+FAIL: gdb.server/reconnect-ctrl-c.exp: second: stop with control-c+}
>     Running [...]/gdb/testsuite/gdb.server/run-without-local-binary.exp ...
>     {+FAIL: gdb.server/run-without-local-binary.exp: run test program until the end+}
>     Running [...]/gdb/testsuite/gdb.server/server-connect.exp ...
>     Running [...]/gdb/testsuite/gdb.server/server-exec-info.exp ...
>     Running [...]/gdb/testsuite/gdb.server/server-kill.exp ...
>     {+FAIL: gdb.server/server-kill.exp: continue to breakpoint: after server_pid assignment+}
>     {+FAIL: gdb.server/server-kill.exp: tstatus+}
>     Running [...]/gdb/testsuite/gdb.server/server-mon.exp ...
>     Running [...]/gdb/testsuite/gdb.server/server-run.exp ...
>     {+FAIL: gdb.server/server-run.exp: continue to main+}
>     Running [...]/gdb/testsuite/gdb.server/solib-list.exp ...
>     {+FAIL: gdb.server/solib-list.exp: non-stop 0: continue+}
>     {+FAIL: gdb.server/solib-list.exp: non-stop 0: p libvar+}
>     {+FAIL: gdb.server/solib-list.exp: non-stop 1: continue+}
>     {+FAIL: gdb.server/solib-list.exp: non-stop 1: p libvar+}
>     Running [...]/gdb/testsuite/gdb.server/stop-reply-no-thread.exp ...
>     {+FAIL: gdb.server/stop-reply-no-thread.exp: continue to main+}
>     {+Running [...]/gdb/testsuite/gdb.server/sysroot.exp ...+}
>     {+FAIL: gdb.server/sysroot.exp: sysroot=local: continue to main+}
>     {+FAIL: gdb.server/sysroot.exp: sysroot=local: continue to printf+}
>     {+FAIL: gdb.server/sysroot.exp: sysroot=remote: continue to main+}
>     {+FAIL: gdb.server/sysroot.exp: sysroot=remote: continue to printf+}
>     Running [...]/gdb/testsuite/gdb.server/unittest.exp ...
>     Running [...]/gdb/testsuite/gdb.server/wrapper.exp ...
>     {+FAIL: gdb.server/wrapper.exp: continue to marker+}
>     {+FAIL: gdb.server/wrapper.exp: print d+}
> 
> These generally seem to be because the "Program received signal SIGSEGV,
> Segmentation fault".  Not any further bisected, or analyzed.


Grüße
 Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 658 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb/attachments/20190420/6596063e/attachment.sig>


More information about the Gdb mailing list