heap memory usage in L4 drops/oskit task

[Bert van Leeuwen]

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 at 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 at 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)
> 


-- 
BvL