Signal Behaviour

Signals and Handling

Signals are one of the ways Linux tells a process something happened. A program can also send signals to itself or other processes. Some are normal, some mean something went wrong. SIGSEGV, for example, usually means invalid memory access.

When GDB is attached, signals go through GDB first. Depending on the signal settings, GDB can stop the process, print a message, pass the signal to the program or swallow it.

You can change this in Settings -> Debug -> Handle Signals:

• Signal: The signal name. The list is generic, so not every signal in there will be used by your target
• Stop & Print: Whether GDB should stop the process and print the signal to log output
• Pass to Program: Whether GDB should forward the signal to the target after handling it

PINCE maps these checkboxes to GDB's handle command internally:

handle SIGNAL stop/nostop print/noprint pass/nopass

Stop and Print are tied together in PINCE. You can't stop without printing or print without stopping from the dialog.

The 4 possible combinations are:

• Both unchecked: GDB ignores the signal and the program never sees it
  • Useful when a signal is just noise and you don't want it to affect anything
• Only Stop & Print checked: GDB stops and logs the signal, but the program never sees it
  • Useful when you want to inspect why a signal happened without letting the program run its handler
• Only Pass to Program checked: GDB does not stop, does not print and forwards the signal to the program
  • This is usually what you want for spammy signals that are normal for the target
• Both checked: GDB stops and logs the signal, then forwards it to the program when you resume
  • Useful for serious signals like SIGSEGV when you want to inspect the crash but still keep normal signal behavior

Default Signal Configuration

By default, PINCE sets most signals to stop, print and pass to the program. The important exceptions are:

• SIGINT and SIGTRAP stop and print, but are not passed to the program. GDB uses these internally a lot
• SIGUSR1, SIGUSR2, SIGPWR, SIGXCPU, SIGXFSZ and SIGSYS don't stop or print, but are still passed to the program due to community feedback
• SIGALRM, SIGURG, SIGCHLD, SIGIO, SIGVTALRM, SIGPROF, SIGWINCH, SIGPOLL, SIGWAITING, SIGLWP, SIGPRIO, SIGCANCEL and SIGLIBRT also don't stop or print by default
• SIG32 through SIG127 are added to the list and default to stop, print and pass

Generally, if a signal keeps pausing the program and it isn't interesting, set it to only Pass to Program. This is common for SIGUSR1, SIGUSR2, SIGALRM, SIGCHLD and numbered signals like SIG32.

Signal settings are applied after GDB is initialized and a process is attached. They are also re-applied when you change settings while attached.

SIGSEGV in Java and WINE

Java uses SIGSEGV internally for memory management, so stopping on every SIGSEGV makes Java targets awful to debug.

If Settings -> Java -> Ignore SIGSEGV for Java processes is enabled and the attached process name starts with java, PINCE overrides SIGSEGV to:

nostop noprint pass

This override is applied after the normal signal list. So if you manually set SIGSEGV in the Handle Signals dialog but this Java option is still enabled, the Java option wins for detected Java processes.

WINE can also use SIGSEGV a lot. Some WINE games keep throwing it at short regular intervals and GDB stopping on every one of them gets annoying fast. PINCE does not currently have a separate WINE auto-override for this, so if a WINE target keeps stopping on SIGSEGV, set SIGSEGV to only Pass to Program manually.

Interrupt Signal

You can configure which signal PINCE uses to interrupt, meaning pause, the process in Settings -> Debug -> Interruption signal. The default is SIGINT.

When SIGINT is selected, PINCE uses GDB's internal interrupt command. This does not actually deliver SIGINT to the process.

When another signal is selected, PINCE sends it to the process with kill while the process is running. For example, selecting SIG34 makes PINCE run the equivalent of:

kill -34 $pid

The selected interrupt signal is always forced to stop and not pass to the program. PINCE does this after applying the rest of the signal settings, so the interrupt signal setting wins over the Handle Signals dialog.

Finding Problem Signals

If you're not sure which signal is stopping the process, turn on GDB output and reproduce the stop.

To find it:

1. Enable either GDB file logging or GDB async output. More info is in Logging
2. Wait until the target stops
3. Check the GDB log or terminal output for something like:

~"1 \"process_name\" received signal SIGNAME, info about the signal"

4. SIGNAME is the signal you need to change in Settings -> Debug -> Handle Signals

For most spammy signals, the fix is only Pass to Program.