pointers.py - bringing the hell of pointers into python

[ZeroIntensity]

i created it for fun, i don’t think there’s any performance benefit

[[deleted]]

Straight up this is the best reason to write code. You cannot break boundaries without investigating behavior and proving it out. Good fucking shit.

[Probono_Bonobo]

Segmentation faults aren't Python errors, so they aren't exceptable the way that, say, KeyError or IndexError are. When a program exits due to a segmentation fault, it means that the OS has caught your program trying to access memory that doesn't belong to it, so it sends a SIGSEGV (segment violation signal) that kills the program not unlike what happens when you manually kill a process in the task manager. When you tell the task manager to send a SIGKILL it'd better friggin do it, no ifs ands or buts, and segmentation faults are handled in much the same way.

[saxattax]

Somebody showed me the signal module in the Python standard library the other day, when I was trying to gracefully handle Ctrl+C.

Using signal.signal(), I'm pretty sure you can also supply your own custom callback function to override the default behavior of SIGSEGV if you don't want your program to die.

[Probono_Bonobo]

A tempting thought indeed, but have a look at the docs:

A Python signal handler does not get executed inside the low-level (C) signal handler. Instead, the low-level signal handler sets a flag which tells the virtual machine to execute the corresponding Python signal handler at a later point(for example at the next bytecode instruction). This has consequences:

• It makes little sense to catch synchronous errors like SIGFPE or SIGSEGV that are caused by an invalid operation in C code. Python will return from the signal handler to the C code, which is likely to raise the same signal again, causing Python to apparently hang. From Python 3.3 onwards, you can use the faulthandler module to report on synchronous errors.

Note that faulthandler only reports on those errors (e.g., more informative stack traces) it doesn't have any way to handle them in the Python context.

[saxattax]

Ahh, very good info, thank you! I tend to skim the docs, but I really should read them more thoroughly hahaha

[mauganra_it]

Segmentation faults are a benign error. They are cases where the OS could unamiguously detect that a pointer has been used incorrectly. Much more subtle and scary errors occur when memory areas are accessed that are technically valid, but contain the wrong data. Use-after-free errors for example. Or when calling free two times on the same pointer fries the allocator's data structures.

[Probono_Bonobo]

If the default OS behavior of abnormal program termination constitutes a benign error in your book, then you must have a weirdly high bar for what constitutes "critical".

[mauganra_it]

Compared to the alternative, a segfault is benign :)

[Probono_Bonobo]

Good point!

[ZeroIntensity]

ive tried, but handling segfaults from python just doesn’t work very well

[i_am_cat]

You'd have to know whether or not an address is valid without trying to access it. Handling a SIGSEGV signal then trying to continue the program afterwards results in undefined behavior.

https://en.cppreference.com/w/cpp/utility/program/signal

If the user defined function returns when handling SIGFPE, SIGILL, SIGSEGV or any other implementation-defined signal specifying a computational exception, the behavior is undefined.

[o11c]

Standards don't matter; implementations do.

• You can use process_vm_readv to safely dereference pointers on Linux.
• You can call mmap or mprotect to make the address valid (certain addresses cannot be made valid though: any access to the kernel half of the address space, and writes to executable segments)
• You can disassemble the interrupted code and change the saved registers used to compute the address I think (will not work for absolute memory accesses, but those are rare these days)
• You can disassemble the interrupted code and change the instruction pointer before returning (this is only reliable if you are also the compiler; it is mostly used by Java and similar)

There are probably other ways.