No stack for Win32 exceptions

[burner]

nicolas.jinchereau reported this on 2017-09-06T18:34:33Z

Transfered from https://issues.dlang.org/show_bug.cgi?id=17811

CC List

• r.sagitario

Description

I'm trying to work on a mixed D/C++ project, but when something goes wrong in the C++ code, I simply get this:

"Unhandled exception: 0xe06d7363: Win32 Exceptions"

The Stack Frame drop down in VS only has two entries:

"KernelBase.dll!_RaiseException@16 + 0x62 bytes" "my.exe!__d_throw_exception() + 0x196 bytes"

And a disassembly window opens up pointing inside "_RaiseException@16:"

There is no way to determine what went wrong from here. Breakpoints often do not work properly either.

[burner]

nicolas.jinchereau commented on 2017-09-06T19:29:09Z

I actually just figured out where the problem was, and it wasn't even C++ code. I was the assert that fires when you try to access an uninitialized payload of RefCounted:

@property nothrow @safe pure @nogc ref inout(T) refCountedPayload() inout return { --> assert(_refCounted.isInitialized, "Attempted to access uninitialized.."); return _refCounted._store._payload; }

[burner]

r.sagitario commented on 2017-09-06T19:59:46Z

The main problem with the missing stack trace for exceptions is that druntime is not built with standard stack frames.

Sometimes it helps if you load symbols from the Microsoft symbol server for Kernelbase.dll and anything else shown on the stack.

Another option might be to use the linker setting "Build and use local version of phobos with same compiler options" to link a debug version of druntime.

[burner]

nicolas.jinchereau commented on 2017-09-06T21:38:19Z

@Rainer Schuetze

Thanks - I hadn't tried that option yet.

I just tried it though, and I'm getting build errors due to the incorrect compiler being used.

Currently, certain parts of Visual D ignore the selected compiler for the project. For example, I have chosen Compiler=LDC in my project settings. The project builds fine using LDC, but when I "Go to definition" on any symbol in my project, it opens the source file from DMD's import path. This can be verified by F12'ing on a symbol, right clicking the newly opened tab, and selecting "Open Containing Folder". The build log from trying to build phobos also shows that DMD is being used to try and compile phobos, which gives tonnes of these errors:

Debug\privatedruntime.lib: Error: corrupt OMF object module Debug\phobos-errno.c.obj 161 Debug\privatedruntime.lib: Error: corrupt OMF object module Debug\phobos-adler32.c.obj 161 ....

[burner]

nicolas.jinchereau commented on 2017-09-06T22:39:03Z

Using LDC, I've added this flag, and the stack frame situation seems greatly improved, if not fixed.

Shouldn't this be default for debug mode?

-link-debuglib

[burner]

r.sagitario commented on 2017-09-07T07:32:24Z

Yeah, some parts are tuned for dmd only. With "Goto Definition" I suspect that you have "Built Phobos browse info" some time in the past? That would be used as a fallback if semantic analysis didn't find a result.

"Build and use local version of phobos with same compiler options" hasn't been tested on LDC, because, as you noted, the main use case is using a debug version of the runtime, and that is provided by LDC.

The debug version is a lot slower, though. I don't think it should be the default, but there should probably be an option to enable it (replacing "build and use...").

[burner]

nicolas.jinchereau commented on 2017-09-07T16:24:50Z

@Rainer Schuetze

"Built Phobos browse info" some time in the past?

Yes, same result though - DMD imports for LDC. I suppose I should file a separate bug for this though. I thought

As was as what lib to use for debug mode, I have to disagree. Slowness is the cost of debug mode. Debug mode is not Debug mode if you can't debug. If an option was added for -link-debuglib, people could turn it off if they wanted they needed to. The issue I was having was not once-in-a-while. Every other bug I was hitting would just crash, giving me no information about what went wrong, or where. I don't believe there's a reasonable argument for this happening in Debug mode. No one will expect to have to flip a switch before debug mode actually works as advertised.

Anyways, thanks for the help. Debugging seems to work fine now that I've enable the correct std lib.

[burner]

r.sagitario commented on 2017-09-16T16:51:34Z

https://github.com/dlang/visuald/releases/tag/v0.46.0-beta1 should fix the import issue with LDC and adds an option to use the debug library.

I'm unsure whether debug library by default is good, as there are some parts of the library that can get very slow with the debug version, e.g. the GC. In addition, you might "step into" a lot of operations that are assumed builtin, e.g. array operations or new.

[burner]

nicolas.jinchereau commented on 2017-09-17T16:12:33Z

Thanks for adding this, it's a big help.

I don't mind flipping a switch, but am more concerned for anyone else being left empty handed when their code fails and not being able to find a solution.

Using LDC's debug library greatly improves the situation, but doesn't entirely fix it for me. I still end up with no stack-frame/code-location sometimes. I think it may be due to the compilation options of the third party libraries I'm using. I've compiled them all from source, and have only been able to do so with the multi-threaded runtime (/MT) - otherwise, they won't link with my D program. I haven't yet been able to look at this issue exhaustively, but I have a feeling it's unfixable without building my own LDC libs.

[burner]

r.sagitario commented on 2017-10-22T17:41:26Z

Issue 11014 has been marked as a duplicate of this issue.