Snapshot functionality - library part

[michalbiesek]

• replace SCOPE_ERROR_SIGNAL_HANDLER with snapshot logic
• handle new configuration options related to snapshot options
• if the snapshot is enabled install our handler
• generate snapshot in following location /tmp/appscope/<PID>
• enable snapshot is done via enabling coredump and/or enabling backtrace
• generating configuration and general information about process is mandatory if snapshot is enabled
• generating coredump and backtrace is optional depending on configuration settings
• call SIGSTOP after generating snapshot
• after receiving SIGCONT call orignal application handler
• Details of files generated by library

[michalbiesek]

@abetones:
This issue will be resolved in v1.3.0.
The snapshot feature extends the crash analysis capabilities of the scoped process.
Following changes needs to be updated accordingly:

• extending the scope.yml with the new section snapshot - this will impact website/src/pages/docs/config-file.md
• the snapshot mentioned above will replace the mechanism SCOPE_ERROR_SIGNAL_HANDLER
• well know limitation of this feature is mentioned in The coredumper library is not sufficient for generating coredumps in all cases #1303

We will discuss the details of this in the future.

This comment here is just a mark point.

[michalbiesek]

QA instructions

The instructions below can be used for different applications but I would recommend testing logic on the application which by itself registers a signal handler for SIGSEGV, SIGINT, SIGILL, SIGFPE, e.g. Redis does it.

Snapshot description

1. Attach Scenario

In terminal 1

# Start redis
redis-server --port 7878

In terminal 2

# Attach to redis
sudo SCOPE_SNAPSHOT_COREDUMP=true SCOPE_SNAPSHOT_BACKTRACE=true ./bin/linux/x86_64/scope attach <redis_pid>
# Send SIGSEGV signal
kill -SIGSEGV <redis_pid>
# The <redis_pid> should stopped - on terminal 1 You should see
# [1]+  Stopped                 redis-server --port 7878
# or You can: `grep  State /proc/<redis_pid>/status` to see stopped status
# At this point You can verify that snapshot files were created in /tmp/appscope/<redis_pid>
# The content of it should reflect the Snapshot description mentioned above

# Allow redis to continue
kill -SIGCONT <redis_pid>

The process should have ended and the redis itself should generate its own backtrace on stdout see the function logStackTrace/printCrashReport (depending on Your work env) is coming from redis
The signal mentioned in redis stacktrace should point to SIGSEGV:

Redis 5.0.7 crashed by signal: 11

2. Scoping from beginning
   The scenario is very similar to first one. We will use single terminal.

Terminal 1

SCOPE_SNAPSHOT_COREDUMP=true SCOPE_SNAPSHOT_BACKTRACE=true ./bin/linux/x86_64/scope redis-server --port 7878
# Send SIGSEGV signal
....

Rest of steps are the same like in scenario 1 and behavior should be just like the one described in the scenario 1.

[jrcheli]

Manually setting this issue to closed, since it's been merged into release/1.3.