www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Advice on debugging possible exception or crash

reply Cecil Ward <cecil cecilward.com> writes:
My program is instrumented with a load of writeflns. At one point 
it looks as though it suddenly quits prematurely because the 
expected writeflns are not seen in the output. It could be that I 
am just reading the flow of control wrong as it goes ret, ret 
etc. I’m wondering if it is throwing an exception, or has a fault 
initiating a crash, perhaps even due to the fetching of arguments 
of one of the writeflns. In my limited experience, exceptions 
produce an error message though, and I’m not seeing anything. Any 
advice on how to debug this, silent termination ?

I don’t have a debugger on this machine, but on an x86-64 box I 
could use gdb if I first take the time to work out how.
Jul 05 2023
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
2 Recommendations:

1. Attach a debugger
2. Make sure to flush stdout whenever you write
Jul 05 2023
parent reply Cecil Ward <cecil cecilward.com> writes:
On Thursday, 6 July 2023 at 06:17:34 UTC, Richard (Rikki) Andrew 
Cattermole wrote:
 2 Recommendations:

 1. Attach a debugger
 2. Make sure to flush stdout whenever you write
I assumed that buffering was to blame. How do I flush stdout? I moved to an x86-64 box. I was using my ARM M2 Mac for which I have no debugger. There must be one somewhere though. I got a visible crash on the x86 machine, array index off the end by one, so I attached gdb and saw the bug. Yay! I’m not sure why there was no crash error message on the ARM Mac though. I had the array length wildly wrong. I then fixed the offending code that was doing the accounting wrongly.
Jul 06 2023
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 06/07/2023 7:07 PM, Cecil Ward wrote:
 On Thursday, 6 July 2023 at 06:17:34 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:
 2 Recommendations:

 1. Attach a debugger
 2. Make sure to flush stdout whenever you write
I assumed that buffering was to blame. How do I flush stdout?
stdout.flush; https://dlang.org/phobos/std_stdio.html#.stdout
Jul 06 2023
parent Cecil Ward <cecil cecilward.com> writes:
On Thursday, 6 July 2023 at 07:09:11 UTC, Richard (Rikki) Andrew 
Cattermole wrote:
 On 06/07/2023 7:07 PM, Cecil Ward wrote:
 On Thursday, 6 July 2023 at 06:17:34 UTC, Richard (Rikki) 
 Andrew Cattermole wrote:
 2 Recommendations:

 1. Attach a debugger
 2. Make sure to flush stdout whenever you write
I assumed that buffering was to blame. How do I flush stdout?
stdout.flush; https://dlang.org/phobos/std_stdio.html#.stdout
Many, many thanks once again.
Jul 06 2023
prev sibling next sibling parent Andrew <andrewlalisofficial gmail.com> writes:
On Thursday, 6 July 2023 at 06:00:04 UTC, Cecil Ward wrote:
 My program is instrumented with a load of writeflns. At one 
 point it looks as though it suddenly quits prematurely because 
 the expected writeflns are not seen in the output. It could be 
 that I am just reading the flow of control wrong as it goes 
 ret, ret etc. I’m wondering if it is throwing an exception, or 
 has a fault initiating a crash, perhaps even due to the 
 fetching of arguments of one of the writeflns. In my limited 
 experience, exceptions produce an error message though, and I’m 
 not seeing anything. Any advice on how to debug this, silent 
 termination ?

 I don’t have a debugger on this machine, but on an x86-64 box I 
 could use gdb if I first take the time to work out how.
Just some advice on if you're spawning threads, you should try and catch exceptions and errors at the top-most level and log them, otherwise they'll just vanish as the thread dies.
Jul 05 2023
prev sibling next sibling parent Dukc <ajieskola gmail.com> writes:
On Thursday, 6 July 2023 at 06:00:04 UTC, Cecil Ward wrote:
 In my limited experience, exceptions produce an error message 
 though, and I’m not seeing anything. Any advice on how to debug 
 this, silent termination ?
If unsure on cases like this, test. Intentionally throw an exception and don't catch it, what happens? Same for any other way of termination you're suspecting.
Jul 06 2023
prev sibling parent reply Chris Katko <ckatko gmail.com> writes:
On Thursday, 6 July 2023 at 06:00:04 UTC, Cecil Ward wrote:
 My program is instrumented with a load of writeflns. At one 
 point it looks as though it suddenly quits prematurely because 
 the expected writeflns are not seen in the output. It could be 
 that I am just reading the flow of control wrong as it goes 
 ret, ret etc. I’m wondering if it is throwing an exception, or 
 has a fault initiating a crash, perhaps even due to the 
 fetching of arguments of one of the writeflns. In my limited 
 experience, exceptions produce an error message though, and I’m 
 not seeing anything. Any advice on how to debug this, silent 
 termination ?

 I don’t have a debugger on this machine, but on an x86-64 box I 
 could use gdb if I first take the time to work out how.
one thing I do is have gdb/lldb break on d assert, before it destroys the stack. That helped me catch a class of bugs. ```sh break _d_assertp break _d_assert break _d_assert_msg gdb -ex "break _d_assert" -ex "break _d_assert_msg" -ex "run $1" ./main ```
Jul 06 2023
parent Cecil Ward <cecil cecilward.com> writes:
On Thursday, 6 July 2023 at 19:53:39 UTC, Chris Katko wrote:
 On Thursday, 6 July 2023 at 06:00:04 UTC, Cecil Ward wrote:
 My program is instrumented with a load of writeflns. At one 
 point it looks as though it suddenly quits prematurely because 
 the expected writeflns are not seen in the output. It could be 
 that I am just reading the flow of control wrong as it goes 
 ret, ret etc. I’m wondering if it is throwing an exception, or 
 has a fault initiating a crash, perhaps even due to the 
 fetching of arguments of one of the writeflns. In my limited 
 experience, exceptions produce an error message though, and 
 I’m not seeing anything. Any advice on how to debug this, 
 silent termination ?

 I don’t have a debugger on this machine, but on an x86-64 box 
 I could use gdb if I first take the time to work out how.
one thing I do is have gdb/lldb break on d assert, before it destroys the stack. That helped me catch a class of bugs. ```sh break _d_assertp break _d_assert break _d_assert_msg gdb -ex "break _d_assert" -ex "break _d_assert_msg" -ex "run $1" ./main
This is brilliant advice. I’m building with LDC and in debug mode with -g, however gdb says it can’t find any symbol table or debug info, can’t even set breakpoints by line numbers. The Matt Godbolt Compiler Explorer can go to source line numbers in the asm. So I’m just missing something.
Jul 06 2023