Diese Seite ist unverschlüsselt! Um sicherzustellen, das Ihr Passwort nicht ausgelesen werden kann, sollten Sie auf die verschlüsselte Seite wechseln!

    Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » C / C++ (GNU/Linux, *NIX, *BSD und Co) » Segfault auf Kernel-Level?
Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: > 1 <
000
03.03.2009, 16:07 Uhr
nAvi



 Hallo, wir entwickeln gerade ein Stueck Software und benutzen als Bibliotheken Boost-Serialization, Boost-MPI, MPI und ParMetis.

Wie das mit C++ halt so ist, bekommen wir ab und an einen Segfault.
Wir haben einen automatisierten Kompilierlauf mit anschliessenedem Test.
Dort fangen wir alles, was ein Testprogramm ausgibt ab mit:


Code:
if [ true ]; then
    EXEC XXX
fi &> log


Damit hatten wir bis jetzt auch alle Seqfaults in den Logs.
Nun bin ich ueber einen Fehler gestolpert, der weit fieser ist. Im Log taucht nichts auf, keine Meldung von einem Fehler, nichts vom OS.

Wir haben uns echt gewundert was da passiert und warum der Test sich so still und leise verabschiedet, bis ich im dmesg das hier gefunden habe:


Code:
check_indexset[8577]: segfault at 0000000000000008 rip 00000000009c2108 rsp 00007fff319a7e80 error 4
initial_deploym[8756]: segfault at 0000003e000000f8 rip 0000000000cfd06b rsp 00007fffe86b59e0 error 4
initial_deploym[8776]: segfault at 0000003e000000f8 rip 0000000000cfd05b rsp 00007fff9c850b80 error 4
--snip--
check_indexset[24773]: segfault at 0000000000000008 rip 00000000009c2108 rsp 00007fff6cc38660 error 4
initial_deploym[24936]: segfault at 0000003d64697267 rip 0000000000d18de6 rsp 00007fff5f49c900 error 4
initial_deploym[24952]: segfault at 0000003d64697267 rip 0000000000d18de6 rsp 00007fff94ae4f50 error 4
check_indexset[10717]: segfault at 0000000000000008 rip 00000000009fa128 rsp 00007fffa912baf0 error 4
initial_deploym[15588]: segfault at 0000010100000101 rip 0000000001063d16 rsp 00007fff3ab8e040 error 4
initial_deploym[15605]: segfault at 0000010100000101 rip 0000000001063b66 rsp 00007fff1df3e3f0 error 4
check_indexset[15758]: segfault at 0000000000000008 rip 00000000009fa128 rsp 00007fff477ec1b0 error 4
initial_deploym[15909]: segfault at 0000010100000101 rip 0000000001063d16 rsp 00007fff35481930 error 4
initial_deploym[15926]: segfault at 0000010100000101 rip 0000000001063b66 rsp 00007fff65fa9460 error 4
check_indexset[28255]: segfault at 0000000000000008 rip 00000000009fbec8 rsp 00007fffad9df3f0 error 4
initial_deploym[28408]: segfault at 0000000000000002 rip 0000000000e2f94e rsp 00007fff00b4e410 error 4
initial_deploym[28425]: segfault at 0000000000000002 rip 0000000000e2f94e rsp 00007fff9ba9aea0 error 4


check_indexset und initial_deployment sind unsere Programme.
Was fuer ein Fehler muss auftreten, dass er hier ausgegeben wird und gar gar nichts auf der Shell. Ich bin echt ratlos.

Meine Vermutung ist fast, dass bei Boost und MPI mit der Kommunikation was schieflaeuft.

Wie kann man hier zur Quelle des Fehlers kommen?

Danke im Voraus.

navimarin


Bearbeitung von FloSoft:

unnötigen output gelöscht (die ethernet-meldungen dürfte nichts zu tun haben) und codetags gefixt

--
Lebe als wolltest du täglich sterben
Dieser Post wurde am 03.03.2009 um 18:35 Uhr von FloSoft editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
001
03.03.2009, 18:34 Uhr
FloSoft
Medialer Over-Flow
(Administrator)


Hi,

das ist normal, da dürfte kernel-auditing (oder debugging?) ansein, dann meldet er segfaults u.ä auch im kernel-log, ist also kein problem, außer das eben eure Anwendungen Fehler haben und auf Speicher zugreifen die ihnen nicht gehört.

Ansonsten geht euch so nur stdout ins log, nicht stderr (wo normalerweise dann "segmentation fault, blablubb" kommt)


Code:
fi 2>&1 &> log

--
class God : public ChuckNorris { };
Dieser Post wurde am 03.03.2009 um 18:36 Uhr von FloSoft editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
002
03.03.2009, 19:47 Uhr
nAvi



 Soweit ich weiß ist &> in der bash ein Catchall? Ich bekomme damit zumindest std::cout und std::cerr. In anderen Shells weiß ich das nicht, die tcsh lässt &> glaube ich gar nicht zu.

Die Ethernetausgaben wurden ja leider entfernt. Ich bin mir nicht so sicher, ob das nicht auch zu dem Problem gehlört. Laut Kernelheader besagt die Meldung, dass zu viele Pakete verschickt werden sollen.
Boost.MPI ist für die Kommunikation der serialisierten Objekte zuständig. In welche Größe die Daten zerhackt werden um Pakete zu erstellen weiß ich nicht, da es mehrere GB Daten sind können es potentiell auch viele Pakete werden.

Mich macht nur stutzig, dass keinerlei Ausgabe in der Shell kommt, sondern nur im Kernel-Log die Segfaults. Das ist mir bis jetzt bei einem C++-Programm, dass nicht als Deamon oder im Kernel-Mode läuft noch nicht unter gekommen. Ich weiß nicht auf welcher Seite ich den Fehler suchen soll. In unserem Code, bei den Libs (Boost, MPI) oder im OS.
--
Lebe als wolltest du täglich sterben
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
003
03.03.2009, 22:27 Uhr
FloSoft
Medialer Over-Flow
(Administrator)


ah okay, das mit dem &> wusste ich nicht.

naja,
evtl fängt boost und co die segfaults intern ab, was aber trotz allem eben eine meldung im kernel-log erzeugt, rettet aber das programm anscheinend ohne es zu terminieren. die Meldung im kernel-log ist natürlich da, da ja eine speicherverletztung auftritt, und das das OS ja mitkriegt und behandelt.

Oh und ich hab anscheinend versehentlich alle rausgemacht, dachte ich hatte eine dringelassen (evtl postest du nochma eine zeile davon)

Normalerweise sollte das ganze ja kein Problem sein, solang du den Socketsendepuffer nicht überlastest (sonst droppt er ja pakete/daten) evtl solltest du eine Regelung/Drosselung der Datenrate deiner Übertragungen anpassen, oder wenn alles auf einem Rechner läuftüber unix-pipes (o.ä) lösen, da kann man normalerweise etwas "höhere" datenraten erreichen
--
class God : public ChuckNorris { };
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
004
03.03.2009, 22:50 Uhr
nAvi



 Auf der anderen Seite dürfte das mit der Netzwerkkarte nichts machen. Wir rechnen nur auf den 4 Kernen des Rechners, damit läuft die Kommunikation ja über das Loopback-Device.

Boost kann den Segfault doch gar nicht fangen. Die Speicherverletzung stellt doch das OS fest und tötet den Prozess (kill). Da kann Boost oder MPI gar nicht dazwischen krätschen. Es gibt ja die Möglichkeit C++ zwei Funktionen zu übergeben. terminate() und unexpected(). Damit kann man aber nur Exceptions abfangen. Das Signal kill kann meines Wissens nach nicht umgangen werden. Deshalb wundert es mich umso mehr, dass wir keine Ausgabe bekommen.

Langsam habe ich keine Lust mehr auf das Projekt. Wir haben es schon geschafft den Intel-Compiler mit einem Segfault in die Knie zu zwingen. Oder dass sich sein Backend einfach beendet. Der gcc hat sich auch schon einfach ohne Fehler verabschiedet. Naja, back to the topic.

Mir fehlt echt tieferes Wissen in Sachen Fehlerbehandlung auf Linux vom Kernel. Hat jemand eine Idee wie ich zumindest an einen Stacktrace komme?
--
Lebe als wolltest du täglich sterben
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
005
03.03.2009, 23:07 Uhr
0xdeadbeef
Gott
(Operator)


Bei einer Speicherverletzung wird ein SIGSEGV geschmissein, kein SIGKILL. Prinzipiell kannst du darauf in einem signal handler reagieren, bei SIGSEGV ist das aber eine ziemlich haarige Angelegenheit.

Besser wär, du kompiliertest das ganze mit Debugsymbolen (-g beim gcc) und jagst es durch gdb. Etwa so:

bash:

user@machine:~$ cat -n test.cc
     1  void f() {
     2    int *p = 0;
     3    *p = 123; // NEEEEEEIIIIN!
     4  }
     5
     6  void g() {
     7    f();
     8  }
     9
    10  int main() {
    11    g();
    12  }
user@machine:~$ g++ -Wall -Wextra -pedantic -ansi -g test.cc
user@machine:~$ gdb ./a.out
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
(gdb) run
Starting program: /home/user/a.out

Program received signal SIGSEGV, Segmentation fault.
0x000000000040057c in f () at test.cc:3
3         *p = 123; // NEEEEEEIIIIN!
(gdb) backtrace
#0  0x000000000040057c in f () at test.cc:3
#1  0x000000000040058d in g () at test.cc:7
#2  0x0000000000400598 in main () at test.cc:11
(gdb) quit
The program is running.  Exit anyway? (y or n) y
user@machine:~$


--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra
Dieser Post wurde am 03.03.2009 um 23:12 Uhr von 0xdeadbeef editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
006
03.03.2009, 23:51 Uhr
nAvi



 Ok, dann teste ich das mal.

Danke soweit.
--
Lebe als wolltest du täglich sterben
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: > 1 <     [ C / C++ (GNU/Linux, *NIX, *BSD und Co) ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: