Note: I found that 20 shoots is not enough to get conclusive leak results // ignore the previous test results. It seems leak conditions are fairly stable until 20 shoots is reached.
These may yield some insight // I'm sure you can deduce my rationale as you follow each test. I standardized on 100 shoots. All tests show a screen shot at 1 shoot and 100 shoots. Some tests have screen shots at 22, 33 and 51 shoots added, so you can observe leak progression.
What I see here ..... from the JPG ONLY tests it is quite obvious that how the directories are deleted have a large impact on leak behavior. Adding CR2 to JPG effectively doubles the leak in the non-transfer and transfer conditions respectively. Worst is TEST 3, best is TEST 4. TEST 1 somewhat agrees with your "24-byte" link.
JPG ONLYTEST 1 #67: 100 shoots, no dcimdl
Leak: 35 B/shoot
cold restart
TEST 2 #68: 100 shoots, full dcimdl, DCIM remains but is empty
Leak: 146 B/shoot
cold restart
TEST 3 #69: 100 shoots, full dcimdl, with DCIM delete (blank SD after each shot)
Leak: 201 B/shoot
cold restart
TEST 4 #70: 100 shoots, full dcimdl, files delete only, leaving CANONMSC and 122___09
Leak: 91 B/shoot
cold restart
TEST 5 #71: consistency test - repeat TEST 4
Leak: 92 B/shoot
cold restart
JPG & CanonCR2TEST 6 #72: repeat TEST 5
Leak: 201 B/shoot
cold restart
TEST 7 #73: repeat TEST1
leak: 86 B/shoot
cold restart
Screen shots:
http://www.sendspace.com/file/6klp5yThus I can confirm your assessment that the latent FIALs in LONG TESTs might be leak-related on that malloc() call you demonstrated. I am interested in your expert analysis and thoughts on these results ... Canon ? CHDK ?
It's possible for me to do a more rigorous isolation sequence in dcimdl, but I'd like your comments and advice first.