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?

Caleb

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