Segmentation fault protection: Difference between revisions

The closest thing the 68000 has to a segfault is an "alignment fault." <code>MOVE.W (An),Dn</code> or <code>MOVE.W (An),Dn</code> where <code>An</code> is any address register that contains an odd value will crash the CPU. More specifically, it will trigger one of the CPU's traps, forcing the program counter to jump to an error handler that is looked up from the trap table in low memory (on some machines such as the NEOGEO this just reboots the CPU. Note that byte-length commands are not subject to this aligment rule, which can lead to problems when working with structs that contain mixed data types. The programmer can avoid this very easily by either padding all their data to word length, use of the <code>EVEN</code> assembler directive after a sequence of byte-length data, or carefully arranging structs/unions so that all byte data is in pairs. An example is below:

 

dc.b $20

dc.b $40

MOVE.B (A0)+,D3

MOVE.B (A0)+,D4

 

As for executing RAM, or writing to code areas, there is no protection for either on the 68000. Failing to "balance" the stack will likely cause the alignment problem mentioned earlier, as the program counter needs to be even-aligned as well as any address registers you use.

Most commonly, segfaults in Julia are indications of a problem in a called C library. However, the functions in Julia prefixed with

unsafe_, such as unsafe_load(), can be used to reference a null pointer as in C, and can thus cause a segfault in the LLVM compiler runtime used to run Julia:

 

Exception: EXCEPTION_ACCESS_VIOLATION at 0x511008e4 -- unsafe_load at .\pointer.jl:105 [inlined]

unsafe_load at .\pointer.jl:105

...

 

=={{header|Perl}}==

<p>

For example, this code will segfault:

But with the safety features enabled you get compilation errors:

use warnings;

{{out}}

<pre>Bareword "p" not allowed while "strict subs" in use at exp/SegV line 6.

 

But if you absolutely feel the need to court disaster, at least run your code in an external process.

 

=={{header|Phix}}==

Phix has extensive compilation and runtime error handling, including bounds checking, unassigned variables, invalid assignments, and more, as well as exception handling, and strives to always deliver clear human-readable and actually useful error messages along with the file name and line number where they occurred - of course within reason, as the following example shows messages triggered by inline assembly (or within prebuilt dll/so) are inherently always going to be a bit more cryptic than the norm.

<span style="color: #008080;">try</span>

#ilASM{ xor eax,eax

<span style="color: #0000FF;">?</span><span style="color: #000000;">e</span>

<span style="color: #008080;">end</span> <span style="color: #008080;">try</span>

{{out}}

<pre>

Barring bugs in the compiler implementation, it should be impossible to generate a seqfault in standard Raku code. Memory is automatically managed, allocated and garbage collected by the virtual machine. Arrays are automatically managed, with storage allocation autovivified on demand. Uninitialized variables default to a Nil value, which decomposes to the base type of the variable. (If a base type was not specified, it could be Any type.)

 

my $var = @array[500];

 

{{out}}

<pre>(Any)</pre>

 

So the example code below compiles:

but if you try to run it you get a "Subscript out of bounds" error.