Skript + "gdb" ?

Seite 1 von 1 - Forum: Linux and other OS auf overclockers.at

URL: https://www.overclockers.at/linux/skript-gdb_237498/page_1 - zur Vollversion wechseln!

Hansmaulwurf schrieb am 08.01.2014 um 14:34

Hiho,
Ich bin gerade am verzweifeln. Folgendes Setup : Matlab über VNC, auf einem CentOS-Server.

MATLAB schmiert bei Benutzer A ab, bei Benutzer B mit den selben Rechten läuft es wie geschmiert. Das Problem, es aktualisiert GUI, ich seh den eingabe-Balken kurz blicken dann steckts.

Ok, geh ich den /bin folder und versuch es mit "-verbose", gibt's keinen Fehler. (Gab vorher nen Font-Fehler den ich gefixed hab). Dann wollt ich es mit gdb probieren. Denkste, ist ein Skript.

Kann ich irgendwie rausfinden welche commandos das script wirklich launched ? (damit ich das dann mit gsb anschauen kann) Bzw das Skript debuggen ?

GrandAdmiralThrawn schrieb am 08.01.2014 um 15:39

Jo, kannst, indem du das Matlab Launcher Skript mit einem Texteditor öffnest. Das nette kleine Skript hat aber fast 2000 Lines of Code, daher würde ich davon absehen, und zuerst Mal versuchen, die lokalen Settings des betroffenen Users zu enfernen. Nach Sicherstellen daß der betroffene User Matlab grade sicher nicht laufen hat vielleicht so:

su - <user>
mv .matlab .matlab-broken
exit

Dann den User anweisen, Matlab neu zu starten. Vielleicht ist nur was an der userspezifischen Config zerrissen, wär bei Matlab nicht das erste Mal, daß sowas passiert.

Wär zumindest mein erster Ansatz, heißt natürlich noch lange nicht, daß ich auch richtig liege.

Hansmaulwurf schrieb am 08.01.2014 um 15:43

Zitat von GrandAdmiralThrawn
Dann den User anweisen, Matlab neu zu starten. Vielleicht ist nur was an der userspezifischen Config zerrissen, wär bei Matlab nicht das erste Mal, daß sowas passiert.

Wär zumindest mein erster Ansatz, heißt natürlich noch lange nicht daß ich richtig liege.

Wurde schon gelöscht, neu erstellt, von einem anderem User probiert

Ich hab jetzt via "bash +vx matlab" (sh-skript debuggen) rausgefunden welche Datei er called, und wenn ich nur die (ohne Argumente) ausführ, erhalte ich das selbe Ergebnis wie bei dem skript. Soweit so gut

Nur streikt jetzt der gdb auf dem kompilierten binary, weil es multithreaded ist, einer der Threads nen SIGSEGV bekommt, und gdb es nicht schafft auf die Adresse von Thread #2 zu springen. *grr*

edit:
Es gibt n ähnliches Problem mit macosx, ich probier mal ein java-downgrade.

GrandAdmiralThrawn schrieb am 08.01.2014 um 16:03

Hmm, ich fürchte das übersteigt dann meine Kenntnisse. Vielleicht hast noch ein Core Dump File, daß sich analysieren ließe? Sollte es ja fast geben, wennst segfault kriegst. Sowas hab ich aber noch nie machen müssen (zum. nicht für *nix Core Dumps), kA wie schwer es ist, auf diesem Weg mit z.B. objdump was rauszufinden.

Ein Problem wie von dir beschrieben hatte ich noch nie, trotzdem viele User hier bei uns immer wieder Matlab eingesetzt haben, ebenfalls auf CentOS (5 & 6, x86_32 & x86_64), und tlw. auch via VNC.

Vielleicht kann es auch helfen, das Binary per strace oder ltrace aufzurufen um mehr zu erfahren.

Hansmaulwurf schrieb am 08.01.2014 um 16:52

Strace auf die binary und es lauft durch. Ich glaub ich werd verrückt.

Thx, ich hab mal eine Lösung aber warum weiß ich nicht..
[Werd ich mir morgen in Ruhe ansehen]

Ringding schrieb am 08.01.2014 um 22:37

Mit core dump ist’s für’s erste mal am einfachsten. Mach ein ulimit -c unlimited und wirf’s an. Dann mach gdb <binary> <core-file>. bt gibt dir dann zumindest einen schönen Backtrace, und gdb sagt dir auch, woran der Prozess gestorben ist.

Taltos schrieb am 09.01.2014 um 10:01

hast den matlab support schon genervt? ihr zahlt ja auch für die software, vielleicht wissen die wo's hakt?

GrandAdmiralThrawn schrieb am 09.01.2014 um 14:51

Stimmt, Mathworks könnte man noch fragen, hab ich auch schon Mal gemacht wegen irgendeinem Problem, und die Hilfe war sogar recht kompetent. Ich weiß nicht mehr was genau da war, aber eine Option wär das auch so nebenher..