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.

2 Recommendations:

1. Attach a debugger
2. Make sure to flush stdout whenever you write

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.

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

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.

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
> # in the gdb interface before running
> break _d_assertp
> break _d_assert
> break _d_assert_msg
>
> # or to combine it into the commandline:
> gdb -ex "break _d_assert" -ex "break _d_assert_msg" -ex "run $1" ./main
>
> # can also add it to your .gdbinit startup code.
> 

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.