This is intentional, and the following key sequences should
be used to ensure orderly cleanup.
A SIGINT signal will abort processing for the current test. On
a UNIX system this is usually a control-C or DEL character. On
a Win32 system this is always control-C.
A SIGQUIT signal (on a UNIX system) or a SIGBREAK signal (on a Win32
system), will abort processing for the entire test run.
On a UNIX system this is usually by typing a control-\ character.
On a Win32 system this is always control-BREAK.
back to index
Occasionally when running TETware we get the following type of messages:
50||(lock.c, 120): can't acquire exclusive lock
The lock appears to be a file in the test directory. Any ideas as to what
might be causing this?
When tcc processes a test case, it uses a locking scheme to prevent
multiple tcc processing threads from interfering with each other.
This functionality is described in Chapter 3 of the TETware Programmers
Guide.
The times that tcc acquires and releases the locks are mentioned in
the tcc processing descriptions in Sections 3.4 -> 3.6 ({Build, Execute, Clean} mode processing).
The locking mechanism itself is described in section 3.10 (Locking).
The error messages that you describe are generated when tcc can't
create a lock for some reason. Usually this is because either:
- the directory in which the lock is to be created doesn't
exist or is not writeable
OR:
- the lock already exists when tcc attempts to create it.
Clearly, (1) is a test suite setup problem.
The directory containing a test case that is mentioned in a scenario
must exist and be writeable by tcc (in TETware-Lite) or tccd (in
Distributed TETware).
Here are some common reasons for (2):
- The test suite is being processed by more than one instance
of tcc.
- The scenario uses the :parallel: directive and the test
suite has not been structured in a way that permits parallel
processing.
- A previous tcc run has crashed or has been killed, leaving
locks in place.
The solutions to (2) are:
- Make sure that the test suite is only being processed by one
instance of tcc. If you are using Distributed TETware, remember to check that
your system is not being used as a remote target of tcc running
on another system.
- If you are using the :parallel: directive, you must arrange
for each test case to have its own directory.
If you use :parallel,count: to execute more than one copy of
each test case, you must set TET_EXEC_IN_PLACE=false in the
execute mode configuration.
- Make sure that there are no instances of tcc running, then
remove the lock(s) by hand.
See T1 for how to terminate tcc cleanly.
back to index
TET_OUTPUT_CAPTURE is required here because in
order to have such output trapped and placed in the journal file
it is necessary to redirect stdout and stderr. That's essentially
what TET_OUTPUT_CAPTURE=True does.
It should also be emphasised that the value for TET_OUTPUT_CAPTURE
controls whether the tool or test case being executed uses the
TETware API. So the naming and use of the variable reflect more
than just whether stdout and stderr are redirected.
(Note that TETware includes extensions for TET_API_COMPLIANT and TET_PASS_TC_NAME
to give finer granularity than just TET_OUTPUT_CAPTURE).
back to index
This is because the execution of test cases on a POSIX.1 system
should follow standard behaviour for well defined signals (that is,
the POSIX.1 defined signals). The TETware test case manager (TCM) is
able to handle these signals according to that specification
precisely because of the POSIX definitions. A test case that
ignores these signals, or changes the default handling, is
likely to be breaking (perhaps inadvertently) some feature of
the system or feature being tested.
back to index
The TET_SIG_IGN and TET_SIG_LEAVE variables are really intended to
be used to specify an action for non-POSIX.1 signals where the test
case manager is unable to accurately determine what to do with
such signals.
If it really is necessary to ignore or change the handling for
POSIX.1 signals, code should be inserted into the test case(s) to
do it. The point is that the handling of signals should be under
control of the test suite author, not the end user. By disallowing
POSIX signals in TET_SIG_IGN and TET_SIG_LEAVE TETware takes care of
the POSIX signals and so the test suite author only has to be concerned
with any non-POSIX signals that are relevant to whatever is being
tested.
back to index
I modified the systems, systems.equiv and services files as documented
in the Installation Guide. When starting up tccdstart I get the
following message:
tccdstart (tccdport.c, 80): tcc/tcp: unknown service Valid name but no data.
When tccdstart needs to determine the well-known port number on which to
listen, it makes a call to
getservbyname("tcc", "tcp")
The error message is generated when this function call fails, and
usually means that there is no entry for the "tcc" service in the
services database.
On our Windows NT 4.0 system, the services database lives in the file
c:/winnt/system32/drivers/etc/services
You should check this file and ensure that it contains the following
line:
tcc NNNN/tcp
where NNNN is the port number that you want to use.
back to index
The TETware tcc uses the trace subsystem in dtet2lib, this is used
for debugging possible problems with TETware itself and its intended
purpose is for use in conjunction with the source code.
There is a description of the user interface to this subsystem in the
section entitled "Trace and debugging facilities" in Appendix G of the
TETware User Guide.
The trace mechanism is controlled by a number of flags.
Each flag controls trace debug output for a particular part of TETware.
Each flag has a value associated with it - the higher the value, the
more detailed is the trace debug output.
As well as the generic client/server trace flags, the following flags
are applicable to tcc:
| flag |
indicator |
description |
| Ttcc |
m |
general information and test case processing actions |
| Tscen |
P |
actions of the scenario parser |
| Texec |
g |
actions of the execution engine |
You can set these flags by using the following command line:
tcc -Tm6 -Tg6 ...
tcc -Tp6 -p -bec contrib/demo
back to index
Firstly, look at /tmp/tccdlog and the results journal
and look for any messages there.
The following shows a missing $TET_ROOT/systems.equiv file (tccdlog output)
tccd (5468) 26 Mar 8:45:42: connection received from localhost
tccd (5468) 26 Mar 8:45:42 (tccd_in.c, 421): can't open /home/dtet/systems.equiv: No such file or directory
tccd (5468) 26 Mar 8:45:42 (tccd.c, 400): client connection closed (sysid = 0, pid = 5463: MTCC)
If that does not help the following trace switches can be useful:
To trace in more detail what tccd is doing you can use the trace
switches -TS,s4
tcc -TS,s4 ....
If you use -TS,s6 you can trace the whole configuration exchange
process (which is illustrated by the diagram on page 56 of the
Programmers Guide).
tcc -TS,s4 ....
If you use -TS,e3 as well, you can watch the message request/reply cycles.
tcc -TS,s4 -TS,s4 ...
Also see the TETware Knowledge base for further information.
back to index
Its possible to set environment variables in the /etc/inetd.conf file,
for example to pick up the Java tools
# tcc
tcc stream tcp nowait tet /home/dtet/bin/in.tccd in.tccd -m 002 \
-e PATH=/bin:/usr/bin:/usr/local/jdk1.1.3/bin \
-e CLASSPATH=.:/usr/local/jdk1.1.3/lib/classes.zip
Please note that in the above example the lines have been folded
and need to be on a single line.
back to index
