Is RABCDAsm supposed to leak?

[ghost]

I tried to use the disassembler class in a D project. After disassembling a few files in one run, I noticed it allocates but never frees, causing my program to throw out of memory after some time. Is this supposed to happen?

[CyberShadow]

D is a garbage collected language, so manual memory management is unnecessary. It's possible that RABCDAsm keeps references to more objects than necessary, or that false pointers prevent any memory from being collected due to the conservative GC. If you can, try building a 64-bit version, and see if that improves memory usage.

[ghost]

Thanks for the quick reply! Why do you think 64-bit would correct the GC's behaviour? I'll try to build it 64-bit anyways, but it's going to take a while until I figured out how to build vibe.d 64-bit... Also note that in my program currently all objects that I use from RABCDAsm are already out of scope again, but it still doesnt collect. I even tried the "delete" keyword (although I know its outdated) and I tried calling GC.free on the objects (which I don't even know if thats correct). Nothing worked so far.

[CyberShadow]

Why do you think 64-bit would correct the GC's behaviour?

Because under 64-bit, there is a much lower chance of false pointers.

Why does your project need vibe.d? Is it a disassembler-as-a-web-service?

[ghost]

Ah ok, I hoped there wouldn't be any chance of false pointers in any bittness ;) Kind of, yes. Somewhat of a UI for the disassembly.

[ghost]

Ok, so I got vibe to compile now in 64-bit now. I made the following observations, but I didn't have time to further investigate the cause. In 32-bit everything works fine, In 64-bit though, it throws an exception:

Error disassembling e725b3aad2032cd7a283cd051e447036: std.conv.ConvException@C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(1794): Unexpected '#' when converting from type string to type doubl
e
----------------
0x000000013F434449 in std.conv.toImpl!(double, string).toImpl at C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(1798)
0x0000000017CBDD00
0x00000000002EDC60
0x00000000002EDC50
0x00000000002EDDC0
0x000000013F4343AA in std.conv.toImpl!(double, string).toImpl at C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(1797)
0x000000013F431A5C in std.conv.to!double.to!(string).to at C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(281)
0x000000013F539B2C in disassembler.Disassembler.dumpDouble at C:\test_flash\project\source\disassembler.d(1103)
0x000000013F53BC5D in disassembler.Disassembler.dumpValue at C:\test_flash\project\source\disassembler.d(1369)
0x000000013F53AF30 in disassembler.Disassembler.dumpTraits at C:\test_flash\project\source\disassembler.d(1261)
0x000000013F53CAAB in disassembler.Disassembler.dumpInstance at C:\test_flash\project\source\disassembler.d(1487)
0x000000013F53C6CD in disassembler.Disassembler.dumpClass at C:\test_flash\project\source\disassembler.d(1456)
0x000000013F53B6A4 in disassembler.Disassembler.dumpTraits.__lambda4 at C:\test_flash\project\source\disassembler.d(1274)
0x000000013F5387FD in disassembler.Disassembler.newInclude at C:\test_flash\project\source\disassembler.d(991)
0x000000013F53B04E in disassembler.Disassembler.dumpTraits at C:\test_flash\project\source\disassembler.d(1273)
0x000000013F53CCE7 in disassembler.Disassembler.dumpScript at C:\test_flash\project\source\disassembler.d(1497)
0x000000013F5393D7 in disassembler.Disassembler.disassemble.__lambda1 at C:\test_flash\project\source\disassembler.d(1034)
0x000000013F5387FD in disassembler.Disassembler.newInclude at C:\test_flash\project\source\disassembler.d(991)
0x000000013F538E24 in disassembler.Disassembler.disassemble at C:\test_flash\project\source\disassembler.d(1033)
0x000000013F4EF39C in main.DisassembleABC at C:\test_flash\project\source\app.d(46)
0x000000013F4EFC84 in main.ProcessFile at C:\test_flash\project\source\app.d(74)
0x000000013F4F02A6 in main._staticCtor4 at C:\test_flash\project\source\app.d(100)
0x000000013F4F046D in void main.__modctor()
0x000000013F72B2BC in void rt.minfo.ModuleGroup.runTlsCtors().pure void __T14runModuleFuncsS492rt5minfo11ModuleGroup11runTlsCtorsMFZv9__lambda1Z.runModuleFuncs(object.ModuleInfo*[])
0x000000013F719A75 in void rt.minfo.ModuleGroup.runTlsCtors()
0x000000013F709F70 in int rt.minfo.rt_moduleTlsCtor().__foreachbody1(ref rt.sections_win64.SectionGroup)
0x000000013F709F3D in rt_moduleTlsCtor
0x000000013F6F4F4E in rt_init
0x000000013F6E7D7A in void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runMainWithInit()
0x000000013F6E6EDE in void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate())
0x000000013F6E6E41 in d_run_main
0x000000013F567B92 in __entrypoint.main
0x000000013F73915C in __tmainCRTStartup at f:\dd\vctools\crt_bld\self_64_amd64\crt\src\crt0.c(241)
0x000000007749652D in BaseThreadInitThunk
0x00000000775CC541 in RtlUserThreadStart

I'll look into it as soon as I get some more time. I couldn't yet really make any judgements on GC behaviour

[CyberShadow]

Any luck?

From that stack trace it looks like the 64-bit C++ runtime is doing something strange with double conversions.

[ghost]

Sorry for not updating this for so long. I just resumed this project yesterday and I'm now running on linux (majaro), where both dmd and gdc produce perfectly working 64-bit executables without any leaks. I won't be digging into the windows problem for now, thanks a lot for your support though!

[CyberShadow]

Good to know, thanks for the update.