www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Any guides on debugging DMD crash?

reply Matt Jones <matthew.brennan.jones gmail.com> writes:
Does anyone have a guide on how to debug DMD crashes? I've been 
getting compiler crashes on version 2.087.1 through 2.091.0 (only 
release mode on both Windows 10 and Linux). Version 2.086.1 was 
the last one that worked:

dub run --arch=x86_64 --build=release

C:\D\dmd2\windows\bin\dmd.exe failed with exit code -1073741795.

Here is the smallest code snippet I could make crash: 
https://github.com/workhorsy/crash_dmd
Mar 22
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Sunday, 22 March 2020 at 22:33:13 UTC, Matt Jones wrote:
 Does anyone have a guide on how to debug DMD crashes? I've been 
 getting compiler crashes on version 2.087.1 through 2.091.0 
 (only release mode on both Windows 10 and Linux). Version 
 2.086.1 was the last one that worked:

 dub run --arch=x86_64 --build=release

 C:\D\dmd2\windows\bin\dmd.exe failed with exit code -1073741795.

 Here is the smallest code snippet I could make crash: 
 https://github.com/workhorsy/crash_dmd
Ah very interesting! Unfortunately I am not good at writing guides, but I will debug this and record a video, of what I do. Would that be acceptable to you? - Stefan
Mar 22
parent Matt Jones <matthew.brennan.jones gmail.com> writes:
On Sunday, 22 March 2020 at 22:37:08 UTC, Stefan Koch wrote:
 On Sunday, 22 March 2020 at 22:33:13 UTC, Matt Jones wrote:
 Does anyone have a guide on how to debug DMD crashes? I've 
 been getting compiler crashes on version 2.087.1 through 
 2.091.0 (only release mode on both Windows 10 and Linux). 
 Version 2.086.1 was the last one that worked:

 dub run --arch=x86_64 --build=release

 C:\D\dmd2\windows\bin\dmd.exe failed with exit code 
 -1073741795.

 Here is the smallest code snippet I could make crash: 
 https://github.com/workhorsy/crash_dmd
Ah very interesting! Unfortunately I am not good at writing guides, but I will debug this and record a video, of what I do. Would that be acceptable to you? - Stefan
I hope so. Thanks!
Mar 22
prev sibling next sibling parent reply Arine <arine123445128843 gmail.com> writes:
On Sunday, 22 March 2020 at 22:33:13 UTC, Matt Jones wrote:
 Does anyone have a guide on how to debug DMD crashes? I've been 
 getting compiler crashes on version 2.087.1 through 2.091.0 
 (only release mode on both Windows 10 and Linux). Version 
 2.086.1 was the last one that worked:

 dub run --arch=x86_64 --build=release

 C:\D\dmd2\windows\bin\dmd.exe failed with exit code -1073741795.

 Here is the smallest code snippet I could make crash: 
 https://github.com/workhorsy/crash_dmd
Since it crashes when you do a release build, this is most likely a bug in the backend. DMD's backend is known to have a lot of issues and they don't tend to be fixed as there's only a few people that actually work on it. Even if someone outside of the main D team fixes the bug, the fix won't get merged in for release as those same individuals don't bother to review those pull requests. You'll probably have better luck using LDC2, which has a tried and proven backend LLVM. It doesn't compile as fast, but I find the few seconds is worth the trade off of not having to deal with as many compiler bugs like the one you've found here. https://github.com/ldc-developers/ldc#installation
Mar 22
next sibling parent reply DanielG <simpletangent gmail.com> writes:
On Monday, 23 March 2020 at 00:17:48 UTC, Arine wrote:
 You'll probably have better luck using LDC2, which has a tried 
 and proven backend LLVM. It doesn't compile as fast, but I find 
 the few seconds is worth the trade off of not having to deal 
 with as many compiler bugs like the one you've found here.
How common is this sentiment among D developers? I've been patiently waiting for a dustmite reduction over the last few days, trying to be a good citizen and produce a bug report for something that has been preventing me from using DMD for months now. Actually it's my 2nd DMD-blocking bug, but the previous one was only stopping Mac/Linux, now I'm limited to LDC2 on all 3 platforms. I would love for my code to be compatible with all D compilers, and have the speed benefit of prototyping with DMD for myself, but I'm not too keen on becoming a compiler spelunker given all the other claims on my time. (For what it's worth I'm not doing anything fancy or esoteric - just bad luck, I guess) So I'm curious if other devs doggedly pursue DMD bugs until they are fixed, or if they just throw their hands up and use LDC2. My deeper fear is that someday I'm going to hit a frontend bug and won't have the skills or capital to get it solved :(
Mar 24
next sibling parent reply bachmeier <no spam.net> writes:
On Tuesday, 24 March 2020 at 16:11:40 UTC, DanielG wrote:
 On Monday, 23 March 2020 at 00:17:48 UTC, Arine wrote:
 You'll probably have better luck using LDC2, which has a tried 
 and proven backend LLVM. It doesn't compile as fast, but I 
 find the few seconds is worth the trade off of not having to 
 deal with as many compiler bugs like the one you've found here.
How common is this sentiment among D developers? I've been patiently waiting for a dustmite reduction over the last few days, trying to be a good citizen and produce a bug report for something that has been preventing me from using DMD for months now. Actually it's my 2nd DMD-blocking bug, but the previous one was only stopping Mac/Linux, now I'm limited to LDC2 on all 3 platforms. I would love for my code to be compatible with all D compilers, and have the speed benefit of prototyping with DMD for myself, but I'm not too keen on becoming a compiler spelunker given all the other claims on my time. (For what it's worth I'm not doing anything fancy or esoteric - just bad luck, I guess) So I'm curious if other devs doggedly pursue DMD bugs until they are fixed, or if they just throw their hands up and use LDC2. My deeper fear is that someday I'm going to hit a frontend bug and won't have the skills or capital to get it solved :(
I can only give one data point, but I started using D in 2013 and have never run into a compiler bug. My use case is primarily as a better C (using the full D language, but working with C libraries). I use mostly basic D features, none of the fancy stuff, so I'm probably not venturing into the less-tested parts of the language very often.
Mar 24
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Mar 24, 2020 at 05:33:26PM +0000, bachmeier via Digitalmars-d wrote:
[...]
 I can only give one data point, but I started using D in 2013 and have
 never run into a compiler bug. My use case is primarily as a better C
 (using the full D language, but working with C libraries). I use
 mostly basic D features, none of the fancy stuff, so I'm probably not
 venturing into the less-tested parts of the language very often.
I've been using D since around late 2011 / early 2012, and have run into a number of DMD bugs -- wrong codegens, ICEs, and problems with the optimization flags. I'd say the majority are front-end bugs, most of which have been fixed since, and a smaller number of backend bugs. It's already bad enough that the backend produces code with not-so-great performance; what makes it worse is that some of the backend bugs I've run into are triggered by optimization flags, meaning that my only recourse was to live off *unoptimized DMD output*. Recently I've switched to LDC for optimized builds, and it's been great. I still use DMD occasionally for subsystem development -- the lightning fast turnaround times is great for the code-compile-test cycle -- but overall I've been finding that LDC's superior codegen is more than worth the cost of a few added seconds to compile times. T -- People demand freedom of speech to make up for the freedom of thought which they avoid. -- Soren Aabye Kierkegaard (1813-1855)
Mar 24
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 25/03/2020 6:55 AM, H. S. Teoh wrote:
 On Tue, Mar 24, 2020 at 05:33:26PM +0000, bachmeier via Digitalmars-d wrote:
 [...]
 I can only give one data point, but I started using D in 2013 and have
 never run into a compiler bug. My use case is primarily as a better C
 (using the full D language, but working with C libraries). I use
 mostly basic D features, none of the fancy stuff, so I'm probably not
 venturing into the less-tested parts of the language very often.
I've been using D since around late 2011 / early 2012, and have run into a number of DMD bugs -- wrong codegens, ICEs, and problems with the optimization flags. I'd say the majority are front-end bugs, most of which have been fixed since, and a smaller number of backend bugs. It's already bad enough that the backend produces code with not-so-great performance; what makes it worse is that some of the backend bugs I've run into are triggered by optimization flags, meaning that my only recourse was to live off *unoptimized DMD output*. Recently I've switched to LDC for optimized builds, and it's been great. I still use DMD occasionally for subsystem development -- the lightning fast turnaround times is great for the code-compile-test cycle -- but overall I've been finding that LDC's superior codegen is more than worth the cost of a few added seconds to compile times.
Similar-ish story for me. Except I have encountered an ICE in debug info. Along with bugs in ldc that end in a very undesirable target/compiler configuration. They have since been fixed :)
Mar 24
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Mar 24, 2020 at 04:11:40PM +0000, DanielG via Digitalmars-d wrote:
 On Monday, 23 March 2020 at 00:17:48 UTC, Arine wrote:
 You'll probably have better luck using LDC2, which has a tried and
 proven backend LLVM. It doesn't compile as fast, but I find the few
 seconds is worth the trade off of not having to deal with as many
 compiler bugs like the one you've found here.
[...]
 I would love for my code to be compatible with all D compilers, and
 have the speed benefit of prototyping with DMD for myself, but I'm not
 too keen on becoming a compiler spelunker given all the other claims
 on my time. (For what it's worth I'm not doing anything fancy or
 esoteric - just bad luck, I guess)
There's ldmd2, an LDC wrapper that works more-or-less as a drop-in replacement for dmd. Unless you're using esoteric DMD command-line options, you can essentially just replace 'dmd' with 'ldmd2' and it should Just Work(tm). For GDC, there's also a similar wrapper for the same purpose.
 So I'm curious if other devs doggedly pursue DMD bugs until they are
 fixed, or if they just throw their hands up and use LDC2. My deeper
 fear is that someday I'm going to hit a frontend bug and won't have
 the skills or capital to get it solved :(
All D compilers currently share the same frontend, so you don't have to worry about that. Most DMD bugs being actively fixed are frontend bugs, and directly benefit the other 2 compilers. Only a small number of people are actively working on the DMD backend (mainly just Walter, plus one or two others occasionally), and its codegen quality, sorry to say, leaves a lot to be desired. Its only redeeming quality currently is its lightning speed. I've recently switched to LDC for all of my new D projects, and use DMD only occasionally for single-module development because of its quick turn-around time (dmd -i -unittest -main is great for fast development of a single module / cluster of related modules). While LDC does add a few seconds to the compile-time, I find the superior codegen quality to be more than worth the cost. Armed with ldmd2, you don't even have to change your build setup except to substitute 'dmd' with 'ldmd2', for the most part. I highly recommend it. T -- The richest man is not he who has the most, but he who needs the least.
Mar 24
prev sibling parent Seb <seb wilzba.ch> writes:
On Tuesday, 24 March 2020 at 16:11:40 UTC, DanielG wrote:
 On Monday, 23 March 2020 at 00:17:48 UTC, Arine wrote:
 You'll probably have better luck using LDC2, which has a tried 
 and proven backend LLVM. It doesn't compile as fast, but I 
 find the few seconds is worth the trade off of not having to 
 deal with as many compiler bugs like the one you've found here.
How common is this sentiment among D developers?
There's virtually no reason to use DMD and I don't think anyone is using it seriously anymore in production. A lot of the companies switched to LDC over the last years. A good example: the Debian/Ubuntu D maintainers didn't even bother creating a package for DMD (even though it's fully open source for more than two years now) as you want to use GDC or LDC to compile libraries or applications anyhow. The only real reason why DMD is still the "reference compiler" and "officially recommended" is that Walter is in charge and DMD is his life work.
Mar 24
prev sibling parent Matt Jones <matthew.brennan.jones gmail.com> writes:
On Monday, 23 March 2020 at 00:17:48 UTC, Arine wrote:
 On Sunday, 22 March 2020 at 22:33:13 UTC, Matt Jones wrote:
 Does anyone have a guide on how to debug DMD crashes? I've 
 been getting compiler crashes on version 2.087.1 through 
 2.091.0 (only release mode on both Windows 10 and Linux). 
 Version 2.086.1 was the last one that worked:

 dub run --arch=x86_64 --build=release

 C:\D\dmd2\windows\bin\dmd.exe failed with exit code 
 -1073741795.

 Here is the smallest code snippet I could make crash: 
 https://github.com/workhorsy/crash_dmd
Since it crashes when you do a release build, this is most likely a bug in the backend. DMD's backend is known to have a lot of issues and they don't tend to be fixed as there's only a few people that actually work on it. Even if someone outside of the main D team fixes the bug, the fix won't get merged in for release as those same individuals don't bother to review those pull requests. You'll probably have better luck using LDC2, which has a tried and proven backend LLVM. It doesn't compile as fast, but I find the few seconds is worth the trade off of not having to deal with as many compiler bugs like the one you've found here. https://github.com/ldc-developers/ldc#installation
I've been trying LDC2 every couple of years. It's been a while. I just tried building a few D apps with LDC2. I managed to get things to compile in release mode. I noticed a few of my apps work differently when compiled in DMD and LDC2. I'll have to see why they run differently. A few 3rd party libraries I use failed with strange linking errors on LDC2. I'll have to look more into this. Looks like LDC2 is more viable now than before.
Mar 24
prev sibling parent reply Stefan Koch <uplink.coder gmail.com> writes:
On Sunday, 22 March 2020 at 22:33:13 UTC, Matt Jones wrote:
 Does anyone have a guide on how to debug DMD crashes? I've been 
 getting compiler crashes on version 2.087.1 through 2.091.0 
 (only release mode on both Windows 10 and Linux). Version 
 2.086.1 was the last one that worked:

 dub run --arch=x86_64 --build=release

 C:\D\dmd2\windows\bin\dmd.exe failed with exit code -1073741795.

 Here is the smallest code snippet I could make crash: 
 https://github.com/workhorsy/crash_dmd
Hi, so I've found out what's going on. An assertion in CSE (Common Subexpression Elimination) fails. Which means that this is indeed an optimizer bug in the backend. I can not yet say how to fix it but is should be enough for you to file a bug report. The steps I took to find this are the following 1. Compile dmd with debug symbols. 2. use dub -v to see the compile commandline which fails. 3. run the commandline under gdb. (gdb --args) 4. look at where the failure happens.
Mar 23
parent Matt Jones <matthew.brennan.jones gmail.com> writes:
On Monday, 23 March 2020 at 19:46:33 UTC, Stefan Koch wrote:
 On Sunday, 22 March 2020 at 22:33:13 UTC, Matt Jones wrote:
 [...]
Hi, so I've found out what's going on. An assertion in CSE (Common Subexpression Elimination) fails. Which means that this is indeed an optimizer bug in the backend. I can not yet say how to fix it but is should be enough for you to file a bug report. The steps I took to find this are the following 1. Compile dmd with debug symbols. 2. use dub -v to see the compile commandline which fails. 3. run the commandline under gdb. (gdb --args) 4. look at where the failure happens.
I'll have to try this. Thanks
Mar 24