I tried valgrind on a testnet node with cgminer, but so far no luck finding useful clues.
Based on what I have heard so far, it seems this is related to getwork. Since a pool at most generate ~100 blocks a day, coinotron said he had to restart ppcoind once a day, I assume that ppcoind was eating >1gb a day, so this excludes the possibility the leak is related to valid blocks (each block taking about 10KB~100KB).
Now getwork does maintain a list of block candidates and a leak there could account for the rapid memory increase. I didn't change things related to allocation and delete of these block candidates and a code review there didn't reveal obvious problem either. I believe cs_main is also used to serialize getwork access so there shouldn't be concurrency issues with the block candidates.
Andy I seem to remember you were testing with some pool software earlier and also observed memory leak issue. Is there a simple way for me to set up a pool software and reproduce this situation? Can you all (Chris, coinotron, Andy) confirm my observations? How fast is ppcoind leaking memory in your production system? Is the leak speed roughly proportional to the number of getwork requests?
Thanks,
Didnt check if it was proportional to generate or getwork, as, hard to tell which - could even be to "mature", but I observed it as per below, prior to "mature" being reached.
I was running a private pool for a while yes, I could set it up again, but the pool software wasnt the problem - I replicated the leaks with valgrind with just ppcoind on testnet, with a single GPU.
If I pull out the valgrind logs dumps for testnet on mining say 5 blocks, and again on 50 blocks, will it be of any use?