Project

General

Profile

Bug #2321

osmo-gsm-tester: store properly coredump files when a process crashes

Added by pespin 2 months ago. Updated 2 months ago.

Status:
New
Priority:
Normal
Assignee:
osmo-gsm-tester
Target version:
-
Start date:
06/12/2017
Due date:
% Done:

0%

Spec Reference:

Description

When a process crashes (both on main unit or on the BTS), we should be able to record the details and store the coredump in the run directory of the trial.

  • Configure the main unit correctly (ulimit, etc.) to output the core dump in the run directory of the crashed process, together with its stderr and stdout files.
  • Same for the BTs + scp it back to the trial directory in the main unit.
  • Extra: Add python code to automatically open the dump file and print a backtrace + other interesting stuff.

This can be tested apparently by sending a SIGQUIT signal to a process: https://stackoverflow.com/questions/6561194/force-a-core-to-dump-from-an-active-normally-running-program-on-freebsd

History

#1 Updated by pespin 2 months ago

  • Subject changed from osmo-gsm-tester: store properly coredump files whena process crash to osmo-gsm-tester: store properly coredump files when a process crashes

#2 Updated by neels 2 months ago

  • Related to Bug #2325: sporadic crash of osmo-bts-trx in osmo-gsm-tester runs added

#3 Updated by neels 2 months ago

I remember to have seen a core file in a result tarball before, so I assumed this would work;
(except for the sysmobts, where we simply don't have code to copy a core file back to the workspace yet.)

#4 Updated by neels 2 months ago

The recent "crash" of osmo-bts-trx that made us question the working core dumps is actually an intentional shutdown by osmo-bts-trx (see #2325) and is not expected to produce a core dump. Anyway, it can't hurt to verify that core dumps are working as intended.

#5 Updated by neels 2 months ago

  • Related to deleted (Bug #2325: sporadic crash of osmo-bts-trx in osmo-gsm-tester runs)

Also available in: Atom PDF