[Top][All Lists]

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

[RFA] fix remote testing I/O conflicts

From: Yvan Roux
Subject: [RFA] fix remote testing I/O conflicts
Date: Wed, 2 Mar 2016 19:45:12 +0100


in our context of extensive GCC cross validation with parallel make
check and ssh/scp communication to the target boards, we have lot of
unstable results (mainly in fortran and libstdc++ testsuite) whereas
there is no issues in native testing.  After lot of digging it occurs
that these instabilities are due to conflicting access to data or
generated temporary files.

The issue is that it is hardcoded in unix_load (and standard_load)
that the program to test is download under /tmp as "/tmp/"
and executed in the homedir of the ssh user (or the one targeted by
board_info rsh_prog) and the data files needed by some testcases are
downloaded by remote_download which put them in the homedir as well.
So, all the data files and generated ones from the different processes
are in the same directory, thus the conflicts.

To fix this issue, changing the layout to have the testcases
downloaded and executed inside "/tmp/pid/" directory would do the job,
but as this change might have an impact on other project or on other
config which use remote_download, my proposal is to offer the
possibility to define the remote directory in which testcases will be
downloaded and executed with a target board info named "remote_dir".
A board spec with the line bellow will then fix our issue:

set_board_info remote_dir "/tmp/[pid]"

The attached patch implements this feature, it was tested on full GCC
testsuite without any issues, and if you think it's ok I can submit it
with an appropriate ChangeLog.

I would have prefer to have this issue fully fixed inside dejagnu, but
my fear is to brake something I can't test, so do you think it is the
proper way to handle the problem ?

If you think this solution is right, I have some comments and/or
related questions on the patch itself:

- I constraint the remote_dir handling to unix_load and the "remote_"
routines, it can easily be added to the standard_ ones (/tmp is also
hardcoded into standard_load) and/or in the various protocol routines
(rsh, ssh ...), I didn't do it as, from what I see in our toolchains'
testsuites, remote_ routines are the entry points, but do you think it
is something needed ?

- I didn't modified remote_upload routine to upload a file from the
given remote_dir as it will brake testcases like profiling feedback
ones which generate the profile info files in a specific directory, do
you think this behavior makes sense, or that GCC profiling harness
have to be changed to handle a dedicated remote dir ?


Attachment: remote-validation-fix.diff
Description: Text document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]