3 ms·

Why wouldn't it be able to? A segfault is just a signal like any other.

by ori_b 17y ago

ars 17y ago
I thought it couldn't be caught, but I checked the docs, and it seems it can. Hmm, maybe I should put that in all my programs - then I won't ever have bugs from segfaults. :)
- bwd2 17y ago
  Back in my student days long ago, a friend of mine who was working on a very difficult assignment hatched a plan to include a SIGSEGV handler that would print "NFS server not responding, still trying..." for use on the day when we had to demo the results to the TAs. The NFS system was pretty flaky and his hope was that the TA would move on to the next demo and get back to him, giving him time to fix whatever problem was happening. Not sure if he actually put it in though.
  - huhtenberg 17y ago
    Back in my student days for DOS-based labs we just did char foo[640*1024]; int main(int argc, char ** argv) { return 0; } When ran, it made the OS say "Out of memory" and then it was lab assistant's headache to unload all that resident stuff that was sitting there and eating good 20-30% of available RAM. They typically opposed to doing that, so the TAs assumed the program actually worked. The end :)
    - mahmud 17y ago
      I must be the only moron who used to be eager for others to see his programs. No teacher ever looked at it long enough to appreciate it though; I quickly established a reputation as a computer show off and the teachers were dismissive of me, spending more time with kid who actually had problems.
      - jhg 17y ago
        >> I quickly established a reputation as a computer show off Hmm ... :)
yan 17y ago
Because the state of a process is undefined after a seg fault.
- cracki 17y ago
  "undefined" doesn't mean it has no state. it does have some state. it's just that this state can't be predicted. it can still be recorded and used in debugging backwards.
- ori_b 17y ago
  2 comments about that: First, it must be well defined in order for the operating system to be able to do something about the process. It may not be consistent, predictable to userspace, or runnable, but it must be something possibly sensible. Therefore, it doesn't matter, the debugger can still inspect it, and the programmer can make sense of this state. Second, the debugger generally catches the signal before it gets handled.

Why wouldn't it be able to? A segfault is just a signal like any other.

by ori_b 17y ago

Why wouldn't it be able to? A segfault is just a signal like any other.

ars 17y ago

I thought it couldn't be caught, but I checked the docs, and it seems it can. Hmm, maybe I should put that in all my programs - then I won't ever have bugs from segfaults. :)

bwd2 17y ago
Back in my student days long ago, a friend of mine who was working on a very difficult assignment hatched a plan to include a SIGSEGV handler that would print "NFS server not responding, still trying..." for use on the day when we had to demo the results to the TAs. The NFS system was pretty flaky and his hope was that the TA would move on to the next demo and get back to him, giving him time to fix whatever problem was happening. Not sure if he actually put it in though.
- huhtenberg 17y ago
  Back in my student days for DOS-based labs we just did char foo[640*1024]; int main(int argc, char ** argv) { return 0; } When ran, it made the OS say "Out of memory" and then it was lab assistant's headache to unload all that resident stuff that was sitting there and eating good 20-30% of available RAM. They typically opposed to doing that, so the TAs assumed the program actually worked. The end :)
  - mahmud 17y ago
    I must be the only moron who used to be eager for others to see his programs. No teacher ever looked at it long enough to appreciate it though; I quickly established a reputation as a computer show off and the teachers were dismissive of me, spending more time with kid who actually had problems.
    - jhg 17y ago
      >> I quickly established a reputation as a computer show off Hmm ... :)

yan 17y ago

Because the state of a process is undefined after a seg fault.

cracki 17y ago
"undefined" doesn't mean it has no state. it does have some state. it's just that this state can't be predicted. it can still be recorded and used in debugging backwards.
ori_b 17y ago
2 comments about that: First, it must be well defined in order for the operating system to be able to do something about the process. It may not be consistent, predictable to userspace, or runnable, but it must be something possibly sensible. Therefore, it doesn't matter, the debugger can still inspect it, and the programmer can make sense of this state. Second, the debugger generally catches the signal before it gets handled.