28. October 2011

Mutextrace – simple tool for detecting problems with mutexes

Debugging multithread apps is not easy task. Some problems never occur in debugging mode and it could be discovered only when application is running for long time. One of problematic issues in multithread apps are mutexes.

There is very simple tool in Debian distribution that could help you with identifying problems mutexes. The tools is mutextrace.

Quote from package description:

This tool displays mutexes locked and unlocked during execution of a program, and can provide hints for debugging multithreaded applications. As it is fairly lightweight and easy to use, it is ideal at the start of a debugging session or when only limited resources are available.

It cannot detect data races as it only looks at the synchronization primitives themselves; if you need that, use helgrind (in the valgrind package) instead.

How to use mutextrace? Like strace. Just add mutextrace before your application in the shell:

mutextrace ./mutex-tester-app param1 param2

Result:

lock #1, free -> thread 1
init #2
lock #2, free -> thread 1
unlock #1
lock #1, free -> thread 1
init #3
lock #3, free -> thread 1
unlock #1
unlock #3

Simple :-)

I couldn’t find reference to original source of mutextrace. It seems that it does not exist.

14. October 2011

_ITERATOR_DEBUG_LEVEL’: value ‘0’ doesn’t match value ‘2’

Update 16.10. 2011: new information added to article.

I was trying to compile an application with Visual Studio 2010 which has some dependency on GDAL open source library.

Everything went ok. GDAL compiled without problem from VS and also from command line:

nmake -f makefile.vc MSVC_VER=1600 DEBUG=1

Compilation of application based on GDAL was also ok. The only problem was when I switched project from Release mode to Debug mode. Linker was throwing a lot of messages like this:

'error LNK2038: mismatch detected forĀ _ITERATOR_DEBUG_LEVEL': 
value '0' doesn't match value '2' in vrtizer.obj

I found some explanation that new version of VS has _ITERATOR_DEBUG_LEVEL set to 2 in Debug mode. It means that there are some extra security controls over iterators to detect memory leaks and other problematic stuff with iterators.

After longer research I came to realization that GDAL is compiled with /MD switch and my application wasn’t. The solution was easy. I just added /MD and Debug mode of app start working like a charm.

Quote from MSDN about /MD compiler switch:

Defines _MT and _DLL so that both multithread- and DLL-specific versions of the run-time routines are selected from the standard .h files. This option also causes the compiler to place the library name MSVCRT.lib into the .obj file.
Applications compiled with this option are statically linked to MSVCRT.lib. This library provides a layer of code that allows the linker to resolve external references. The actual working code is contained in MSVCR71.DLL, which must be available at run time to applications linked with MSVCRT.lib.

Update 16.10. 2011

/MD solved problem, but there was another warning: Command line warning D9025: overriding ‘/MDd’ with ‘/MD’.

To solve Iterator issue for GDAL you need to compile DEBUG version of gdal.lib with switch /MDd instead of default /MD.

Just open nmake.opt file and replace /MD in lines with DEBUG definition by /MDd.

There are two lines with MD:

OPTFLAGS= $(CXX_ANALYZE_FLAGS) /nologo /MDd /EHsc /Zi /W4 /D_CRT_SECURE_NO_DEPRECATE 
/D_CRT_NONSTDC_NO_DEPRECATE /Fd$(GDAL_ROOT)\gdal$(VERSION).pdb /DDEBUG
OPTFLAGS=   /nologo /MDd /EHsc /GR /Zi /W4 /Fd$(GDAL_ROOT)\gdal$(VERSION).pdb  /DDEBUG

Then rebuild GDAL:

nmake -f makefile.vc clean
nmake -f makefile.vc MSVC_VER=1600 DEBUG=1