On Tue, Jun 14, 2016 at 6:00 AM, Mirar @ Pike developers forum 10353@lyskom.lysator.liu.se wrote:
The only other case for SIGSEGV would be to crash your program to restart it because _Pike itself_ had a bug. I haven't seen that case for many years. YMMV.
GTK2 bugs have been crashing Pike periodically, until they get pinned down and fixed. So Pike bugs _do_ happen, but you can ignore them in mmap.
ChrisA
Also, on a somewhat related note, does catching SIGSEGV not work for some reason?
I can see no reason for why it would not work for this specific purpose.
Still, doing the checks that are done now in mmap does not in any way provide protection against sigsegvs.
Per Hedbor () @ Pike (-) developers forum wrote:
Also, on a somewhat related note, does catching SIGSEGV not work for some reason?
*Catching* SIGSEGVs works fine, however... a. You should be able to distinguish segmentation faults caused by your flaky mmap() from other segfaults. That might be harder than you think (in the generic case it ultimately requires dissassembly of the instruction at the point of failure, including knowledge of the register content, which implies knowledge of the stack layout used to save the registers). b. When you return from the signal-trap-function you should either have made sure that the memory access now succeeds (making sure of that involves knowing what caused it, see (a)), or you should make sure that the thread that caused it is killed accordingly, or you should unwind the stackframe using a longjmp() back to safety.
So, yes, you can catch the SIGSEGV, but the trick is doing "the right thing" after that.
Still, doing the checks that are done now in mmap does not in any way provide protection against sigsegvs.
Granted.
I had experimental code throwing an error() many years ago, so it should be possible.
pike-devel@lists.lysator.liu.se