This is the nature of most software. If you recurse non-stop you will get a segmentation fault.
We are better than that though. We should be able to find a means to detect infinite recursion and error out. This was found with the following snippet:
(:= c_void "void")
(fn c_ptr [t] (<- (+ t "*")))
(macro c_ptr [d] (c_ptr c_void)) # This was user error. shouldn't be allowed. (disallow macros to be named existing items?
(use "io")
(io::println (c_ptr "3"))
Perhaps we can monitor calls, but we don't want to actually incur storage overhead here.. perhaps instead when something is first called, or created, we make a call graph real quick to see if fault might occur.
If this can't be done quickly, or in a manner that it only ever happens once per unique call then maybe we should introduce a signal handler to intercept the seg fault. This interception would then dump the call stack to an N depth. We could also evaluate the call stack and attempt to present a helpful error message before we exit out.
bosley
commented
1 year ago
This is the nature of most software. If you recurse non-stop you will get a segmentation fault. We are better than that though. We should be able to find a means to detect infinite recursion and error out. This was found with the following snippet:
Perhaps we can monitor calls, but we don't want to actually incur storage overhead here.. perhaps instead when something is first called, or created, we make a call graph real quick to see if fault might occur.
If this can't be done quickly, or in a manner that it only ever happens once per unique call then maybe we should introduce a signal handler to intercept the seg fault. This interception would then dump the call stack to an N depth. We could also evaluate the call stack and attempt to present a helpful error message before we exit out.