Subject: kern/18466: 1.6 + dejagnu + gdb == random SIGSEGV from wait4()
To: None <>
From: None <>
List: netbsd-bugs
Date: 09/29/2002 07:50:31
>Number:         18466
>Category:       kern
>Synopsis:       1.6 + dejagnu + gdb == random SIGSEGV from wait4()
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Sep 29 07:51:00 PDT 2002
>Originator:     Andrew Cagney
>Release:        1.6 userland
NetBSD localhost 1.6G NetBSD 1.6G (NETLUX) #0: Sat Sep 21 15:14:07 EDT 2002     boor@localhost:/usr/new/sys/arch/macppc/compile/NETLUX macppc

Current GDB under 1.6 and head of 1.5 has really bad test results.

Part of it is attributable to a more agressive compiler (frameless functions) but part of it is not.  In fact, part is downright weird.

Under the dejagnu test framework I see results like:

> (gdb) p t_char_values(0,0)
> Program received signal SIGSEGV, Segmentation fault.
_start ()
> ...

Which would, most likely, be due to wait4() returning SIGSEGV instead of SIGTRAP (there is a breakpoint at _start()).

If GDB is run outside of the test framework, it works.

If you're thinking it's GDB/dejagnu version, think again.  Switching to the NetBSD [un-]bundled expect/dejagnu and things don't work.  Switching to a previous, GDB release and things also no longer work.

Of course, it isn't reliably reproduceable.  While it happens more often than not, when it doesn't happening, the bug can be can quickly ticked by opening/closing xterms (...).

See also: pkg/15315.

I should also note that there is a very long standing *BSD+dejagnu+pty bug (I'll file a bug report for that as well).  So it could be a dejagnu badness that has been made worse by recent kernel/userland changes.

cvs -d co gdb+dejagnu
cvs -d co gdb (if you have dejagnu installed)
mkdir `src/config.guess`
cd !$
`cd ../src && pwd`/configure
make check-gdb RUNTESTFLAGS=callfuncs.exp

Someone needs to reproduce this!