vmcore untersuchen

S

sunny

Member
Tag zusammen,

ich hatte heute die 2. panic in dieser Woche. Das gibt mir stark zu denken.
System: 6.0-RELEASE FreeBSD

/var/log/messages sagt:
Aug 6 15:13:01 sechole savecore: reboot after panic: page fault

Als ich die vmcore mit gdb untersuchen wollte kam folgendes:

Code: 
gdb /var/crash/vmcore.3
...
This GDB was configured as "i386-marcel-freebsd"..."/var/crash/vmcore.3": not in
 executable format: File format not recognized

Kann mir hier jemand weiterhelfen?

Danke und Viele Grüße
 
Was hast du denn für Programme am laufen? Ein page fault ist das was einer Zugriffsverletzung unter Windows (bluescreen) entspricht. Das lässt meißt auf ein fehlerhaftes Programm schließen, dass mit Pointern durcheinander gekommen ist (z.B. Objekte zerstört obwohl sie noch referenziert sind).
 
Hallo Kamikaze,
vielen Dank für deine Mühen.
Eigentlich läuft nicht viel. Bzw. nichts was nicht schon immer lief. Vor der ersten panic hatte ich ne uptime von > 100 Tagen. Es laufen immer die gleichen Programme.
dovecot, postfix, apache, mysql, sbnc (bouncer), vsftpd, tor...und das wars im großen und ganzen auch schon.
Hier mal ne ausgabe von top:
Code: 
 COMMAND
 dovecot
 mysqld
 perl5.8.8
 imap
 tor
 imap
 imap
 imap-login
 imap
 imap
 httpd
 imap-login
 imap-login
 dovecot-auth
 perl5.8.8
 sshd
 httpd
 sshd
 master
 top
 tcsh
 syslogd
 httpd
 cron
 tcsh
 vsftpd
 perl5.8.8
 sbnc
 qmgr
 httpd
 sh
 trivial-rewrite
 anvil
 vsftpd
 httpd
 httpd
 httpd
 usbd
 httpd
 silcd
 httpd
 getty
 httpd
 getty
 getty
 getty
 getty
 getty
 getty
 getty
 sshd
 devd
 vsftpd
 adjkerntz
 
[LoN]Kamikaze schrieb:
Ein page fault ist das was einer Zugriffsverletzung unter Windows (bluescreen) entspricht.
Zum Vergrößern anklicken....
Nein, das ist ein Segmentation Fault. Ein Page Fault dagegen tritt auf, wenn die angeforderte Speicherseite nicht im RAM liegt, sondern in den Swap ausgelagert wurde. Das ist kein Fehler im eigentlichen Sinne, sondern eine völlig normale Situation. Der Kernel muß lediglich diese Seite in den RAM laden und kann das Programm dann ganz normal fortsetzen. Dabei geht hier allerdings gründlich was schief. Das Problem liegt also nicht an den eingesetzten Programmen, sondern ausschließlich beim Kernel bzw. dessen VM-Subsystem.

sunny schrieb:
gdb /var/crash/vmcore.3
Zum Vergrößern anklicken....
gbd(1) ist der GNU-Debugger, der mit einem FreeBSD-Kernel-Dump nichts anfangen kann. Du benötigst dazu den FreeBSD-Kernel-Debugger, der heißt kgdb(1).
 
Ich dachte ein Segfault wäre wenn eine Speicheradresse nicht an der Wortlänge ausgerichtet ist und ein Page Fault wenn man auf eine Speicheradresse zugreift, die einem nicht (mehr) gehört.
 
Hallo 0815Chaot,

danke das sieht schon besser aus.
Code: 
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Unde
fined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd".
(no debugging symbols found)...Attempt to extract a component of a value that is
 not a structure pointer.
(kgdb) core-file /var/crash/vmcore.3
warning: "/var/crash/vmcore.3": no core file handler recognizes format, using de
fault
warning: you won't be able to access this core file until you terminate
your kernel core files.; do ``info files''
(kgdb) info files
Symbols from "/boot/kernel/kernel".
kernel core files.:
        `/var/crash/vmcore.3', file type elf32-i386-freebsd.
        0x00000000 - 0x0009f000 is load0
        0x00100000 - 0x3fffc000 is load1
Local core dump file:
        `/var/crash/vmcore.3', file type elf32-i386-freebsd.
        0x00000000 - 0x0009f000 is load0
        0x00100000 - 0x3fffc000 is load1
(kgdb)

Allerdings bin ich hier mit meinem Latein am Ende.
Kannst du mir paar commands an den Kopf werden wie ich weiter komme? :)

Viele Grüße
 
[LoN]Kamikaze schrieb:
Ich dachte ein Segfault wäre wenn eine Speicheradresse nicht an der Wortlänge ausgerichtet ist und ein Page Fault wenn man auf eine Speicheradresse zugreift, die einem nicht (mehr) gehört.
Zum Vergrößern anklicken....
Nein, das Ausrichten an Wortlängen ist ein plattformspezifisches Problem, das vom Compiler korrekt gehandhabt werden muß. Wenn der Compiler dabei fehlerhaften Code produziert, kann natürlich ein Segmentation Fault auftreten. Das ist aber nur eine mögliche Ursache für einen Segmentation Fault, und zudem schon eine ziemlich spezifische, die mir persönlich bisher bei keinem Compiler untergekommen ist. (Das heißt natürlich nicht, daß das nicht mal irgendeinem Compiler irgendwann mal passiert sein mag.)

Ganz allgemein passiert ein Segmentation Fault immer dann, wenn man auf Speicherbereiche zugreift, die man nicht (mehr) für sich reserviert hat und dementsprechend in diesen Speicherbereichen einfach nichts zu suchen hat. Dieses Problem hat der Anwendungsprogrammierer dann selbst verbockt, woraufhin der Kernel das Programm zwangsweise terminiert.

Ein Page Fault dagegen könnte etwa beim folgenden Code auftreten, wenn der Speicherbereich, auf den string verweist, zwischen den beiden Anweisungen in den Swap rausgeschrieben würde:
Code: 
char* string = malloc(sizeof("Hello World!"));
string = "Hello World!";
Dann müßte dieser Speicherbereich erst wieder in den RAM geschoben werden, damit die zweite Anweisung ausgeführt werden kann. Dies sollte normalerweise kein Problem sein, da bei einem Page Fault in den Kernel-Modus geschaltet wird und dieser die benötigten Speicherseiten reinkopiert. Anschließend wird das Programm fortgesetzt - es hat nichts von dem Page Fault mitbekommen.

Ein Page Fault ist also ein durch den Kernel reparabler "Fehler" und bei Systemen mit virtueller Speicherverwaltung ganz alltäglich. Wenn dabei was schiefgeht, liegt ein Fehler im Betriebssystem oder ein Hardwarefehler vor. Die Anwendung ist dabei unschuldig, denn sie kann das Paging gar nicht beeinflussen.

Ich möchte das Thema an dieser Stelle nicht weiter breittreten, da es dem OP nichts bringt, sondern eher auf passende Literatur (wie etwa "Modern Operating Systems" von Tanenbaum) verweisen.

sunny schrieb:
Kannst du mir paar commands an den Kopf werden wie ich weiter komme?
Zum Vergrößern anklicken....
Schau dir mal http://wwww.lemis.com/grog/Papers/Debug-tutorial/tutorial.pdf an, das ist IMO eine gute und umfassende Einführung in das Thema (ist übrigens vom Autor des Buches "The Complete FreeBSD").
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben