ubuntuusers.de

Kann man den Speicherort eines Coredumps festlegen?

Status: Ungelöst | Ubuntu-Version: Ubuntu MATE 22.04 (Jammy Jellyfish)
Antworten |

Dakuan

Avatar von Dakuan

Anmeldungsdatum:
2. November 2004

Beiträge: 6450

Wohnort: Hamburg

Ich habe da eine selbstgestrickte Anwendung, die systemweit Dateien anschaut, also auch die anderer User (soweit erlaubt). Leider stürzt diese Anwendung immer wieder mal ab. Kein Debugger konnte mir dabei helfen. Nemiver erkennt nur den Absturz und ddd hängt sich selber auf (konnte früher immer sehr genau den Ort des Absturzes anzeigen, auch ohne coredump).

Ich habe es jetzt, nach umfangreicher Internetsuche, geschafft, Coredumps an apport vorbei zu erzeugen. Aber die werden, wie im Standard vorgesehen, immer im aktuellen Arbeitsverzeichnis abgelegt, wenn möglich. Mein Programm hat aber nicht immer im aktuellen Arbeitsverzeichnis Schreibrecht (da anderer User).

Es wäre daher wünschenswert, wenn man den Speicherort, unabhängig vom Arbeitsverzeichnis, festlegen könnte. Geht das überhaupt?

Momentane Einstellungen sind:

/proc/sys/kernel/core_pattern - core.%e.%p
/proc/sys/kernel/core_uses_pid - 1

rklm Team-Icon

Projektleitung

Anmeldungsdatum:
16. Oktober 2011

Beiträge: 13075

Du setzt einfach einen absoluten Pfad. "The template may include '/' characters, which are interpreted as delimiters for directory names." https://man7.org/linux/man-pages/man5/core.5.html über core_pattern.

Die Alternative ist, Dein Programm so zu ändern, dass es egal ist, von welchem Arbeitsverzeichnis es gestartet wurde. Das macht Dein Programm sowieso robuster.

Dakuan

(Themenstarter)
Avatar von Dakuan

Anmeldungsdatum:
2. November 2004

Beiträge: 6450

Wohnort: Hamburg

Wir haben wohl beide nicht zu ende gedacht. proc ist wohl ein virtuelles Dateisystem und der Inhalt wird bei jedem Start neu erstellt. Da ist dann wieder der Kram von Ubuntu drin:

|/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E

Und das mit dem '/' bezieht sich wohl nur auf den Fall, dass die Ausgabe mittels Pipe an ein anderes Programm weiter geleitet wird. Jedenfalls ein einfaches

~/core.%e.%p

geht nicht, dann passiert gar nichts mehr.

Die Alternative ist, Dein Programm so zu ändern, dass es egal ist, von welchem Arbeitsverzeichnis es gestartet wurde.

Das macht mein Programm ja und genau dadurch entsteht ja erst das Problem. Wenn das Programm auf einem externen Datenträger arbeitet, der schreibgeschützt oder voll ist, wird kein Coredump geschrieben.

Mylin

Avatar von Mylin

Anmeldungsdatum:
23. Juli 2024

Beiträge: 187

Dein Vorhaben sollte mit ../ funktionieren, damit kannst du dich auch bis ins Wurzelverzeichnis hoch hangeln.

Dakuan

(Themenstarter)
Avatar von Dakuan

Anmeldungsdatum:
2. November 2004

Beiträge: 6450

Wohnort: Hamburg

Ich habe das jetzt erstmal anders gelöst:

/tmp/core.%e.%p

Das funktioniert erst mal, ist aber nur ein Provisorium.

rklm Team-Icon

Projektleitung

Anmeldungsdatum:
16. Oktober 2011

Beiträge: 13075

Dakuan schrieb:

Ich habe das jetzt erstmal anders gelöst:

/tmp/core.%e.%p

Das funktioniert erst mal, ist aber nur ein Provisorium.

Nee, das ist genau das, was ich meinte. Ich weiß nicht, warum Du da mit Pipe-Symbol und Tilde gearbeitet hast. Die werden an dieser Stelle nicht interpretiert, soweit ich das sehe. Hast Du Dir die verlinkte Manpage angeschaut? Sonst mit man -s 5 core die aktuelle von Deinem System anschauen.

Dakuan

(Themenstarter)
Avatar von Dakuan

Anmeldungsdatum:
2. November 2004

Beiträge: 6450

Wohnort: Hamburg

Ich weiß nicht, warum Du da mit Pipe-Symbol und Tilde gearbeitet hast.

Das mit dem Pipe-Symbol war ich nicht. Das war Apport und das Programm ignoriert auch (meistens) Abstürze meiner Programme.

Mit der Tilde wollte ich erreichen, dass die Coredumps im Verzeichnis des jeweiligen Benutzers landen, da ich mehrere Benutzer eingerichtet habe.

Dakuan

(Themenstarter)
Avatar von Dakuan

Anmeldungsdatum:
2. November 2004

Beiträge: 6450

Wohnort: Hamburg

Update:

Eine generelle Lösung habe ich noch nicht gefunden, aber eine die temporär funktioniert. Dafür habe ich dieses Script erstellt, welches mit "sudo" aufgerufen werden muss:

1
2
3
4
5
6
7
8
9
#!/bin/bash
#   Freischalten eines coredumps und als Speicherort "/tmp/" festlegen.
if [ $UID -eq 0 ]; then
    echo "/tmp/core.%e.%p" > /proc/sys/kernel/core_pattern
    echo "1" > /proc/sys/kernel/core_uses_pid
    service procps start
else
    echo "Du bist nicht root!"
fi

Dummerweise reicht das noch nicht. Man muss dann noch in dem Terminal, in dem man die fehlerverdächtige Anwendung startet, folgendes eingeben:

ulimit -c unlimited

ansonsten ist das wirkungslos. Ich hätte mir eine bessere Lösung gewünscht.

Mein erster Erfolgsfall lief dann so:

manfred@samurai:~/prog/gui/videodb$ gdb ./vlist /tmp/core.vlist.11698
...
Reading symbols from ./vlist...fertig.
[New LWP 11698]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./vlist'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000000000041cea4 in XPlayerOptions::is_option (this=0x2037510, 
    str=0x24e5329 "%mirror=h") at XPlayerOptions.cpp:202
202	    while( *optr->name ) {
...

Die Eingabe von "bt" war nicht mehr erforderlich. Damit war in diesem Fall der Fehler schnell gefunden, die Länge des Vergleichsstrings war in der Tabelle fehlerhaft. Was wieder mal den Spruch meines Berufsvorgängers bestätigt "es ist immer einer mehr oder weniger als man denkt".

p.s. Ich finde es wenig zweckmäßig, dass Ubuntu die normal vorhandenen Fehler-Erkennungs Hilfsmittel so verbiegt, dass Ubuntu für Programmierer wenig geeignet ist. Die denken nur an ihre Vorteile und klammern alle anderen aus 👿

Humbi

Anmeldungsdatum:
14. Juni 2014

Beiträge: 74

Wenn es dir nur um die Ortung eines SEGV ging, warum benutzt du dann nicht Valgrind?

1
2
3
4
5
6
7
8
#include <stddef.h>

int main(void){
	char *test=NULL;

	while(*test){
	}
}
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
humbi@laptop:~$ gcc -Wall -Wextra -Werror -g test.c
humbi@laptop:~$ ./a.out 
Segmentation fault (core dumped)
humbi@laptop:~$ valgrind ./a.out 
==9929== Memcheck, a memory error detector
==9929== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==9929== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==9929== Command: ./a.out
==9929== 
==9929== Invalid read of size 1
==9929==    at 0x10913E: main (test.c:6)
==9929==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==9929== 
==9929== 
==9929== Process terminating with default action of signal 11 (SIGSEGV)
==9929==  Access not within mapped region at address 0x0
==9929==    at 0x10913E: main (test.c:6)
==9929==  If you believe this happened as a result of a stack
==9929==  overflow in your program's main thread (unlikely but
==9929==  possible), you can try to increase the size of the
==9929==  main thread stack using the --main-stacksize= flag.
==9929==  The main thread stack size used in this run was 8388608.
==9929== 
==9929== HEAP SUMMARY:
==9929==     in use at exit: 0 bytes in 0 blocks
==9929==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==9929== 
==9929== All heap blocks were freed -- no leaks are possible
==9929== 
==9929== For lists of detected and suppressed errors, rerun with: -s
==9929== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)

Wie du siehst wird dir Zeile 6 als Verursacher angezeigt.

Dakuan

(Themenstarter)
Avatar von Dakuan

Anmeldungsdatum:
2. November 2004

Beiträge: 6450

Wohnort: Hamburg

Es geht um mehr als nur um SIGSEGV. Das Programm, für das ich diese Änderung will, ist vor ca. 3 Wochen an einem Abend zweimal abgestürzt. Danach war Ruhe bis vorgestern. Da musste ich dann feststellen, dass das ulimit im Script unwirksam war (kein Coredump) und habe es deshalb raus genommen und zu Fuß eingegeben.

Der Absturz gestern passierte im einem anderen Programm aus der gleichen Sammlung. Und da ich dort nur eine Baustelle habe, hätte ich den Fehler auch so gefunden.

Ich betrachte den gestrigen Absturz als Bestätigung, dass die gezeigte Notlösung jetzt funktioniert, wünsche mir aber immer noch eine dauerhafte Lösung.

Und da beide Programme viel genutzt werden, ist Valgrind eher als Bremse anzusehen. Bei drei Wochen ohne Absturz müsste ich wohl auch sehr aufpassen, dass mir die Platte nicht voll läuft.

Antworten |