gnome-terminal assert failure: ERROR:terminal-app.c:1444:terminal_app_init: assertion failed: (app->default_profile_id != NULL)

Bug #436188 reported by don hardaway on 2009-09-24
502
This bug affects 105 people
Affects Status Importance Assigned to Milestone
gnome-terminal (Debian)
Fix Released
Unknown
gnome-terminal (Fedora)
Won't Fix
Medium
gnome-terminal (Ubuntu)
Medium
Unassigned

Bug Description

Binary package hint: gnome-terminal

this bug just popped up when i was launching a terminal window

ProblemType: Crash
Architecture: i386
AssertionMessage: ERROR:terminal-app.c:1444:terminal_app_init: assertion failed: (app->default_profile_id != NULL)
Date: Thu Sep 24 16:14:59 2009
DistroRelease: Ubuntu 9.10
ExecutablePath: /usr/bin/gnome-terminal
Package: gnome-terminal 2.28.0-0ubuntu1
ProcCmdline: gnome-terminal
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-10.35-generic
Signal: 6
SourcePackage: gnome-terminal
StacktraceTop:
 __kernel_vsyscall ()
 raise () from /lib/tls/i686/cmov/libc.so.6
 abort () from /lib/tls/i686/cmov/libc.so.6
 g_assertion_message () from /usr/lib/libglib-2.0.so.0
 g_assertion_message_expr () from /usr/lib/libglib-2.0.so.0
Tags: ubuntu-unr
Title: gnome-terminal assert failure: ERROR:terminal-app.c:1444:terminal_app_init: assertion failed: (app->default_profile_id != NULL)
Uname: Linux 2.6.31-10-generic i686
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

Description of problem:
When starting a gnome-terminal on a remote host with all X11/TCP infrastructure code including CORBA via IPv4 enabled (other apps work fine), the gnome-terminal gets a glibc double free error and crashes...

rsh willow gnome-terminal --display $DISPLAY
**
ERROR:terminal-app.c:1525:terminal_app_init: assertion failed: (app->default_profile_id != NULL)
*** glibc detected *** gnome-terminal: double free or corruption (out): 0x000000000178c0e0 ***

and then hangs...

Other X applications work fine.

Version-Release number of selected component (if applicable):
gnome-terminal-2.24.1-2.fc10.x86_64

How reproducible:
every time

Steps to Reproduce:
1. Enable X11/TCP mode and xauth on NFS - restart GDM/X server
2. Enable ORBIOPIPv4 in /etc/orbitrc
3. Login into GNOME session on Workstation
4. xauth list - take value and xauth -f .Xauthority add with the
details
5. Enable rsh-server on the file server machine on the local network
6. Test rsh is working (.rhosts etc)
7. Run: rsh fileserver gnome-terminal --display $DISPLAY

Actual results:
Gnome terminal crashes with assertion failure.

Expected results:
Gnome terminal starts on fileserver displaying via X11/TCP

Additional info:
Local network is secure - TCP/X11 tunnelling and SSH is totally unnecessary and over the top and produces significant latency and consumes ptys.

This also happens if you login via ssh and try to start gnome-terminal from the command line like so:

willow% gnome-terminal --display cyane:0 &
[1] 13791
willow% **
ERROR:terminal-app.c:1525:terminal_app_init: assertion failed: (app->default_profile_id != NULL)

[1] Abort gnome-terminal --display cyane:0
willow%

I'm getting the same failure when starting gnome-terminal from the GNOME panel or command line of an existing gnome-terminal. I have no idea why I was able to start gnome-terminals then it stopped. I've seen this in several login sessions. I've had to put xterm on the panel as a backup.

don hardaway (don-hardaway) wrote :

StacktraceTop:__kernel_vsyscall ()
*__GI_raise (sig=6)
*__GI_abort () at abort.c:92
g_assertion_message () from /usr/lib/libglib-2.0.so.0
g_assertion_message_expr () from /usr/lib/libglib-2.0.so.0

Changed in gnome-terminal (Ubuntu):
importance: Undecided → Medium
tags: removed: need-i386-retrace
Paul Sladen (sladen) wrote :
visibility: private → public
Paul Sladen (sladen) wrote :

Previously appeared as: bug #298426

Changed in gnome-terminal (Ubuntu):
status: New → Confirmed

https://launchpad.net/bugs/436188 + dups, although this was allegedly fixed before at https://launchpad.net/bugs/298426

Paul Sladen (sladen) wrote :

Theoretically this has been fixed/superseded...

"gnome-terminal (2.26.2-2) unstable; urgency=low

  * 02_let_gconf_autostart.patch: Don’t exit if there is no GConf daemon
    running. Instead, let dbus-daemon and gconfd be autostarted as they
    should be if this is needed. Thanks to Sean Finney for the
    suggestion. Closes: #531734 and some duplicates.

 -- Josselin Mouette <email address hidden> Sat, 27 Jun 2009 14:53:33 +0200
"

Changed in gnome-terminal (Debian):
status: Unknown → New
Changed in gnome-terminal (Fedora):
status: Unknown → Confirmed
Changed in gnome-terminal (Ubuntu):
status: Confirmed → Triaged
Max Bowsher (maxb) wrote :

I've just seen this for the first time now, on Karmic.

Gerhard (mail-gbalthasar) wrote :

Had this today for the first time on karmic64 up to date

Gerhard (mail-gbalthasar) wrote :

had this problem directly after an update. a restart settled it. sorry

I got this just now on an up-to-date Karmic install. So this bug is alive and well in Karmic.

Please! Let's not have two releases in a row where the basic functionality of:

$ ssh -X karmic-host gnome-terminal

fails to work correctly.

I have just come across this problem with a source code install. The way the system was build was using make DESTDIR=/arch/pkg/32/gnome-terminal-2.28.0 install etc for each gnome package. The contents of these directories was then copied onto a clean file system before being run under KVM.

Running gnome-terminal produced the app->default_profile_id != NULL error. I found the problem was to do with the fact that while the schema files were copied correctly into /etc/gconf/schemas these were not been properly installed into gconf.

Running

GCONF_CONFIG_SOURCE=xml:merged:/etc/gconf/gconf.xml.defaults /usr/bin/gconftool-2 --make-install-rule /etc/gconf/schemas/desktop_gnome_interface.schemas
GCONF_CONFIG_SOURCE=xml:merged:/etc/gconf/gconf.xml.defaults /usr/bin/gconftool-2 --make-install-rule /etc/gconf/schemas/gnome-terminals.schemas

put the necessary entries into gconf for gnome-terminal to work correctly.

All source files are from GNOME 2.28.1. A quick test using

gconftool-2 -R /apps/gnome-terminal

should show if the profiles are installed in gconf correctly.

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 10 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

AFAIK, this is still current; it is in the other distros above.

Yes, this is still a problem with Fedora 11.

Looks like I have managed to change the release to Fedora 11, so the bug won't get automatically closed.

Malaise (malaise) wrote :

>$ ssh -X karmic-host gnome-terminal
>fails to work correctly.

i confirm. From a Hary I do: ssh -X karmic-host gnome-terminal
It fails with:
Xlib: extension "Generic Event Extension" missing on display "localhost:10.0".
// 6l times

Failed to get the session bus: Failed to connect to socket /tmp/dbus-MQ78xxPMgm: Connection refused
Falling back to non-factory mode.
GConf Error: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://projects.gnome.org/gconf/ for information. (Details - 1: Failed to get connection to session: Failed to connect to socket /tmp/dbus-MQ78xxPMgm: Connection refused)
// 8 times

**
ERROR:terminal-app.c:1444:terminal_app_init: assertion failed: (app->default_profile_id != NULL)

Sometimes it is fixed after a reboot of the karmic host, but rarely.

Malaise (malaise) wrote :

In fact, it seems to be fixed after doing:
rm -rf $HOME/.dbus on the remote host then reboot it.

On Sat, 2009-12-12 at 16:35 +0000, Malaise wrote:
> i confirm. From a Hary I do:

Is this bug really in a state where it needs confirmation? I think this
is a well known issue plaguing a lot of people -- and sadly, even after
a major distribution update (i.e. this was a bug in Intrepid too) it's
still not fixed. :-(

Malaise (malaise) wrote :

I confirm the use case:
Problem occurs when stopping (shutdown) the remote host while a "ssh -X <remote_host> gnome-terminal" is running.
Local host is Hardy, remote is Karmic. DisallowTCP=false on remote host, of course.

Malaise (malaise) wrote :

Correction
Problem occurs IF stopping (shutdown) the remote host while a "ssh -X <remote_host> gnome-terminal" is running.
And it occurs AFTER rebooting the remote host, of course.

Malaise (malaise) wrote :

Can anybody explain where this reference to "/tmp/dbus-xxx" cames from and how to clean it?
This seems to be stored somewhere on the <remote_host>, but I can't find it.
I'm sure that cleaning this "obsolete" reference would solve the problem.

Malaise (malaise) wrote :

Workaround (not 100% precise):
- remove rm -rf $HOME/.dbus on both hosts
- reboot both hosts
- retry
- on the remote host, $HOME/.dbus now belongs to root!!!
- remove it (as root).

Now it works, as far as I could understand.

rogert (rthornblad) wrote :

I've tried all the workarounds listed above with no success. I've also tried something I found in another thread (below)

I subsequently discovered that the original user can be fixed by deleting these directories in /home/original-user
.dbus
.gconf
.gconfd
.gnome2
.gnome2_private

The only workaround I've found so far is to dump the existing user account and create a new user. Are there any other workaround(s) I can try?

Pedro Villavicencio (pedro) wrote :

This seems to be fixed on Lucid, there's no confirmation based on the reports (duplicates) that the issue is reproducible on Lucid, could somebody please test the same and confirm ? Thanks in advance.

Changed in gnome-terminal (Ubuntu):
status: Triaged → Incomplete
Malaise (malaise) wrote :

Now I reproduce it 100%.
From a Hardy I do: ssh -X karmic-host gnome-terminal. While the terminal is connected reboot the Karmic host.
Then do ssh -X karmic-host gnome-terminal again.
Workaround (works 100%): On the Karmic host, rm -rf .dbus/session-bus/*, then reboot the Hardy host.

But maybe this failure occurs in other circumstances when this workaround does not apply.

This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 11 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Malaise (malaise) wrote :

Unfortunately I can confirm that the problem still occurs between 2 hosts on Lucid.
From client host C to server host S.
C: ssh -X S gnome-terminal
S: reboot
C: // do NOT close (force quit) the ghost window. When S reboots it disappears
C: ssh -X S gnome-terminal // Fails with the following log:
Failed to get the session bus: Failed to connect to socket /tmp/dbus-tKraUoAi0F: Connection refused
Falling back to non-factory mode.
Failed to summon the GConf demon; exiting. Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://projects.gnome.org/gconf/ for information. (Details - 1: Failed to get connection to session: Failed to connect to socket /tmp/dbus-tKraUoAi0F: Connection refused)

S: rm -rf .dbus/session-bus/* // as root, because one file belongs to root!
C: reboot
C: ssh -X S gnome-terminal // OK

Adam Collard (adam-collard) wrote :

I have followed the most recent steps to reproduce (with a Maverick client, and Lucid host) but cannot reproduce this bug.

Malaise - does this occur every time for you? Can you try launching gnome-terminal with "--disable-factory" and see if this also produces the problem?

Malaise (malaise) wrote :

Yes I confirm that the problem with the scenario above is 100% reproducible (with 2 Lucid).
With ssh -X S "gnome-terminal --disable-factory" the problem is still present.

Adam, if you want me to do more tests or if you want to log on my machines you can contact me directly.

Changed in gnome-terminal (Debian):
status: New → Fix Released
Changed in gnome-terminal (Fedora):
importance: Unknown → Medium
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.