> > So when this happens, my program would allocate gigabytes of ram. And > > since I used --malloc-fill=, valgrind would then initialize this ram > > (I'm speculating here) causing big time swapping. I found this out by > > disabling swap memory. > To verify that this is the problem, you might use --trace-malloc=yes, > and see the last trace before the thing does not respond anymore. > Note that also that if that is the problem, either ulimit -d > or ulimit -m should give a protection and make the thing fail.
The trace malloc (I have that one) never ends up on disk. I also tried the -d and -m but neither helpded. So hmmm, maybe then it is some other problem. > > So either I'm totally wrong and something else is going wrong or it > > might be nice to implement "lazy malloc fill" which initializes pages > > to that value only when a pagefault occurs. Might help overcommit as > > well. > > In your case, wouldn't that only hide a (real) bug ? Well, no: it would more slowly fill the memory which I can monitor then with 'top'. > It would be difficult to implement such a page fault handler at Valgrind > level, from what I understand from Valgrind and linux. >From what I read on wikipedia, Valgrind runs things in a virtual machine and from my experience (wrote an MSX (z80) emulator once, no twice) you can emulate everything, maybe a tad slow. -- www.vanheusden.com bitcoin account: 14ExronPRN44urf4jqPMyoAN46T75MKGgP msn address: s...@vanheusden.com ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
