During my mem debugging effort I came across a useful thing. I'm sure all the gurus on this list already know about it, but for the benefit of the other oskit/l4 newbs like me, this is particulary useful:
http://www.cs.utah.edu/flux/oskit/html/oskit-wwwch31.html#x45-284600031
You can just link oskit_memdebug into your program (before -loskit_freebsd_c or whichever version you use), and it can help you find all sorts of memory problems.
On 7/28/05, Bert van Leeuwen bert.vanleeuwen@gmail.com wrote:
People probably aren't going to be believe me, but this is what I've found: I looked at all the scenarios which made my program crash, and compared to the ones that did not. A number of differences in program flow was identified, and by process of elimination I found the culprit leading to my memory corruption bug:
I replaced std::queue with std::list in one part of my program, and used list::push_back and list::pop_front instead of queue::push and queue::pop. This simple change causes the program to not crash anymore in L4.... Curious. So be warned: if you notice weird behaviour in your program in L4, and you're using std::queue, then that might be a factor... Possibly the version of STL included in l4/pkg/libstdc++ has an obscure bug in std::queue, as unlikely as it seems...
On 7/27/05, Bert van Leeuwen bert.vanleeuwen@gmail.com wrote:
*sigh* The same program seems to work fine in linux, I've tried running it through valgrind too without problems. Unlikely as it seems, I'm starting to suspect errant behaviour in drops or oskit. Perhaps the different thread scheduling exposes a bug in my program somewhere, or perhaps the semaphores are not working as expected (in linux I get to use the pthread mutexes, no such luxury in drops/oskit)