I have a program that was crashing due to a "Conversion positive overflow", specifically calling .to!int on a too-large unsigned value.

However it was simply crashing with an exit code (-1073740771 / ‭0xC000041D‬), and I was having a heck of a time trying to debug on Windows. (Shoutout to the revamped WinDbg Preview, couldn't get anything else to work!)

I wondered if there was something in my code that was causing the silent crash, so I isolated the calculation (with a little bit of context to mimic the in-situ code), but in a standalone .d file, I simply get the overflow exception with a normal stack trace.

Is this something I should try to whittle down with DustMite to get to the bottom of, for a bug report? Or is there something I'm failing to understand about this kind of crash?

This is on Windows 10 64-bit, DMD v2.084.0, both x86_mscoff and x86_64.

On Thursday, 31 January 2019 at 11:09:56 UTC, DanielG wrote:
> I have a program that was crashing due to a "Conversion positive overflow", specifically calling .to!int on a too-large unsigned value.
>
> However it was simply crashing with an exit code (-1073740771 / ‭0xC000041D‬), and I was having a heck of a time trying to debug on Windows. (Shoutout to the revamped WinDbg Preview, couldn't get anything else to work!)
>
> I wondered if there was something in my code that was causing the silent crash, so I isolated the calculation (with a little bit of context to mimic the in-situ code), but in a standalone .d file, I simply get the overflow exception with a normal stack trace.
>
> Is this something I should try to whittle down with DustMite to get to the bottom of, for a bug report? Or is there something I'm failing to understand about this kind of crash?
>
> This is on Windows 10 64-bit, DMD v2.084.0, both x86_mscoff and x86_64.

Did you compile it with debug info? Eg. -g

I can't say for sure, but there are some cases I know where you don't get stack trace (mostly dmd bugs):

- inside module constructors `shared static this()`
- null function pointer call

On Thursday, 31 January 2019 at 11:28:40 UTC, bauss wrote:
> Did you compile it with debug info? Eg. -g

Yep, I use dub for builds which does that by default. Until this bug I was getting the usual stack traces with my project since the beginning.

On Thursday, 31 January 2019 at 11:09:56 UTC, DanielG wrote:
> However it was simply crashing with an exit code (-1073740771 / ‭0xC000041D‬), and I was having a heck of a time trying to debug on Windows. (Shoutout to the revamped WinDbg Preview, couldn't get anything else to work!)

For Windows, you can try VisualD and VSCode with C++ debugger. I had good experience using those, at least to determine which line crashes in my code when stacktrace is not provided.

On Friday, 1 February 2019 at 09:00:32 UTC, JN wrote:
> For Windows, you can try VisualD and VSCode with C++ debugger.

I tried both of those but neither seemed to work out of the gate. I didn't take notes but my vague memory is that VisualD wasn't picking up some local dub dependecies and/or something to do with 32-bit COFF linkage, and VSCode seemed to be trying to debug but it wouldn't show me a stack trace of my own code, just telling me it didn't have symbols for some Windows kernel DLL.

I definitely need to sit down with one or both of those to understand how to get them to work in the future, because I lost way too much time to such a small issue!