www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - crashing with no stack trace, why?

reply DanielG <simpletangent gmail.com> writes:
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.
Jan 31 2019
next sibling parent reply bauss <jj_1337 live.dk> writes:
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
Jan 31 2019
parent DanielG <simpletangent gmail.com> writes:
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.
Jan 31 2019
prev sibling next sibling parent NX <nightmarex1337 hotmail.com> writes:
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
Jan 31 2019
prev sibling parent reply JN <666total wp.pl> writes:
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.
Feb 01 2019
parent DanielG <simpletangent gmail.com> writes:
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!
Feb 01 2019