Valgrind 3.3 - Advanced Debugging and Profiling for GNU/Linux applications by J. Seward, N. Nethercote, J. Weidendorfer and the Valgrind Development Team Paperback (6"x9"), 164 pages ISBN 0954612051 RRP £12.95 ($19.95) Get a printed copy>>>

Valgrind 3.3 Buy the book here >>> support free documentation

4.2.3 Wrapping Semantics

The ability for a wrapper to replace an infinite family of functions is powerful but brings complications in situations where ELF objects appear and disappear (are dlopen'd and dlclose'd) on the fly. Valgrind tries to maintain sensible behaviour in such situations.

For example, suppose a process has dlopened (an ELF object with soname) ‘object1.so’, which contains ‘function1’. It starts to use ‘function1’ immediately.

After a while it dlopens ‘wrappers.so’, which contains a wrapper for ‘function1’ in (soname) ‘object1.so’. All subsequent calls to ‘function1’ are rerouted to the wrapper.

If ‘wrappers.so’ is later dlclose'd, calls to ‘function1’ are naturally routed back to the original.

Alternatively, if ‘object1.so’ is dlclose'd but wrappers.so remains, then the wrapper exported by ‘wrapper.so’ becomes inactive, since there is no way to get to it--there is no original to call any more. However, Valgrind remembers that the wrapper is still present. If ‘object1.so’ is eventually dlopen'd again, the wrapper will become active again.

In short, valgrind inspects all code loading/unloading events to ensure that the set of currently active wrappers remains consistent.

A second possible problem is that of conflicting wrappers. It is easily possible to load two or more wrappers, both of which claim to be wrappers for some third function. In such cases Valgrind will complain about conflicting wrappers when the second one appears, and will honour only the first one.