digitalmars.D - Any guides on debugging DMD crash?
- Matt Jones (8/8) Mar 22 2020 Does anyone have a guide on how to debug DMD crashes? I've been
- Stefan Koch (7/15) Mar 22 2020 Ah very interesting!
- Matt Jones (2/21) Mar 22 2020 I hope so. Thanks!
- Arine (13/21) Mar 22 2020 Since it crashes when you do a release build, this is most likely
- DanielG (17/21) Mar 24 2020 How common is this sentiment among D developers?
- bachmeier (7/29) Mar 24 2020 I can only give one data point, but I started using D in 2013 and
- H. S. Teoh (18/23) Mar 24 2020 I've been using D since around late 2011 / early 2012, and have run into
- rikki cattermole (6/28) Mar 24 2020 Similar-ish story for me.
- H. S. Teoh (25/39) Mar 24 2020 There's ldmd2, an LDC wrapper that works more-or-less as a drop-in
- Seb (11/17) Mar 24 2020 There's virtually no reason to use DMD and I don't think anyone
- Matt Jones (9/34) Mar 24 2020 I've been trying LDC2 every couple of years. It's been a while.
- Stefan Koch (11/19) Mar 23 2020 Hi, so I've found out what's going on.
- Matt Jones (2/14) Mar 24 2020 I'll have to try this. Thanks
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 2020
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_dmdAh 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 2020
Matt Jones <matthew.brennan.jones gmail.com> 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:I hope so. Thanks!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_dmdAh 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 2020
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_dmdSince 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 2020
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 2020
On Tuesday, 24 March 2020 at 16:11:40 UTC, DanielG wrote:On Monday, 23 March 2020 at 00:17:48 UTC, Arine 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.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 2020
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 2020
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: [...]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 :)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.
Mar 24 2020
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 2020
On Tuesday, 24 March 2020 at 16:11:40 UTC, DanielG wrote:On Monday, 23 March 2020 at 00:17:48 UTC, Arine wrote: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.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?
Mar 24 2020
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: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.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_dmdSince 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 24 2020
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_dmdHi, 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 2020
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:I'll have to try this. Thanks[...]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 24 2020