Ursache für SIGSEGV finden

21/12/2007 - 17:31 von Michel Strähl | Report spam
Hallo

ich habe ein Programm, welches unter bestimmten Bedingungen abstürzt,
kann aber leider den Grund dazu nicht herausfinden.
Vorausschickend noch folgende Infos:
- der Fehler ist jederzeit reproduzierbar (auch schon mal eine Hilfe)
- ich kann 2 unterschiedliche Szenarien verwenden, in einem Fall làuft
das Programm durch, im anderen Fall stürzt es ab
- in beiden Szenarien sind die Daten die gleichen (aus Oracle-DB 10g)
und im Prinzip der gleiche Sourcecode
- Unterschied liegt in der Tatsache, dass im 1. Fall es sich um ein
Binary mit Debug-Informationen handelt, im 2. Fall (mit dem Absturz)
um ein Binary ohne Debug-Information (strip-Befehl). Dieses Binary
wird dem Livesystem übergeben.

Da die Version, die den Absturz verursacht, diejenige ohne Debug-
Informationen ist, habe ich leider wenig Glück mit gdb, dbx oder einem
anderen gàngigen Debugger. Habe alles bereits ausprobiert. Das
abstürzende Programm liefert eine core dump, aber wie gesagt auch hier
scheitert die Analyse mit z.B. gdb.

Einziger Hinweis: wenn ich mit gdb den laufenden Prozess debugge,
erhalte ich folgende Meldung:
Program received signal SIGSEGV, Segmentation fault.
0x00196f30 in Compare_Date ()

Wie der Name der Funktion sagt, werden 2 Daten mit einander
vergleichen. Aber wo der Absturz ausgelöst wird, kann ich nicht
ermitteln.

Mit truss sehe ich folgende Informationen:
27165 2683: read(15, 0x0055ADE6, 2064) = 125
27166 2683: \0 }
\0\006\0\0\0\0\00602\001\0\0\001\0\0\0\0\0\0\0\0\0\00702C105
27167 2683: \b\00501F5 HA9\0\0\0\0\0\0\0
5\0\0\0\0\0\0\0\0\0\0\0\004\0\0\001
27168 2683: 04 m\0\0\001\0\0\0\0\0\0\0 5\0\003\0\0\0\0\0\0\0
yA8\0\v\0\0\0\v
27169 2683: \002\0\0\0\0\0 o
\0\0\0\0\001\0\0\0\0\0\0\0\0\0\0\0\0\0\0
27170 2683: Incurred fault #6, FLTBOUNDS %pc = 0x00196F30
27171 2683: siginfo: SIGSEGV SEGV_MAPERR addr=0x007C0000
27172 2683: Received signal #11, SIGSEGV [caught]
27173 2683: siginfo: SIGSEGV SEGV_MAPERR addr=0x007C0000
27174 2683: sigprocmask(SIG_SETMASK, 0xFF19CFC0, 0x00000000) = 0

und am Ende:
27193 2683: sigaction(SIGABRT, 0x00000000, 0xFFBE2AF0) = 0
27194 2683: llseek(0, 0, SEEK_CUR) = 4361
27195 2683: llseek(27, 0xFFFFFFFFFFFFF5CC, SEEK_CUR) = 5580
27196 2683: sigaction(SIGABRT, 0xFFBE2940, 0xFFBE2A40) = 0
27197 2683: sigprocmask(SIG_SETMASK, 0xFF1A8CE8, 0xFFBE2948) = 0
27198 2683: lwp_kill(1, SIGABRT) = 0
27199 2683: sigprocmask(SIG_SETMASK, 0xFFBE2948, 0x00000000) = 0
27200 2683: Received signal #6, SIGABRT [default]
27201 2683: siginfo: SIGABRT pid&83 uidp09448 code=-1
27202 2683: *** process killed ***

Dazwischen geschehen noch ein paar Cleanups auf der DB (Freigabe von
Locks)

FD 15 ist ein Socket:
15: S_IFSOCK mode:0666 dev:304,0 ino:38541 uid:0 gid:0 size:0
O_RDWR FD_CLOEXEC
sockname: AF_INET xx.xx.xxx.xxx port: 58532
peername: AF_INET xx.xx.xxx.xxx port: 1521

Anhand der Port-Nummer 1521 handelt es sich wohl um den DB-Connect zur
Oracle-DB

Wie kann ich nun heraus finden, an welcher Stelle das Programm
abstürzt? Das es in irgend welcher Form mit den Daten zu tun haben
könnte, ist mir klar. Nur nicht klar ist mir, bei welchen Befehl exakt
der Absturz erfolgt.

Vielen Dank im Voraus

Gruss
Michel
 

Lesen sie die antworten

#1 Markus Wichmann
21/12/2007 - 18:04 | Warnen spam
Michel Stràhl schrieb:
Hallo

ich habe ein Programm, welches unter bestimmten Bedingungen abstürzt,
kann aber leider den Grund dazu nicht herausfinden.
Vorausschickend noch folgende Infos:
- der Fehler ist jederzeit reproduzierbar (auch schon mal eine Hilfe)
- ich kann 2 unterschiedliche Szenarien verwenden, in einem Fall làuft
das Programm durch, im anderen Fall stürzt es ab
- in beiden Szenarien sind die Daten die gleichen (aus Oracle-DB 10g)
und im Prinzip der gleiche Sourcecode
- Unterschied liegt in der Tatsache, dass im 1. Fall es sich um ein
Binary mit Debug-Informationen handelt, im 2. Fall (mit dem Absturz)
um ein Binary ohne Debug-Information (strip-Befehl). Dieses Binary
wird dem Livesystem übergeben.

Da die Version, die den Absturz verursacht, diejenige ohne Debug-
Informationen ist, habe ich leider wenig Glück mit gdb, dbx oder einem
anderen gàngigen Debugger. Habe alles bereits ausprobiert. Das
abstürzende Programm liefert eine core dump, aber wie gesagt auch hier
scheitert die Analyse mit z.B. gdb.




Ah, so etwas hatte ich auch mal. Allerdings auf Windows und mit Pascal
in Verbindung mit DLLs. Letztlich stellte sich heraus, dass ich einen
Denkfehler beging, sodass auf uninitialisierte Variablen zugegriffen wurde.

Ansonsten: Passiert der Absturz auch, wenn du gleich ohne Debug-Infos
(ohne -g) kompilierst und den Strip bleiben làsst?
Einziger Hinweis: wenn ich mit gdb den laufenden Prozess debugge,
erhalte ich folgende Meldung:
Program received signal SIGSEGV, Segmentation fault.
0x00196f30 in Compare_Date ()

Wie der Name der Funktion sagt, werden 2 Daten mit einander
vergleichen. Aber wo der Absturz ausgelöst wird, kann ich nicht
ermitteln.




Debugge doch die Version _mit_ Debug-Info, wo alles ein Compare_Date
vorkommt. Dann suche die Gegend (im Code) nach undefiniertem Verhalten ab.

Mit truss sehe ich folgende Informationen:


^^^^^
Ist das so etwas wie strace?

27165 2683: read(15, 0x0055ADE6, 2064) = 125
27166 2683: \0 }
\0\006\0\0\0\0\00602\001\0\0\001\0\0\0\0\0\0\0\0\0\00702C105
27167 2683: \b\00501F5 HA9\0\0\0\0\0\0\0
5\0\0\0\0\0\0\0\0\0\0\0\004\0\0\001
27168 2683: 04 m\0\0\001\0\0\0\0\0\0\0 5\0\003\0\0\0\0\0\0\0
yA8\0\v\0\0\0\v
27169 2683: \002\0\0\0\0\0 o
\0\0\0\0\001\0\0\0\0\0\0\0\0\0\0\0\0\0\0
27170 2683: Incurred fault #6, FLTBOUNDS %pc = 0x00196F30
27171 2683: siginfo: SIGSEGV SEGV_MAPERR addr=0x007C0000
27172 2683: Received signal #11, SIGSEGV [caught]
27173 2683: siginfo: SIGSEGV SEGV_MAPERR addr=0x007C0000
27174 2683: sigprocmask(SIG_SETMASK, 0xFF19CFC0, 0x00000000) = 0




Er stürzt direkt nach einem DB-Zugriff ab.

und am Ende:
27193 2683: sigaction(SIGABRT, 0x00000000, 0xFFBE2AF0) = 0
27194 2683: llseek(0, 0, SEEK_CUR) = 4361
27195 2683: llseek(27, 0xFFFFFFFFFFFFF5CC, SEEK_CUR) = 5580
27196 2683: sigaction(SIGABRT, 0xFFBE2940, 0xFFBE2A40) = 0
27197 2683: sigprocmask(SIG_SETMASK, 0xFF1A8CE8, 0xFFBE2948) = 0
27198 2683: lwp_kill(1, SIGABRT) = 0
27199 2683: sigprocmask(SIG_SETMASK, 0xFFBE2948, 0x00000000) = 0
27200 2683: Received signal #6, SIGABRT [default]
27201 2683: siginfo: SIGABRT pid&83 uidp09448 code=-1
27202 2683: *** process killed ***




Da hat er dann wohl zu lange an dem SIGSEGV gerechnet und der Kernel
verlor die Geduld.

Dazwischen geschehen noch ein paar Cleanups auf der DB (Freigabe von
Locks)

FD 15 ist ein Socket:
15: S_IFSOCK mode:0666 dev:304,0 ino:38541 uid:0 gid:0 size:0
O_RDWR FD_CLOEXEC
sockname: AF_INET xx.xx.xxx.xxx port: 58532
peername: AF_INET xx.xx.xxx.xxx port: 1521

Anhand der Port-Nummer 1521 handelt es sich wohl um den DB-Connect zur
Oracle-DB




Und Port 58532 werden wohl die Daten sein, oder?

Wie kann ich nun heraus finden, an welcher Stelle das Programm
abstürzt? Das es in irgend welcher Form mit den Daten zu tun haben
könnte, ist mir klar. Nur nicht klar ist mir, bei welchen Befehl exakt
der Absturz erfolgt.

Vielen Dank im Voraus

Gruss
Michel



HTH,
Markus
Was haben eigentlich alle gegen Beamte? Die tun doch nichts!

Ähnliche fragen