Why sometimes stacktraces are printed and sometimes not?

bauss jj_1337 at live.dk
Thu Sep 30 07:10:22 UTC 2021


On Wednesday, 29 September 2021 at 12:15:30 UTC, Steven 
Schveighoffer wrote:
> On 9/29/21 6:57 AM, JN wrote:
>> What makes the difference on whether a crash stacktrace gets 
>> printed or not?
>> 
>> Sometimes I get a nice clean stacktrace with line numbers, 
>> sometimes all I get is "segmentation fault error -1265436346" 
>> (pseudo example) and I need to run under debugger to get the 
>> crash location.
>
> segmentation faults are memory access errors. It means you are 
> accessing a memory address that is not valid for your 
> application. If you are accessing the wrong memory, it means 
> something is terribly wrong in your program.
>
> Note that on Windows in 32-bit mode, I believe you get a stack 
> trace. On Linux, there is the undocumented 
> `etc.linux.memoryhandler` which allows you to register an 
> error-throwing signal handler.
>
> Signals are not really easy to deal with in terms of properly 
> throwing an exception. This only works on Linux, so I don't 
> know if it's possible to port to other OSes. I've also found 
> sometimes that it doesn't work right, so I only enable it when 
> I am debugging.
>
> -Steve

You might also mention that even if you had a stacktrace where 
the error happened, that's usually not where the error was 
caused. It's most likely a completely different place in the code.

The only time where you somewhat can be sure where it happens is 
when you try to access ex. a reference type that hasn't been 
instantiated.

That's why in languages like C# you don't get a segfault/access 
violation, but you get a NullReferenceException.

It's not a concept D has, so it defaults to segfault/access 
violation.

Which means you're in really deep water when you encounter one 
because you have no idea what caused it and where it was caused.


More information about the Digitalmars-d-learn mailing list