Feature #4967: dmalloc reported memory leaks in ruby

• Status: Rejected
• Assignee: mame (Yusuke Endoh)
• Target version: 2.0.0

[jojelino (jojelino _)]

hi i've modified dmalloc,pthreads-win32 to make it work win32. and dmalloc_t passed so far.
and then, ruby is chosen to check memory leaks.
for dmalloc to work with ruby, some part of ruby has been patched.
after successful build of ruby trunk, i ran 'make test'.
here's dmalloc reported.

[jojelino (jojelino _)]

• File log_make_test_ext_32373.zip log_make_test_ext_32373.zip added

also i ran './ruby.exe -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- "./test/runner.rb"' here is the result.
log files with some glitch(size>1000KB) have been pruned.

[jojelino (jojelino _)]

and cumulative result from preceeding log
total-byte count src line
746668032 45573 gc.c 1033
388703018 2920209 string.c 395
277872640 530 vm.c 1634
171948600 7164525 st.c 532
106382904 4432621 st.c 463
88318756 1734835 st.c 191
74383361 324663 string.c 1841
70691360 3534568 vm_method.c 215
69311540 3465577 vm_method.c 268
42305640 1762735 st.c 186
40509916 104407 re.c 772
38034329 326863 string.c 1798
21876792 911533 st.c 503
21842049 168884 string.c 744
14215060 43953 regcomp.c 296
10182396 450451 array.c 323
9653688 141966 encoding.c 220
9492208 215732 regparse.c 1130
8949288 745774 class.c 52
8184376 1023047 variable.c 1918
6743444 19285 array.c 163
5911556 77767 array.c 156
4377564 13389 regcomp.c 208
4332000 270750 transcode.c 175
4143752 395949 parse.y 9076
3957496 27900 st.c 543
3850384 10463 vm.c 1818
3228880 12155 compile.c 543
3228880 12155 compile.c 1337
1974210 12155 compile.c 1338
1798940 12155 iseq.c 174
1791552 1466 encoding.c 198
1781024 63608 variable.c 370
1415101 143487 util.c 606
931874 12155 compile.c 1339
917504 97 io.c 1217
911460 45573 gc.c 1038
814128 1432 gc.c 1010
759936 4326 regcomp.c 255
732932 1889 regcomp.c 5604
674768 3077 regcomp.c 228
550274 34266 regcomp.c 151
508872 63609 variable.c 369
472956 7284 regcomp.c 289
445764 10131 thread.c 3353
442783 69337 regcomp.c 57
328200 8205 regexec.c 180
328200 8205 regexec.c 184
315000 6385 compile.c 1582
273816 34227 vm_method.c 92
262560 8205 re.c 835
165804 1431 array.c 1351
116033 1816 string.c 1303
91200 1425 regcomp.c 671
57600 1440 proc.c 83
55172 8472 compile.c 1228
49284 1369 vm.c 294
45856 1433 regcomp.c 662
35344 4418 gc.c 971
35008 1369 vm.c 384
27808 829 variable.c 1088
23504 1468 bignum.c 149
23456 1466 marshal.c 122
23456 2932 variable.c 788
21840 84 thread.c 2430
21204 171 io.c 6366
18032 98 parse.y 10131
9568 26 vm.c 2157
8008 26 vm.c 2156
6332 323 variable.c 1082
5760 96 parse.y 5449
5712 34 gc.c 1014
5667 93 string.c 3634
4328 481 compile.c 1136
4092 33 io.c 4757
3072 48 time.c 1864
1728 432 compile.c 1009
1100 25 io.c 6711
664 83 parse.y 2856
660 15 st.c 572
650 75 cfunc.c 159
512 16 parse.y 131
448 16 marshal.c 1777
360 2 parse.y 5476
360 15 st.c 565
300 25 proc.c 282
200 25 thread.c 3116
200 2 token.re 525
192 1 regcomp.c 246
128 8 parse.y 128
96 4 regparse.c 742
93 2 handler.c 159
64 4 time.c 1033
48 3 cfunc.c 84
48 4 handle.c 89
48 2 node.c 20
36 4 regparse.c 247
32 2 bignum.c 173
32 4 regparse.c 387
32 2 variable.c 584
24 2 cptr.c 65
24 2 node.c 90
15 3 string.c 1385
2 2 object.c 222

---

Bug #4967: dmalloc reported memory leaks in ruby

What about valgrind?

[kosaki (Motohiro KOSAKI)]

• Priority changed from Normal to 3

[naruse (Yui NARUSE)]

• Tracker changed from Bug to Feature

[naruse (Yui NARUSE)]

• Target version changed from 1.9.3 to 2.0.0

Interesting, but briefly I inspect the list includes many false positive.
You may think they are leaked, but they are correctly GCed.

Anyway we sometimes uses valgrind.

[mame (Yusuke Endoh)]

• Status changed from Open to Assigned
• Assignee set to mame (Yusuke Endoh)

[mame (Yusuke Endoh)]

• Status changed from Assigned to Rejected

Hello,

Thank you for introducing an analysis tool and providing the
result. But, please send such information as a mail, not open
a ticket. A ticket should be for each concrete problem.

I guess valgrind (with option --show-reachable=yes) will
provide similar analysis.

--
Yusuke Endoh [e-mail]