NoBug

The following features are provided by NoBug:

In contrast to traditional debuggers, NoBug is a non-interactive debugger which is linked to your application doing hard-coded tests in an efficient, low-overhead way.

NoBug is a (macro-)library, it is not a C/C++ language extension. This means that code must be called at runtime to benefit from the set up contracts. Whats not tested is likely slipping through the net. Being part of the program itself it is affected by memory corruption, certain kinds of misuse may introduce new bugs (test expressions with side effects for example).

NoBug has been developed on linux, using gcc. It should be possible to port it to any other POSIX compliant operating system. Platform/compiler specific things are kept optional. Currently Linux with a gcc that conforms to C99 is supported for both 32 and 64 bit architectures.

NoBug has few mandatory dependencies on other software and libraries, some things such as valgrind support are optional and should be automatially detected during the build, i.e., when ./configure is called. Nevertheless it requires pkg-config to be installed, you get some weird errors already at bootstrapping (autoreconf) when this is not available.

Releases are available on: http://www.pipapo.org/nobug-releases/

Gpg signed tarballs are being used for distribution. The first step involves checking the signature:

This will produce a nobug-VERSION.tar.gz and report if the signature could be validated.

Since they are built with gnu autotools, the usual build and install procedure will work:

You can obtain a development version by using git. The git repository can be cloned via: git://git.pipapo.org/nobug or mirrored at repo.or.cz git://repo.or.cz/nobug.git.

Clone the git repository by:

After cloning the repository, then bootstrap the autotools:

Then the usual cd build && ../configure && make && make install (as above) will work. Careful users may run make check to run a testsuite before installing.

To update to any new revision, just enter the nobug dir and

After that you can build as above (cd build && ../configure && make && make install). This default pull will update from the master branch which is meant to be an on-going stable version (latest release + bugfixes).

Currently, NoBug installs the following:

There are Makefile targets for generating the documentation, Either one of the following does what you may expect:

building the documentation has quite some more dependencies than building NoBug itself. Unless you are a packager you may want to refer to the online doc or the shipped README which is actually this full nobug manual. Generating the documentation requires: gawk, asciidoc, graphviz and some toolchains to further process docbook (dblatex, …).

Your application will have to include the header file nobug.h before NoBug can be used:

Once you've included the NoBug API in your application, you'll then have to select a build-level. Build-levels are discussed later, c.f., buildlevel. Build-levels are used to define the amount of information NoBug provides to you. Maximum information is generally required while developing an application and the ALPHA build-level is most apropriate during this phase; whereas the released phase of an application will usually only require sparse information, for which the RELEASE build-level has been conceived.

A build-level must always be specified, otherwise the compiler will complain while attempting to compile your application. You can specifiy a build level in one of two ways: use a define statement in one of your modules, or pass the build-level using the -D flag to your compiler. Assuming we'd like to select the ALPHA build-level in your application, then your module would assume the following form:

Subsequently you'll have to link the appropriate library to your application.

A number of different libraries are available to link depending on whether you require to statically or dynamically link, or whether your application is multi or single threaded. The link order is important on your link line. Link the NoBug library after your application's modules. Here's how to statically link, single-threaded applications:

However, for more flexibility in selecting a build-level, you might wish to define various targets in your makefile, one for each build-level. In such cases, the -D flag in your makefile is most appropriate; so your link line for an ALPHA build with multi-threaded support would look like the following:

Both libraries must be initialised before they can be used. There are a number of different ways to initialise the NoBug libraries. One of the easiest ways to initialise the NoBug libraries is to use the NOBUG_INIT macro, which must be used before any features can be used or any thread is created. This is discussed in more detail in the multithreading chapter.

So putting all this together, our application using NoBug might look something like the following:

Many aspects of NoBug can be configured by overriding macros before nobug.h is included.

A project using NoBug can use autoconf to check for execinfo and valgrind:

For Multithreaded programs, you should also check for the availability of pthreads and flavour

When the resulting HAVE_PTHREAD, HAVE_EXECINFO_H and HAVE_VALGRIND_H are defined by the configure script, the relevant features become available.

NoBug then defines NOBUG_USE_PTHREAD, NOBUG_USE_VALGRIND and NOBUG_USE_EXECINFO to 1. If you do not want to use any of these features in NoBug, you can override these macros by setting to 0 before including nobug.h.

If NVALGRIND is defined, there will be no support for valgrind.

There are many other macros which can be set and overridden by the user to control behavior. Your help would be appreciated in expanding this documentation if you find some features useful; or simply contact any of the authors.

Various peripheral tools can be used by NoBug depending on the requirements of the application and the detail desired by the user. Such tools can provide additional, detailed information on the application and its behaviour. However, some applications may not require such detail and the associated overhead in information, and users may decide to omit excess information by excluding such tools.

At the moment NoBug supports the optional inclusion of gdb, valgrind and support for multi-threaded applications and the information that can be provided by these tools. However, support for other tools may be supplied in the future, e.g. the dbx debugger on OpenSolaris.

Such tools can be easily queried on the system and if they are available on a particular system, they can be used by NoBug to provide even more information on the application using NoBug. If such tools are not available or are not required by the user for one reason or other, then NoBug will happily function as usual, just without the extra information.

Testing the availability of such tools on a particular system can be achieved using autoconf, as illustrated in the following:

These macros are then automatically defined when the configuration system provides the associated HAVE_* macros, but can then be overridden by the user, depending on the user's requirements.

Finally, the appropriate library (for either single or multi-threaded applications) is linked to the project.

NoBug installed static and dynamic libraries. When your application uses multiple dynamic libraries which use NoBug or you build a dynamic library, then you have to link against the dynamic library.

You can use the pkg-config tool to gather information about NoBug in your build system.

Release builds remove all assertions, but logging is still kept. We make the assumption that bugs which were not covered in alpha and beta builds will not easily show up in releases because the assertions there were not sufficient. Furthermore, end users are not test bunnies and will not provide good bug reports anyway. If there is a problem in a release build, try to track down the cause using a beta build from the same source.

Before anything from NoBug can be used, NoBug must be initialised. This is performed by calling one of the NOBUG_INIT_ macros.

The simpliest such macro among the initialising set is the following:

NOBUG_INIT can be called more than once, subsequent calls will be a no-op, thus initialising in main and in libraries won't interfere with one another.

In other words, NOBUG_INIT is usually the first call to NoBug.

Since NoBug is intended to be available throughout its whole lifetime, destroying it is not to be advised. Nevertheless, there is a destroy function void nobug_destroy (void)

to shutdown NoBug, and this frees all resources associated with it. This is mostly used in the NoBug testsuite itself to check for leaks, and it might be useful for other programs which employ some kind of leak checker.

If you want to use environment variable controlled debuging, then you have to initialize each defined flag with

or

or one of the C++ compatibility macros.

This is documented later in the logging configuration chapter.

In Multithreaded programs you should assign an identifier to each thread. A thread identifier is a string which will be automatically appended with an underscore and a incrementing integer. It is is created with:

Calling NOBUG_THREAD_ID_SET("worker") will yield in a thread identifier worker_1 for example.

If you don't set an identifier, then NoBug will assign an automatic one. This is further documented in the multi threading section of this manual.

There are three different levels of debugging information available: alpha, beta and release. One of these levels must be specified before compiling, otherwise an error while compiling will occur.

A logging level can be selected by either using a define in one of the applications' modules, or by passing the appropriate level using the -D switch to the compiler:

If none of the above switches has been set, NoBug will abort the compilation with an error.

Nearly all NoBug Macros emit some log message. NoBug gives the user fine grained control over these log messages to display only interesting information without loosing details.

Log messages can be routed to various destinations. The following destintaions are available:

Each logmessage has a priority describing its severity in the same way as syslog messages do.

All non-fatal messages are associated with a programmer defined flag describing the source of the message (subsystem, module, …).

Putting this all together: A user can define which source/flag will be logged at what priority level and to which destination. To make this all easier, NoBug tries to provide reasonable defaults.

Each log macro has an explicit or implicit log-level which correspondends to syslog levels. Logging is only emitted when the message is more severe or the same as a defined limit.

Depending on the build level, there is a default logging target and a default limit which is selected when the user doesn't specify one.

The following default limits are available:

The default targets are:

You can override all these values with your own values. As an alternative, NOBUG_LOG_LIMIT and NOBUG_LOG_TARGET can be defined before including "nobug.h" to override all defaults.

Flags are used to inform NoBug about subsystems/modules or even finer grained sections of the code. These are referred to as channels in other logging libraries.

A flag should be declared in a headerfile using the following mechanism:

It is advisable to do so in one of your header files.

Furthermore, the flag must be defined in some implementation file by using one of the following schemes:

or:

Moreover, macros are available that accept a parent flag as a parameter, which is then used to initialize the defaults from another flag:

or

This can be used to create hierachies of flags

Additional macros are available for applications written in C++:

These macros statically initialize the flags when they are defined, there is no need to call NOBUG_INIT_FLAG() (see below).

When the the following preprocessor constant is defined to be 1:

then all definitions here (NOBUG_DEFINE_*) become declarations only. When this is defined to be 0 (which is the default) then all definitions behave as described. This can be used to construct a headerfile which only contains definitions, but, by default, yield only declarations. This provides one convenient single point to maintain flag configurations.

Next you should call

or

once at the start of your program for each flag.

For flags defined with NOBUG_DEFINE_FLAG(flagname) the defaults are initialized as in the table above, while NOBUG_DEFINE_FLAG_LIMIT(flagname, level) is used to initialize the default target (depending on build level) to level.

The NOBUG_INIT_FLAG… calls parsing the environment variable NOBUG_LOG to configure what gets logged at runtime. The syntax is as following:

Roughly speaking, NOBUG_LOG contains a comma separated list of declarations for flags which are the name of the flag followed by a limit which is written in all uppercase letters and preceeded by a colon, followed by target declarations which are names of the targets, introduced by a at sign. Target declarations can have option, described in the next section. Limit and target declarations are optional and then choosen from the defaults table above. These defaults are currently just an guess what should be useable and might be redefined in future.

The Following options are available:

There are some debugging flags which are predefined by NoBug.

The flag NOBUG_ON is always enabled at LOG_DEBUG level. This is static and can not be changed.

The flag NOBUG_ANN is used for the source annotations. This is static and can not be changed. It differs from NOBUG_ON as in never logging to syslog and only define a LOG_WARNING limit for the application callback.

Actions on NoBug itself will be logged under the nobug flag itself. When you want to see whats going on (useful to check if you call NOBUG_INIT_FLAG() on all flags) you can enable it with NOBUG_LOG=nobug:TRACE.

The NoBug interface is almost completely implemented using preprocessor macros. This is required because NoBug uses the __FILE__, __LINE__ and __func__ macros to log information on the current file, line number and function. Moreover, all the flat namespace uppercase identifiers make it ease to recognise the macros in source code.

All macros are available without condition with a NOBUG_… prefix. Many macros (the common cases) are also available without this prefix as a convenience, however macros without this prefix must not have been previously defined. When NOBUG_DISABLE_SHORTNAMES is defined before including nobug.h, then only the NOBUG_ prefixed macros are available and the short forms will never be defined.

A set of macros are provided by NoBug that are postfixed by …_IF. These macros have the following form:

They perform the desired action only if when is true. For example:

The assertion will only be performed if foo is non NULL.

NoBug also also contains a facility to pass the source context (file, line, function) around, this can be used to write functions which handle things where one is more interested in the context of the caller than the location where the macros appears.

This macros are postfixed with …_CTX and take an extra context parameter (usually at last but before the logging format specifier and any variable argument list). The context parameter must be of type const struct nobug_context.

When the _CTX context form is used together with the conditional _IF form then the suffix of the macros is always …_IF_CTX.

The macros which take a context have no short form and must always be prefixed with NOBUG_….

We use names for parameters which describe their type. These names are orthogonal through all macro definitions.

NoBug passes information about the source location of a given statement in const struct nobug_context structures. These can be generated with NOBUG_CONTEXT or NOBUG_CONTEXT_NOFUNC. The later one doesn't define a function name and must be used when the function context is not available like in static initialization etc..

This assertion is never optimized out. Its main purpose is for implementing testsuites where one want to assert tests independent of the build level

Precondition (input) check. Use these macros to validate input a function receives. The checks are enabled in ALPHA and BETA builds and optimized out in RELEASE builds.

Postcondition (progress/output) check. Use these macros to validate the data a function produces (example: return value). ENSURE is enabled unconditionally in ALPHA builds and optimized out in BETA builds for scopes which are tagged as CHECKED.

The ENSURE_IF variants are enabled in ALPHA and BETA builds.

In RELEASE builds this checks are always optimized out, scopes tagged as UNCHECKED are not permitted.

Generic check. Use these macros when you want to validate something which doesn't fall into one of the above categories. A example is when a library function can return a unexpected result (scanf with syntax error in the formatstring, when a constant/literal formatstring is expected). The checks are enabled in ALPHA and BETA builds and optimized out in RELEASE builds.

NoBug overrides the standard assert macro, using NOBUG_ASSERT. This is just a compatibility feature, its use is not suggested.

Checking invariants. You can provide more complex checking functions which test the validity of datastructures. Invariants are only enabled in ALPHA builds for scopes which are not tagged as CHECKED and otherwise optimized out.

Logging targets a flag (except for ECHO) and is done at a log-level relating to syslog levels.

Never optimized out, logs at LOG_NOTICE level. Its main purpose is for implementing testsuites where one want to print and log messages independent of the build level

This is the most critical condition an application might log. This might be used if an error occurs which can not be handled except a safe shutdown for example.

An error which can not be handled occured but the application does not need to be shutdowen, perhaps waiting for an operator to fix the cause.

Application takes a error handling brach

Rare, handled but unexpected branch

Message about program progress

More detailed progress message

Very fine grained messages

Generic logging macro which takes the level explicitly, avoid this, unless you implement your own logging facilities.

anything more detailed than this base limits will be optimized out. This is used to reduce the logging overhead for RELEASE builds. By default the limit is set to LOG_DEBUG for ALPHA and BETA builds, so all logging is retained and LOG_NOTICE in RELEASE builds to log the application progress only coarsely then.

This macros can be defined before including nobug.h to some other log level (as defined in syslog.h).

TODO How to write DUMP handlers

One can write functions for dumping complex datastructures using the NoBug facilities. This is done by writing a custom function for each datastructure to be dumped which may recursively call other dumping functions. There are macros for logging within such a dumper function and for initiating a dump of a given datastructure.

A dump function has the prototype:

where NAME is the identifier for what you want to dump, POINTER is a pointer to the data to be dumped, DEPTH is a integer which will be decremented when recursing into the datastructure dumper (your dump function does that, see below) to limit the recursion depth, CONTEXT is a source context generated by nobug when you call DUMP() and EXTRA is a pointer transparently passed around you can use to store some extra state. // src/nobug.h:341 // .DUMP DUMP(flag, type, pointer, depth, extra) DUMP_IF(when, flag, type, pointer, depth, extra)

This macros call a datastructure dump of the object (pointer) in question. DUMP is only available in ALPHA and BETA builds, DUMP_IF is also enabled for the RELEASE builds.

extra is a void* which is transparently passed around and can be used to pass some state around. NoBug does not touch it.

Any output from DUMP handlers should be done by these macros.

Dumping is by default done on level LOG_DEBUG, this can be overridden by defining NOBUG_DUMP_LEVEL to some other level.

then you define a function like:

now you can use the DUMP() macros within the code

One can tag features as:

Something which shouldn't be used in future

not yet finished feature

known bug to be fixed later

enhancement to be done soon

future enhancement

used to tag code-path which shall be never executed.

same as else NOTREACHED(), but wholly optimized out in release builds.

The advantage of this tagging over plain source comments is that we can take some actions if we run in such a tag at compile or runtime:

the action to be taken when such a macro is hit depends on the build level:

Legend:

The programmer can tag any scope as UNCHECKED or CHECKED. In ALPHA and BETA builds, a global UNCHECKED is implied. In RELEASE builds, UNCHECKED scopes are not allowed.

NoBug has some macros which can be used to simulate errorneous behaviour:

substitutes to an expression and returns good when expr is false and bad when expr is true. In BETA and RELEASE builds good is always returned.

substitutes to a statement which executes bad when expr is true. Optimitzed out in BETA and RELEASE builds.

In both cases, when a fault is injected it will be logged at NOBUG_INJECT_LEVEL (default: LOG_NOTICE). This can be defined before including nobug.h to override it.

With little effort, NoBug can watch all kinds of resources a program uses. This becomes useful for resources which are distributed over a multithreaded program. Resource tracking includes logging actions on resource and checking locking policies over acquired resources. Resource logging is active in ALPHA and BETA builds when NOBUG_RESOURCE_LOGGING is defined to 1 (the default). The resource tracker which supervises locking policies is only enabled in ALPHA builds.

Resources are abstracted, NoBug has little knowledge about the semantics of a resource, it only keeps records of resources and the code using it and ensures basic constraints. Detailed usage checks of resource have to be done with other NoBug facilities.

Resources are identified by a arbitrary identifier which is just a pointer. Additionally a name, the type and the source locations which announced the resource are stored.

Code which wants to use a resource calls a enter macro with its own identifier and state, then might alter the state and finally a leave macro when finished with it.

When a resource is used one has to pass one of this states:

Possible state transitions:

There are small race conditions between logging and checking resource tracking and the actual call to the resource using function. This is a design decision there is no way to account for this exactly when the function call may block.

The Resource Tracker relies on proper announce/forget and enter/leave are properly pairing. The programmer should ensure that this is done right, otherwise the results are unpredictable.

Unless the user defines NOBUG_RESOURCE_LOGGING to 0 each of the above macros will emit a log message at NOBUG_RESOURCE_LOG_LEVEL which defaults to LOG_DEBUG.

Define and initialize handles for to track resources.

There are two kinds of handles, each resource itself is abstracted with a RESOURCE_HANDLE and every access to this resources is tracked through a RESOURCE_USER handle. These macros takes care that the declaration is optimized out in the same manner as the rest of the resource tracker would be disabled. You can still instantiate handles as struct nobug_resource_record* or struct nobug_resource_user* in structures which must have a constant size unconditional of the build level. The two *_INIT macros can be used to initialize resource handles and are optimized out when the resource tracker gets disabled.

Publishes resources.

Resources must be unique, it is a fatal error when a resource it tried to be announced more than one time.

RESOURCE_ANNOUNCE() acts like the head of a C loop statement, it ties to the following (block-) statement. Leaving and the user defined following statement are atomic. This statement must not be left by break, return or any other kind of jump.

Removes resources that have become unavailable from the registry.

The resource must still exist and no users must be attached to it, else a fatal error is raised.

RESOURCE_FORGET() acts like the head of a C loop statement, it ties to the following (block-) statement. Leaving and the user defined following statement are atomic. This statement must not be left by break, return or any other kind of jump.

Acquire a resource.

RESOURCE_ENTER() acts like the head of a C loop statement, it ties to the following (block-) statement. Leaving and the user defined following statement are atomic. This statement must not be left by break, return or any other kind of jump.

This is just an alias for RESOURCE_ENTER(flag, resource, user, NOBUG_RESOURCE_WAITING, handle)

This is just an alias for RESOURCE_ENTER(flag, resource, user, NOBUG_RESOURCE_TRYING, handle). Trying on a resource is similar to waiting but will not trigger a deadlock check. This can be used when a deadlock is expected at runtime and one handles this otherwise (by a timed wait or something like that).

Changes resource's state.

RESOURCE_STATE() acts like the head of a C loop statement, it ties to the following (block-) statement. Leaving and the user defined following statement are atomic. This statement must not be left by break, return or any other kind of jump.

Disconnect from a resource identified with its handle.

RESOURCE_LEAVE() acts like the head of a C loop statement, it ties to the following (block-) statement. Leaving and the user defined following statement are atomic. This statement must not be left by break, return or any other kind of jump.

Assert that we have a resource in a given state. For multithreaded programms the topmost state of the calling thread is checked, for non threadeded programs the most recent state on resource is used.

Dump the state of a single resource.

Dump the state of all resources.

List all registered resources.

The Resource Tracker is able to detect potential deadlocks. This is done by learning the relations between locks (precedence). A possible deadlock results in a log message and a fatal abort. Note that only waiting on resources can lead to a deadlock. Deadlock detection is implemented in the Resource Tracker and active in ALPHA builds and optimized out on any other build level.

For details about the deadlock detection algorithm see Appendix: Resource Tracking Alorithm.

NoBug provides callbacks, applications can use these to present logging information in some custom way or hook some special processing in. The callbacks are initialized to NULL and never modified by NoBug, its the solve responsibility of the user to manage them.

used for the logging callbacks

used for the abort callback

This global variable is initialized to NULL and will never be touched by NoBug. One can use it to pass extra data to the callback functions.

This callback gets called when something gets logged. NoBug will still hold its mutexes when calling this hook, calling NoBug logging or resource tracking functions from here recursively will deadlock and must be avoided. The log parameter points to the logging message in the ringbuffer. Unlike other logging targets it is not automatically limited to the log level configured in the flag but called unconditionally. The callback should implement its own limiting.

When one wants to do complex calls which may include recursion into logging and resource tracking functions, the intended way is to pass contextual information possibly including a copy of the log parameter in NOBUG_THREAD_DATA to the postlogging callback (see below). Other internal NoBug facilties, like the ringbuffer etc, are protected by the mutexes and may be accessed from this function.

This callback gets called after something got logged. The log parameter is always NULL and all NoBug mutexes are released. This means that this function may call any complex things, including calling logging and resource tracking, but may not call internal NoBug facilities. Contextual created in the nobug_logging_callback and stored in NOBUG_THREAD_DATA can be retrieved here and may need to be cleaned up here.

This callback gets called when the application shall be terminated due an error. It can be used to hook exceptions or similar things in. When it returns, abort() is called.

Using this macro one can pass a direct pointer to a flag where a name would be expected. This is sometimes convinient when flag pointers are passed around in management strutures and one wants to tie logging to dynamic targets.

The backtrace macro logs a stacktrace using the NoBug facilities. This is automatically called when NoBug finds an error and is due to abort. But one might call it manually too.

This is the default implementation for aborting the program, it first syncs all ringbuffers to disk, then calls the abort callback if defined and then abort().

If not overridden, evaluates to NOBUG_ABORT_. One can override this before including nobug.h to customize abortion behaviour. This will be local to the translation unit then.

Sometimes it is useful to have initializer code only in ALPHA builds, for example when you conditionally include resource handles only in ALPHA versions. An initializer can then use this macros to append a comman and something else only in ALPHA builds as in: struct foo = {"foo", "bar" NOBUG_ALPHA_COMMA_NULL };

This macros allow one to conditionally include the code in (…) only if the criteria on the build level is met. If not, nothing gets substituted. Mostly used internally, but can also be used for custom things.

It is important that NoBug protects certain operations with locks in multithreaded programs. You have to ensure that HAVE_PTHREAD_H is defined by the configuration system and use the libnobugmt library for linking. It is particular important that libraries using NoBug are compiled with HAVE_PTHREAD_H enabled when they are intended to be used in multithreaded programs.

When Multithreading is used, log messages contain a identifier of the originating thread. This identifier should be set by

Nobug will assemble a unique identifier by appending a underscore and a number to name, for example NOBUG_THREAD_ID_SET("gui") will result in a identifier like "gui_5". When you don't set a thread identifier, then NoBug assigns one automatically with the name thread preprended if needed. Thread identifiers may be reset with a new call to this macro.

Will return a const char* of the thread id in multithreaded programs and a pointer to a literal empty string in singlethreaded programs.

Evaluates to a variable of type void* which can be used to store thread local information. This is useable for callbacks which may prepare context information to be reused later.

This macro is also available in singlethreaded programs, refering to a single global variable.

Nobug initializes this variable to NULL and then touches it never again.

NoBug installs the nobug_rbdump tool for dumping the content of a persistent ringbuffer. It is invoked with the filename of the ringbuffer, the content is then printed to stdout.

NoBug maintains a test.sh script which drives extensive testsuites. Look at into the tests/ folder about how to apply this.

Each resource registers a global resource_record.

Every new locking path discovered is stored as resource_node structures which refer to the associated resource_record.

Threads keep a trail of resource_user strcutures for each resource entered. This resource_user struct refer to the resource_nodes and thus indirectly to the associated resource_record.

The deadlock checker uses this information to test if the acqusition of a new resource would yield a potential deadlock.

In multithreaded programs, whenever a thread wants to wait for a resource_record the deadlock checker jumps in.

The deadlock checking algorithm is anticipatory as it will find and abort on conditions which may lead to a potential deadlock by violating the locking order learned earlier.

Each thread holds a stack (list) of each resource_user it created. Leaving a resource will remove it from this stacklist.

Each resource_record stores the trail which other resource_records are already entered. This relations are implemented with the resource_node helper structure.

First we find out if there is already a node from the to be acquired resource back to the topmost node of the current threads user stack.

Deadlock checking is only done when the node is entered in WAITING state and only available in multithreaded programs.

If node was found above, then this locking path is already validated and no deadlock can happen, else, if this stack already holds a resource (user is set) we have to go on with checking.

If not then its checked that the resource to be entered is not on any parent trail of the current topmost resource, if it is then this could be a deadlock which needs to be further investigated.

if the resource was on the trail, we search if there is a common ancestor before the resource on the trail and the threads current chain, if yes then this ancestor protects against deadlocks and we can continue.

If no ancestor found, we finally abort with a potential deadlock condition.

store the tail and next aside, we need it later

remove user struct from thread stack The res_stack is now like it is supposed to look like with the user removed. We now need to fix the node tree up to match this list.

When the the user node was not the tail or only node of the thread stack, we have to check (and possibly construct) a new node chain for it. No valdation of this chain needs to be done, since it was already validated when entering the resources first.

iterate over all users following the removed node, finding nodes pointing to this users or create new nodes.

find the node pointing back to parent, create a new one if not found, rinse repeat

NoBug is released under the "GNU General Public License version 2 or any later" to protect its freedom. If one wants to use NoBug in a propietary program, please contact the main author for acknowledging relicensing terms.

For BSD license style Free Software, this means you can not distribute binaries linking NoBug without making its source available. To make this compatible, it is suggested that you dual-license your software with your prefered BSD like license and the GPL. As long as it uses NoBug, the GPL will take over and you have to make the source available, while one can ship a BSD or LGPL Licensed headerfile which defines all NoBug macros as empty macros and remove libnobug from the linking, then NoBug isn't used anymore and you may apply BSD license terms for resulting binaries.

Improvements and patches must be licensed as "GPL v2 or any later" to be acceptable. Further a contributor must either assign his copyright to the main NoBug author or agree with the possibility that NoBug can be relicensed for propietary use:

The intention is that anyone who worked on NoBug should be able to benefit from his work. This means one should be able to use it at his workplace, to gain a job or as well as relicense it for a customer. Unlike other projects which simply ask for transfering the copyright to the main author, NoBug tries to make it possible to retain the copyright by anyone who helped the project.

This additional agreement has no impact on the GPL, it's sole purpose is to define relicensing policies between the NoBug main author and contributors. When you recieve NoBug it will be licensed under GPL unless you personally acknowledged other terms with the NoBug main author (or any other main contributor).

If anyone feels he is not credited in the AUTHORS file or in any copyright notice, please contact the main author for inclusion.