[thimo@...153...: Bug#261848: inkscape: segfaults on startup (Alpha)]
Hi alltogether,
I received the attached bug report for the debian package of inkscape, ver 0.39. Can someone comment on this? I ask here berfore I submit it to the tracker because I'm not sure if it's my package or inkscape. The other bug referenced in the report is available at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=187196
With best regards,
Wolfi
----- Forwarded message from Thimo Neubauer <thimo_at_debian_dot_org> -----
X-Original-To: wolfi@...33... Subject: Bug#261848: inkscape: segfaults on startup (Alpha) Reply-To: Thimo Neubauer <thimo_at_debian_dot_org>, 261848@...499... Resent-From: Thimo Neubauer <thimo_at_debian_dot_org> Original-Sender: Thimo Neubauer <thimo@...500...> Resent-To: debian-bugs-dist@...501... Resent-Cc: Wolfram Quester <wolfi@...111...> Resent-Date: Wed, 28 Jul 2004 15:33:01 UTC Resent-Message-ID: <handler.261848.B.109102783927786@...499...> X-Debian-PR-Message: report 261848 X-Debian-PR-Package: inkscape X-Debian-PR-Keywords: From: Thimo Neubauer <thimo_at_debian_dot_org> To: Debian Bug Tracking System <submit@...499...> Resent-Sender: Debian BTS <debbugs@...499...> X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at honk.physik.uni-konstanz.de X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at honk.physik.uni-konstanz.de
Package: inkscape Version: 0.39-1 Severity: important
Even before showing the first window inkscape runs into a segfault. This is the backtrace:
riff /home/thimo> gdb inkscape GNU gdb 6.1-debian 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 "alpha-linux"...(no debugging symbols found)...Using host libthread_db library "/usr/lib/debug/libthread_db.so.1".
(gdb) r Starting program: /usr/bin/inkscape [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 11392)]
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 11392)] 0x0000020000a3cba8 in g_type_is_a (type=540847136, iface_type=4835814432) at gtype.c:2730 2730 gtype.c: Datei oder Verzeichnis nicht gefunden. in gtype.c (gdb) bt #0 0x0000020000a3cba8 in g_type_is_a (type=540847136, iface_type=4835814432) at gtype.c:2730 #1 0x0000000120095a34 in sp_object_repr_build_tree () #2 0x0000000120050690 in SPDocument::collectOrphans () #3 0x0000000120050e98 in sp_document_new () #4 0x0000000120054efc in sp_file_new () #5 0x000000012004f078 in sp_main_gui () #6 0x000000012004ed50 in main () (gdb)
It seems a bit like #187196 but all my other Gnome-programs work fine. Additionally, the inkscape package from testing (0.38.1-4) starts without problem but runs into another segfault on exit, but also inside libgobject-2.0.so.0. I can't really tell if it's inkscape or glib but at least the different behaviours of the inkscape versions seem to suggest that inkscape at least takes part in the problem. If my assumption is wrong, feel free to reassign the bug :)
Tell me if you need more information.
Cheers Thimo
-- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: alpha Kernel: Linux 2.6.6-1-generic Locale: LANG=de_DE@...502..., LC_CTYPE=de_DE@...502...
Versions of packages inkscape depends on: ii libatk1.0-0 1.6.1-2 The ATK accessibility toolkit ii libc6.1 2.3.2.ds1-13 GNU C Library: Shared libraries an ii libfontconfig1 2.2.3-1 generic font configuration library ii libfreetype6 2.1.7-2.1 FreeType 2 font engine, shared lib ii libgcc1 1:3.4.1-3 GCC support library ii libglib2.0-0 2.4.4-1 The GLib library of C routines ii libgtk2.0-0 2.4.4-1 The GTK+ graphical user interface ii libpango1.0-0 1.4.0-4 Layout and rendering of internatio ii libpng12-0 1.2.5.0-6 PNG library - runtime ii libpopt0 1.7-4 lib for parsing cmdline parameters ii libsigc++-1.2-5c102 1.2.5-1 Type-safe Signal Framework for C++ ii libstdc++5 1:3.3.4-5 The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-5 X Window System protocol client li ii libxft2 2.1.2-6 FreeType-based font drawing librar ii libxml2 2.6.11-2 GNOME XML library ii libxrender1 0.8.3-7 X Rendering Extension client libra ii xlibs 4.3.0.dfsg.1-6 X Window System client libraries m ii zlib1g 1:1.2.1.1-5 compression library - runtime
-- no debconf information
----- End forwarded message -----
On Fri, 2004-08-06 at 04:38, Wolfram Quester wrote:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 11392)] 0x0000020000a3cba8 in g_type_is_a (type=540847136, iface_type=4835814432)
Hmmm, I'm guessing someone cast a pointer to an integer somewhere. This is the most common problem with programs not working on Alpha (remember 64-bit address and 32-bit ints). And judging that: 540847136 == 0x203CAC20 and the rest of the address in the backtrace have 0x00000001 in the upper four bytes...
I thought that there was a warning that was spit out when you compiled on Alpha? Wolfi, is it possible to get an Alpha build log?
--Ted
On Fri, Aug 06, 2004 at 10:00:56AM -0700, Ted Gould wrote:
On Fri, 2004-08-06 at 04:38, Wolfram Quester wrote:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 11392)] 0x0000020000a3cba8 in g_type_is_a (type=540847136, iface_type=4835814432)
Hmmm, I'm guessing someone cast a pointer to an integer somewhere. This is the most common problem with programs not working on Alpha (remember 64-bit address and 32-bit ints). And judging that: 540847136 == 0x203CAC20 and the rest of the address in the backtrace have 0x00000001 in the upper four bytes...
I thought that there was a warning that was spit out when you compiled on Alpha? Wolfi, is it possible to get an Alpha build log?
The build-log of the debian package is available at http://buildd.debian.org/fetch.php?&pkg=inkscape&ver=0.39-1&arch... There are warnings like if alpha-linux-g++ -DHAVE_CONFIG_H -I. -I. -I.. -DXTHREADS -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -I/usr/lib/sigc++-1.2/include -I/usr/include/sigc++-1.2 -Wall -W -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O2 -MT interface.o -Molekular-Dynamik -MP -MF ".deps/interface.Tpo" \ -c -o interface.o `test -f 'interface.cpp' || echo './'`interface.cpp; \ then mv -f ".deps/interface.Tpo" ".deps/interface.Po"; \ else rm -f ".deps/interface.Tpo"; exit 1; \ fi interface.cpp: In function `void sp_ui_menu_key_press(GtkMenuItem*, GdkEventKey*, void*)': interface.cpp:323: warning: cast from pointer to integer of different size interface.cpp: In function `GtkWidget* sp_ui_menu_append_item_from_verb(GtkMenu*, int, SPView*)': interface.cpp:444: warning: cast to pointer from integer of different size
[...snip...]
if alpha-linux-g++ -DHAVE_CONFIG_H -I. -I. -I.. -DXTHREADS -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -I/usr/lib/sigc++-1.2/include -I/usr/include/sigc++-1.2 -Wall -W -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O2 -MT seltrans.o -Molekular-Dynamik -MP -MF ".deps/seltrans.Tpo" \ -c -o seltrans.o `test -f 'seltrans.cpp' || echo './'`seltrans.cpp; \ then mv -f ".deps/seltrans.Tpo" ".deps/seltrans.Po"; \ else rm -f ".deps/seltrans.Tpo"; exit 1; \ fi seltrans.cpp: In function `gboolean sp_sel_trans_handle_request(SPKnot*, NR::Point*, unsigned int, gboolean*)': seltrans.cpp:634: warning: cast from `gboolean*' to `const SPSelTransHandle*' increases required alignment of target type
[...snip...]
if alpha-linux-g++ -DHAVE_CONFIG_H -I. -I. -I.. -DXTHREADS -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -I/usr/lib/sigc++-1.2/include -I/usr/include/sigc++-1.2 -Wall -W -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O2 -MT sp-ellipse.o -Molekular-Dynamik -MP -MF ".deps/sp-ellipse.Tpo" \ -c -o sp-ellipse.o `test -f 'sp-ellipse.cpp' || echo './'`sp-ellipse.cpp; \ then mv -f ".deps/sp-ellipse.Tpo" ".deps/sp-ellipse.Po"; \ else rm -f ".deps/sp-ellipse.Tpo"; exit 1; \ fi sp-ellipse.cpp: In function `void sp_genericellipse_update(SPObject*, SPCtx*, unsigned int)': sp-ellipse.cpp:142: warning: cast from `SPCtx*' to `SPItemCtx*' increases required alignment of target type sp-ellipse.cpp:142: warning: cast from `SPCtx*' to `SPItemCtx*' increases required alignment of target type sp-ellipse.cpp:142: warning: cast from `SPCtx*' to `SPItemCtx*' increases required alignment of target type sp-ellipse.cpp:142: warning: cast from `SPCtx*' to `SPItemCtx*' increases required alignment of target type
and such. Another warning which is probaly unrelated to this problem is if alpha-linux-g++ -DHAVE_CONFIG_H -I. -I. -I.. -DXTHREADS -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -I/usr/lib/sigc++-1.2/include -I/usr/include/sigc++-1.2 -Wall -W -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O2 -MT spiral-context.o -Molekular-Dynamik -MP -MF ".deps/spiral-context.Tpo" \ -c -o spiral-context.o `test -f 'spiral-context.cpp' || echo './'`spiral-context.cpp; \ then mv -f ".deps/spiral-context.Tpo" ".deps/spiral-context.Po"; \ else rm -f ".deps/spiral-context.Tpo"; exit 1; \ fi spiral-context.cpp: In function `void sp_spiral_drag(SPSpiralContext*, NR::Point, unsigned int)': spiral-context.cpp:440: warning: `sp_view_set_status' is deprecated (declared at view.h:194)
It looks like we should get rid of this, too.
--Ted
With best regards and thanks for the help,
Wolfi
On Fri, 2004-08-06 at 07:38, Wolfram Quester wrote:
#0 0x0000020000a3cba8 in g_type_is_a (type=540847136, iface_type=4835814432) at gtype.c:2730 #1 0x0000000120095a34 in sp_object_repr_build_tree () #2 0x0000000120050690 in SPDocument::collectOrphans () #3 0x0000000120050e98 in sp_document_new () #4 0x0000000120054efc in sp_file_new () #5 0x000000012004f078 in sp_main_gui () #6 0x000000012004ed50 in main ()
Hmm. That backtrace looks a little suspect to me, SPDocument::collectOrphans() never calls sp_object_repr_build_tree() directly.
I don't think any of the functions which might get inlined there would do so either... so I'm kind of stumped. :/
-mental
On Fri, 2004-08-06 at 23:40, MenTaLguY wrote:
On Fri, 2004-08-06 at 07:38, Wolfram Quester wrote:
#0 0x0000020000a3cba8 in g_type_is_a (type=540847136, iface_type=4835814432) at gtype.c:2730 #1 0x0000000120095a34 in sp_object_repr_build_tree () #2 0x0000000120050690 in SPDocument::collectOrphans () #3 0x0000000120050e98 in sp_document_new () #4 0x0000000120054efc in sp_file_new () #5 0x000000012004f078 in sp_main_gui () #6 0x000000012004ed50 in main ()
Hmm. That backtrace looks a little suspect to me, SPDocument::collectOrphans() never calls sp_object_repr_build_tree() directly.
By "suspect", I mean it looks like the stack may have been corrupted. Is this from a core dump or a live gdb session? The latter is sometimes more reliable in capturing the stack.
-mental
Hi mental,
Thimo Neubauer replied to my question regarding th backtrace and provided additional information. I hope to get some time to look into the gcc warnings you pointed out soon.
Thanks for your help,
Wolfi
Thimo Neubauer wrote: Hi,
On Sun, Aug 08, 2004 at 03:36:05PM +0200, Wolfram Quester wrote:
I forwarded your report to the inkscape developer ML and one replay was
On Fri, 2004-08-06 at 23:40, MenTaLguY wrote:
On Fri, 2004-08-06 at 07:38, Wolfram Quester wrote:
#0 0x0000020000a3cba8 in g_type_is_a (type=540847136, iface_type=4835814432) at gtype.c:2730 #1 0x0000000120095a34 in sp_object_repr_build_tree () #2 0x0000000120050690 in SPDocument::collectOrphans () #3 0x0000000120050e98 in sp_document_new () #4 0x0000000120054efc in sp_file_new () #5 0x000000012004f078 in sp_main_gui () #6 0x000000012004ed50 in main ()
Hmm. That backtrace looks a little suspect to me, SPDocument::collectOrphans() never calls sp_object_repr_build_tree() directly.
By "suspect", I mean it looks like the stack may have been corrupted. Is this from a core dump or a live gdb session? The latter is sometimes more reliable in capturing the stack.
It was a live session, I didn't fake the gdb-call and run-command in my report :) Maybe the effect is due to a cunning g++-optimization, The results so far were with the original binary and the -dbg-libs.
Ok, now a new debug-build (noopt, nostrip) is ready but the backtrace is nearly the same:
riff inkscape-0.39/src> setenv LD_LIBRARY_PATH /usr/lib/debug/ riff inkscape-0.39/src> gdb ./inkscape GNU gdb 6.1-debian 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 "alpha-linux"...Using host libthread_db library "/usr/lib/debug/libthread_db.so.1".
(gdb) r Starting program: /tmp/inkscape-0.39/src/inkscape [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 860)]
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 860)] 0x0000020000a40b68 in g_type_is_a (type=541535280, iface_type=4836502576) at gtype.c:2730 2730 gtype.c: Datei oder Verzeichnis nicht gefunden. in gtype.c Current language: auto; currently c (gdb) bt #0 0x0000020000a40b68 in g_type_is_a (type=541535280, iface_type=4836502576) at gtype.c:2730 #1 0x00000001200daa74 in sp_object_repr_build_tree (document=0x12047c260, repr=0x1204eef10) at sp-object-repr.cpp:54 #2 0x000000012007e2a4 in sp_document_create (rdoc=0x1204e9c70, uri=0x0, base=0x0, name=0x1204d4510 "Neues Dokument 1", advertize=1, keepalive=1) at document.cpp:305 #3 0x000000012007eb4c in sp_document_new (uri=0x0, advertize=1, keepalive=1) at document.cpp:431 #4 0x0000000120084394 in sp_file_new () at file.cpp:82 #5 0x000000012007c92c in sp_main_gui (argc=1, argv=0x11ffff848) at main.cpp:294 #6 0x000000012007c5fc in main (argc=1, argv=0x11ffff848) at main.cpp:233 (gdb)
HTH Thimo
On Mon, 2004-08-16 at 14:02, Wolfram Quester wrote:
It was a live session, I didn't fake the gdb-call and run-command in my report :) Maybe the effect is due to a cunning g++-optimization, The results so far were with the original binary and the -dbg-libs.
That's what I meant. The weirdness was either stack corruption or side-effects of compiler optimizations.
Ok, now a new debug-build (noopt, nostrip) is ready but the backtrace is nearly the same:
Well, with the important difference that it is a believable call sequence, so I can be more confident the backtrace information is accurate.
Line numbers help too:
#0 0x0000020000a40b68 in g_type_is_a (type=541535280, iface_type=4836502576) at gtype.c:2730
I seem to recall that type is an index into an array, so both these values are far too large (unless they're now direct pointers)...
#1 0x00000001200daa74 in sp_object_repr_build_tree (document=0x12047c260, repr=0x1204eef10) at sp-object-repr.cpp:54
(since moved down a few lines:)
g_assert (g_type_is_a (type, SP_TYPE_ROOT));
So it looks like perhaps the types in question have not been properly registered somehow?
It would be instructive to set a breakpoint on sp_root_get_type() and make sure that is behaving as it ought.
-mental
Hi, The problem on windows seems to be the same issue, I'm getting seg faults in sp_object_repr_build_tree at the gpointer newobj = g_object_new(type, 0); call. type has a value of 55128808.
will keep looking into it.
John
--- MenTaLguY <mental@...3...> wrote:
On Mon, 2004-08-16 at 14:02, Wolfram Quester wrote:
It was a live session, I didn't fake the gdb-call and run-command
in
my report :) Maybe the effect is due to a cunning g++-optimization, The results so far were with the original binary and the -dbg-libs.
That's what I meant. The weirdness was either stack corruption or side-effects of compiler optimizations.
Ok, now a new debug-build (noopt, nostrip) is ready but the
backtrace
is nearly the same:
Well, with the important difference that it is a believable call sequence, so I can be more confident the backtrace information is accurate.
Line numbers help too:
#0 0x0000020000a40b68 in g_type_is_a (type=541535280,
iface_type=4836502576)
at gtype.c:2730I seem to recall that type is an index into an array, so both these values are far too large (unless they're now direct pointers)...
#1 0x00000001200daa74 in sp_object_repr_build_tree
(document=0x12047c260,
repr=0x1204eef10) at sp-object-repr.cpp:54(since moved down a few lines:)
g_assert (g_type_is_a (type, SP_TYPE_ROOT));
So it looks like perhaps the types in question have not been properly registered somehow?
It would be instructive to set a breakpoint on sp_root_get_type() and make sure that is behaving as it ought.
-mental
ATTACHMENT part 2 application/pgp-signature name=signature.asc
__________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail
participants (4)
-
John Cliff -
MenTaLguY -
Ted Gould -
Wolfram Quester