3 ms·

As a useful variant of this: I have grown accustomed to killing processes that hang with kill -11 (SIGSEGV). This is essentially the same as -9, with the except

As a useful variant of this: I have grown accustomed to killing processes that hang with kill -11 (SIGSEGV). This is essentially the same as -9, with the exception that it creates a coredump. Saves a lot of hassle with manually attaching GDB.

btmorex 12y ago
Yup, there are risks too though with that approach. You should be sure that ulimit for core size is large enough (not default almost always). Also, a core dump can take a very long time if your programs address space is large. It might involve writing tens of gigabytes to disk. So not only do you need the file system space, but you also need to be prepared to wait tens of minutes while your program is dumping core.
- stingraycharles 12y ago
  While what you say is true, this is not really a problem in practice; most of the time, the process doesn't have the amount of memory allocated to be a serious problem, and the coredump file is written in a smart way [1]: usually, the address space has many 'gaps': instead of writing these all as \0 characters to disk, it uses more elaborate storage techniques. The end result is that you can have a coredump file which is reported to have a size of 1GB, while only having 100MB written on disk. [1] https://en.wikipedia.org/wiki/Core_dump#Format https://en.wikipedia.org/wiki/Core_dump#Format
dfox 12y ago
It's probably better to use SIGABRT (-6) for that, as it also dumps core and is less likely to be handled by the process (there are valid reasons to handle SIGSEGV and continue in execution)
- voltagex_ 12y ago
  I never thought of handling SIGSEGV. What would you use it for?
  - xfs 12y ago
    Many applications will try to print their own stack before exiting on SIGSEGV.
  - dfox 12y ago
    It's mostly about removing checks for rare occurrences: * catching of NULL pointer references (ie. transforming SEGV into catchable userspace exception) * testing whether some in memory data have been changed/accessed (ie. mprotect(), wait for SEGV, set flag, un-mprotect(), return) * paging in userspace (eg. across network) All that seems obscure (and is mainly useful for virtual machines and such), but it is not so rare to find process that actually does this (usually because of some library, or because it is some kind of virtual machine)

btmorex 12y ago

Yup, there are risks too though with that approach. You should be sure that ulimit for core size is large enough (not default almost always). Also, a core dump can take a very long time if your programs address space is large. It might involve writing tens of gigabytes to disk. So not only do you need the file system space, but you also need to be prepared to wait tens of minutes while your program is dumping core.

stingraycharles 12y ago
While what you say is true, this is not really a problem in practice; most of the time, the process doesn't have the amount of memory allocated to be a serious problem, and the coredump file is written in a smart way [1]: usually, the address space has many 'gaps': instead of writing these all as \0 characters to disk, it uses more elaborate storage techniques. The end result is that you can have a coredump file which is reported to have a size of 1GB, while only having 100MB written on disk. [1] https://en.wikipedia.org/wiki/Core_dump#Format https://en.wikipedia.org/wiki/Core_dump#Format

dfox 12y ago

It's probably better to use SIGABRT (-6) for that, as it also dumps core and is less likely to be handled by the process (there are valid reasons to handle SIGSEGV and continue in execution)

voltagex_ 12y ago
I never thought of handling SIGSEGV. What would you use it for?
- xfs 12y ago
  Many applications will try to print their own stack before exiting on SIGSEGV.
- dfox 12y ago
  It's mostly about removing checks for rare occurrences: * catching of NULL pointer references (ie. transforming SEGV into catchable userspace exception) * testing whether some in memory data have been changed/accessed (ie. mprotect(), wait for SEGV, set flag, un-mprotect(), return) * paging in userspace (eg. across network) All that seems obscure (and is mainly useful for virtual machines and such), but it is not so rare to find process that actually does this (usually because of some library, or because it is some kind of virtual machine)