I had quite an interesting bug hunting last week in one of our extern engagements. In summer a memory leak was discovered in a new used third party library. Back then, we started with testing using Java profilers (Java SDK ships a good enough profiler - visual vm). Surprisingly, we found nothing; the heap didn’t grow, number of threads remained the same, … in short, the usual suspects seemed innocent. Due to some other projects, we hadn’t enough time to do more testing, and so we just informed the company that sells the library about the issue. After some weeks, the company’s response was a we-dont-have-a-memory-leak-your-testing-is-wrong response (they suggested memory consumption is probably because of a different virtual machine and I have to admit that the task manager was also used to view the memory growth, which isn’t the tool to convince any real developer that there is a memory leak). However, the problem became urgent (like software problems tend to do) when the application was stress tested in real environment for a real customer. This project will be the first shipping with the new library. The application failed after approximately 6 hours due to a java.lang.OutOfMemoryError … Out of swap space?.

Continue Reading »