views:

42

answers:

2

I get a crash like this:

#0  0x2c58def0 in raise () from /lib/libpthread.so.0
#1  0x2d9b8958 in abort () from /lib/libc.so.0
#2  0x2d9b7e34 in __malloc_consolidate () from /lib/libc.so.0
#3  0x2d9b6dc8 in malloc () from /lib/libc.so.0

I guess it is a heap corruption issue. uclibc does not have mcheck/mprobe. Valgrind does not seem to MIPS support and my app (which is multi-threaded) depends on hw specific drivers. Any suggestions to check the consistency of the heap and to detect corruption?

A: 

I would use a replacement malloc() (see also this answer) that can easily be made to be more verbose. I'm not saying you need garbage collection, but you do seem to need the additional logging facilities that the link provides.

If it is heap corruption, the collector is going to choke on it as well, and give you more meaningful messages. It should not be too difficult to use, get what you need, then stop using (especially if you just let it intercept malloc()).

Its not going to zero in on the problem like Valgrind does, but at least its an option :)

Tim Post
A: 

You could write stub drivers that pretend to be the hardware, which should let you build and test your program in a more full-featured environment.

caf