On Thursday 31 August 2006 12:48, Caleb Tennis wrote:
> Ok, I've updated to the latest changes in the 3.5 branch of the
> qtruby/korundum and ran my program through valgrind for about 24 hours to
> accumulate where the leaks are still coming from.  Here are the two big
> offenders:
>
>
> ==15683== 15,177,794 (897,708 direct, 14,280,086 indirect) bytes in
> 224,427 blocks are definitely lost in loss record 391 of 391
> ==15683==    at 0x401F942: operator new(unsigned) (in
> /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
> ==15683==    by 0x50026D2: qstringFromRString(unsigned long)
> (handlers.cpp:836)
> ==15683==    by 0x5002A44: marshall_QString(Marshall*) (handlers.cpp:864)
> ==15683==    by 0x4FFF802: EmitSignal::next() (Qt.cpp:612)
> ==15683==    by 0x4FF9924: qt_signal (Qt.cpp:1795)
> ==15683==    by 0x4045517: call_cfunc (eval.c:5553)
> ==15683==    by 0x404E980: rb_call0 (eval.c:5692)
> ==15683==    by 0x404EDCA: rb_call (eval.c:5920)
> ==15683==    by 0x404AC36: rb_eval (eval.c:3396)
> ==15683==    by 0x404ABBE: rb_eval (eval.c:3391)
> ==15683==    by 0x404B1DA: rb_eval (eval.c:3033)
> ==15683==    by 0x404E996: rb_call0 (eval.c:5826)
>
>
> ==15683== 6,282,113 bytes in 224,400 blocks are definitely lost in loss
> record 389 of 391
> ==15683==    at 0x401F506: malloc (in
> /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
> ==15683==    by 0x5000211: marshall_charP(Marshall*) (handlers.cpp:760)
> ==15683==    by 0x4FFFA62: MethodCall::next() (Qt.cpp:462)
> ==15683==    by 0x4FFA9F5: method_missing (Qt.cpp:1506)
> ==15683==    by 0x4045517: call_cfunc (eval.c:5553)
> ==15683==    by 0x404E980: rb_call0 (eval.c:5692)
> ==15683==    by 0x404EDCA: rb_call (eval.c:5920)
> ==15683==    by 0x405091D: method_missing (eval.c:5533)
> ==15683==    by 0x404EEBA: rb_call (eval.c:5916)
> ==15683==    by 0x404AB1A: rb_eval (eval.c:3381)
> ==15683==    by 0x404E996: rb_call0 (eval.c:5826)
> ==15683==    by 0x404EDCA: rb_call (eval.c:5920)
>
>
> I can definitely see HOW the memory is being leaked, but it's not entirely
> clear where the responsibility lies for cleaning up the heap objects after
> they are created.  I may just stab at it for a while unless you have any
> thoughts, Richard?
I think the QtRuby code for QStrings is probably wrong, but for 'char *'s I'm 
not sure as there are no rules for who 'owns' the string after the call has 
completed. Perhaps we can usually assume QtRuby should delete the 'char *', 
but special case when it shouldn't - tricky..

-- Richard
_______________________________________________
Kde-bindings mailing list
Kde-bindings@kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings