digitalmars.D - [Feedback] Main difficulties encountered with D
- Xavier Bigand (18/18) Dec 19 2013 Hi,
- H. S. Teoh (6/18) Dec 19 2013 [...]
- Xavier Bigand (3/19) Dec 19 2013 I also tried with gdc, and DrMemory and Valgrind doesn't works better
- Xavier Bigand (93/116) Dec 19 2013 Here is both trace of DrMemory, first for dmd, second GDC :
- Dmitry Olshansky (5/14) Dec 19 2013 At least valgrind works just fine for me. If compiled with debug symbols...
- ed (18/41) Dec 19 2013 If I compile with -gc I have very little problem debugging my D
- Xavier Bigand (6/37) Dec 19 2013 GDB issues aren't blockers like you say, but with valgrind I always have...
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
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
Le 19/12/2013 22:43, H. S. Teoh a écrit :On Thu, Dec 19, 2013 at 10:35:05PM +0100, Xavier Bigand wrote:I also tried with gdc, and DrMemory and Valgrind doesn't works better with binaries generated with gdc. (I tried under Windows and Linux).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
Dec 19 2013
Xavier Bigand <flamaros.xavier gmail.com> Le 19/12/2013 23:02, Xavier Bigand a écrit :Le 19/12/2013 22:43, H. S. Teoh a écrit :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~~ indirect bytes [d:\drmemory_package\common\alloc_replace.c:3048] <KERNELBASE.dll+0x1084e>) <image.exe+0x12287f>) <KERNEL32.dll+0x1336a>) ~~Dr.M~~ indirect bytes [d:\drmemory_package\common\alloc_replace.c:2292] <image.exe+0x124141>) <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~~ byte(s) within 0x0255114c-0x02551150 <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~~ indirect bytes [d:\drmemory_package\common\alloc_replace.c:3048] <KERNEL32.dll+0x1336a>) ~~Dr.M~~ indirect bytes [d:\drmemory_package\common\alloc_replace.c:3048] <KERNELBASE.dll+0x1084e>) <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?On Thu, Dec 19, 2013 at 10:35:05PM +0100, Xavier Bigand wrote:I also tried with gdc, and DrMemory and Valgrind doesn't works better with binaries generated with gdc. (I tried under Windows and Linux).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
Dec 19 2013
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
On Thursday, 19 December 2013 at 22:07:52 UTC, Dmitry Olshansky wrote:20-Dec-2013 01:35, Xavier Bigand пишет: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.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.
Dec 19 2013
Le 20/12/2013 00:47, ed a écrit :On Thursday, 19 December 2013 at 22:07:52 UTC, Dmitry Olshansky wrote: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.20-Dec-2013 01:35, Xavier Bigand пишет: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.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.
Dec 19 2013