Ubuntu
gnome-terminal package

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
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)
Fix Released
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

Revision history for this message
In , Bevis (bevis-redhat-bugs) wrote :

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.

Revision history for this message
In , Bevis (bevis-redhat-bugs) wrote :

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%

Revision history for this message
In , George (george-redhat-bugs) wrote :

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.

Revision history for this message
don hardaway (don-hardaway) wrote :
Revision history for this message
Apport retracing service (apport) wrote : Stacktrace.txt (retraced)

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

Revision history for this message
Apport retracing service (apport) wrote : ThreadStacktrace.txt (retraced)
Changed in gnome-terminal (Ubuntu):
importance: Undecided → Medium
tags: removed: need-i386-retrace
Revision history for this message
Paul Sladen (sladen) wrote :

Macports: http://trac.macports.org/ticket/18142

visibility: private → public
Revision history for this message
Paul Sladen (sladen) wrote :

Previously appeared as: bug #298426

Changed in gnome-terminal (Ubuntu):
status: New → Confirmed
Revision history for this message
In , Paul (paul-redhat-bugs) wrote :

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

Revision history for this message
Paul Sladen (sladen) wrote :

Arch: http://bbs.archlinux.org/viewtopic.php?id=56472

Revision history for this message
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
"

Bug Watch Updater (bug-watch-updater)
Changed in gnome-terminal (Debian):
status: Unknown → New
Bug Watch Updater (bug-watch-updater)
Changed in gnome-terminal (Fedora):
status: Unknown → Confirmed
Pedro Villavicencio (pedro)
Changed in gnome-terminal (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
Max Bowsher (maxb) wrote :

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

Revision history for this message
Gerhard (mail-gbalthasar) wrote :

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

Revision history for this message
Gerhard (mail-gbalthasar) wrote :

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

Revision history for this message
Brian J. Murrell (brian-interlinx) wrote :

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.

Revision history for this message
Ross Alexander (ross-alexander) wrote :

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.

Revision history for this message
In , Bug (bug-redhat-bugs) wrote :

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

Revision history for this message
In , Paul (paul-redhat-bugs) wrote :

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

Revision history for this message
In , Bevis (bevis-redhat-bugs) wrote :

Yes, this is still a problem with Fedora 11.

Revision history for this message
In , Bevis (bevis-redhat-bugs) wrote :

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

Revision history for this message
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.

Revision history for this message
Malaise (malaise) wrote :

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

Revision history for this message
Brian J. Murrell (brian-interlinx) wrote : Re: [Bug 436188] Re: gnome-terminal assert failure: ERROR:terminal-app.c:1444:terminal_app_init: assertion failed: (app->default_profile_id != NULL)

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. :-(

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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?

Revision history for this message
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
Revision history for this message
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.

Revision history for this message
In , Bug (bug-redhat-bugs) wrote :

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

Revision history for this message
In , Bug (bug-redhat-bugs) wrote :

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.

Revision history for this message
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

Revision history for this message
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?

Revision history for this message
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.

Bug Watch Updater (bug-watch-updater)
Changed in gnome-terminal (Debian):
status: New → Fix Released
Bug Watch Updater (bug-watch-updater)
Changed in gnome-terminal (Fedora):
importance: Unknown → Medium
status: Confirmed → Won't Fix
Revision history for this message
Paul White (paulw2u) wrote :

GNOME 2 package is obsolete
Further to comments #21 and #24 issue fixed
Debian task also showing fixed

Changed in gnome-terminal (Ubuntu):
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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