Home Corporate Contacts


You are here: TETworks > TETware FAQ Index > FAQ

Troubleshooting Questions

T1. How to I stop tcc running properly? When I hit the interrupt key some processes keep going, and sometimes lock files get left behind,

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

T2. Why do we get TETware locking errors? How can we avoid them?

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:

  1. the directory in which the lock is to be created doesn't exist or is not writeable
  2. OR:

  3. 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

T3. Why does TET_OUTPUT_CAPTURE need to be enabled in order to see make problems?

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

T4. Why does TETware not allow POSIX.1 signals to be set to be ignored or left unchanged?

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

T5. How will results be perverted if POSIX.1 signals are mentioned in TET_SIG_IGN or TET_SIG_LEAVE?

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

T6. tccdstart does not work on Windows NT, what should I do?

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


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

T7. How does the TETware trace facility work?

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 ...

So for example to see the scenario processing in detail:

tcc -Tp6 -p -bec contrib/demo

back to index

T8. How can I trace what tccd is doing?

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

T9. When using Distributed TETware tccd does not find tools not in the default PATH.

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

Home Contacts Legal Copyright Corporate News

Copyright © The Open Group 1995-2012, All Rights Reserved