Hello,
Should a correct program compiled with gambit-c always show zero lost bytes (memory leaks) under valgrind? The reason I ask is that "dynamic languages" sometimes show funny under valgrind (AFAIR).
I am using gambit-c with cairo bindings (version 2 from dumping grounds), the program is currently short and simple, and calls cairo destroy functions when I think it should.
What it currently does: it reads (in sequence) pairs of .png images from a directory full of .png images, does xor on them and then releases resources (currently it does not write results).
It is quite possible that the bug is at the front of the keyboard ;-), but would you have any pointers on how to start tracking this down? When I run:
valgrind --leak-check=full ./my-program
It gives me some hex numbers (function addresses?), but what do I do with these?
Also, I have tested this under 2 different versions of 64 bit linux and libcairo, both show a leak, but not the same size.
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...
Afficher les réponses par date
From: Vladimir Konrad v.konrad@lse.ac.uk
I am
using gambit-c with cairo bindings (version 2 from dumping grounds), the program
is currently short and simple, and calls cairo destroy functions when
I think it should.
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.
I'm planning from a long time to investigate the question.
Thank you very much for the report.
--marco
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...
From: Vladimir Konrad v.konrad@lse.ac.uk
[...] Not sure this helps, in any case it is not a big deal (for my app).
Not a big deal for my apps too (and that is the reason why I haven't faced it yet), but it's something that must be verified/fixed. I hope I can find time to work on it soon, thanks for samples.
--marco
From: Vladimir Konrad v.konrad@lse.ac.uk
[...] 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).
I have done some tests, and I haven't observed any memory leak. My guess is that the memory "lost" is spent to allocate binding's symbols, that are permanent objects.
I've also added enums and automatic decrement of reference counters, so the code I've tested looks like:
(load "../cairo")
(define image_path "img.png")
(let loop ((counter 1000)) (if (zero? counter) #f (let* ([imsur_1 (cairo-image-surface-create-from-png image_path)] [imsur_2 (cairo-image-surface-create-from-png image_path)] [cr (cairo-create imsur_1)]) (cairo-set-operator cr CAIRO_OPERATOR_XOR) (cairo-set-source-surface cr imsur_2 0.0 0.0) (cairo-paint cr) (loop (- counter 1)))))
New version of cairo bindings is on dumping grounds.
--marco
Hello Marco,
New version of cairo bindings is on dumping grounds.
I am testing the Cairo-r3, and getting:
*** WARNING -- Could not find C function: "____20_cairo_2e_o1" *** ERROR IN | test-cairo-xor| -- /afs/cats.lse.ac.uk/users/vladimir/programming/test/scheme/gambit-scheme/cairo.o1: undefined symbol: cairo_destroy_rectangle_list
For the above, the cairo library binding was build as usual and loaded with "load".
A similar thing happens if I compile like this a different application (should be on one line): gsc-gambit -exe -cc-options "`pkg-config --cflags cairo`" -ld-options "`pkg-config --libs cairo`" ~/tmp/Cairo-r3/src/cairo.scm lib/sort.scm ~/lib/slib/gambit.init xor-images.scm
/home/vladimir/programming/lazane/xor-images_.c: ../../tmp/Cairo-r3/src/cairo.o: In function `_cairo_free_rectangle_list': cairo.c:(.text+0x1980c): undefined reference to `cairo_destroy_rectangle_list' collect2: ld returned 1 exit status *** ERROR IN ##main -- C link failed while linking "/home/vladimir/tmp/Cairo-r3/src/cairo.o" "/home/vladimir/programming/lazane/lib/sort.o" "/home/vladimir/lib/slib/gambit.o" "/home/vladimir/programming/lazane/xor-images.o" "/home/vladimir/programming/lazane/xor-images_.o"
Both of the above work with the r2 bindings. The system used is debian lenny with gcc 4.3.2 and the gambit-c 4.6.0 .
About the memory leak - I will test again. ;-) But maybe beginners should not post tests ;-)
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...
From: Vladimir Konrad
I am testing the Cairo-r3, and getting:
*** WARNING -- Could not find C function: "____20_cairo_2e_o1" *** ERROR IN |test-cairo-xor| --
/afs/cats.lse.ac.uk/users/vladimir/programming/test/scheme/gambit-scheme/cairo.o1:
undefined symbol: cairo_destroy_rectangle_list
Doh!
Sorry, I've just fixed it and uploaded new Cairo-r3.tgz on Dumping Ground. Thank you for report.
--marco
-
Marco Benelli -
Vladimir Konrad