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