System-specific bug hunting?

Question

Hey all,

I have recently been messing around with SFML, a multimedia library. I use C# so naturally I went for the .Net binding, which you can fetch from the SVN in the latest 2.0 version. After a while of messing around I noticed that my application would sometimes hang up when using the Text object, an object used to draw texture fonts.

Further investigation by using profilers and the almighty Windows task manager revealed that a simple application using Text seemed to be somehow leaking memory. I then made a thread on the SFML forums about it (the thread). However, the main dev of SFML was unable to reproduce the bug on his machine. Thinking I couldn't be crazy, I sent it to a friend and he reported that he indeed saw it happening.

I made an example for Laurent, the dev of SFML, but he still couldn't reproduce the bug. Thinking this might be OS related, I sent the file to everyone I could and queried about their OSes. Here are my results:

http://spreadsheets.google.com/ccc?key=0AhcHeJlLGEVUdG1TTi1mTkFxeFlHYVRISXhjbFBDUmc&hl=en

As you can see, Turc and K7 both have the same OS but it doesn't crash on K7's (The table is incomplete where the test candidates didn't haven't repoted in yet). Anyways, this tells me that clearly it isn't an OS issue.

So my actual question is, what other factors but the OS or the architecture can influence bugs like this, that only appear on certain systems?

For reference, here is the file I sent my friends: http://dl.dropbox.com/u/3310651/MemLeak2.rar

And a screenshot of the profiling I did: http://dl.dropbox.com/u/3310651/sfml_memleak.png

Thanks!

Answer 1

I'm not sure what could be causing the difference, but given you can reproduce the issue on your machine one option would be to investigate why all the Text objects are hanging around. You can do this by using the "sos" debugging library and querying to find out what is rooting the Text objects. A good introduction to using sos in Visual Studio is available here.

If you only have the Express version of Visual Studio you can use sos from the WinDbg debugger which is part of the Debugging Tools for Windows. Another good overview which is tailored to using sos with WinDbg can be found here.

Answer 2

I figured it out after a while of talking on IRC and guys helping me out. The native library wasn't thread safe, so there were issues with allocating and deallocating referred objects at the same time.