Hi,


It's been a few months since I work on "DQuick" at a rate of a few minutes or hours from time to time. After working professionally with Java during a year I was really surprise to see D capable to compete a such language on productivity and providing much more features than C++.

But because D and his compiler aren't as mature as c++ compilers, it can be really hard to debug our code, mainly when searching memory issues, because generated code by DMD isn't compatible with existing tools (Valgrind, DrMemory).

I generally use those tools when it's hard to put markers manually in code or when I don't have a call stack on a crash.

I search the cause of a crash that I have under Windows, but I don't have nothing more than this message box :

Unhandled exception at 0x0075fe53 in Image.exe: 0xC0000005: Access violation reading location 0x00000000.

I don't have the stack.


So, it's certainly one of the worst points dmd isn't compatible with C++ debugging tools.

On Thu, Dec 19, 2013 at 10:35:05PM +0100, Xavier Bigand wrote:
> Hi,
> 
> It's been a few months since I work on "DQuick" at a rate of a few minutes or hours from time to time. After working professionally with Java during a year I was really surprise to see D capable to compete a such language on productivity and providing much more features than C++.
> 
> But because D and his compiler aren't as mature as c++ compilers, it can be really hard to debug our code, mainly when searching memory issues, because generated code by DMD isn't compatible with existing tools (Valgrind, DrMemory).
[...]

What about gdc?


T

-- 
All problems are easy in retrospect.

Le 19/12/2013 22:43, H. S. Teoh a écrit :
> On Thu, Dec 19, 2013 at 10:35:05PM +0100, Xavier Bigand wrote:
>> Hi,
>>
>> It's been a few months since I work on "DQuick" at a rate of a few
>> minutes or hours from time to time. After working professionally
>> with Java during a year I was really surprise to see D capable to
>> compete a such language on productivity and providing much more
>> features than C++.
>>
>> But because D and his compiler aren't as mature as c++ compilers, it
>> can be really hard to debug our code, mainly when searching memory
>> issues, because generated code by DMD isn't compatible with existing
>> tools (Valgrind, DrMemory).
> [...]
>
> What about gdc?
>
>
> T
>
I also tried with gdc, and DrMemory and Valgrind doesn't works better with binaries generated with gdc. (I tried under Windows and Linux).

Le 19/12/2013 23:02, Xavier Bigand a écrit :
> Le 19/12/2013 22:43, H. S. Teoh a écrit :
>> On Thu, Dec 19, 2013 at 10:35:05PM +0100, Xavier Bigand wrote:
>>> Hi,
>>>
>>> It's been a few months since I work on "DQuick" at a rate of a few
>>> minutes or hours from time to time. After working professionally
>>> with Java during a year I was really surprise to see D capable to
>>> compete a such language on productivity and providing much more
>>> features than C++.
>>>
>>> But because D and his compiler aren't as mature as c++ compilers, it
>>> can be really hard to debug our code, mainly when searching memory
>>> issues, because generated code by DMD isn't compatible with existing
>>> tools (Valgrind, DrMemory).
>> [...]
>>
>> What about gdc?
>>
>>
>> T
>>
> I also tried with gdc, and DrMemory and Valgrind doesn't works better
> with binaries generated with gdc. (I tried under Windows and Linux).


Here is both trace of DrMemory, first for dmd, second GDC :

E:\Dev\Personal\DQuick\data>drMemory E:\Dev\Personal\DQuick\data\image.exe
~~Dr.M~~ Dr. Memory version 1.6.0
~~Dr.M~~ Running "E:\Dev\Personal\DQuick\data\image.exe"
~~Dr.M~~
~~Dr.M~~ Error #1: LEAK 3214 direct bytes 0x02460368-0x02460ff6 + 0 indirect bytes
~~Dr.M~~ # 0 replace_RtlAllocateHeap [d:\drmemory_package\common\alloc_replace.c:3048]
~~Dr.M~~ # 1 KERNELBASE.dll!GetEnvironmentStringsA+0x8b     (0x771c084e <KERNELBASE.dll+0x1084e>)
~~Dr.M~~ # 2 _cinit                               +0xe      (0x0052287f <image.exe+0x12287f>)
~~Dr.M~~ # 3 KERNEL32.dll!BaseThreadInitThunk     +0x11     (0x7648336a <KERNEL32.dll+0x1336a>)
~~Dr.M~~
~~Dr.M~~ Error #2: LEAK 8 direct bytes 0x03120220-0x03120228 + 264 indirect bytes
~~Dr.M~~ # 0 replace_malloc [d:\drmemory_package\common\alloc_replace.c:2292]
~~Dr.M~~ # 1 _setargv                         +0x40     (0x00524141 <image.exe+0x124141>)
~~Dr.M~~ # 2 KERNEL32.dll!BaseThreadInitThunk +0x11     (0x7648336a <KERNEL32.dll+0x1336a>)
~~Dr.M~~
~~Dr.M~~ ERRORS FOUND:
~~Dr.M~~       0 unique,     0 total unaddressable access(es)
~~Dr.M~~       0 unique,     0 total uninitialized access(es)
~~Dr.M~~       0 unique,     0 total invalid heap argument(s)
~~Dr.M~~       0 unique,     0 total GDI usage error(s)
~~Dr.M~~       0 unique,     0 total warning(s)
~~Dr.M~~       2 unique,     2 total,   3486 byte(s) of leak(s)
~~Dr.M~~       0 unique,     0 total,      0 byte(s) of possible leak(s)
~~Dr.M~~ ERRORS IGNORED:
~~Dr.M~~       7 unique,   109 total,   9916 byte(s) of still-reachable allocation(s)
~~Dr.M~~          (re-run with "-show_reachable" for details)
~~Dr.M~~ Details: D:\Softs\Dr. Memory\drmemory\logs\DrMemory-image.exe.8476.000\results.txt
~~Dr.M~~ WARNING: application exited with abnormal code 0x1

E:\Dev\Personal\DQuick\data>drMemory E:\Dev\Personal\DQuick\data\image.exe
~~Dr.M~~ Dr. Memory version 1.6.0
~~Dr.M~~ Running "E:\Dev\Personal\DQuick\data\image.exe"
~~Dr.M~~
~~Dr.M~~ Error #1: UNADDRESSABLE ACCESS: reading 0x0255114e-0x02551150 2 byte(s) within 0x0255114c-0x02551150
~~Dr.M~~ # 0 strlen
~~Dr.M~~ # 1 __build_environ
~~Dr.M~~ # 2 _setenvp
~~Dr.M~~ # 3 _cinit
~~Dr.M~~ # 4 mainCRTStartup
~~Dr.M~~ # 5 KERNEL32.dll!BaseThreadInitThunk +0x11     (0x7648336a <KERNEL32.dll+0x1336a>)
~~Dr.M~~ Note: @0:00:00.391 in thread 8940
~~Dr.M~~ Note: refers to 0 byte(s) beyond last valid byte in prior malloc
~~Dr.M~~ Note: prev lower malloc:  0x025504c0-0x0255114e
~~Dr.M~~ Note: instruction: mov    (%ecx) -> %eax
~~Dr.M~~
~~Dr.M~~ Error #2: LEAK 8 direct bytes 0x02550498-0x025504a0 + 266 indirect bytes
~~Dr.M~~ # 0 replace_RtlAllocateHeap [d:\drmemory_package\common\alloc_replace.c:3048]
~~Dr.M~~ # 1 malloc
~~Dr.M~~ # 2 KERNEL32.dll!BaseThreadInitThunk     +0x11     (0x7648336a <KERNEL32.dll+0x1336a>)
~~Dr.M~~
~~Dr.M~~ Error #3: LEAK 3214 direct bytes 0x025504c0-0x0255114e + 0 indirect bytes
~~Dr.M~~ # 0 replace_RtlAllocateHeap [d:\drmemory_package\common\alloc_replace.c:3048]
~~Dr.M~~ # 1 KERNELBASE.dll!GetEnvironmentStringsA+0x8b     (0x771c084e <KERNELBASE.dll+0x1084e>)
~~Dr.M~~ # 2 _cinit
~~Dr.M~~ # 3 KERNEL32.dll!BaseThreadInitThunk     +0x11     (0x7648336a <KERNEL32.dll+0x1336a>)
~~Dr.M~~
~~Dr.M~~ ERRORS FOUND:
~~Dr.M~~       1 unique,     1 total unaddressable access(es)
~~Dr.M~~       0 unique,     0 total uninitialized access(es)
~~Dr.M~~       0 unique,     0 total invalid heap argument(s)
~~Dr.M~~       0 unique,     0 total GDI usage error(s)
~~Dr.M~~       0 unique,     0 total warning(s)
~~Dr.M~~       2 unique,     2 total,   3488 byte(s) of leak(s)
~~Dr.M~~       0 unique,     0 total,      0 byte(s) of possible leak(s)
~~Dr.M~~ ERRORS IGNORED:
~~Dr.M~~       5 unique,   109 total,  10128 byte(s) of still-reachable allocation(s)
~~Dr.M~~          (re-run with "-show_reachable" for details)
~~Dr.M~~ Details: D:\Softs\Dr. Memory\drmemory\logs\DrMemory-image.exe.4024.000\results.txt
~~Dr.M~~ WARNING: application exited with abnormal code 0x1


Maybe an issue due to the gc?

20-Dec-2013 01:35, Xavier Bigand пишет:
> Hi,
>
>
> It's been a few months since I work on "DQuick" at a rate of a few
> minutes or hours from time to time. After working professionally with
> Java during a year I was really surprise to see D capable to compete a
> such language on productivity and providing much more features than C++.
>
> But because D and his compiler aren't as mature as c++ compilers, it can
> be really hard to debug our code, mainly when searching memory issues,
> because generated code by DMD isn't compatible with existing tools
> (Valgrind, DrMemory).

At least valgrind works just fine for me. If compiled with debug symbols callgrind works quite well, and so do the other tools e.g. massif.

-- 
Dmitry Olshansky

On Thursday, 19 December 2013 at 22:07:52 UTC, Dmitry Olshansky wrote:
> 20-Dec-2013 01:35, Xavier Bigand пишет:
>> Hi,
>>
>>
>> It's been a few months since I work on "DQuick" at a rate of a few
>> minutes or hours from time to time. After working professionally with
>> Java during a year I was really surprise to see D capable to compete a
>> such language on productivity and providing much more features than C++.
>>
>> But because D and his compiler aren't as mature as c++ compilers, it can
>> be really hard to debug our code, mainly when searching memory issues,
>> because generated code by DMD isn't compatible with existing tools
>> (Valgrind, DrMemory).
>
> At least valgrind works just fine for me. If compiled with debug symbols callgrind works quite well, and so do the other tools e.g. massif.

If I compile with -gc I have very little problem debugging my D code.

I regularly use valgrind and except for the occasional issue with valgrind's crappy floating point support it works fine.

For general debugging I find GDB handles D more than well enough. There are some minor issues, but nothing yet that is a show stopper. Because GDB on the terminal is ugly I find Nemiver or QtCreator work fine as front-ends, the latter requiring some initial config.

Very rarely GDB will get it so wrong that it won't be able to show the value of a variable automatically. When that happens I still have the address, type and size of the variable. From that it is then trivial to set up a watch expression.

Occasionally when stepping source code GDB will appear step backwards. I get this with C++ as well and it has never been an issue for me.

Le 20/12/2013 00:47, ed a écrit :
> On Thursday, 19 December 2013 at 22:07:52 UTC, Dmitry Olshansky wrote:
>> 20-Dec-2013 01:35, Xavier Bigand пишет:
>>> Hi,
>>>
>>>
>>> It's been a few months since I work on "DQuick" at a rate of a few
>>> minutes or hours from time to time. After working professionally with
>>> Java during a year I was really surprise to see D capable to compete a
>>> such language on productivity and providing much more features than C++.
>>>
>>> But because D and his compiler aren't as mature as c++ compilers, it can
>>> be really hard to debug our code, mainly when searching memory issues,
>>> because generated code by DMD isn't compatible with existing tools
>>> (Valgrind, DrMemory).
>>
>> At least valgrind works just fine for me. If compiled with debug
>> symbols callgrind works quite well, and so do the other tools e.g.
>> massif.
>
> If I compile with -gc I have very little problem debugging my D code.
>
> I regularly use valgrind and except for the occasional issue with
> valgrind's crappy floating point support it works fine.
>
> For general debugging I find GDB handles D more than well enough. There
> are some minor issues, but nothing yet that is a show stopper. Because
> GDB on the terminal is ugly I find Nemiver or QtCreator work fine as
> front-ends, the latter requiring some initial config.
>
> Very rarely GDB will get it so wrong that it won't be able to show the
> value of a variable automatically. When that happens I still have the
> address, type and size of the variable. From that it is then trivial to
> set up a watch expression.
>
> Occasionally when stepping source code GDB will appear step backwards. I
> get this with C++ as well and it has never been an issue for me.

GDB issues aren't blockers like you say, but with valgrind I always have floating point issue I don't know how to work around.

Maybe having a lot of initialization step in "static this()" of modules can put some tools in difficulties?
DQuick load some dynamic libraries in that way.