Hi,
is somebody using valgrind here?
I'm always getting this error message (tested several programms...)
==11013== Conditional jump or move depends on uninitialised value(s)
==11013== at 0x40731E4: ??? (in /lib/libc.so)
==11013== by 0x4083164: ??? (in /lib/libc.so)
==11013==
==11013== Conditional jump or move depends on uninitialised value(s)
==11013== at 0x4072924: ??? (in /lib/libc.so)
==11013== by 0x4072D98: ??? (in /lib/libc.so)
==11013==
vex mips->IR: unhandled instruction bytes: 0x0 0x6A 0x2 0xF5
==11013== valgrind: Unrecognised instruction at address 0x4923c31.
==11013== at 0x4923C31: ??? (in /usr/lib/libnl-tiny.so)
==11013== by 0x4082934: ??? (in /lib/libc.so)
==11013== Your program just tried to execute an instruction that Valgrind
==11013== did not recognise. There are two possible reasons for this.
==11013== 1. Your program has a bug and erroneously jumped to a non-code
==11013== location. If you are running Memcheck and you just saw a
==11013== warning about a bad jump, it's probably your program's fault.
==11013== 2. The instruction is legitimate but Valgrind doesn't handle it,
==11013== i.e. it's Valgrind's fault. If you think this is the case or
==11013== you are not sure, please let us know and we'll try to fix it.
==11013== Either way, Valgrind will now raise a SIGILL signal which will
==11013== probably kill your program.
==11013==
==11013== Process terminating with default action of signal 4 (SIGILL)
==11013== Illegal opcode at address 0x4923C31
==11013== at 0x4923C31: ??? (in /usr/lib/libnl-tiny.so)
==11013== by 0x4082934: ??? (in /lib/libc.so)
Valgrind seems limited on non-x86 architectures.
I guess it's because it tries to understand actual opcode/assembly instructions.
We tried using it on mpc85xx but our P1020 chip (from freescale/nxp) has some instructions that Valgrind does not understand.
Valgrind eventually adds support to these instructions.
But the pace is slow.
Depending on what you want to do, there may be alternatives.
For example you could preload a library (with LD_PRELOAD) to count mallocs & frees to check for leaks.
The method is a bit more limited than Valgrind, but it works on all architectures ; because it avoids caring about chip instructions
Thanks. I will try this. 
May I will write some wiki entry if everything works.
Furthermore some other developer used cppcheck.
I will try this too.
we also use cppcheck internally ; there are some limitations with it, since it has some implicit rules/definitions, but even so, it's pretty good
cppcheck does become more useful when you start defining rules for your own functions
Ahhhhh. There is a problem. The ubus libs are calling the free function very often.
Often it's free(0).
Hmmmm. Complicated to analyze if there are memleaks...
well, analyzing a program that's running is never simple right from the start
imagine if you have a program linking against libopenssl, libcurl, libubus, etc
for example Valgrind will always complain about libopenssl [with false positives], because it has some weird constructs that are not recommended for regular code, but are fine for crypto "random-ness"
so, then you need to define a list of suppressions for Valgrind
while, with LD_PRELOAD, the idea is to stop the program at some point in time, and dump whatever was not allocated to a file
you don't need to check what is alloc-ed & free'd at runtime ; it's like trying to photograph the piston of a car while it's running [ you can do it, but it offers not benefit, and it's difficult to do]
typically, leaks will exist in the program when you exit ;
of course, you also need to make sure your exit-path cleans everything when exit-ing, so that you don't have false positives
and you can ignore free(NULL) ; free() ignores NULL