Hannah / is on Nostr

Incomprehensible cat girl, #trans #lesbian (I think?) and local (server) maid
Currently level 29
Too much #ADHD with (probably) a little #Autism sprinkled in
I like #cats, [#3D-modelling](https://moonserver.yorha.nexus/tags/3D-modelling ), #programming, girls
Very interested in #gamedev

Last Notes

2024-08-18 04:08:03

- reply

I like that analogy. I need to remember that :blohaj_asparagus:
The crash dump usually contains the last "eip" and "rip" register ("execution instruction pointer" and "return instruction pointer") which tell you where exactly it was just before disaster struck and who called the offending function you find yourself in.
In this particular case it was not that hard to find since the stack trace itself was not mangled and the offending function was quickly found.
The "real fun" (read: pain) begins, when some of that information is missing.
A stack trace that just... stops. Or a "rip" that points into unallocated memory.
Does not usually happen, but when it occurs... pray to whatever higher being you believe in that it is easily reproducible so you can get a better crash dump.
Otherwise: get some caffeine (or other performance enhancing drug of choice). You will need it :blobcat_derp:
Not going to lie here though: I really enjoy this kind of stuff. It is like a gigantic logic puzzle.
I will stay glued to a crash dump and *will* find the cause if I really put my mind to it :blobcat_wink:

2024-08-18 03:22:40

- reply

The program cannot tell you anything meaningful anymore, you are correct.
Resolving a null pointer is "undefined behaviour" per C/C++ programming standard. (As far as I am aware, any programming language with memory pointers defines it this way)
Anything past that operation has no meaning, as further operations (like calling a function or even simple addition) cannot be determinalistic anymore. An underlying core assumption was "proven wrong", but no result from such operations can be trusted.
I certainly would not believe a computer that claims it can divide by zero.
The operating system traps invalid instructions like these and immediately kills misbehaving programs like these. If left running for a while (to try to gather information about what exactly went wrong for example) the operating system itself is in jeopardy as it *has* to rely on the information the program provides.
Information that are, as established above, meaningless. Nobody would trust a calculator that "successfully" divides by zero.
So the only really good option the operating system has is to immediately kill the offending process and dump the content of the memory to disk for analysis (which is kind of what you can see in the picture).

2024-08-18 02:41:44

- reply

My comment was intended to be sarcastic. I apologize, I should have made my intent clearer from the start.
Of course an error message would be more helpful, but receiving one would be near impossible.
I do not know how much you know about computers, so a quick tl;dr is: This kind of error usually means immediate termination from the operating system as absolutely nothing the program does from this point onwards can be trusted.
All you are left with is a crashdump, if you are lucky.

2024-08-18 02:11:52

- reply

Who needs error messages when you can just jump into memory and dig up the problem yourself.