[Fluxus] string leak!

[David Griffiths]

Hi Gabor,

Good find!

Same happens here - It looks like a racket bug. I tried freeing and
deleting it, resulting in crashes, checked the docs for 
scheme_utf8_encode_to_buffer and it claims it allocates with
scheme_malloc_atomic which should use the gc.

The next thing would be to write a small c program to replacate this and
post it to the racket list. 

cheers,

dave

On Fri, 2011-01-14 at 12:08 +0100, gabor papp wrote:
> while checking out the path/string issue that kassen brought up i found 
> our string handling a bit strange. the memory usage of the following 
> script increases about 30 megabytes in 2 minutes on my computer. i 
> generate a long string which i use in (load-texture) to force the scheme 
> string to c conversion.
> 
> (clear)
> 
> (define (rnd-str n)
>    (build-string n (lambda (x) (integer->char (+ 97 (random 26))))))
> 
> (every-frame
>      (begin
>          (load-texture (rnd-str 16384))
>          (collect-garbage)))
> 
> StringFromScheme looks like this:
> 
> string SchemeHelper::StringFromScheme(Scheme_Object *ob)
> {
>      char *ret = NULL;
>      MZ_GC_DECL_REG(2);
>      MZ_GC_VAR_IN_REG(0, ob);
>      MZ_GC_VAR_IN_REG(1, ret);
>      MZ_GC_REG();
>      ret = scheme_utf8_encode_to_buffer(SCHEME_CHAR_STR_VAL(ob), 
> SCHEME_CHAR_STRLEN_VAL(ob), NULL, 0);
>      MZ_GC_UNREG();
>      return string(ret);
> }
> 
> first i thought it was strange to register a char* buffer with the 
> garbage collector, but after reading the docs it may seem fine. what do 
> you think? can you reproduce the leaking? or am i overlooking something?
> 
> this would also explain the (pdata-map) leak, since it uses strings to 
> pass the pdata type in pdata-set!.
> 
> best,
> gabor