After too many days of frustration to be able to count, I finally discovered what works for our builds: the debug build of 64-bit dmd on Windows.

When I build the release version from the Makefile or use digger, it produces a dmd binary that crashes randomly (bad enough) or compiles executables which themselves crash or run forever (much, much worse).

In all cases I installed dmd 2.080.0 from the installer then just copied over dmd.exe over the 32-bit one. I can't see what reason there'd be for the pre-built druntime and phobos binaries to not work just because dmd changed from 32-bit to 64-bit. But who knows.

This post is both a warning to the intrepid D programmers out there who'd rather not hit a 4GB RAM limit for no reason on Windows and also a question to see if anybody has been able to use 64-bit dmd on Windows like <insert deity here> intended.

Slightly slower builds are definitely better than ones that are flaky or hit gitlab's time limit.

Atila

On Wednesday, 13 June 2018 at 17:13:09 UTC, Atila Neves wrote:
> This post is both a warning to the intrepid D programmers out there who'd rather not hit a 4GB RAM limit for no reason on Windows and also a question to see if anybody has been able to use 64-bit dmd on Windows like <insert deity here> intended.

Works For Me(TM). But, as I mentioned in a thread a few weeks back, I open the Visual Studio solution and compile with the help of VisualD. I also just dump the resultant .exe over the release version.

I guess it's time to repeat the point though: Win64 DMD needs to be released alongside Win32. Day and date.

On Wednesday, 13 June 2018 at 17:13:09 UTC, Atila Neves wrote:
> After too many days of frustration to be able to count, I finally discovered what works for our builds: the debug build of 64-bit dmd on Windows.
>
> When I build the release version from the Makefile or use digger, it produces a dmd binary that crashes randomly (bad enough) or compiles executables which themselves crash or run forever (much, much worse).

I've used 64-bit DMD exclusively while Windows was my primary OS, but that was a few years ago.

Do you have a way to reproduce these problems reliably? If so, a few things you could try to narrow down the problem:

- Use DustMite and a test script that compiles a program with 64-bit release dmd.exe and a 32-bit or 64-bit debug dmd.exe, and accepts any reductions in which only the former crashes.

- See if this is a regression (do older 64-bit DMDs work OK?), and if so, use Digger to find where it was introduced.

- It's possible that the bug occurs not in the compiled DMD code, but in the host DMD compiler. There was at least one recorded case of a bug in the host DMD resulting in a broken built DMD which in turn executed successfully, but built broken programs. A discrepancy between which host DMD compiler is used can sometimes explain why some tests succeed on CI but fail locally, or vice versa.

On Wednesday, 13 June 2018 at 17:30:34 UTC, Vladimir Panteleev wrote:
> On Wednesday, 13 June 2018 at 17:13:09 UTC, Atila Neves wrote:
>> After too many days of frustration to be able to count, I finally discovered what works for our builds: the debug build of 64-bit dmd on Windows.
>>
>> When I build the release version from the Makefile or use digger, it produces a dmd binary that crashes randomly (bad enough) or compiles executables which themselves crash or run forever (much, much worse).
>
> I've used 64-bit DMD exclusively while Windows was my primary OS, but that was a few years ago.
>
> Do you have a way to reproduce these problems reliably? If so, a few things you could try to narrow down the problem:
>
> - Use DustMite and a test script that compiles a program with 64-bit release dmd.exe and a 32-bit or 64-bit debug dmd.exe, and accepts any reductions in which only the former crashes.

Until recently, I only had random dmd crashes. It was only yesterday that I managed to get a build that failed consistently. I'll try dustmite on it.

On another note, it seems that debug dmd only crashes less frequently. It just crashed on me again.

> - See if this is a regression (do older 64-bit DMDs work OK?), and if so, use Digger to find where it was introduced.

We never had problems up until 2.77.3 if I'm not mistaken.

> - It's possible that the bug occurs not in the compiled DMD code, but in the host DMD compiler. There was at least one recorded case of a bug in the host DMD resulting in a broken built DMD which in turn executed successfully, but built broken programs. A discrepancy between which host DMD compiler is used can sometimes explain why some tests succeed on CI but fail locally, or vice versa.

I tried multiple versions of host dmd. No differences in behaviour.

Atila

On Wednesday, 13 June 2018 at 17:30:34 UTC, Vladimir Panteleev wrote:
> On Wednesday, 13 June 2018 at 17:13:09 UTC, Atila Neves wrote:
>> [...]
>
> I've used 64-bit DMD exclusively while Windows was my primary OS, but that was a few years ago.
>
> [...]

Reviewing the dustmite documentation, I'm not sure how the reduction would work when the build that's broken is a dub one that uses local packages.

On Wednesday, 13 June 2018 at 17:54:29 UTC, Atila Neves wrote:
> Reviewing the dustmite documentation, I'm not sure how the reduction would work when the build that's broken is a dub one that uses local packages.

You will need to either reduce the test to a command which does not involve dub (its verbose output can help), or try using "dub dustmite" instead (I can't help much with the latter though).