www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [Feedback] Main difficulties encountered with D

reply Xavier Bigand <flamaros.xavier gmail.com> writes:
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.
Dec 19 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Dec 19 2013
parent reply Xavier Bigand <flamaros.xavier gmail.com> writes:
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).
Dec 19 2013
parent Xavier Bigand <flamaros.xavier gmail.com> writes:
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?
Dec 19 2013
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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
Dec 19 2013
parent reply "ed" <sillymongrel gmail.com> writes:
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.
Dec 19 2013
parent Xavier Bigand <flamaros.xavier gmail.com> writes:
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.
Dec 19 2013