NextPrevious Table of Contents

### 4. Appendix

### 4.1 UNIX Signals

These are the signals as explained on the manual page of signal(7). For details consult the manual page with:

`man 7 signal`

The following signals are defined by Posix and can be sent by kpm:

- SIGHUP: Hangup detected on controlling terminal or death of controlling process
- SIGINT: Interrupt from keyboard
- SIGQUIT: Quit from keyboard
- SIGILL: Illegal Instruction
- SIGABRT: Abort signal from abort(3)
- SIGFPE: Floating point exception
- SIGKILL: Kill signal
- SIGSEG: Invalid memory reference
- SIGPIPE: Broken pipe: write to pipe with no readers
- SIGALRM: Timer signal from alarm(1)
- SIGTERM: Termination signal
- SIGUSR1: User-defined signal 1
- SIGUSR2: User-defined signal 2
- SIGCHLD: Child stopped or terminated
- SIGCONT: Continue if stopped
- SIGSTOP: Stop process
- SIGTSTP: Stop typed at tty
- SIGTTIN: tty input for background process
- SIGTTOU: tty output for background process

These signals aren't defined by Posix, nor available from kpm (yet)

- SIGTRAP: Trace/breakpoint trap
- SIGIOT: IOT trap. A synonym for SIGABRT
- SIGBUS: Bus error
- SIGSYS: Bad argument to routine (SVID)
- SIGSTKFLT: Stack fault on coprocessor
- SIGURG: Urgent condition on socket (4.2 BSD)
- SIGIO: I/O now possible (4.2 BSD)
- SIGPOLL: synonym for SIGIO (System V)
- SIGCLD: synonym for SIGCHLD
- SIGXCPU: CPU time limit exceeded (4.2 BSD)
- SIGXFSZ: File size limit exceeded (4.2 BSD)
- SIGVTALRM: Virtual alarm clock (4.2 BSD)
- SIGPROF: Profile alarm clock
- SIGPWR: Power failure (System V)
- SIGINFO: A synonym for SIGPWR
- SIGLOST: File lock lost
- SIGWINCH: Window resize signal (4.3 BSD, Sun)
- SIGUNUSED: Unused signal

### 4.2 Known bugs and problems

- kpm sometimes dies with a segmentation fault if more than one process is marked and the list is updated. I've no clue why...
- The info bar and the process list itself are optimized for 12pt fonts. It will look good enough with fonts up to 14pt, but look very ugly for bigger fonts.
- kpm can consume a lot of CPU resources if the update period is too small. On my system (AMD K6PR200) it uses approximatly 5 percent CPU time with an update period of one second. This heavily depends on the total number of processes (all processes, not only those displayed) and can be much higher than this.
- The %CPU number isn't accurate at very short update periods due to timer granularity.
- The WCHAN field isn't correct if a process sleeps in a location outside those in `System.map` (for instance, in a kernel module). In these cases, the last entry in `System.map` will be showed (something like `_end`).
- kpm doesn't handle more than one process with the same PID. This can occur when using CLONE_PID with the clone() system call.

NextPrevious Table of Contents