By using a hardware watch point on a CamelMboxFolder reference:

p &((GObject *)mail_folder)->ref_count
watch *$<print-out-value>
commands
bt
continue
end

in gdb - I got a nice trace - which I've pruned signal pairs (etc. from) - to try to work out why we leak references to CamelFolders.

Sadly it's unclear to me (since things are unreffed at idle - why are they?) whether we are perhaps just missing a few idle handler runs before we exit to release some more refs (or something).

Either way, there is clearly a runaway reference leak on the 'Templates' folder; I have:

       0x8307418       CamelMboxFolder 12158   'Templates'     'Templates'

ie. 12158 references on exit last time ;-)