digitalmars.D.learn - How to enable feedback for AssertError?
- your_name (6/6) Jun 05 2016 Hello,
- =?UTF-8?Q?Ali_=c3=87ehreli?= (44/46) Jun 05 2016 That's strange. When an assertion fails, the stack trace is printed and
- your_name (13/63) Jun 06 2016 Hello Ali,
- Seb (2/17) Jun 06 2016 Please open an issue - this sounds like a big then.
- Mike Parker (12/27) Jun 06 2016 Exceptions thrown from spawned threads do not, by default,
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
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
On Monday, 6 June 2016 at 00:09:15 UTC, Ali Çehreli wrote:On 06/05/2016 07:39 AM, your_name 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 :)The problem I have is whenever an assert in my debug buildfails theprogram 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 06 2016
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:Please open an issue - this sounds like a big then.[...]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
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: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.comThe 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
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: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 :)On Tuesday, 7 June 2016 at 01:40:01 UTC, your_name wrote: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.comThe 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 08 2016
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