GNOME terminal 2.2.1 segfaults at startup before a terminal window can appear. Stacktrace: #0 0x40a4c7a3 in type_check_is_value_type_U () from /usr/lib/libgobject-2.0.so.0 #1 0x40a41344 in g_signal_newv () from /usr/lib/libgobject-2.0.so.0 #2 0x40a414fd in g_signal_new_valist () from /usr/lib/libgobject-2.0.so.0 #3 0x40a40ed0 in g_signal_new () from /usr/lib/libgobject-2.0.so.0 #4 0x4004c604 in vte_terminal_class_init () from /usr/lib/libvte.so.4 #5 0x40a49128 in type_class_init_Wm () from /usr/lib/libgobject-2.0.so.0 #6 0x40a4a14f in g_type_class_ref () from /usr/lib/libgobject-2.0.so.0 #7 0x40a383d5 in g_object_newv () from /usr/lib/libgobject-2.0.so.0 #8 0x40a38acb in g_object_new_valist () from /usr/lib/libgobject-2.0.so.0 #9 0x40a3834e in g_object_new () from /usr/lib/libgobject-2.0.so.0 #10 0x4003f801 in vte_terminal_new () from /usr/lib/libvte.so.4 #11 0x08069996 in terminal_widget_new () #12 0x08066cd5 in terminal_screen_get_type () #13 0x40a48831 in g_type_create_instance () from /usr/lib/libgobject-2.0.so.0 #14 0x40a38b25 in g_object_constructor () from /usr/lib/libgobject-2.0.so.0 #15 0x40a38512 in g_object_newv () from /usr/lib/libgobject-2.0.so.0 #16 0x40a38acb in g_object_new_valist () from /usr/lib/libgobject-2.0.so.0 #17 0x40a3834e in g_object_new () from /usr/lib/libgobject-2.0.so.0 #18 0x08067010 in terminal_screen_new () #19 0x0805d2b7 in terminal_app_new_terminal () #20 0x0805cb68 in terminal_skey_do_popup () #21 0x0805cf5a in main () #22 0x40c27a34 in __libc_start_main () from /lib/libc.so.6 I had to recompile glib, vte and gnome-terminal with CFLAGS="-march=pentium4 -Os -pipe" to get a stacktrace. -fomit-frame-pointer really messes up stacktraces. Reproducible: Always Steps to Reproduce: 1. Start GNOME terminal 2.2.1 Actual Results: Segfault Expected Results: Xterminal session Portage 2.0.47-r2 (default-x86-1.4, gcc-3.2.1, glibc-2.3.1-r2) ================================================================= System uname: 2.4.19-gentoo-r10 i686 Intel(R) Pentium(R) 4 CPU 1500MHz GENTOO_MIRRORS="http://ftp.gentoo.or.kr http://gentoo.gnukorea.org http://distro.ibiblio.org/gentoo " CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="/usr/portage.local" USE="x86 oss apm avi crypt cups encode gif jpeg libg++ mikmod mmx mpeg ncurses nls pdflib png quicktime spell truetype xml2 xmms xv zlib gdbm berkdb slang readline tetex svga java guile mysql X sdl gpm tcpd pam libwww ssl python imlib oggvorbis gnome gtk motif opengl -3dnow alsa -arts bonobo cdr cjk dga esd gb gphoto2 gtkhtml jikes -kde kerberos ldap mbox mozilla mule odbc perl pic -qt -qtmt samba sse tcltk tiff usb" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -Os -pipe -fomit-frame-pointer" CXXFLAGS="-march=pentium4 -Os -pipe -fomit-frame-pointer" ACCEPT_KEYWORDS="x86" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="sandbox ccache userpriv usersandbox" Ignore the -fomit-frame-pointer, it is irrelevant.
does this happen for all users? What are the current (the user who get the crashes) settings ? (is the shell correct fex.) also, is this over remote protocl, or local?
> does this happen for all users? All Users. > What are the current (the user who get the crashes) settings ? (is the shell correct fex.) All users have shells defined. > also, is this over remote protocl, or local? Local. I'll try creating a new account with default settings to see whether or not this happens because of user intervention.
New account with default settings, but it still crashes.
I experience this too. It began with 2.2 final, but then for a moment I fixed it by emerging lib-zvt or something like that that I had unmerged by misstake. But then next vte update gnome-terminal began to segfault again, and I hadn't touched lib-zvt this time so I doubt that even was what fixed it in the first place.
it has nothing todo with zvt being around or not, it isnt used anymore by gnome-terminal. Do you use the latest (masked) version of vte (0.10.23) ? Please test that version and build everything related with 'inherit debug' added at the top of the ebuild, so the backtrace is a bit more useful.
inherit debug? I'll try that. Building with DEBUGBUILD=yes didn't seem to help, it only silenced the gdb No Debugging Symbols messages. This problem also happens with the vte widget demo, so I think it would be more appropriate to say that vte widgets inexplicably cause segfaults. Then again, maybe it's glib, but other programs haven't started segfaulting (except gnome-panel and notification-area-applet, but that's another story).
This is a vte backtrace, since it is practically identical to a gnome-terminal backtrace, except for a few small details: #0 0x4051d929 in type_check_is_value_type_U (type=1472430591) at gtype.c:2873 tflags = G_TYPE_FLAG_VALUE_ABSTRACT node = (struct _TypeNode *) 0x400347dc #1 0x40512148 in g_signal_newv (signal_name=0x0, itype=134652408, signal_flags=G_SIGNAL_RUN_LAST, class_closure=0x0, accumulator=0, accu_data=0x0, c_marshaller=0x57c381ff, return_type=4, n_params=1, param_types=0x80698a0) at gsignal.c:1408 name = (gchar *) 0x806a8e8 "text_scrolled" signal_id = 0 i = 0 node = (struct _SignalNode *) 0x0 #2 0x40512301 in g_signal_new_valist (signal_name=0x400eee46 "text-scrolled", itype=134652408, signal_flags=G_SIGNAL_RUN_LAST, class_closure=0x0, accumulator=0, accu_data=0x0, c_marshaller=0x40516211 <g_cclosure_marshal_VOID__INT>, return_type=4, n_params=1, args=0xbfffec80 "$
This is a vte backtrace, since it is practically identical to a gnome-terminal backtrace, except for a few small details: #0 0x4051d929 in type_check_is_value_type_U (type=1472430591) at gtype.c:2873 tflags = G_TYPE_FLAG_VALUE_ABSTRACT node = (struct _TypeNode *) 0x400347dc #1 0x40512148 in g_signal_newv (signal_name=0x0, itype=134652408, signal_flags=G_SIGNAL_RUN_LAST, class_closure=0x0, accumulator=0, accu_data=0x0, c_marshaller=0x57c381ff, return_type=4, n_params=1, param_types=0x80698a0) at gsignal.c:1408 name = (gchar *) 0x806a8e8 "text_scrolled" signal_id = 0 i = 0 node = (struct _SignalNode *) 0x0 #2 0x40512301 in g_signal_new_valist (signal_name=0x400eee46 "text-scrolled", itype=134652408, signal_flags=G_SIGNAL_RUN_LAST, class_closure=0x0, accumulator=0, accu_data=0x0, c_marshaller=0x40516211 <g_cclosure_marshal_VOID__INT>, return_type=4, n_params=1, args=0xbfffec80 "$µR@") at gsignal.c:1529 param_types = (GType *) 0x80698a0 i = 134650016 signal_id = 3221220480 #3 0x40511cd4 in g_signal_new (signal_name=0x400eee46 "text-scrolled", itype=134652408, signal_flags=G_SIGNAL_RUN_LAST, class_offset=134650016, accumulator=0, accu_data=0x0, c_marshaller=0x40516211 <g_cclosure_marshal_VOID__INT>, return_type=4, n_params=1) at gsignal.c:1261 No locals. #4 0x4004c614 in vte_terminal_class_init (klass=0x806a2a8, data=0x0) at vte.c:14434 gobject_class = (struct _GObjectClass *) 0x40515fb4 widget_class = (struct _GtkWidgetClass *) 0x57c381ff quark = 1472430591 i = 134652584 #5 0x4051a2ae in type_class_init_Wm (node=0x806a1f8, pclass=0x0) at gtype.c:1582 slist = (struct _GSList *) 0x0 init_slist = (struct _GSList *) 0x8058220 class = (struct _GTypeClass *) 0x806a2a8 entry = (struct _IFaceEntry *) 0x0 bnode = (struct _TypeNode *) 0x0 i = 1079160320 #6 0x4051b2d5 in g_type_class_ref (type=1079160320) at gtype.c:2048 No locals. #7 0x40508967 in g_object_newv (object_type=134652408, n_parameters=0, parameters=0x0) at gobject.c:641 cparams = (struct _GObjectConstructParam *) 0x3d oparams = (struct _GObjectConstructParam *) 0x7 nqueue = (struct _GObjectNotifyQueue *) 0x806a268 object = (struct _GObject *) 0x4086a1e0 class = (struct _GObjectClass *) 0x1 slist = (struct _GSList *) 0x806a1f8 n_total_cparams = 0 n_cparams = 0 n_oparams = 0 n_cvalues = 1073822096 cvalues = (struct _GValue *) 0xbfffed74 clist = (struct _GList *) 0x0 i = 226500039 #8 0x40509094 in g_object_new_valist (object_type=134652408, first_property_name=0x0, var_args=0xbfffee04 "`Ú\005\bX\177\006\b\230îÿ¿y¥\004\bX\177\006\bX\n\a\b") at gobject.c:764 class = (struct _GObjectClass *) 0x40014040 params = (struct _GParameter *) 0x87e name = (const gchar *) 0x8070a58 "P \006\b\001" object = (struct _GObject *) 0x8070a58 n_params = 0 n_alloced_params = 16 #9 0x405088e0 in g_object_new (object_type=134652408, first_property_name=0x0) at gobject.c:618 No locals. #10 0x4003f811 in vte_terminal_new () at vte.c:5931 No locals. #11 0x0804a579 in main (argc=1, argv=0xbfffeee4) at vteapp.c:426 window = (struct _GtkWidget *) 0x8067f58 hbox = (struct _GtkWidget *) 0x8070a58 scrollbar = (struct _GtkWidget *) 0x57c381ff widget = (struct _GtkWidget *) 0x8067f58 env_add = {0x804ae87 "FOO=BAR", 0x804ae8f "BOO=BIZ", 0x0} background = 0x0 transparent = 0 audible = 1 blink = 1 debug = 0 dingus = 0 geometry = 1 dbuffer = 1 lines = 100 font = 0x0 terminal = 0x0 command = 0x0 working_directory = 0x0 argv2 = (char **) 0x8067f58 opt = 1472430591 i = 134643544 j = 134650016 args = (struct _GList *) 0x8070a58 fore = {pixel = 1, red = 0, green = 0, blue = 0} back = {pixel = 1082639328, red = 65535, green = 65535, blue = 65535} #12 0x4075ba34 in __libc_start_main () from /lib/libc.so.6
Created attachment 8618 [details] backtrace Here's the gnome-terminal backtrace.
I think I have found the problem. It seems that when vte-0.10.25 is compiled without -Os flags, it works just fine. I have to perform experiments on vte-0.10.17 though. Perhaps someone with more processing power and patience can try some optimization tests, i.e. -mfpmath settings etc.
Forgot to mention, I was also compiling with the new gcc-3.2.2 compiler. Maybe that did the trick.
Same problem here. Same solution as Zhen. In my /etc/make.conf I've got the following: CFLAGS="-march=athlon-mp -Os -fomit-frame-pointer -pipe" Compiling vte-0.10.25 with -O2 instead of -Os fixes the crash. GCC 3.2.1. Any idea why some applications have bad behaviour when compiled with -Os ? It's not the first time I see that mentioned here. If it's a compiler bug, we might want to report it to the GCC people. Also, it might be a good idea to tell the GNOME people: http://bugzilla.gnome.org/show_bug.cgi?id=105408 (adding self to CC)
so the solution for this would be to filter the -Os flag ? Does -03 work ok ?
-O2, -O3 and no -O works perfectly fine. -Os should be replaced with -O2, since that is closer to what -Os does.
k done, added a little flag-o-matic line which should do just that.
