Hi David, Thanks for these insights! I've also noticed that the routine gives consistently good results when the test case allocates large chunks (20 MB) of memory. The nondeterminism happens for the small chunks (32 bytes) version. My guess is that the memory allocator in glibc uses different allocation strategies and heap areas depending on the size of the chunk, and it may not count all of them when reporting the total memory usage. In any case, I have temporarily disabled the small chunks version of the test case and now everything seems to work well.
Cheers, Stefan On Tue, Aug 23, 2011 at 11:38 PM, David Ramos <[email protected]> wrote: > Hi Stefan, > > I'm not sure why it's being so inconsistent for you on such a small > testcase. However, this LLVM routine does suffer from an overflow problem on > 64-bit machines. Any memory usage over 2GB is treated as a signed negative > number (easy to fix), and over 4GB overflows completely. Unfortunately, > glibc doesn't provide an interface for reliably figuring out the size of a > 64bit heap. I doubt this is happening in your case, but the routine is > pretty unreliable in general. > > -David > > On Aug 23, 2011, at 2:31 PM, Stefan Bucur wrote: > > > Hi, > > > > I've recently noticed that the Klee test case test/Feature/MemoryLimit.c > intermittently fails on my machine [*]. The test case expects that Klee > would terminate the running state after a (small) memory limit is reached. > However, sometimes this did not happen, and Klee successfully terminated > without reaching the memory cap. > > > > Therefore, I added some debug messages that outputted the memory usage > reported by the sys::Process::GetTotalMemoryUsage() invoked by Klee in > Executor::stepInState, when comparing to the MaxMemory command line > parameter. > > > > I was surprised to find that the growth rate of this value varied > significantly across multiple independent runs, supposedly equivalent. In > some runs, the growing rate was so slow that it allowed Klee to terminate > without reaching the memory limit. The reported memory usage was apparently > underestimating the actual memory usage implied by the execution of the test > case (200 MB). > > > > Do you have knowledge about the reliability of this LLVM call? Wouldn't > perhaps be better to use a different metric (like the amount of memory > mapped in the process address space, which also shows in utilities such as > "top")? > > > > Thanks, > > Stefan > > > > [*] I'm running Ubuntu 10.10 x64 on a quad-core machine with 20GB of RAM. > > _______________________________________________ > > klee-dev mailing list > > [email protected] > > http://keeda.Stanford.EDU/mailman/listinfo/klee-dev > >
_______________________________________________ klee-dev mailing list [email protected] http://keeda.Stanford.EDU/mailman/listinfo/klee-dev
