Hello Marco,
Thank you for cairo binding btw.
It's possible that cairo bindings doesn't handle memory properly. Some cairo object are reference-counted; I though that handling them as opaque type would leave all the needed refcounting on the C side, handled by cairo primitives, but I'm not so sure.
Cairo does do reference counting, but it is not automatic - user is responsible to call destroy when necessary (AFAIK - the examples I saw show this).
I have attached 2 minimalist test programs, one is in c one in gambit scheme (both do essentially the same thing. (you would need to change path to .png file for them to work).
When I run the .c version under valgrind:
==11278== LEAK SUMMARY: ==11278== definitely lost: 0 bytes in 0 blocks. ==11278== possibly lost: 0 bytes in 0 blocks. ==11278== still reachable: 152 bytes in 1 blocks. ==11278== suppressed: 0 bytes in 0 blocks.
The "still reachable" is apparently common and ok (according to valgrind faq)
Vhen I run the gambit-c version under valgrind: ==11320== LEAK SUMMARY: ==11320== definitely lost: 152 bytes in 1 blocks. ==11320== possibly lost: 0 bytes in 0 blocks. ==11320== still reachable: 1,650 bytes in 6 blocks. ==11320== suppressed: 0 bytes in 0 blocks.
The strange thing is that the gambit-c looses _exactly_ the same amount of bytes as the .c version has under "still reachable".
Not sure this helps, in any case it is not a big deal (for my app).
Kind regards,
Vladimir
------
because it reverses the logical flow of conversation + it is hard to follow.
why not?
do not put a reply at the top of the message, please...
Please access the attached hyperlink for an important electronic communications disclaimer: http://www.lse.ac.uk/collections/planningAndCorporatePolicy/legalandComplian...