An experiment talking to a campaign server via the JobClient/JobServer
interface needs the FailControlMessage.proto compiler to run before the
experiment is compiled. A dependency on fail-comm ensures this.
If CommandLine.hpp and (indirectly) optionparser.h is #included in
FailBochsInit.ah, bochs compilation fails (for, e.g., gui/x.cc, at least
on Debian 6).
When we want to use a bounded job queue, job producer and job consumer must
run in different threads in order not to deadlock the campaign. Ideally
this functionality moves to the CampaignManager later (including the
retrieval of existing experiment results and storing new results).
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@1946 8c4709b5-6ec9-48aa-a5cd-a96041d1645a
Synchronize re-sending jobs in sendPendingExperimentData() and modifying
(or indirectly, via getDone() and the campaign, deleting) jobs in the
m_runningJobs queue.
a) sendPendingExperimentData needs an intact job to serialize and send it.
b) After moving the job to m_doneJobs, it may be retrieved and deleted
by the campaign at any time.
Additionally, receiving a result overwrites the job's contents. This
already may cause breakage in sendPendingExperimentData (a).
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@1943 8c4709b5-6ec9-48aa-a5cd-a96041d1645a
This modification creates and uses multiple intermediate snapshot states
(one every 1,000,000 instructions) to fast-forward to the FI site.
Unfortunately this doesn't work yet; the trace seems to change in many (not
all!) cases we do this. One possible cause could be an incorrect
(off-by-one or alike?) restoration of the serial device timers, and
therefore an earlier/later transition to "output buffer empty", resulting
in eCos' serial putc function needing a different amount of polling loop
iterations. Needs more investigation.
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@1940 8c4709b5-6ec9-48aa-a5cd-a96041d1645a
For the eCos kernel test campaign we define a relatively "special" metric
to compare FI results from different applications: Instead of aligning
the fault-space dimensions (e.g., by artificially adding "don't care" space
to the right for shorter application variants), we only keep the data
address axis constant. The rationale behind this is that -- despite the
benchmark applications' run-to-completion behavior -- an operating system's
scheduler usually runs ad infinitum, and that we therefore can extrapolate
from a short application run to any longer period.
In essence, this means we use a failure/experiment-length quotient (ignoring
the Y axis for simplicity, as it is constant in size) to compare
application variants, instead of an absolute failure count. One important
side effect is that we do not punish any application slowdown with this
metric. (And simply prolongating non-susceptible program sections with,
e.g., NOPs, seemingly "improves" fault tolerance.)
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@1922 8c4709b5-6ec9-48aa-a5cd-a96041d1645a
As we have a global CampaignManager instance in the fail-cpn library, a
JobServer member variable is not such a good idea. Essentially, we started
all JobServer threads (which is done in its constructor) within a
fail-client before this commit.
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@1915 8c4709b5-6ec9-48aa-a5cd-a96041d1645a
Over a few indirections, this broke Bochs' 16550 UART simulation after
transferring a few hundreds of bytes. The UART uses internal timers to
simulate the configured baud rate; these timers cease to work after
repeated misuse from the Fail/Bochs bridge.
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@1887 8c4709b5-6ec9-48aa-a5cd-a96041d1645a
This allows single-stepping through REP/REPZ/REPNZ iterations. We mainly
need this for a little more realistic timing model when, e.g., copying
large memory areas with REP MOVSB.
Be aware that memory-access tracing only works reliably for REPxx-prefixed
instructions if Bochs was configured with --disable-repeat-speedups, as
this Bochs optimization completely circumvents the usual memory access
paths.
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@1885 8c4709b5-6ec9-48aa-a5cd-a96041d1645a
As we don't know what happens after the "right margin" of the specified
fault space (specified by trace length, or an explicit instruction limit),
we need to do one FI experiment for every register/bit in the end.
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@1847 8c4709b5-6ec9-48aa-a5cd-a96041d1645a
This commit *introduced* a segfault to the nanojpeg experiment. Indeed there is
no point in clearing m_FireList here:
1. Multiple active listeners match an event coming from the simulator. These
listeners are moved from their queue to m_FireList.
2. In a loop iterating over m_FireList, one of the listeners is triggered
(ListenerManager::triggerActiveListeners()). Context switches to an
experiment. The experiment explicitly (or implicitly, e.g., by terminating)
calls simulator.clearListeners().
3. ListenerManager::remove() clears all active (but not currently fired, or
about to be fired) listeners from the main listener queue (and additionally
all type-specific special containers). To prevent the "about to be fired"
listeners to fire, they are copied to m_DeleteList.
4. The loop mentioned in 2. does not trigger any listener mentioned in
m_DeleteList. Afterwards, m_FireList (and m_DeleteList) is cleared.
Clearing m_FireList in step 3 invalidates the iterator used in the loop from
steps 2 and 4. In fact, this problem was the reason we introduced the
m_DeleteList workaround in the first place.
This reverts commit r1817.
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@1818 8c4709b5-6ec9-48aa-a5cd-a96041d1645a
This is necessary as a temporary fix: Currently, campaign code cannot use
Fail*'s architecture abstractions at all (e.g., we cannot iterate over all
existing GP registers). Until this is corrected by separating a concrete
backend and architecture information (the latter being usable by a
campaign), we now at least can use register IDs.
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@1792 8c4709b5-6ec9-48aa-a5cd-a96041d1645a
Unfortunately, this does not (yet) work as advertised. I need to fight another
round of CMake battles before retrying. Reverting to previous state for now.
This reverts r1753.
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@1767 8c4709b5-6ec9-48aa-a5cd-a96041d1645a
ag++ is now called with a list of currently active aspect headers
(ag++ -a aspect1.ah -a aspect2.ah ...). This resolves several problems at
once:
- Build directories may be positioned arbitrarily now, they need not be
a subdirectory of the project anymore.
- Multiple build directories can coexist within the project tree. Before
this commit, the generated instantiate-*.ah aspect headers disturbed
neighboring build trees.
- Due to this, the regression test should be runnable much more easily
now.
- The build time was reduced by an average of about 10%.
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@1753 8c4709b5-6ec9-48aa-a5cd-a96041d1645a
We need to be able to grep for our manual changes. It doesn't help to
have variations with "TUDOS" or "BOCHS-MODIFIED" around. Please
understand "// DanceOS" comments as an abbreviation for "this code was
manually modified and needs to be manually ported once we switch to a
newer version of Bochs."
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@1747 8c4709b5-6ec9-48aa-a5cd-a96041d1645a
Horst Schirmeier