www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - How to enable feedback for AssertError?

reply your_name <name example.com> writes:
Hello,

thanks for reading this.

The problem I have is whenever an assert in my debug build fails 
the program or thread is just killed silently.

How can I change this behavior to something akin to SIGSEGV ?

Thanks!
Jun 05 2016
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 06/05/2016 07:39 AM, your_name wrote:

 The problem I have is whenever an assert in my debug build fails the
 program or thread is just killed silently.
That's strange. When an assertion fails, the stack trace is printed and the program is terminated. For example: void fun(int i) { assert(i == 7); } void main() { fun(42); } That program fails loudly :) with something similar to the following: core.exception.AssertError deneme.d(2): Assertion failure ---------------- ??:? _d_assert [0x422b9b] ??:? void deneme.__assert(int) [0x422acc] ??:? void deneme.fun(int) [0x422a62] ??:? _Dmain [0x422a75] ??:? _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv [0x423012] ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) [0x422f5c] ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll() [0x422fce] ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) [0x422f5c] ??:? _d_run_main [0x422ecd] ??:? main [0x422b05] ??:? __libc_start_main [0x30ea082f] If you want to prevent termination, it is possible but not recommended to catch and swallow AssertError (or Error, or Throwable): import core.exception; void fun(int i) { assert(i == 7); } void main() { try { fun(42); } catch (AssertError) { // Something bad happened. We can't trust the state // of this program any more. } } As noted, when an Error is thrown, you can't know whether the program can do anything correctly any more. Ali
Jun 05 2016
parent reply your_name <yn example.com> writes:
On Monday, 6 June 2016 at 00:09:15 UTC, Ali Çehreli wrote:
 On 06/05/2016 07:39 AM, your_name wrote:

 The problem I have is whenever an assert in my debug build
fails the
 program or thread is just killed silently.
That's strange. When an assertion fails, the stack trace is printed and the program is terminated. For example: void fun(int i) { assert(i == 7); } void main() { fun(42); } That program fails loudly :) with something similar to the following: core.exception.AssertError deneme.d(2): Assertion failure ---------------- ??:? _d_assert [0x422b9b] ??:? void deneme.__assert(int) [0x422acc] ??:? void deneme.fun(int) [0x422a62] ??:? _Dmain [0x422a75] ??:? _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv [0x423012] ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) [0x422f5c] ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll() [0x422fce] ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) [0x422f5c] ??:? _d_run_main [0x422ecd] ??:? main [0x422b05] ??:? __libc_start_main [0x30ea082f] If you want to prevent termination, it is possible but not recommended to catch and swallow AssertError (or Error, or Throwable): import core.exception; void fun(int i) { assert(i == 7); } void main() { try { fun(42); } catch (AssertError) { // Something bad happened. We can't trust the state // of this program any more. } } As noted, when an Error is thrown, you can't know whether the program can do anything correctly any more. Ali
Hello Ali, The behavior you described is what I'd expect, however, it's not what I get. The way I traced the problem, ironically ;), was to catch Error and print it to screen. It involved dereferencing a null pointer in a thread and an 'assert null this' silently killed the thread leaving me wondering why it didn't produce data. Anyhow, I've had this behavior at least 1 more time but I forgot what exactly it was related to. Maybe I missed something beyond building a normal -debug version. Anyways, thanks for your reply :)
Jun 06 2016
parent reply Seb <seb wilzba.ch> writes:
On Tuesday, 7 June 2016 at 01:40:01 UTC, your_name wrote:
 On Monday, 6 June 2016 at 00:09:15 UTC, Ali Çehreli wrote:
 [...]
Hello Ali, The behavior you described is what I'd expect, however, it's not what I get. The way I traced the problem, ironically ;), was to catch Error and print it to screen. It involved dereferencing a null pointer in a thread and an 'assert null this' silently killed the thread leaving me wondering why it didn't produce data. Anyhow, I've had this behavior at least 1 more time but I forgot what exactly it was related to. Maybe I missed something beyond building a normal -debug version. Anyways, thanks for your reply :)
Please open an issue - this sounds like a big then.
Jun 06 2016
parent reply Mike Parker <aldacron gmail.com> writes:
On Tuesday, 7 June 2016 at 02:05:00 UTC, Seb wrote:
 On Tuesday, 7 June 2016 at 01:40:01 UTC, your_name wrote:
 The way I traced the problem, ironically ;), was to catch 
 Error and print it to screen.
 It involved dereferencing a null pointer in a thread and an 
 'assert null this' silently killed the thread leaving me 
 wondering why it didn't produce data.
 Anyhow, I've had this behavior at least 1 more time but I 
 forgot what exactly it was related to.

 Maybe I missed something beyond building a normal -debug 
 version.

 Anyways, thanks for your reply :)
Please open an issue - this sounds like a big then.
Exceptions thrown from spawned threads do not, by default, terminate the main thread, so they will not be printed to the screen unless it's done explicitly. See this old forum thread at [1]. Note this quote from Sean Kelley (the original maintainer of DRuntime): "Oh, I should mention that if you use core.thread explicitly, any unhandled exception will be re-thrown in the context of whoever joins that thread." [1] http://forum.dlang.org/post/mailman.1153.1344440030.31962.digitalmars-d-learn puremagic.com
Jun 06 2016
parent reply your_name <yn example.com> writes:
On Tuesday, 7 June 2016 at 04:21:34 UTC, Mike Parker wrote:
 On Tuesday, 7 June 2016 at 02:05:00 UTC, Seb wrote:
 On Tuesday, 7 June 2016 at 01:40:01 UTC, your_name wrote:
 The way I traced the problem, ironically ;), was to catch 
 Error and print it to screen.
 It involved dereferencing a null pointer in a thread and an 
 'assert null this' silently killed the thread leaving me 
 wondering why it didn't produce data.
 Anyhow, I've had this behavior at least 1 more time but I 
 forgot what exactly it was related to.

 Maybe I missed something beyond building a normal -debug 
 version.

 Anyways, thanks for your reply :)
Please open an issue - this sounds like a big then.
Exceptions thrown from spawned threads do not, by default, terminate the main thread, so they will not be printed to the screen unless it's done explicitly. See this old forum thread at [1]. Note this quote from Sean Kelley (the original maintainer of DRuntime): "Oh, I should mention that if you use core.thread explicitly, any unhandled exception will be re-thrown in the context of whoever joins that thread." [1] http://forum.dlang.org/post/mailman.1153.1344440030.31962.digitalmars-d-learn puremagic.com
Hi Mike, thanks for the pointer. However, since this is my first program in D using multi threading I am very sure that the other issue occured in a single threaded program. This was a while ago and I have since updated dmd/druntime/phobos several times so I could not tell if it would still apply. I try to investigate tomorrow, or day after tomorrow, depending on my schedule... Anyways, thanks everyone for your help so far :)
Jun 08 2016
parent your_name <yn example.com> writes:
Sorry for the necromancy.

I failed to reproduce the issue for single threaded programs. 
Which is good.

As far as std.concurrency is concerned I still have questions.
1. How does the main thread of a program print an 
(Assert)Error/Exception when it is terminated by it ?

2. Where is the place to make a suggestion for a documentation 
update for std.concurrency?
  For someone unware to this pitfall it can be quite a time waster 
so a Notice in the docs would be nice.

Thanks for the help.
Jun 18 2016