5 ms·

Plan 9's abort causes an access fault, causing the current process to enter the `Broken' state. The process can then be inspected by a debugger. Pretty elegant

by p9idf 15y ago

Plan 9's abort causes an access fault, causing the current process to enter the `Broken' state. The process can then be inspected by a debugger. Pretty elegant. http://plan9.bell-labs.com/sources/plan9/sys/src/libc/9sys/abort.c http://plan9.bell-labs.com/sources/plan9/sys/src/libc/9sys/a...

cpeterso 15y ago
Beautiful! The gurus do not disappoint.
ristretto 15y ago
again, what's with the while()? even if it doesnt cause a segmentation fault, there's a chance it will evaluate to 0.
- rm445 15y ago
  I'm not a plan 9 programmer, but to me it looks 'cute' (in the sense of attractive to some people but annoying to others) - that form of abort() would only be used on systems where that operation is known to abort the process, but enclosing it in a while simply makes it apparent that there is no alternative to trying it. On a more prosaic note, perhaps for(;;) *(int *)0; generates a compiler warning that the programmer wanted to avoid.
- p9idf 15y ago
  As far as I know, the kernel programs the MMU so that dereferencing 0 will always fault. I could be wrong, as my understanding of the kernel is limited. I am not sure of the purpose of the loop, but to me it make it unavoidably obvious that the function never returns.
- singular 15y ago
  gcc, at least, optimises out the null deref for both:- *(int *)0; and:- for(;;) *(int *)0; So the first bit of code does nothing, and the second slips off into an infinite loop. I suspect that treating expressions that demonstrably lack side effects (other than the intended segfault here of course) as statements is undefined, and hence these are getting optimised out (even with -O0). Clearly with:- while(*(int *)0) The expression is being evaluated and is therefore not elided, I guess the choice of while is to 'be cute' as others have suggested, and I guess the world is sane in plan 9 and 0 is readable so you can't get a situation where it escapes the loop. Perhaps there is a deeper reason here that I am missing, however.
  - raldi 15y ago
    (int *)0 is not defined as a pointer to memory address 0x0 on architectures that support such an address. 0 cast as a pointer is defined by the spec to always be the NULL pointer, which on such architectures would have a value other than 0x0 and not point anywhere addressable.
  - ristretto 15y ago
    Thanks. I could never guess it could be optimized out.
1amzave 15y ago
In practical terms, does this differ significantly from killing the process and leaving a coredump?
jethroalias97 15y ago
Very elegant, though in some cases 0x0 is addressable, in which case, the abort never happens.
- gchpaco 15y ago
  Not, as it happens, on plan 9 systems where the kernel marks that area as not accessible. This could fail, conceivably, but then you're in much deeper stuff.
- raldi 15y ago
  0 cast as a pointer is not necessarily 0x0. The spec says it equals NULL, which, too, is not necessarily 0x0.

by p9idf 15y ago

cpeterso 15y ago

Beautiful! The gurus do not disappoint.

ristretto 15y ago

again, what's with the while()? even if it doesnt cause a segmentation fault, there's a chance it will evaluate to 0.

rm445 15y ago
I'm not a plan 9 programmer, but to me it looks 'cute' (in the sense of attractive to some people but annoying to others) - that form of abort() would only be used on systems where that operation is known to abort the process, but enclosing it in a while simply makes it apparent that there is no alternative to trying it. On a more prosaic note, perhaps for(;;) *(int *)0; generates a compiler warning that the programmer wanted to avoid.
p9idf 15y ago
As far as I know, the kernel programs the MMU so that dereferencing 0 will always fault. I could be wrong, as my understanding of the kernel is limited. I am not sure of the purpose of the loop, but to me it make it unavoidably obvious that the function never returns.
singular 15y ago
gcc, at least, optimises out the null deref for both:- *(int *)0; and:- for(;;) *(int *)0; So the first bit of code does nothing, and the second slips off into an infinite loop. I suspect that treating expressions that demonstrably lack side effects (other than the intended segfault here of course) as statements is undefined, and hence these are getting optimised out (even with -O0). Clearly with:- while(*(int *)0) The expression is being evaluated and is therefore not elided, I guess the choice of while is to 'be cute' as others have suggested, and I guess the world is sane in plan 9 and 0 is readable so you can't get a situation where it escapes the loop. Perhaps there is a deeper reason here that I am missing, however.
- raldi 15y ago
  (int *)0 is not defined as a pointer to memory address 0x0 on architectures that support such an address. 0 cast as a pointer is defined by the spec to always be the NULL pointer, which on such architectures would have a value other than 0x0 and not point anywhere addressable.
- ristretto 15y ago
  Thanks. I could never guess it could be optimized out.

1amzave 15y ago

In practical terms, does this differ significantly from killing the process and leaving a coredump?

jethroalias97 15y ago

Very elegant, though in some cases 0x0 is addressable, in which case, the abort never happens.

gchpaco 15y ago
Not, as it happens, on plan 9 systems where the kernel marks that area as not accessible. This could fail, conceivably, but then you're in much deeper stuff.
raldi 15y ago
0 cast as a pointer is not necessarily 0x0. The spec says it equals NULL, which, too, is not necessarily 0x0.