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)