gedit fails to start on first try, but does on the second

Reported by Curtis Hovey on 2011-08-16
198
This bug affects 31 people
Affects Status Importance Assigned to Milestone
Unity
High
Mikkel Kamstrup Erlandsen
unity-2d
High
Unassigned
unity-lens-applications
High
Mikkel Kamstrup Erlandsen
unity-lens-files
High
Mikkel Kamstrup Erlandsen
gedit (Ubuntu)
Medium
Unassigned
Oneiric
Medium
Unassigned
unity (Ubuntu)
High
Mikkel Kamstrup Erlandsen
Oneiric
High
Mikkel Kamstrup Erlandsen
unity-lens-applications (Ubuntu)
Undecided
Unassigned
Oneiric
Undecided
Unassigned
unity-lens-files (Ubuntu)
Undecided
Unassigned
Oneiric
Undecided
Unassigned

Bug Description

The gedit window fails to appear when I start gedit on my first try. It does appear on my second try. This is true when starting from the launcher, opening a document from a folder, or opening a file using the terminal. I can see gedit did started the first time; the process is running.

If I start gedit using --standalone it does work the first time. This implies that default behaviour is to start gedit in the background. The file is ignored when gedit starts in the background, so a second call is needed to load the document.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: gedit 3.1.3-0ubuntu1
ProcVersionSignature: Ubuntu 3.0.0-8.11-generic-pae 3.0.1
Uname: Linux 3.0.0-8-generic-pae i686
NonfreeKernelModules: nvidia wl
Architecture: i386
Date: Tue Aug 16 10:29:05 2011
ExecutablePath: /usr/bin/gedit
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: gedit
UpgradeStatus: Upgraded to oneiric on 2011-07-30 (17 days ago)

Curtis Hovey (sinzui) wrote :
Jean-Baptiste Lallement (jibel) wrote :

Thanks for your report.

I can confirm this behavior and think bug 808918 is a duplicate. I'm setting to confirmed and targeting for Oneiric because gedit is a core application.

Changed in gedit (Ubuntu):
importance: Undecided → Medium
status: New → Confirmed
Changed in unity (Ubuntu):
status: New → Confirmed
assignee: nobody → Canonical Desktop Experience Team (canonical-dx-team)
Changed in unity (Ubuntu Oneiric):
importance: Undecided → Medium
importance: Medium → High
Jean-Baptiste Lallement (jibel) wrote :

Added a task for unity. It doesn't happen when launched from a terminal.

David Barth (dbarth) on 2011-08-19
Changed in unity (Ubuntu Oneiric):
assignee: Canonical Desktop Experience Team (canonical-dx-team) → Jason Smith (jassmith)
David Barth (dbarth) wrote :

So that bug and bug 808918 seem to indicate that this is not a problem in either u2d, u3d or bamf, but more a regression in gedit. It was working in natty, and the part of the code that starts applications didn't change in that regard. Besides the anomaly is limited to gedit and other programs don't exhibit the same issue.

Changed in unity (Ubuntu Oneiric):
status: Confirmed → Invalid
assignee: Jason Smith (jassmith) → nobody
Curtis Hovey (sinzui) wrote :

As of my updates this morning, gedit is starting correctly from the terminal and the launcher. I think this issue was caused by a combination of libs that have changed. This is fixed for me.

Curtis Hovey (sinzui) on 2011-09-07
Changed in gedit (Ubuntu Oneiric):
status: Confirmed → Fix Released
Omer Akram (om26er) wrote :

the issue happens when a document file is opened from within the files & folders lense, sometimes gedit would open the other it wont

Changed in gedit (Ubuntu Oneiric):
status: Fix Released → Won't Fix
status: Won't Fix → Confirmed
Doug McMahon (mc3man) wrote :

Just to add - from the files & folder lens - it's exactly every other time here, starting with doesn't, does. doesn't does, ect.

The only exception to that is if another file is open in gedit, whether on the same or a different workspace

Curtis Hovey (sinzui) wrote :

I have not experienced this in about a month. The launchpad/console issue is fixed, but the problem appears to have mutated. as stated above the dash is starting gedit as a server. The window will not appear until another instance is started either by running gedit or choosing a document that will run gedit.

Alberto Mardegan (mardy) wrote :

I can reproduce this quite easily:

1) Press Alt + F2, type "gedit", press Enter
2) if gedit opens, close it
3) jump to 1)

It really works only every other time. The curious thing is that if I kill unity-applications-daemon, and start it from the console, then the Dash always succeeds in launching gedit.

Can everyone confirm that this only happens when using alt-f2, and *not* when using the normal dash (ie. hit <super> and type 'gedit'). That's the behavior I am seeing here at least.

(forgot to add) ... and *only* for gedit, correct?

Doug McMahon (mc3man) wrote :

correct - when trying to open gedit from Alt+F2 it only opens opens every other time
(same as when trying to open a text file from the files lens which defaults to gedit, if switched to another default editor then no issue in the lens

Sebastien Bacher (seb128) wrote :

Seems like it has something to do with unity or how unity is starting gedit at least, Mikkel it seems you started looking at it, do you want to own the bug for the unity team? ;-) If not feel free to unassign or reassign to somebody else in dx

Changed in unity (Ubuntu Oneiric):
status: Invalid → Confirmed
assignee: nobody → Mikkel Kamstrup Erlandsen (kamstrup)
Paul Kenyon (rixoff) wrote :

#848631 is a duplicate. I made a comment in there that may or may not be relevant:

In a terminal, run gedit. Nothing will happen. Then, in a second terminal, run gedit again. Now a window pops up. The interesting thing is the second instance exited immediately. The first instance is still running, but now the following message appears on STDERR:

** (gedit:5671): CRITICAL **: _gedit_app_get_window_in_viewport: assertion `GEDIT_IS_WINDOW (window)' failed

I had a similar problem with empathy's chat window not showing up the first time you click Chat (but it does the second time.) Is this perhaps a problem with Unity?

Michael Terry (mterry) wrote :

This is because in Unity's environment, DBUS_STARTER_ADDRESS is set. And in gedit (gedit-dbus.c:767), that will trigger gedit to start as a service instead of a standalone window. So it won't show anything, but it will be around to grab and proxy future gedit opens (as you see when you try to launch it the second time).

Not sure of the proper fix for this yet.

Michael Terry (mterry) wrote :

Looking at the DBus spec [1], DBUS_STARTER_ADDRESS is used when auto-launching DBus services. So this is arguably reasonable behavior on gedit's part, and it's confusing for applications that Unity will have that variable set for its subprocesses.

I would argue the best fix is for Unity to strip DBUS_STARTER_ADDRESS and DBUS_STARTER_BUS_TYPE from subprocess environments.

[1] http://dbus.freedesktop.org/doc/dbus-specification.html

@Michael: I don't see DBUS_STARTER_ADDRESS set here. I tried starting a gnome-terminal from both the launcher and the dash...

Sorry Michael, Seb just taught me on IRC to use 'strings /proc/$(pidof gedit)/environ | grep DBUS', and lo and behold, my gedit *does* have the starter address set.

fwiw - i bet this behavioral change is related to gedit recently switching from a dbus-glib based single-instancing to a GApplication based one.

Changed in unity-lens-files:
importance: Undecided → High
status: New → Confirmed
Changed in unity:
importance: Undecided → High
status: New → Confirmed
Changed in unity-lens-files:
assignee: nobody → Mikkel Kamstrup Erlandsen (kamstrup)
milestone: none → 0.6.10
status: Confirmed → Fix Committed
Changed in unity:
assignee: nobody → Mikkel Kamstrup Erlandsen (kamstrup)
milestone: none → 4.20.0
status: Confirmed → Fix Committed

I added the following to both apps and files lenses and now everything starts as it should. Thanks to Michael Terry for debugging :-)

+ /* Sub processes inheriting our environment may be confused if they
+ * see a starter bus set */
+ Environment.unset_variable ("DBUS_STARTER_ADDRESS");
+ Environment.unset_variable ("DBUS_STARTER_BUS_TYPE");

Changed in unity-lens-applications:
assignee: nobody → Mikkel Kamstrup Erlandsen (kamstrup)
importance: Undecided → High
status: New → Fix Committed
milestone: none → 0.4.12
Didier Roche (didrocks) on 2011-09-28
Changed in unity (Ubuntu Oneiric):
status: Confirmed → Invalid
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package unity-lens-applications - 0.4.10-0ubuntu2

---------------
unity-lens-applications (0.4.10-0ubuntu2) oneiric; urgency=low

  * Cherry-pick from upstream:
    - gedit fails to start on first try, but does on the second (LP: #827414)
 -- Didier Roche <email address hidden> Wed, 28 Sep 2011 12:21:01 +0200

Changed in unity-lens-applications (Ubuntu Oneiric):
status: New → Fix Released
Martin Pitt (pitti) wrote :

I suppose this is not a gedit bug, as it starts up just fine from a terminal.

Changed in gedit (Ubuntu Oneiric):
status: Confirmed → Invalid
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package unity-lens-files - 0.6.10-0ubuntu1

---------------
unity-lens-files (0.6.10-0ubuntu1) oneiric; urgency=low

  * New upstream release.
    - Unity's files lens fails to mount bookmarked remote shares (LP: #760309)
    - gedit fails to start on first try, but does on the second (LP: #827414)
    - Files lens should also search Downloads (LP: #748915)
    - Dash opens browser when selecting a FTP-bookmark (LP: #862112)
 -- Didier Roche <email address hidden> Thu, 29 Sep 2011 15:49:50 +0200

Changed in unity-lens-files (Ubuntu Oneiric):
status: New → Fix Released
Michal Hruby (mhr3) on 2011-09-29
Changed in unity:
status: Fix Committed → Fix Released
Changed in unity-lens-applications:
status: Fix Committed → Fix Released
Changed in unity-lens-files:
status: Fix Committed → Fix Released
tags: added: iso-testing
tags: added: rls-mgr-o-tracking

Similar bug 808918 has been marked as a duplicate of this bug, but the behavior is a bit different and it persists even though this bug has been fixed (it seems reliably reproducible on a fully updated Precise system), so I suspect that it is not really a duplicate. I have commented in bug 808918 (https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/808918/comments/9) with details.

hdante (hdante) wrote :

I'm having this problem on 11.10 with unity 2d:

- click on the panel, write terminal, execute
hdante@aielwaste:~$ set | grep -i dbus
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-AWtwvAGZYd,guid=e5ab56cebeaea834bcdeba6b00000104
DBUS_STARTER_ADDRESS=unix:abstract=/tmp/dbus-AWtwvAGZYd,guid=e5ab56cebeaea834bcdeba6b00000104
DBUS_STARTER_BUS_TYPE=session
  gitcvs.dbuser
_qdbus ()
hdante@aielwaste:~$ gedit
^C
hdante@aielwaste:~$ unset DBUS_STARTER_ADDRESS DBUS_STARTER_BUS_TYPE
hdante@aielwaste:~$ gedit
hdante@aielwaste:~$

It only happens with unity 2d. I'm so pissed off. I just rm -rf ~/.* thinking it was a lost socket.

Glennz nl (glenn-de-groot) wrote :

It´s still here on Unity-2D.

I still have this in Unity 2D as well, in Precise, still as described in bug 808918. (I haven't tested in Oneiric in a while.)

Glennz nl (glenn-de-groot) wrote :

Because it seems like this only happens to Unity 2D users, I added Unity 2D to affected list.

This is NOT fixed. Still an issue in ubuntu 11.10 with all the updates up to date.

I have this problem on 11.10 with unity 2d

hdante (hdante) wrote :

Reporting a bug in Ubuntu is like trying to have a serious conversation with /dev/null

Changed in unity-2d:
status: New → Confirmed
Gerry Boland (gerboland) on 2012-01-19
Changed in unity-2d:
importance: Undecided → High
milestone: none → 5.2.1
Gerry Boland (gerboland) wrote :

Thanks for all your comments. I can see how this is unfuriating. I'm using today's trunk on Precise, and I'm not seeing this problem, but perhaps I'm not doing the correct thing. I will investigate more.

We added the fix mentioned above (see bug 873027) on 12 Oct, but that was too late for Oneiric.

Erik Reuter (misc71) wrote :

I got tired of waiting for this to be fixed, so I implemented a workaround.

I moved the gedit binary to gedit.bin, then I created a shell-script named "gedit" that calls gedit.bin with the --standalone option:

% mv /usr/bin/gedit /usr/bin/gedit.bin
% vi /usr/bin/gedit

#!/bin/sh
/usr/bin/gedit.bin --standalone "$@"

% chmod 755 /usr/bin/gedit

Hopefully this helps someone who is having this issue.

Changed in unity-2d:
milestone: 5.2.1 → 5.6
Gerry Boland (gerboland) wrote :

Running Precise, I'm unable to reproduce this bug. Can anyone else using Precise confirm?

Vadim Rutkovsky (roignac) wrote :

Can't reproduce in Unity-2d 5.4.0-0ubuntu1 via steps from comment #25

Gerry, I had this problem in 11.10 (comment #30), but I just installed Precise Beta 1 and can't reproduce anymore too. Seems to be fixed.

About comment #36: in both cases i ran unity-2d.

Didier Roche (didrocks) on 2012-03-05
Changed in unity-2d:
milestone: 5.6 → 5.8
Gerry Boland (gerboland) wrote :

Thanks for the comments Vadim & Jorge!

Gerry Boland (gerboland) wrote :

I'm still unable to reproduce, so marking as fix released.

Changed in unity-2d:
status: Confirmed → Fix Released
milestone: 5.8 → none

Is this issue going to be fixed in 11.10? I still have the issue and I install any available updates daily.

(Using Ubuntu 11.10 AMD64 Unity3D)

entonjackson (aj-mysc) wrote :

Bug is still present in precise.

For me, this problem went away after upgrade to 12.04.

Problem was fixed in 12.04 for me as well.

Jason P. (jasonp) wrote :

For me the problem is still present in 12.04 fully upgraded so far.

I've had the exact same problem since I upgraded from 12.04 to 12.10! I've never had it before and I've been using Ubuntu since v4 with heavy usage of gedit!!!...I can confirm all of this:

gedit 3.6.1
-open just fine when launched from Unity or the terminal
-opens the second time when double-clicking or hitting enter while having selected the file (process appears on system monitor the first time I double-click though!)

Very strange indeed...

Remdul (buijs512) wrote :

This is most likely not related to Unity, for the same problem occurs for me with Linux Mint 13 XFCE.

If gedit is started from terminal (just "gedit", no arguments passed), it doesn't show up, nothing is printed in terminal and thus effectively hangs in limbo. Task Manager sees it sitting around consuming 0% CPU, it doesn't terminate on it's own.
When gedit is then started again, either via desktop shortcut/menu or another terminal window, it causes the first gedit instance to terminate with this message:

** (gedit:3900): CRITICAL **: _gedit_app_get_window_in_viewport: assertion `GEDIT_IS_WINDOW (window)' failed

The second instance then shows up normally. If a filename was passed as argument, it opens the file as expected.

If gedit is run with --standalone option, it always starts normally without fault, no matter what I tried.

The above is 100% reliably reproducable for me.

Now there are some oddities. For example when I start gedit from a panel (FYI: xfce4-panel 4.10.0), it always starts normally (launcher command: "gedit %U", or just "gedit").
When I doubleclick to open a text file in Thunar, the bug also occurs. When I do the same in Nautilus, the same works without the problem.

By the looks of it, this is a gedit bug. Obviously, gedit tries to find a running instance so it can open a new tab in the existing instance. It probably lacks a robust handler for the condition where it fails -- for whatever reason -- to find a running instance.

Hope that helps.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers