Häufige Erstellung von Core Dateien sind nervend, wie abstellen?

Die Ursache war vermutlich, dass der user nicht in der class "staff" war. Dadurch haben die gesetzten limits nicht gegriffen und daher die coredumps. Nun ist der user in der class "staff" und die coredumps sollten der Vergangenheit angehoeren.
 
CrimsonKing schrieb:
"Keine Coredatei" und "läuft einwandfrei" ist nach dem Abschalten von Coredateien eine Gleichsetzung, mit der ich persönlich sanfter umgehen würde.
Zum Vergrößern anklicken....
Da stimme ich Dir natürlich voll umfänglich bei. Aber auch bei FreeBSD gab es hier oder da mal Probleme, und core Dateien beim Gnome Desktop waren an der Tagesordnung. Auch da habe ich mir geholfen, indem das in der sysctl.conf mit kern.coredump=0 unterbunden wurde. Meine technischen Kenntnisse sind nicht ausreichend, um ein Betriebssystem oder einzelne fertige Binärpakete zu debuggen. Wer es kann und über diese Fähigkeit verfügt, Hut ab, ich kann es nicht.
 
Columbo0815 schrieb:
ch würde auch nach der Ursache für die Coredumps suchen anstatt sie einfach abzuschalten und mir damit "vorzugaukeln", dass alles gut wäre. Bei Thunar erinnere ich mich an einen Bug - wohl betriebssystemübergreifend - der Thunar zum Absturz brachte, wenn man zB Dateien umbenennt. Ich habe jetzt aber nicht geprüft, welche Version von Thunar in OpenBSD 6.3 ist.
Zum Vergrößern anklicken....
Ja, das wäre im Idealfall so. Das Umbenennen von Ordnern funktioniert bei mir mit der aktuellen Thunar Version fehlerfrei. Dennoch habe ich den Verdacht, das Thunar schon noch ein bißchen verbuggt ist, auch wenn ich das nicht mit Fakten belegen oder beweisen kann. Nautilus hat zumindest bei mir diese Probleme nicht.

Columbo0815 schrieb:
Wobei ich jetzt nicht weiß, ob du das mit der Deaktivierung der Coredumps rückgängig gemacht hast und dennoch Ruhe ist.
Zum Vergrößern anklicken....
Das habe ich eben ausprobiert und er wirft wieder Core Dateien, zumindest bei smtube. Also ich kann mit diesen Einstellungen leben und habe ansonsten keine Einschränkungen in der Funktionalität von smtube oder Thunar bemerkt.
 
midnight schrieb:
Die Ursache war vermutlich, dass der user nicht in der class "staff" war. Dadurch haben die gesetzten limits nicht gegriffen und daher die coredumps. Nun ist der user in der class "staff" und die coredumps sollten der Vergangenheit angehoeren.
Zum Vergrößern anklicken....
Auch das kann ich leider nicht bestätigen. Aber es ist durchaus möglich, das Thunar keine Core Dateien mehr erzeugt und smtube immer noch und das Problem in smtube selbst liegt. Da hatte ich auch früher unter anderen OS schon meine Probleme mit. Ansonsten funktioniert es jetzt und die nervigen Core Dateien gehören der Vergangenheit an. Mehr kann ich nicht erwarten. Und ich finde trotzdem, das das schon eine Menge ist.
 
Koenntest Du mal probieren, smtube aus dem Terminal heraus aufzurufen? Evtl. werden hier Fehlermeldungen angezeigt?
 
midnight schrieb:
Koenntest Du mal probieren, smtube aus dem Terminal heraus aufzurufen? Evtl. werden hier Fehlermeldungen angezeigt?
Zum Vergrößern anklicken....
Gerne hier die Ausagbe:

Code: 
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-ralph'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-ralph'
Translations path: "/usr/local/share/smtube/translations"
Sig::load
Sig::load
BrowserWindow::loadConfig
DesktopInfo::isInsideScreen: geometry of screen: x:0 y:0 w:2560 h:1440
BrowserWindow::loadConfig: cache enabled. Location: "/home/ralph/.cache/smtube"
Players::load
Players::availablePlayers: 0 : "/usr/local/bin/mpv"
Players::availablePlayers: 1 : "/usr/local/bin/smplayer"
Players::availablePlayers: 2 : "/usr/local/bin/smplayer"
Players::availablePlayers: 3 : "/usr/local/bin/smplayer"
Players::availablePlayers: 4 : "/usr/local/bin/mplayer"
Players::availablePlayers: 9 : "/usr/local/bin/mpv"
MyCookieJar::load
MyCookieJar::load: 1 cookies loaded
BrowserWindow::adjustLocation: "http://www.tonvid.com/"
BrowserWindow::finishLoading: url: "http://www.tonvid.com/"
BrowserWindow::finishLoading: add_download_button: false
BrowserWindow::finishLoading: external_download_url: "http://www.dlvyoutube.com/%YT_URL%"
BrowserWindow::saveConfig
Players::save
MyCookieJar::save
MyCookieJar::save: "country"
Segmentation fault

Diese Meldung:

Code: 
XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-ralph'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-ralph'

habe ich auch regelmäßig, wenn ich ein Qt5 Programm compiliere im Qtcreator.

Code: 
Segmentation fault

wird wohl erzeugt, nach dem Beenden von smtube, und das wird wohl auch die Core Datei erzeugen.
 
Ich finde, "startet nicht" ist schon eine gewisse Einschränkung der Funktionalität.
 
CrimsonKing schrieb:
Ich dachte, smtube schmeiße weiterhin einen segfault?
Zum Vergrößern anklicken....
Aber nicht beim Starten, sondern beim Beenden des Programms. Wäre das beim Starten, würde das Programm ja abstürzen, es läuft und funktioniert aber ganz normal, bis ich es beende. Danach wird die Core Datei erzeugt.
 
x11/qt5/qtwebkit scheint hier der Ueberlaeter zu sein. Von den segmentation fault sind laut mailingliste auch andere tools, wie z.B. der otter-browser oder der mailclient trojita, betroffen.
 
midnight schrieb:
x11/qt5/qtwebkit scheint hier der Ueberlaeter zu sein. Von den segmentation fault sind laut mailingliste auch andere tools, wie z.B. der otter-browser oder der mailclient trojita, betroffen.
Zum Vergrößern anklicken....
Danke, das erklärt ja einiges, denn ich wollte mir für dokuwiki einen eigenen kleinen Browser mit qtwebkit unter Qt 5.9.4 erstellen, was relativ einfach ist, weil es webkit ja als Widget gibt. Und genau stürzt es nach dem Compilieren im Qtcreator mit dem selben Fehler ab. Mit einer älteren Qt Version unter FreeBSD passiert das nicht, denn da habe ich den Browser fertig stellen können. Ja, es klärt sich alles irgendwie auf, wenn man nur hartnäckig genug am Ball bleibt. Nicht immer bringe ich die Geduld auf ..... aber immer öfter.:)
 
Der zweite Übeltäter ist auch nicht Thunar, sondern in Wirklichkeit Mousepad. Habe nochmals

Code: 
:coredumpsize=0:\

rausgenommen und Thunar in der Konsole gestartet. Häufiges Umbenennen kein Problem mehr, aber wenn ich eine neue Datei anlege und probehalber ein paar Zeilen hinein schreibe, dann die Datei im Thunar anklicke, so das sie mit Mousepad geöffnet wird und dann wieder schließe, wird ein core file erzeugt und Thunar an den Pranger gestellt, obwohl einwandfrei Mousepad der Auslöser war.

Code: 
(mousepad:63044): GLib-CRITICAL **: g_variant_new_string: assertion 'string != NULL' failed

(mousepad:63044): GtkSourceView-CRITICAL **: gtk_source_style_scheme_get_id: assertion 'GTK_IS_SOURCE_STYLE_SCHEME (scheme)' failed
Bus error (core dumped)

Na, ich werde wohl mal gedit installieren.
 
Habe leafpad installiert, stürzt auch ab. Dann nautilus und gedit, die Abhängigkeiten sind gering. Und siehe, es isr Ruhe und läuft wie es soll. So damit ist für mich die Angelegenheit erledigt.
 
Nothing is perfect! :cool:

Bei mir stürzt der jwm beim Aufruf von xpat2 reproduzierbar ab - alle anderen wm starten dieses wichtige Programm ohne Probleme.
Also muss jetzt openbox ran.
 
berni51 schrieb:
Nothing is perfect! :cool:

Bei mir stürzt der jwm beim Aufruf von xpat2 reproduzierbar ab - alle anderen wm starten dieses wichtige Programm ohne Probleme.
Also muss jetzt openbox ran.
Zum Vergrößern anklicken....
So ist es, aber openbox ist ja jahrelang erprobt und wirklich gut. Mir zeigt es nur erneut, das ich für was für einen WIndowmanager auch immer, keine Empfehlung abgeben kann. Was bei dem einen stabil läuft, zickt bei einem anderen rum, man kann gezielt den Fehler suchen, aber das ist oft zu zeitaufwendig. Zumeist nimmt man das dann, was einfach funktioniert und läuft. Zur Zeit probiere ich KDE 4 unter OpenBSD 6.3 aus, werde später mal in einem gesonderten Thread darüber berichten.
 
Das würde mich interessieren, ralli. Allein um zu wissen, ob das OpenBSD damit unerträglich langsam wird oder nicht.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben