Sofortiger Segmentation Fault bei Programmstart (gelöst)

Vom einfachen Programm zum fertigen Debian-Paket, Fragen rund um Programmiersprachen, Scripting und Lizenzierung.
Antworten
WalDHeiNi
Beiträge: 6
Registriert: 06.10.2009 22:19:06

Sofortiger Segmentation Fault bei Programmstart (gelöst)

Beitrag von WalDHeiNi » 06.10.2009 22:54:24

Hallo zusammen,

ich möchte eine von mir entwickelte Software von einem Windows XP auf mein Debian System portieren (Kernel 2.6.26-2.686). Vorher kompiliere ich es mit dem g++ (4-3-2) ohne Probleme. Die Portabilität wird durch Einsatz von Qt 4.5.1 und ACE erreicht (hat in früheren Versionen meiner Software schon funktioniert)

Nach dem Start erhalte ich sofort einen Segmentation Fault. :roll:
Kann passieren... Aber:
Wenn ich mit einer leeren main() Funktion (d.h. nichts außer einem return 0, alle includes raus) kompiliere und starte erhalte ich weiterhin einen Segmentation Fault.

Ein Backtrace des gdb sagt mir folgendes:

Code: Alles auswählen

#0  0x0811a3db in std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::overflow ()
#1  0xb6eb7313 in std::basic_streambuf<char, std::char_traits<char> >::sputc () from /usr/lib/libstdc++.so.6
#2  0x0811a48a in std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::overflow ()
...
Das geht so "unendlich" weiter. Bei einem strace sind die letzten Zeilen:

Code: Alles auswählen

mmap2(NULL, 79678, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f5a000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/i686/cmov/libmkl_def.dylib", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/i686/libmkl_def.dylib", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/libmkl_def.dylib", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/i686/cmov/libmkl_def.dylib", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/i686/libmkl_def.dylib", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/sse2/libmkl_def.dylib", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/libmkl_def.dylib", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/i486-linux-gnu/libmkl_def.dylib", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/i486-linux-gnu/libmkl_def.dylib", O_RDONLY) = -1 ENOENT (No such file or directory)
munmap(0xb7f5a000, 79678)               = 0
open("/sys/devices/system/cpu", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
fcntl64(3, F_GETFD)                     = 0x1 (flags FD_CLOEXEC)
getdents64(3, /* 7 entries */, 4096)    = 200
getdents64(3, /* 0 entries */, 4096)    = 0
close(3)                                = 0
open("/sys/devices/system/cpu", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
getdents64(3, /* 7 entries */, 4096)    = 200
getdents64(3, /* 0 entries */, 4096)    = 0
close(3)                                = 0
futex(0xb6f546fc, FUTEX_WAKE_PRIVATE, 2147483647) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Mich wundert dabei die Missglückten open() bzw. access() Aufrufe. Ich kenne mich leider nicht so gut mit strace aus und die libmkl_def.dylib kenne ich auch nicht..

Ich habe die Software jetzt mit einer virtuellen Maschine (virtual box) und mit einem Rechner mit Intel I7 Quad Core, mit einem Desktop Board DX 58 SO, mit 3 GByte RAM und bin in beiden Fällen zum selben Ergebniss gekommen.

Hat jemand soetwas schon einmal erlebt oder hat weitere Ideen zum debuggen? Wäre für jede Idee dankbar... :hail:
Zuletzt geändert von WalDHeiNi am 19.10.2009 11:31:30, insgesamt 1-mal geändert.

uname
Beiträge: 12424
Registriert: 03.06.2008 09:33:02

Re: Sofortiger Segmentation Fault bei Programmstart

Beitrag von uname » 07.10.2009 10:52:31

Habe lange nicht mehr programmiert. Aber hast du schon mal einen Debugger wie

http://packages.debian.org/lenny/ddd

probiert?

Benutzeravatar
GoKi
Beiträge: 2068
Registriert: 04.07.2003 23:08:56
Lizenz eigener Beiträge: MIT Lizenz

Re: Sofortiger Segmentation Fault bei Programmstart

Beitrag von GoKi » 07.10.2009 11:11:15

uname hat geschrieben:Aber hast du schon mal einen Debugger wie
Er nutzt GDB.

Gegen welche Libraries linkst Du? Evtl geht der Backtrace in den Code einer Library.
bspw. liefert ldd für ein Hello World in C++

Code: Alles auswählen

$ ldd hello 
	linux-gate.so.1 =>  (0xb7fbd000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7eb0000)
	libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7e89000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7e7a000)
	libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d17000)
	/lib/ld-linux.so.2 (0xb7fbe000)
MfG GoKi
:wq

WalDHeiNi
Beiträge: 6
Registriert: 06.10.2009 22:19:06

Re: Sofortiger Segmentation Fault bei Programmstart

Beitrag von WalDHeiNi » 07.10.2009 19:52:52

Hi,

ein ldd liefert:

Code: Alles auswählen

	linux-gate.so.1 =>  (0xb7ee4000)
	libACE.so.5.6.0 => /home/stephan/lib/ACE/lib/libACE.so.5.6.0 (0xb7d50000)
	libcv.so.1 => /home/stephan/lib/OpenCV_100/lib/libcv.so.1 (0xb7c7d000)
	libcxcore.so.1 => /home/stephan/lib/OpenCV_100/lib/libcxcore.so.1 (0xb7b67000)
	libhighgui.so.1 => /home/stephan/lib/OpenCV_100/lib/libhighgui.so.1 (0xb7b42000)
	libQtCore.so.4 => /usr/local/Trolltech/Qt-4.5.1/lib/libQtCore.so.4 (0xb7903000)
	libQtGui.so.4 => /usr/local/Trolltech/Qt-4.5.1/lib/libQtGui.so.4 (0xb6f13000)
	libQtXml.so.4 => /usr/local/Trolltech/Qt-4.5.1/lib/libQtXml.so.4 (0xb6ecf000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb6de0000)
	libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb6dba000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6dad000)
	libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb6c52000)
	libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb6c39000)
	libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb6b7f000)
	libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb6b7a000)
	librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb6b71000)
	libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb6b6c000)
	libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb67e1000)
	libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb675b000)
	libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb673f000)
	libpangoxft-1.0.so.0 => /usr/lib/libpangoxft-1.0.so.0 (0xb6738000)
	libpangox-1.0.so.0 => /usr/lib/libpangox-1.0.so.0 (0xb672d000)
	libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb66ed000)
	libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb66d5000)
	libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb6698000)
	libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb6694000)
	libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb65df000)
	libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb65bb000)
	libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb659c000)
	libz.so.1 => /usr/lib/libz.so.1 (0xb6587000)
	libtiff.so.3 => /usr/lib/libtiff.so.3 (0xb6532000)
	libjasper-1.701.so.1 => /usr/lib/libjasper-1.701.so.1 (0xb64e2000)
	libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb646d000)
	libSM.so.6 => /usr/lib/libSM.so.6 (0xb6465000)
	libICE.so.6 => /usr/lib/libICE.so.6 (0xb644e000)
	libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb6445000)
	libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb6419000)
	libXext.so.6 => /usr/lib/libXext.so.6 (0xb640b000)
	libX11.so.6 => /usr/lib/libX11.so.6 (0xb631c000)
	/lib/ld-linux.so.2 (0xb7ee5000)
	libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb6312000)
	libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xb630f000)
	libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb630b000)
	libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb6306000)
	libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb629a000)
	libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb6297000)
	libXi.so.6 => /usr/lib/libXi.so.6 (0xb628f000)
	libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb6288000)
	libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb627f000)
	libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb6258000)
	libXft.so.2 => /usr/lib/libXft.so.2 (0xb6245000)
	libpcre.so.3 => /usr/lib/libpcre.so.3 (0xb621c000)
	libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb61f5000)
	libXau.so.6 => /usr/lib/libXau.so.6 (0xb61f2000)
	libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0xb61f0000)
	libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb61d8000)
	libdirectfb-1.0.so.0 => /usr/lib/libdirectfb-1.0.so.0 (0xb6171000)
	libfusion-1.0.so.0 => /usr/lib/libfusion-1.0.so.0 (0xb6168000)
	libdirect-1.0.so.0 => /usr/lib/libdirect-1.0.so.0 (0xb6154000)
	libxcb-render-util.so.0 => /usr/lib/libxcb-render-util.so.0 (0xb6150000)
	libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0xb6149000)
	libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0xb6120000)
	libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb611a000)
Auffällig find ich, dass zweimal gegen die libstdc++ (5 und 6) gelinkt wird...


update:
Auch in früheren lauffähigen Versionen wurde gegen bei gelinkt. Die 5 wird für libACE und die OpenCV Libs benötigt. Die 6er vermutlich für alle anderen...

Benutzeravatar
schorsch_76
Beiträge: 2612
Registriert: 06.11.2007 16:00:42
Lizenz eigener Beiträge: MIT Lizenz

Re: Sofortiger Segmentation Fault bei Programmstart

Beitrag von schorsch_76 » 14.10.2009 21:56:49

Hi,

da wird sicher irgendwo eine statische Variable deklariert welche immer konstruiert und am ende wieder zerstört wird. Das ist egal, ob die main() was macht oder nicht.

Ideen:
a) Mach nen Breakpoint mal direkt in die main auf das "return 0". Passiert der Crash vor oder nachdem der Breakpoint angelaufen wurde?
b) Entferne nacheinander alle cpp dateien aus dem skript. Linke unbd versuch es wieder. Wann hört es auf? Wenn es aufhört war das dann das File mit dem Fehler.
c) Schau dir deine Klassen nach Exceptions an. Wo kann eine geworfen werden? Wo kann Speicher angefordert werden, aber evtl.keiner zu verfügung stehen?

d) So wie das aussieht,
#0 0x0811a3db in std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::overflow () hast du ein Problem mit einem Streambuffer. Vermutlich in einem String. Machst du irgedwo "komische Sachen" mit std::string.c_str()? Oder streambuffer.str()? Bsp. ein std::ostringstream Ja? Das ist "Bööööse" ;)

Siehe
http://publib.boulder.ibm.com/infocente ... stream.htm

Gruß

schorsch

P.S.: Viel Erfolg :D

WalDHeiNi
Beiträge: 6
Registriert: 06.10.2009 22:19:06

Re: Sofortiger Segmentation Fault bei Programmstart

Beitrag von WalDHeiNi » 16.10.2009 20:29:04

Hi schorch,

danke für die vielen Ideen! Habe auch schon Streams in Verdacht. Wusste aber garnicht das ich so böse bin :D
Das Programm stürzt noch vor dem Breakpoint ab. Ich werde jetzt mal deine zweite Idee verfolgen, wird aber ein bisschen dauern ;)

Gruß

Benutzeravatar
armin
Beiträge: 2682
Registriert: 17.03.2005 11:49:14

Re: Sofortiger Segmentation Fault bei Programmstart

Beitrag von armin » 16.10.2009 20:50:03

Wie schaffst du es eigentlich gegen den ganzen Wust zu linken, wenn du nur ein simples Testprogramm compilierst?
Und warum holst du dir libace, opencv und Qt nicht aus dem Debianquellen? Dann brauchst du auch nicht gegen eine alte libc und ähnliches zu linken und ich würde Wetten der Segfault erledigt sich dann auch (du kompilierst ja nur eine leere Main-Methode, richtig?).
Formerly known as Trigger.
HP 8510p - Debian Sid
Mitglied des Debian-KDE-Teams

WalDHeiNi
Beiträge: 6
Registriert: 06.10.2009 22:19:06

GELÖST!!!

Beitrag von WalDHeiNi » 16.10.2009 23:39:41

Hi,

es ist schon ein größeres Projekt. Ich habe aber die main komplett geleert.

ich habe die Quellen der Libs und verschiede Makefiles für verschiedene Umgebungen/Compiler um portabel zu sein. Benötige leider die Versionen von ACE (die halt leider die libstdc++5 braucht) und OpenCV für meine eigene Bibliothek in der ich so Dinge wie z.B. Socketkommunikation gekapselt habe. Leider benötigen viele andere Debian Libs die neuere libstdc++6... Habe schon in der Paketverwaltung nach ACE gesucht, leider finde ich nur eine Version drüber, die sich nicht mit meiner Bibliothek linken lässt.
Und Qt baue ich am liebsten selber, da ich schonmal "schlimme" Überraschungen mit einer "Paketversion" hatte.

Naja aber ich habe es jetzt hinbekommen. Das Problem liegt in TinyXML. Die TinyXML lib lässt sich mit STL Unterstützung bauen oder eben nicht. Dazu muss das Compilerdefine TIXML_USE_STL angegeben werden.
Meine TinyXML Lib wurde mit STL Unterstützung gebaut. Jetzt habe ich dieses define in mein Projektmakefile eingebaut, sodass die Tiny-Header ebenfalls damit kompiliert werden und jetzt klappts!!! :D :D

Vielen dank für eure Unterstützung und eure Ideen!!!

Schöne Grüße

Antworten