Problem with PKG_CHECK_MODULES under Mac OS X

Yesterday I had some problem with compiling my Glib application under Mac OS X. I knew that everything worked before on Debian and the problem had to be one of this darwin-specific.
Just to make myself clear. Here is the error I got after executing: ./configure

checking for pkg-config... pkg-config
./configure: line 3489: syntax error near unexpected token `GLIB,'
./configure: line 3489: `PKG_CHECK_MODULES(GLIB, glib-2.0)'

It seemed that there was some problem with PKG_CHECK_MODULES – autoconf’s macro responsible for detecting if a given library or module was installed in the system (basing on pkg-config).
In fact it came out that the macro was not defined at all. Normally after running aclocal command it should be generated in the file aclocal.m4. But in my situation there was no such entry.

Why did that occur? At that time I could not answer that question but at least I had some starting point.
You may probably know that aclocal is one of the tools of Autotools package. It creates a file named aclocal.m4 which includes a number of Autoconf macros that can be used later by configure. (one of these macros is of course PKG_CHECK_MODULES)
After reading the aclocal info page I found out that the aclocal.m4 file content was based on some external .m4 files and my configure.ac. I read that the PKG_CHECK_MODULES macro should be defined inside pkg.m4 file, and I really could find it there in my directory /opt/local/share/aclocal .

And here the answer came. I installed pkg-config and Glib using darwin ports, where the default prefix for packages was /opt/local. But on the other hand all the Autotools programs were located in /usr/bin. It was obvious that the prefix was different, so that aclocal could not detect pkg.m4 file and define PKG_CHECK_MODULES macro.

The only missing thing was to inform aclocal about the path of pkg.m4 and all other external .m4 files.
It was simple and could be done by adding extra parameter -I:

aclocal -I /opt/local/share/aclocal

Now after running my autogen.sh file which more or less looked liked that:

aclocal -I /opt/local/share/aclocal
autoheader
automake
autoconf

and later

./configure
make

my application was compiled.
Of course this can be also achieved in many different ways. To find more solutions I recommend studying aclocalinfo page (especially secion Macro Search Path)

Glib, GObject and memory leaks

I’m working currently on a server application which uses Glib and GObject system. I wanted to test it with valgrind against memory leaks, but the results had really scared me. I got tens of memory alignment errors and hundreds of bytes that leaked somewhere. After investigating the problem I found possible reasons and a solution.
The main problem is related to Glib and the way it allocates memory. It doesn’t use a pure C-like way which is based only on malloc & free. It rather uses something called “slice allocator”.
If you don’t know what the “slice allocator” is, I will quote some useful information from the Gnome Reference Manual.

Memory slices provide a space-efficient and multi-processing scalable way to allocate equal-sized pieces of memory, just like the original GMemChunks (from GLib <= 2.8), while avoiding their excessive memory-waste, scalability and performance problems. To achieve these goals, the slice allocator uses a sophisticated, layered design that has been inspired by Bonwick's slab allocator. It uses posix_memalign() to optimize allocations of many equally-sized chunks, and has per-thread free lists (the so-called magazine layer) to quickly satisfy allocation requests of already known structure sizes. This is accompanied by extra caching logic to keep freed memory around for some time before returning it to the system. Memory that is unused due to alignment constraints is used for cache colorization (random distribution of chunk addresses) to improve CPU cache utilization. The caching layer of the slice allocator adapts itself to high lock contention to improve scalability.

If you are interested more information about “slice allocator” can be found here.

Unfortunately valgrind has some problems with the above concept and cannot detect if given blocks of memory were actually freed or not. When I tested a simple Glib application using g_slice_alloc with valgrind I got tens of memory alignment errors.
You can imagine how hard it can be to find some other errors/leaks which are not related to “slice alloc”, but are rather the fault of the programmer.
Having tens or hundreds of messages printed by valgrind can be quite misleading and in fact can hide some real problems. So how to avoid that? The simplest solution is always the best. Why can’t we disable “slice allocator”? Of course only for testing, later on when we are sure that there are no memory leaks in our application we can turn it on again.

In order to do this we have to set an environmental variable which disables the “slice allocator” and forces Glib to use normal mallocs.

G_SLICE=always-malloc

There is no need to change anything in a source code, even the program doesn’t have to be recompiled.

Unfortunately “slice allocator” is not the only problem, the other one lies on the GObject side.
I don’t know why, but somebody invented a really “nice” function called g_type_init, which is responsible for initializing GObject type system. Ok, its great but why there is no g_type_deinit? Does anyone know where the whole memory that was previously initialized is freed? Valgrind doesn’t know that and again it complaints…
I managed to get rid of some of this errors by creating suppression files that are forcing valgrind to omit some of the most common errors. Of course it is not the best solution, but at least it can help to reduce the number of errors that are not the result of our fault.

The suppression file can be found below:
glibsupp.txt

One thing is certain. The list of suppression will be expanding. The more I work with Glib the more suppressions I have to add. The current version of this file includes suppressions mainly from GHashTable, g_thread_init and g_type_init. If I find more possible leaks I will update this file.

Now it’s time to start valgrind with the whole configuration which allows to get rid of this Glib and GObject errors, the command is as follows:

G_SLICE=always-malloc valgrind --suppressions=build-aux/glib.supp --leak-check=full --show-reachable=yes ./our_program

Logic gates with Neural Networks

Simple Java Swing application written to present learning abilities of Neural Networks. Program uses a back propagation algorithm and provides a set of adjustable logic gates which can be used for the testing purposes.

Read More

Pacman3D

Pacman3D is a clone of a well known computer game moved into 3D world. It was created for a Computer Graphics course during my studies at Windesheim University of Applied Sciences, Holland. The project was realized in a group of five people. My main responsibilities were connected to 3D scene coding, sound effects, game AI and basic 2D graphics (like menu, game panel and console).

Some of the game elements are based on Quake graphics (menu, console etc.). However the core of the Pacman is based on the original game rules.

Read More

Image Processing Tools

Useful collection of Image Processing and manipulation algorithms embedded in a GUI application enabling quick previewing and comparison. Application written in Java, using Swing and JUnit tests.

Read More

aMazeProject

aMazeProject is a simple maze generator and solver. Application is written in Java and was created using NetBeans 6.0 IDE. The code is commented so that it should be self explanatory.

Read More

Simple Digit Recognizer

A simple digit recognition application in Java using a concept of Neural Networks and back propagation algorithm.
The application is able to detect one character digits or symbols having some minor distortions.
My project is based on the algorithm described by Sacha Barber on the codeproject.com

Read More

Instant Messenger

PIMP is a client server Instant Messenger based on an XML protocol. The application is a composition of two independent components; a server written in Python and client written in Java. The two parts are communicating with each other using invented protocol. The client was created as a final project for GUI Programming course while the server was realized as an independent module when I’ve been learning Python.

Read More