[gambit-list] Memory leak (?) using `c-define`d functions from foreign release functions.

Mikael mikael.rcv at gmail.com
Mon Dec 30 04:09:04 EST 2013


Refcount is 1 by default so you need to decrease it for it to GFC?

Allocate a zillion points and check the two respective ways.


2013/12/29 Estevo <euccastro at gmail.com>

> Here's a more realistic version of what I was trying to do:
>
> (c-declare "struct { int x; int y; } point;")
>
> (define no-err ((c-lambda () scheme-object "___result =
> ___FIX(___NO_ERR);")))
>
> (c-define (release-point ptr)
>           ((pointer void)) scheme-object "scm_release_point" ""
>   (println "release-point called")
>   ((c-lambda ((pointer void)) void "___release_rc") ptr)
>   no-err)
>
> (c-define-type point (pointer "point" (point*) "scm_release_point"))
>
>
> (define p ((c-lambda () point
>              "___result_voidstar = ___EXT(___alloc_rc)(sizeof(point));")))
>
> (println "p is " p)
> (set! p #f)
>
> (##gc)
>
> (println "Bye.")
>
> valgrind's complaint is different in this one.  What is leaked here
> (again, unless valgrind is giving me a false positive) seems to be the
> Scheme representation of `ptr`:
>
> ==9631== Memcheck, a memory error detector
> ==9631== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
> ==9631== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
> ==9631== Command: ./test-c-define
> ==9631==
> p is #<point* #2 0x5c04620>
> release-point called
> Bye.
> ==9631==
> ==9631== HEAP SUMMARY:
> ==9631==     in use at exit: 158 bytes in 2 blocks
> ==9631==   total heap usage: 154 allocs, 152 frees, 4,247,245 bytes
> allocated
> ==9631==
> ==9631== 158 (87 direct, 71 indirect) bytes in 1 blocks are definitely
> lost in loss record 2 of 2
> ==9631==    at 0x4C2B6CD: malloc (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==9631==    by 0x4C7DC6: ___alloc_mem (os_base.c:185)
> ==9631==    by 0x4B6905: alloc_mem_aligned (mem.c:452)
> ==9631==    by 0x4B77A7: alloc_scmobj_still (mem.c:1245)
> ==9631==    by 0x4B78B1: ___alloc_scmobj (mem.c:1285)
> ==9631==    by 0x4C3DEE: ___POINTER_to_SCMOBJ (c_intf.c:5154)
> ==9631==    by 0x4B1C88: scm_release_point (test-c-define.c:665)
> ==9631==    by 0x4C1027: ___release_foreign (c_intf.c:1713)
> ==9631==    by 0x4BAEA4: free_unmarked_still_objs (mem.c:3271)
> ==9631==    by 0x4BD472: ___garbage_collect (mem.c:4698)
> ==9631==    by 0x4E4357: ___H__20___kernel (_kernel.c:9170)
> ==9631==    by 0x4B49B2: trampoline (setup.c:1618)
> ==9631==
> ==9631== LEAK SUMMARY:
> ==9631==    definitely lost: 87 bytes in 1 blocks
> ==9631==    indirectly lost: 71 bytes in 1 blocks
> ==9631==      possibly lost: 0 bytes in 0 blocks
> ==9631==    still reachable: 0 bytes in 0 blocks
> ==9631==         suppressed: 0 bytes in 0 blocks
> ==9631==
> ==9631== For counts of detected and suppressed errors, rerun with: -v
> ==9631== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
>
>
>
> On Thu, Dec 26, 2013 at 11:23 PM, Estevo <euccastro at gmail.com> wrote:
>
>> Valgrind reports Gambit is leaking a "sfun stack marker" if I call, from
>> a foreign release function, another function defined with `c-define`.  The
>> code below is about the most innocent looking thing I could come up with.
>>
>> Doesn't Gambit like c-define functions called within release functions,
>> or is Valgrind giving me a false positive here (as it is wont to do quite
>> often.)
>>
>> ; ~/gambit-dbg/bin/gsc -exe -cc-options -g test-c-define.scm && valgrind
>> --leak-check=full ./test-c-define
>>
>> (c-declare #<<c-declare-end
>>
>> typedef struct { int x; int y; } point;
>>
>> void scm_release_point(unsigned long);
>>
>> ___SCMOBJ c_release_point(void *ptr) {
>>     scm_release_point((unsigned long)ptr);
>>     ___EXT(___release_rc)(ptr);
>>     return ___FIX(___NO_ERR);
>> }
>>
>> c-declare-end
>> )
>>
>> (c-define (release-point ptr) (unsigned-long) void "scm_release_point" ""
>>   (println "release-point called"))
>>
>> (c-define-type point (pointer "point" (point*) "c_release_point"))
>>
>> (define p ((c-lambda () point
>>                  "___result_voidstar =
>> ___EXT(___alloc_rc)(sizeof(point));")))
>>
>> (println "p is " p)
>> (set! p #f)
>>
>> (##gc)
>> ; for good measure...
>> (##gc)
>> (##gc)
>>
>> (println "Bye.")
>>
>>
>> valgrind --leak-check=full ./test-c-define
>> ==16301== Memcheck, a memory error detector
>> ==16301== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
>> ==16301== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright
>> info
>> ==16301== Command: ./test-c-define
>> ==16301==
>> p is #<point* #2 0x5c04640>
>> release-point called
>> Bye.
>> ==16301==
>> ==16301== HEAP SUMMARY:
>> ==16301==     in use at exit: 71 bytes in 1 blocks
>> ==16301==   total heap usage: 153 allocs, 152 frees, 4,247,198 bytes
>> allocated
>> ==16301==
>> ==16301== 71 bytes in 1 blocks are definitely lost in loss record 1 of 1
>> ==16301==    at 0x4C2B6CD: malloc (in
>> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>> ==16301==    by 0x4C922E: ___alloc_mem (os_base.c:185)
>> ==16301==    by 0x4B7DB5: alloc_mem_aligned (mem.c:452)
>> ==16301==    by 0x4B8C57: alloc_scmobj_still (mem.c:1245)
>> ==16301==    by 0x4B8D61: ___alloc_scmobj (mem.c:1285)
>> ==16301==    by 0x4B8E44: ___make_vector (mem.c:1362)
>> ==16301==    by 0x4C677B: ___make_sfun_stack_marker (c_intf.c:6452)
>> ==16301==    by 0x4B359E: scm_release_point (test-c-define.c:139)
>> ==16301==    by 0x4B354B: c_release_point (test-c-define.c:130)
>> ==16301==    by 0x4C24D7: ___release_foreign (c_intf.c:1713)
>> ==16301==    by 0x4BC354: free_unmarked_still_objs (mem.c:3271)
>> ==16301==    by 0x4BE922: ___garbage_collect (mem.c:4698)
>> ==16301==
>> ==16301== LEAK SUMMARY:
>> ==16301==    definitely lost: 71 bytes in 1 blocks
>> ==16301==    indirectly lost: 0 bytes in 0 blocks
>> ==16301==      possibly lost: 0 bytes in 0 blocks
>> ==16301==    still reachable: 0 bytes in 0 blocks
>> ==16301==         suppressed: 0 bytes in 0 blocks
>> ==16301==
>> ==16301== For counts of detected and suppressed errors, rerun with: -v
>> ==16301== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
>>
>
>
> _______________________________________________
> Gambit-list mailing list
> Gambit-list at iro.umontreal.ca
> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20131230/dd41a523/attachment.htm>


More information about the Gambit-list mailing list