tuxcmd (home:saigkill): Unhandled Exception
Hallo Liste, das paketieren von tuxcmd klappt soweit ganz gut. Nach einem tuxcmd in der Konsole erhalte ich nun: sascha@linux-m4rp:~/osc/home:saigkill/tuxcmd> tuxcmd An unhandled exception occurred at $00007FB3BD5BE428 : EInvalidOp : Invalid floating point operation $00007FB3BD5BE428 $00007FB3BD5D0C83 $00007FB3BD5DA927 $00007FB3C30412AB Wie kann ich am besten vorgehen, um den Fehler einzukreisen (finden)? -- Sincerely yours Sascha Manns openSUSE Community & Support Agent openSUSE Marketing Team Blog: http://saigkill.wordpress.com Web: http://www.open-slx.de (openSUSE Box Support German) Web: http://www.open-slx.com (openSUSE Box Support English) -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Moin, On Sun, 21 Mar 2010, 14:19:27 +0100, Sascha 'saigkill' Manns wrote:
Hallo Liste,
das paketieren von tuxcmd klappt soweit ganz gut. Nach einem tuxcmd in der Konsole erhalte ich nun:
sascha@linux-m4rp:~/osc/home:saigkill/tuxcmd> tuxcmd An unhandled exception occurred at $00007FB3BD5BE428 : EInvalidOp : Invalid floating point operation $00007FB3BD5BE428 $00007FB3BD5D0C83 $00007FB3BD5DA927 $00007FB3C30412AB
Wie kann ich am besten vorgehen, um den Fehler einzukreisen (finden)?
ich kenne tuxcmd nicht, aber, wenn das ein in C oder C++ geschriebenes Programm ist, dann wuerde ich das Paket erstmal mit "-g -O0" bauen (beim Compilieren), und das Executable dann unter'm gdb laufen lassen (ach ja, beim Linken darauf achten, dass das Executable nicht mit "-s" seiner symbolischen Informationen beraubt wird!). Damit solltest du problemlos herausfinden, in welcher Funktion der Fehler passiert. Mithilfe der "print" Funktion im gdb kannst du dir alle moeglichen Werte ausgeben lassen, um zu ueberpruefen, was da schief gegangen sein koennte. Ein "bt" hilft ausserdem gewaltig, denn damit erhaeltst du die Aufrufhierarchie der bislang aktiven Funktionen (Stack-Backtrace). HTH, cheers. l8er manfred -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hallo Manfred, hallo Liste, Am Sonntag, 21. März 2010 14:47:16 wrote Manfred Hollstein:
Moin,
On Sun, 21 Mar 2010, 14:19:27 +0100, Sascha 'saigkill' Manns wrote:
Hallo Liste,
das paketieren von tuxcmd klappt soweit ganz gut. Nach einem tuxcmd in der Konsole erhalte ich nun:
sascha@linux-m4rp:~/osc/home:saigkill/tuxcmd> tuxcmd An unhandled exception occurred at $00007FB3BD5BE428 : EInvalidOp : Invalid floating point operation
$00007FB3BD5BE428 $00007FB3BD5D0C83 $00007FB3BD5DA927 $00007FB3C30412AB
Wie kann ich am besten vorgehen, um den Fehler einzukreisen (finden)?
ich kenne tuxcmd nicht, aber, wenn das ein in C oder C++ geschriebenes Programm ist, dann wuerde ich das Paket erstmal mit "-g -O0" bauen (beim Compilieren), und das Executable dann unter'm gdb laufen lassen (ach ja, beim Linken darauf achten, dass das Executable nicht mit "-s" seiner symbolischen Informationen beraubt wird!). Damit solltest du problemlos herausfinden, in welcher Funktion der Fehler passiert. Mithilfe der "print" Funktion im gdb kannst du dir alle moeglichen Werte ausgeben lassen, um zu ueberpruefen, was da schief gegangen sein koennte. Ein "bt" hilft ausserdem gewaltig, denn damit erhaeltst du die Aufrufhierarchie der bislang aktiven Funktionen (Stack-Backtrace). Ist hier an diesem backtrace etwas verdächtiges?
(gdb) bt #0 0x00007ffff182f428 in gdk_rectangle_intersect () from /usr/lib64/gtk-2.0/2.10.0/engines/libqtcurve.so #1 0x00007ffff1841c83 in ?? () from /usr/lib64/gtk-2.0/2.10.0/engines/libqtcurve.so #2 0x00007ffff184b927 in ?? () from /usr/lib64/gtk-2.0/2.10.0/engines/libqtcurve.so #3 0x00007ffff72b22ab in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #4 0x00007ffff72b39c5 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #5 0x00007ffff71bc9f8 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #6 0x00007ffff6b9663e in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0 #7 0x00007ffff6bab6dd in ?? () from /usr/lib64/libgobject-2.0.so.0 #8 0x00007ffff6bacc5c in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0 #9 0x00007ffff6bad313 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0 #10 0x00007ffff72c3cef in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #11 0x00007ffff71b6233 in gtk_main_do_event () from /usr/lib64/libgtk- x11-2.0.so.0 #12 0x00007ffff6e1228a in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #13 0x00007ffff6e12237 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #14 0x00007ffff6e12237 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #15 0x00007ffff6e0eda9 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #16 0x00007ffff6e10b81 in gdk_window_process_all_updates () from /usr/lib64/libgdk-x11-2.0.so.0 #17 0x00007ffff7134c41 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #18 0x00007ffff6ded8b6 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #19 0x00007ffff68fedee in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0 #20 0x00007ffff69027b8 in ?? () from /usr/lib64/libglib-2.0.so.0 #21 0x00007ffff69028e0 in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #22 0x00007ffff71b62f1 in gtk_main_iteration () from /usr/lib64/libgtk- x11-2.0.so.0 #23 0x0000000000422c71 in gtk_handle_box_get_handle_position () #24 0x00007ffff7f670c0 in ?? () #25 0x00007ffff1801020 in ?? () #26 0x00007fffffffd960 in ?? () ---Type <return> to continue, or q <return> to quit--- #27 0x000000000043e0dd in gtk_handle_box_get_handle_position () #28 0xcec0000000000000 in ?? () #29 0x0000000000004007 in ?? () #30 0x00007ffff7f709b0 in ?? () #31 0x0000000000000005 in ?? () #32 0xcec0000000000000 in ?? () #33 0x0000000000a34007 in ?? () #34 0x0000000010000001 in ?? () #35 0x0000000000a3b800 in ?? () #36 0x00007ffff7bd6e60 in ?? () from /lib64/libc.so.6 #37 0x0000000000000090 in ?? () #38 0x0000000010000001 in ?? () #39 0x00007ffff78f86a3 in ?? () from /lib64/libc.so.6 #40 0x00007ffff68f02f5 in ?? () from /usr/lib64/libglib-2.0.so.0 #41 0x0000000000000000 in ?? () -- Sincerely yours Sascha Manns openSUSE Community & Support Agent openSUSE Marketing Team Blog: http://saigkill.wordpress.com Web: http://www.open-slx.de (openSUSE Box Support German) Web: http://www.open-slx.com (openSUSE Box Support English) -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hi Sascha, On Sun, 21 Mar 2010, 17:37:17 +0100, Sascha 'saigkill' Manns wrote:
Hallo Manfred, hallo Liste,
Am Sonntag, 21. März 2010 14:47:16 wrote Manfred Hollstein:
Moin,
On Sun, 21 Mar 2010, 14:19:27 +0100, Sascha 'saigkill' Manns wrote:
Hallo Liste,
das paketieren von tuxcmd klappt soweit ganz gut. Nach einem tuxcmd in der Konsole erhalte ich nun:
sascha@linux-m4rp:~/osc/home:saigkill/tuxcmd> tuxcmd An unhandled exception occurred at $00007FB3BD5BE428 : EInvalidOp : Invalid floating point operation
$00007FB3BD5BE428 $00007FB3BD5D0C83 $00007FB3BD5DA927 $00007FB3C30412AB
Wie kann ich am besten vorgehen, um den Fehler einzukreisen (finden)?
ich kenne tuxcmd nicht, aber, wenn das ein in C oder C++ geschriebenes Programm ist, dann wuerde ich das Paket erstmal mit "-g -O0" bauen (beim Compilieren), und das Executable dann unter'm gdb laufen lassen (ach ja, beim Linken darauf achten, dass das Executable nicht mit "-s" seiner symbolischen Informationen beraubt wird!). Damit solltest du problemlos herausfinden, in welcher Funktion der Fehler passiert. Mithilfe der "print" Funktion im gdb kannst du dir alle moeglichen Werte ausgeben lassen, um zu ueberpruefen, was da schief gegangen sein koennte. Ein "bt" hilft ausserdem gewaltig, denn damit erhaeltst du die Aufrufhierarchie der bislang aktiven Funktionen (Stack-Backtrace). Ist hier an diesem backtrace etwas verdächtiges?
Ja, denn die Ausgaben unten kommen alle lediglich aus den shared Libraries, waehrend die Aufrufe aus deinem Programm (sowas wie 0x000000000...) alle voellig ohne Information, was den Funktionsnamen betrifft, sind: z.B. #29 0x0000000000004007 in ?? () Hast du das Programm doch strip'en lassen? Da es allerdings so tief in irgendwelchen shared Libs kracht, wuerde ich mir an deiner Stelle mal sehr genau das "config.log" nach dem Bauen ansehen, ob es da irgendwelche Hinweise auf Inkompatibilitaeten gibt. Unter Umstaenden hast du auf deinem System die falschen Versionen irgendwelcher benoetigten Libs installiert, oder moeglicherweise manche fehlen gar... Steht da was in einem File INSTALL drueber, was da gebraucht wird?
(gdb) bt #0 0x00007ffff182f428 in gdk_rectangle_intersect () from /usr/lib64/gtk-2.0/2.10.0/engines/libqtcurve.so #1 0x00007ffff1841c83 in ?? () from /usr/lib64/gtk-2.0/2.10.0/engines/libqtcurve.so #2 0x00007ffff184b927 in ?? () from /usr/lib64/gtk-2.0/2.10.0/engines/libqtcurve.so #3 0x00007ffff72b22ab in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #4 0x00007ffff72b39c5 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #5 0x00007ffff71bc9f8 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #6 0x00007ffff6b9663e in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0 #7 0x00007ffff6bab6dd in ?? () from /usr/lib64/libgobject-2.0.so.0 #8 0x00007ffff6bacc5c in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0 #9 0x00007ffff6bad313 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0 #10 0x00007ffff72c3cef in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #11 0x00007ffff71b6233 in gtk_main_do_event () from /usr/lib64/libgtk- x11-2.0.so.0 #12 0x00007ffff6e1228a in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #13 0x00007ffff6e12237 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #14 0x00007ffff6e12237 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #15 0x00007ffff6e0eda9 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #16 0x00007ffff6e10b81 in gdk_window_process_all_updates () from /usr/lib64/libgdk-x11-2.0.so.0 #17 0x00007ffff7134c41 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #18 0x00007ffff6ded8b6 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #19 0x00007ffff68fedee in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0 #20 0x00007ffff69027b8 in ?? () from /usr/lib64/libglib-2.0.so.0 #21 0x00007ffff69028e0 in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #22 0x00007ffff71b62f1 in gtk_main_iteration () from /usr/lib64/libgtk- x11-2.0.so.0 #23 0x0000000000422c71 in gtk_handle_box_get_handle_position () #24 0x00007ffff7f670c0 in ?? () #25 0x00007ffff1801020 in ?? () #26 0x00007fffffffd960 in ?? () ---Type <return> to continue, or q <return> to quit--- #27 0x000000000043e0dd in gtk_handle_box_get_handle_position () #28 0xcec0000000000000 in ?? () #29 0x0000000000004007 in ?? () #30 0x00007ffff7f709b0 in ?? () #31 0x0000000000000005 in ?? () #32 0xcec0000000000000 in ?? () #33 0x0000000000a34007 in ?? () #34 0x0000000010000001 in ?? () #35 0x0000000000a3b800 in ?? () #36 0x00007ffff7bd6e60 in ?? () from /lib64/libc.so.6 #37 0x0000000000000090 in ?? () #38 0x0000000010000001 in ?? () #39 0x00007ffff78f86a3 in ?? () from /lib64/libc.so.6 #40 0x00007ffff68f02f5 in ?? () from /usr/lib64/libglib-2.0.so.0 #41 0x0000000000000000 in ?? ()
HTH, cheers. l8er manfred -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
On Sun, 21 Mar 2010 18:25:34 +0100, Manfred Hollstein
"-g -O0" bauen (beim Compilieren), und das Executable dann unter'm gdb laufen lassen (ach ja, beim Linken darauf achten, dass das Executable nicht mit "-s" seiner symbolischen Informationen beraubt wird!).
Normalerweise reicht es für den ersten Versuch, das Paket ganz normal zu bauen und dann auch das -debuginfo und das -debugsrc Paket zu installieren. Das sollte zumindest reichen, um die genau Stelle zu finden und in vielen Fällen kann man auch im optimierten Code die Ursache ausfindig machen. Wenn das nicht reicht, kann man den CFLAGS am Ende immer noch ein -O0 mitgeben, um das -O2 aus den RPM_OPT_FLAGS zu überscheiben.
#29 0x0000000000004007 in ?? ()
Hast du das Programm doch strip'en lassen? Da es allerdings so tief in irgendwelchen shared Libs kracht, wuerde ich mir an deiner Stelle mal sehr genau das "config.log" nach dem Bauen ansehen,
Zunächst sollte man einfach die -debuginfo Pakete *aller* beteiligten Bibliotheken installieren, allen voran glibc-debuginfo. Philipp -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
On Sun, 21 Mar 2010, 19:05:30 +0100, Philipp Thomas wrote:
On Sun, 21 Mar 2010 18:25:34 +0100, Manfred Hollstein [...]
#29 0x0000000000004007 in ?? ()
Hast du das Programm doch strip'en lassen? Da es allerdings so tief in irgendwelchen shared Libs kracht, wuerde ich mir an deiner Stelle mal sehr genau das "config.log" nach dem Bauen ansehen,
Zunächst sollte man einfach die -debuginfo Pakete *aller* beteiligten Bibliotheken installieren, allen voran glibc-debuginfo.
Stimmt prinzipiell, aber nicht in diesem konkreten Fall, denn die niedrigen Addressen liegen im eigenen Programm, nicht in irgendwelchen hohen Adressbereichen, wohin die shared Libraries gemapped werden; dafuer helfen die -debuginfo Pakete der _anderen_ Pakete nicht. Wenn Sascha beim Bauen seines tuxxyz Paketes tatsaechlich auch ein -debuginfo Paket bekommen hat, dann, ja, sollte er das installieren. Ich haette allerdings unter /usr/src/packages/BUILD im Build-Directory einfach ein "make clean", gefolgt von einem "make CFLAGS='-O0 -g' LDFLAGS=''" gemacht und dann auch einfach da gedebugged...
Philipp
Cheers. l8er manfred -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Am Sonntag, 21. März 2010 19:26:16 wrote Manfred Hollstein:
On Sun, 21 Mar 2010, 19:05:30 +0100, Philipp Thomas wrote:
On Sun, 21 Mar 2010 18:25:34 +0100, Manfred Hollstein [...]
#29 0x0000000000004007 in ?? ()
Hast du das Programm doch strip'en lassen? Da es allerdings so tief in irgendwelchen shared Libs kracht, wuerde ich mir an deiner Stelle mal sehr genau das "config.log" nach dem Bauen ansehen,
Zunächst sollte man einfach die -debuginfo Pakete *aller* beteiligten Bibliotheken installieren, allen voran glibc-debuginfo.
Stimmt prinzipiell, aber nicht in diesem konkreten Fall, denn die niedrigen Addressen liegen im eigenen Programm, nicht in irgendwelchen hohen Adressbereichen, wohin die shared Libraries gemapped werden; dafuer helfen die -debuginfo Pakete der _anderen_ Pakete nicht. Wenn Sascha beim Bauen seines tuxxyz Paketes tatsaechlich auch ein -debuginfo Paket bekommen hat, dann, ja, sollte er das installieren. Ich haette allerdings unter /usr/src/packages/BUILD im Build-Directory einfach ein "make clean", gefolgt von einem "make CFLAGS='-O0 -g' LDFLAGS=''" gemacht und dann auch einfach da gedebugged... So nun hab ich ein debuginfo Paket :-)
Der aktuelle backtrace sagt: (gdb) bt #0 0x00007ffff1857428 in gdk_rectangle_intersect () from /usr/lib64/gtk-2.0/2.10.0/engines/libqtcurve.so #1 0x00007ffff1869c83 in ?? () from /usr/lib64/gtk-2.0/2.10.0/engines/libqtcurve.so #2 0x00007ffff1873927 in ?? () from /usr/lib64/gtk-2.0/2.10.0/engines/libqtcurve.so #3 0x00007ffff72b22ab in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #4 0x00007ffff72b39c5 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #5 0x00007ffff71bc9f8 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #6 0x00007ffff6b9663e in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0 #7 0x00007ffff6bab6dd in ?? () from /usr/lib64/libgobject-2.0.so.0 #8 0x00007ffff6bacc5c in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0 #9 0x00007ffff6bad313 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0 #10 0x00007ffff72c3cef in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #11 0x00007ffff71b6233 in gtk_main_do_event () from /usr/lib64/libgtk- x11-2.0.so.0 #12 0x00007ffff6e1228a in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #13 0x00007ffff6e12237 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #14 0x00007ffff6e12237 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #15 0x00007ffff6e0eda9 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #16 0x00007ffff6e10b81 in gdk_window_process_all_updates () from /usr/lib64/libgdk-x11-2.0.so.0 #17 0x00007ffff7134c41 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #18 0x00007ffff6ded8b6 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #19 0x00007ffff68fedee in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0 #20 0x00007ffff69027b8 in ?? () from /usr/lib64/libglib-2.0.so.0 #21 0x00007ffff69028e0 in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #22 0x00007ffff71b62f1 in gtk_main_iteration () from /usr/lib64/libgtk- x11-2.0.so.0 #23 0x000000000042353d in PROCESSMESSAGES (this=0x89e648) at libgtk_kylix/GTKForms.pas:673 #24 0x000000000043f73a in AFTERSTART (this=0x99b008) at UMain.pas:1322 #25 0x0000000000438372 in FORMCREATE (SENDER=0x99b008, this=0x99b008) at UMain.pas:460 #26 0x0000000000423d26 in CREATE (AOWNER=0x89e648, vmt=0x1, this=0x99b008) at libgtk_kylix/GTKForms.pas:786 #27 0x00000000004233c6 in CREATEFORM (INSTANCECLASS=0x7a3650, REFERENCE=@0x880140, this=0x89e648) at libgtk_kylix/GTKForms.pas:639 #28 0x0000000000421ca7 in main () at tuxcmd.dpr:90 Ist der informativer, als der letzte? Hätte eventuell jemand Lust, mich etwas darin einzuweisen, wie man einen backtrace liest? Grüße Sascha -- Sincerely yours Sascha Manns openSUSE Community & Support Agent openSUSE Marketing Team Blog: http://saigkill.wordpress.com Web: http://www.open-slx.de (openSUSE Box Support German) Web: http://www.open-slx.com (openSUSE Box Support English) -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Moin Sascha, On Tue, 23 Mar 2010, 15:45:53 +0100, Sascha 'saigkill' Manns wrote:
Am Sonntag, 21. März 2010 19:26:16 wrote Manfred Hollstein:
On Sun, 21 Mar 2010, 19:05:30 +0100, Philipp Thomas wrote:
On Sun, 21 Mar 2010 18:25:34 +0100, Manfred Hollstein [...]
#29 0x0000000000004007 in ?? ()
Hast du das Programm doch strip'en lassen? Da es allerdings so tief in irgendwelchen shared Libs kracht, wuerde ich mir an deiner Stelle mal sehr genau das "config.log" nach dem Bauen ansehen,
Nach dem tief geschachtelten Backtrace aller moeglicher GTK Libs, bleibe ich dabei, dass es u.U. mit irgendwelchen Anforderungen deines Paketes gegen die GTK Libs zusammen haengen koennte. Was ich aber mal als erstes ausprobieren wuerde, ist die Pakete, zu denen "/usr/lib64/gtk-2.0/2.10.0/engines/libqtcurve.so*" gehoert, zu loeschen und es dann nochmal zu probieren. Wenn mich nicht alles taeuscht, war das Ding (qtcurve-gtk2, qtcurve-kde, qtcurve-kde4) immer irgendwie in merkwuerdiges Verhalten bis hin zu Abstuerzen von GTK Programmen verantwortlich.
[...] So nun hab ich ein debuginfo Paket :-)
Der aktuelle backtrace sagt: (gdb) bt #0 0x00007ffff1857428 in gdk_rectangle_intersect () from /usr/lib64/gtk-2.0/2.10.0/engines/libqtcurve.so #1 0x00007ffff1869c83 in ?? () from /usr/lib64/gtk-2.0/2.10.0/engines/libqtcurve.so #2 0x00007ffff1873927 in ?? () from /usr/lib64/gtk-2.0/2.10.0/engines/libqtcurve.so #3 0x00007ffff72b22ab in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #4 0x00007ffff72b39c5 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #5 0x00007ffff71bc9f8 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #6 0x00007ffff6b9663e in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0 #7 0x00007ffff6bab6dd in ?? () from /usr/lib64/libgobject-2.0.so.0 #8 0x00007ffff6bacc5c in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0 #9 0x00007ffff6bad313 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0 #10 0x00007ffff72c3cef in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #11 0x00007ffff71b6233 in gtk_main_do_event () from /usr/lib64/libgtk- x11-2.0.so.0 #12 0x00007ffff6e1228a in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #13 0x00007ffff6e12237 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #14 0x00007ffff6e12237 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #15 0x00007ffff6e0eda9 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #16 0x00007ffff6e10b81 in gdk_window_process_all_updates () from /usr/lib64/libgdk-x11-2.0.so.0 #17 0x00007ffff7134c41 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #18 0x00007ffff6ded8b6 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #19 0x00007ffff68fedee in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0 #20 0x00007ffff69027b8 in ?? () from /usr/lib64/libglib-2.0.so.0 #21 0x00007ffff69028e0 in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #22 0x00007ffff71b62f1 in gtk_main_iteration () from /usr/lib64/libgtk- x11-2.0.so.0 #23 0x000000000042353d in PROCESSMESSAGES (this=0x89e648) at libgtk_kylix/GTKForms.pas:673 #24 0x000000000043f73a in AFTERSTART (this=0x99b008) at UMain.pas:1322 #25 0x0000000000438372 in FORMCREATE (SENDER=0x99b008, this=0x99b008) at UMain.pas:460 #26 0x0000000000423d26 in CREATE (AOWNER=0x89e648, vmt=0x1, this=0x99b008) at libgtk_kylix/GTKForms.pas:786 #27 0x00000000004233c6 in CREATEFORM (INSTANCECLASS=0x7a3650, REFERENCE=@0x880140, this=0x89e648) at libgtk_kylix/GTKForms.pas:639 #28 0x0000000000421ca7 in main () at tuxcmd.dpr:90
Ist der informativer, als der letzte?
Ja, schon.
Hätte eventuell jemand Lust, mich etwas darin einzuweisen, wie man einen backtrace liest?
info --index-search=Backtrace gdb
Grüße Sascha
HTH, cheers. l8er manfred -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
participants (3)
-
Manfred Hollstein
-
Philipp Thomas
-
Sascha 'saigkill' Manns