Project

General

Profile

Feature #4212

TTCN3 docker containers: tell glibc to print segfault output to stderr

Added by pespin about 1 month ago. Updated about 1 month ago.

Status:
New
Priority:
Normal
Assignee:
sysmocom
Target version:
-
Start date:
09/18/2019
Due date:
% Done:

0%


Description

According to links below, glibc has a feature to log crash related output to stderr instead of /dev/tty (which in the case of running udner docker gets lost afaiu). The feature can be enabled by env var: LIBC_FATAL_STDERR_=1

The idea is to enable that var in docker containers we use to run osmo-* during TTCN3 tests (and unit tests) in order to be able to easily see that the program is crashing, and hopefully also get a backtrace.

We should also enable that in osmo-gsm-tester.

[1] https://stackoverflow.com/a/32057301
[2] https://stackoverflow.com/questions/32056387/catching-libc-error-messages-redirecting-from-dev-tty
[3] https://stackoverflow.com/questions/4290336/how-to-redirect-runtime-errors-to-stderr

History

#1 Updated by osmith about 1 month ago

  • Subject changed from TTCN3 docker containers: tell glibc to print segfault outputto stderr to TTCN3 docker containers: tell glibc to print segfault output to stderr

Note that right now, the osmo-* programs are configured to log to a file, e.g.

log file /data/osmo-msc.log

The osmo-* containers that run the programs are running in the background in the jenkins.sh scripts (docker run -d), which means printing the segfault output to stderr would get lost.

But it should work when we change the configs to log to stderr, and then start the osmo-* programs with redirected output:

export LIBC_FATAL_STDERR_=1
osmo-msc > /data/osmo-msc.log 2>&1

(A nice side-effect is, that we also get some output if the program does not start because the config can't be parsed etc.)

#2 Updated by pespin about 1 month ago

Agree with @osmith.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)