NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

bin/49141: lib/librumpclient/t_exec/threxec test randomly fails



>Number:         49141
>Category:       bin
>Synopsis:       lib/librumpclient/t_exec/threxec test randomly fails
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Aug 22 14:40:00 +0000 2014
>Originator:     Andreas Gustafsson
>Release:        NetBSD-current
>Organization:

>Environment:
System: NetBSD
Architecture: i386
Machine: i386
>Description:

The lib/librumpclient/t_exec/threxec test case has been randomly
failing ever since it was first created.  What happens is that the 
h_execthr program sometimes hangs until ATF times out and kills it.

Here is the log from the first recorded failure, from the day the
test was committed.  This is from my own testbed since the TNF one
didn't exist yet:

  
http://www.gson.org/netbsd/bugs/build/i386/2011/2011.03.08.22.21.52/test.html#lib_librumpclient_t_exec_threxec

Here is the log from a recent failure on the TNF testbed:

  
http://releng.netbsd.org/b5reports/i386/build/2014.08.21.22.00.30/test.html#lib_librumpclient_t_exec_threxec

The test also sometimes fails in the amd64 and sparc runs, but less
often than in the i386 ones.  Perhaps this has something to do with
the i386 VM having less memory than the others.  Anyway, I'm also
seeing this when running the tests on the bare metal, so it's clearly
not a qemu issue.  The test's 300 second timeout does not appear to be
to short, either, because when the test passes, it does so quickly,
typically in 30 seconds or less.

>How-To-Repeat:

Run the lib/librumpclient/t_exec test repeatedly.

>Fix:



Home | Main Index | Thread Index | Old Index