https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823
Peter Bergner changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823
--- Comment #16 from Jonathan Wakely ---
(In reply to Ian Lance Taylor from comment #11)
> I'm just noting that DejaGNU appears to have a bug in the standard_wait
> procedure:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823
--- Comment #15 from Jakub Jelinek ---
Might very well be
https://lists.gnu.org/archive/html/bug-dejagnu/2018-07/msg0.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823
--- Comment #14 from Ian Lance Taylor ---
The code that kills the test process (close_wait_program in lib/remote.exp) has
indeed changed between DejaGNU 1.6.1 and 1.6.2. That said, I don't see any
reason why the 1.6.1 code wouldn't kill the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823
--- Comment #13 from Jakub Jelinek ---
I got that with dejagnu 1.6.1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823
--- Comment #12 from Ian Lance Taylor ---
Other than the timeout issue, DejaGNU appears to work as expected on my system.
After 300 seconds, it will run the shell command "kill -2 $spid" which kills
the program. The program issue19182.go does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823
--- Comment #11 from Ian Lance Taylor ---
I'm just noting that DejaGNU appears to have a bug in the standard_wait
procedure:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823
--- Comment #10 from Jakub Jelinek ---
Got it stuck again over the weekend:
kojibui+ 9992 101 0.1 884512 29120 ?Sl Jan31 968:04
\_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823
--- Comment #9 from Jakub Jelinek ---
I don't have access to the box where it happened, I was just lucky somebody
else had and could find the stuck process for me and kill it.
In the past 2 month gcc builds were stuck similar way several times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823
--- Comment #8 from Ian Lance Taylor ---
The test is pretty simple.
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/testsuite/go.test/test/fixedbugs/issue19182.go;h=e1f3ffb4749f4dbb4c2204c4a0f484aea91b4771;hb=HEAD
The interesting thing it does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823
--- Comment #7 from Andreas Schwab ---
Perhaps the test is blocking or ignoring SIGTERM, or handling it in some
incompatible way.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823
--- Comment #6 from Ian Lance Taylor ---
Thanks. So, unix_load does seem to have a timeout by default, and as far as I
can see the Go testsuite code isn't doing anything to change that. Why isn't
the timeout working?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823
--- Comment #5 from Andreas Schwab ---
And for the unix board, its implementation is in
/usr/share/dejagnu/config/unix.exp.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823
--- Comment #4 from Andreas Schwab ---
That's standard part of dejagnu.
/usr/share/dejagnu/standard.exp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823
--- Comment #3 from Ian Lance Taylor ---
I'm sure I'm missing something, but what I see in lib/gcc-dg.exp is code that
says "if ${tool}_load already exists, then wrap it." I don't see the original
implementation of ${tool}_load.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823
--- Comment #2 from Andreas Schwab ---
go_load is defined in lib/gcc-dg.exp.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823
--- Comment #1 from Ian Lance Taylor ---
The Go testsuite is intended to have timeouts for all tests.
The test gcc/testsuite/go.test/test/fixedbugs/issue19182.go is just passed off
to the TCL function go-torture-execute. Running the executable
17 matches
Mail list logo
