www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Stacktraces in static constructors

reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
AFAICT, stacktraces are not emitted with debug information when 
errors occurr in static module constructors. Is this a know bug?

This is a big problem for me because, in my application, I've 
realized unittests as functions called from within static shared 
module constructors to elide the problem of unittests being 
enabled recursively, which slows down iterative compilation time 
enormously.
May 03 2016
next sibling parent reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Tuesday, 3 May 2016 at 10:48:51 UTC, Nordlöw wrote:
 AFAICT, stacktraces are not emitted with debug information when
Should be static shared module constructors.
 errors occur in static module constructors. Is this a know bug?
My stacktraces contain no information of the call stack so it's very very tedious work to find the reason for a failing unittest.
May 03 2016
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
On Tuesday, 3 May 2016 at 10:52:20 UTC, Nordlöw wrote:
 On Tuesday, 3 May 2016 at 10:48:51 UTC, Nordlöw wrote:
 AFAICT, stacktraces are not emitted with debug information when
Should be static shared module constructors.
 errors occur in static module constructors. Is this a know bug?
My stacktraces contain no information of the call stack so it's very very tedious work to find the reason for a failing unittest.
I assume this is on windows? Yes its a known issue (I know about it). I Don't know if its filed though. As a workaround you can import "core.sys.windows.stacktrace" into each of your modules. That will force the module system to initialize the stacktracing code before the module ctors. The underlying issue is that the module system does not know about the implicit dependeny of every module on the stacktracing module. Kind Regards Benjamin Thaut
May 03 2016
parent reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Tuesday, 3 May 2016 at 12:31:10 UTC, Benjamin Thaut wrote:
 I assume this is on windows? Yes its a known issue (I know
No, the problem occurs on my Linux aswell.
May 03 2016
parent Benjamin Thaut <code benjamin-thaut.de> writes:
On Wednesday, 4 May 2016 at 06:37:28 UTC, Nordlöw wrote:
 On Tuesday, 3 May 2016 at 12:31:10 UTC, Benjamin Thaut wrote:
 I assume this is on windows? Yes its a known issue (I know
No, the problem occurs on my Linux aswell.
From core.runtime: static this() { // NOTE: Some module ctors will run before this handler is set, so it's // still possible the app could exit without a stack trace. If // this becomes an issue, the handler could be set in C main // before the module ctors are run. Runtime.traceHandler = &defaultTraceHandler; } So a possible workaround would be to either import core.runtime in each of your modules or manually run the line Runtime.traceHandler = &defaultTraceHandler. Also I find it strange that the trace handler is initialized in a regular module constructor. In my eyes it should be a shared module ctor because the storage behind Runtime.traceHandler is __gshared anyway. Kind Regards Benjamin Thaut
May 04 2016
prev sibling parent =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Tuesday, 3 May 2016 at 10:48:51 UTC, Nordlöw wrote:
 This is a big problem for me because, in my application, I've 
 realized unittests as functions called from within static 
 shared module constructors to elide the problem of unittests 
 being enabled recursively, which slows down iterative 
 compilation time enormously.
Doh, correction. I hade made the wrong assumption about separate compilation of unittests. It *only* instantiates unittests in the module I compile and *not* in the unittests contained in the imported modules. Sorry for disturbance, Per
May 06 2016