heap memory usage in L4 drops/oskit task

[Bert van Leeuwen]

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)