now "NIL access" error in Modules.Mod indeed works.

[norayr]

tested on linux/x86_64, linux/aarch64 and freebsd 15/x86_64.

[Oleg-N-Cher]

What about Windows? Does it work on Windows?

The point is that such triggering without explicitly specifying the location in a medium to large sized program is very uninformative. It would be nice to have the runtime prints the module name and the line where the NIL access occurred, for quicker bug retrieval.

Haven't you figured out how to get runtime to print this additional info when the SIGSEGV is triggered?

[norayr]

hello! it doesn't work on windows. and my idea was that since we already handled every other case like type guard checks or index ranges, only the nil access remains unhandled, so catching segfault at least is better than doing nothing. and the idea was that well, program in a safe language shouldn't just segfault and it is better to come up with some message (we had the message for years, but never wrote a code to handle it). and the idea was that probably it is better to catch the segfault than proactively check every pointer access which may be too costly.

but today i think maybe i was wrong and it needs a better solution.

hey, at least it does segfault anymore.

p. s. i think the only other possibility to segfault is the stack overflow now. which is not good again, it should be handled.

[norayr]

It would be nice to have the runtime prints the module name and the line where the NIL access occurred, for quicker bug retrieval.

yes, it would. did you implement it? i would be curious to look at other implementations.

[norayr]

Haven't you figured out how to get runtime to print this additional info when the SIGSEGV is triggered?

thank you, i'll think of it. maybe indeed that's doable. right now i am not even sure catching sigsegv was a good idea in the first place. :/ and windows should be handled, but there seems to be no crossplatform way of doing it, so windows case is separate. but i don't even have windows to test anything.

[norayr]

yes, the more i think, i realize i did it wrong. no wonder it's not implemented in ofront or wasn't done here.

but i'll do something about it. probably memory manager should be used.

[dcwbrown]

FYI I've been working on a form of PO2013 for Windows X64, and have worked out how to trap windows exceptions. It's in https://github.com/dcwbrown/osys It is not at all ready for anyone to use, but it loads PO2013 on windows. If you have a WIndows machine, git clone it and run build.cmd - it will build multiple times (bootstrapping) and you should see the PO2013 UI appear - you can use SYSTEM.Directory, Edit.Open and a few others. Look in file WinHost.Mod for the call to Windows API AddVectoredExceptionHandler, and the implementation of PROCEDURE ExceptionHandler. I hope this hlps a bit. Cheers -- Dave.

[Oleg-N-Cher]

Hi, Norayr and Dave,

Norayr, I agree with you on everything. Segfaults were Ofront's greatest scourge.

No, I didn't implement it, though I really meant to. This feature is a must.

But I didn't like the idea of checking the pointer every time it was dereferenced, since it's really an overhead. It might be worth doing that though. What do you think, Dave? Is there a good way to pass the module name and string to the output when a segfault is triggered?

If I'd had the chance to do this before, I would implement a __DEREF macro that would access the pointer with a NIL check, something like this:

#define __DEREF(ptr, name, line) ((ptr) ? *(ptr) : (__HALT, -10, name, line))

But I don't really like that solution. Although of course you can optionally turn it off.

But now that Norair has shown another way, it seems like a very interesting to me.