emacs23/24 and other GTK applications do not start when run in Kubuntu 13.04 with oxygen-gtk theme enabled

[Paul White]

[Impact]

* Emacs24 does not startup in KDE

[Test Case]

* Install emacs24
* Set gtk3 theme to oxygen-gtk via systemsettings > Application Appearence > GTK
* Run emacs24
* Install update
* Try and run emacs24 again

[Regression Potential]
* Minimal
* Upstream release for oxygen-gtk3 is only a bug fix release

If I try to run emacs23 in Kubuntu 13.04, (KDE 4.10.0) I am finding that the GUI starts only some of the time.

If the GUI doesn't start then I will only see a process running in htop or similar.

Starting emacs in a terminal window with the -nw argument or installing the Lucid interface shows that emacs does run each time it starts so the problem is either with the emacs GTK interface or the GTK libraries.

Emacs24 exhibits the same problem.

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: emacs23 (not installed)
ProcVersionSignature: Ubuntu 3.8.0-9.18-generic 3.8.1
Uname: Linux 3.8.0-9-generic x86_64
ApportVersion: 2.9-0ubuntu2
Architecture: amd64
Date: Sun Mar 3 14:19:01 2013
InstallationDate: Installed on 2013-01-05 (57 days ago)
InstallationMedia: Kubuntu 13.04 "Raring Ringtail" - Alpha amd64 (20130104)
MarkForUpload: True
ProcEnviron:
 LANGUAGE=en_GB:en
 TERM=screen-256color
 PATH=(custom, no user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: emacs23
UpgradeStatus: No upgrade log present (probably fresh install)

[tbjablin (tjablin)]

I can confirm this bug. Switch the gtk theme to Raliegh causes emacs to start reliably. The relevant part of the gdb backtrace is:

#0 0x00007f48f1bf63cd in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f48f50e915c in g_main_context_poll (n_fds=1, fds=0xee1330, timeout=-1, context=0xd51620, priority=<optimized out>)
    at /build/buildd/glib2.0-2.35.8/./glib/gmain.c:3995
#2 g_main_context_iterate (context=0xd51620, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
    at /build/buildd/glib2.0-2.35.8/./glib/gmain.c:3696
#3 0x00007f48f50e963a in g_main_loop_run (loop=0xee1280) at /build/buildd/glib2.0-2.35.8/./glib/gmain.c:3895
#4 0x00007f48f512b101 in g_spawn_sync (working_directory=working_directory@entry=0x0, argv=<optimized out>, envp=envp@entry=0x0,
    flags=flags@entry=G_SPAWN_SEARCH_PATH, child_setup=child_setup@entry=0x0, user_data=user_data@entry=0x0,
    standard_output=standard_output@entry=0x7fffd2ec6ad8, standard_error=standard_error@entry=0x0, exit_status=exit_status@entry=0x0,
    error=error@entry=0x0) at /build/buildd/glib2.0-2.35.8/./glib/gspawn.c:434
#5 0x00007f48f512b578 in g_spawn_command_line_sync (command_line=<optimized out>, standard_output=0x7fffd2ec6ad8, standard_error=0x0,
    exit_status=0x0, error=0x0) at /build/buildd/glib2.0-2.35.8/./glib/gspawn.c:735
#6 0x00007f48e9bca184 in Oxygen::QtSettings::kdeConfigPathList() const ()

I believe this patch to glib is ultimately responsible: https://git.gnome.org/browse/glib/commit/glib/gspawn.c?id=ce0022933c255313e010b27f977f4ae02aad1e7e

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Andy Choens (andy-choens)]

This bug affects me too. If there is an update to glib (or anything else) I am willing to be a tester.

[Paul White (paulw2u)]

Recent tests show that the problem is with the oxygen-gtk themes (GTK2 and GTK3).

When other themes are enabled both the GUI for emacs23 and emacs24 start every time.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Andy Choens (andy-choens)]

If someone could offer a suggestion on how to approach looking into this, I'll try to help in anyway that I can. I don't know squat about theming or GTK theme engines, but this affects me and I'd like to get it resolved. Pitching in is one way to help make that happen, so here I am.

[Paul White (paulw2u)]

Andy, we need to establish exactly in which package the bug lies. I added the gkt-engines package after a little research. I might be right, I might be wrong, I really don't know. The bug probably isn't in emacs itself anyway.

Seeing that there are just four weeks to go before Kubuntu 13.04 is released and that only three of us have acknowledged the bug I fear that it won't be fixed in time. I think there needs to be more testing to establish under what conditions emacs will or will not run and then some research done to establish which package is at fault.

I've done my bit, I believe Kubuntu's oxygen themes to be the problem.

[Andy Choens (andy-choens)]

That is too bad. In the meantime, I guess I will force GTK3 apps to use the Adwaita theme. Seems to work and looks better than a plain, unthemed GTK3.

[Mikael Gerdin (mgerdin)]

Proably affects Firefox and Thunderbird too, see Bug 963736

[Alain (alaindelplanque)]

I have the same problem. Both with emacs23 and emacs24

[Alain (alaindelplanque)]

When I compile emacs24.3, the problem remains with
./configure --with-x-toolkit=gtk2
./configure --with-x-toolkit=gtk3

emacs doesnt start, no error report in the console

When I use
./configure --with-x-toolkit=athena
It's OK

[Imad (imaduddinh)]

Just upgraded to Kubuntu 13.04 today and find that Emacs24 is no longer usable.

As tbjablin states above, switching to Raleigh theme provides a workaround.

[TomHarrison (l12436)]

after i use the do-release-upgrade to upgrade from 12.10 to 13.04.
the hime and gcin no longer work.
just ibus can work.
is there any package or config i need to remove in 13.04?
or this is a bug in 4.10.2 13.04 version?

Reproducible: Always

[Christoph-maxiom (christoph-maxiom)]

This gcin input method server is not created by the KDE community. For help, please ask in the forums of your distribution at http://ubuntuforums.org/

If you believe there is a bug, please report any issues related to gcin directly to the bug tracker of your distribution via https://bugs.launchpad.net/ubuntu

[TomHarrison (l12436)]

i have found the bug of this problem.
it seems the .gtkrc-2.0 config has something error with the hime.
and i found that file is create by the kde gtk config.
is this kde problem or the input method problem?

[Christoph-maxiom (christoph-maxiom)]

> is create by the kde gtk config

Can you be more specific what you do to create the broken .gtkrc file?

[TomHarrison (l12436)]

Created attachment 79489
this is the config that cause the hime could not start.

if this config remove or let it broken.
the hime turn normal.

[TomHarrison (l12436)]

i also try the livecd kubuntu.
it will cause this problem too.
because the ubuntu unity did not has oxygen style.
so i did not try.

[Christoph-maxiom (christoph-maxiom)]

Bugs for the GTK configuration in System Settings are not tracked at the KDE bug tracker, because the GTK configuration module is a distribution-specific add-on.

Please report this issue directly to the bug tracker of your distribution via https://bugs.launchpad.net/ubuntu

Other than that, I fail to see any error in the attached .gtkrc configuration file. If other components fail to correctly initialize because of this file, they are probably disabled by default, and need to be enabled in the .gtkrc file.

[TomHarrison (l12436)]

i am i little sure about the gtk error.
when i change the style to the Raleigh, which is the gtk default on the kde.
and the hime error is gone.
are you sure that is not the kde problem?

[TomHarrison (l12436)]

and the .xsession-error is continue show this message
QPixmap: It is not safe to use pixmaps outside the GUI thread

[TomHarrison (l12436)]

this is the error maybe opening the gtk config
systemsettings(332)/kcontrol KCModuleLoader::loadModule: This module still uses K_EXPORT_COMPONENT_FACTORY. Please port it to use KPluginFactory and K_EXPORT_PLUGIN.

[TomHarrison (l12436)]

and since upgrade to the 13.04.
the kde has crash frequently because of the gtk.

[Kevin Hearn (kbhearn)]

Also recently upgraded to Kubuntu 13.04 and am having a similar issue with another gtk2 application (eboard) - how do i go about changing the theme engine to try to work around it?

[Kevin Hearn (kbhearn)]

Nevermind, found it. It is the same bug that was causing eboard to freeze, switching to Raleigh fixed it.

[TomHarrison (l12436)]

i have found the error in the oxygen-engines-gtk the settings.
gtkrc file
inside " style "oxygen-default" "
"
     engine "oxygen-gtk"
     {}
"
this two line cause the gtk engine error.
without this two line.
the hime work normal

[Olof Staffans (olof-staffans)]

I've got the same problems (see Bug 1173857).

Sorry for my ignorance, but how do I change the theme from oxygen to something else?

I just did some testing to se what causes emacs23 to hang:

- If I start emacs from a terminal, then it most of the time does to open a new window.
- emacs -nw from a terminal works fine (as also noticed above)
- If I start emacs from the kubuntu menu, then it (almost) always starts, and does not hang immiately. After that there are many things that I can do before Emacs hangs, such as:

- compose an E-mail message (using M-X mail). It hangs only when I try to send the mail (using Ctl-C).
- Write some text in the scratch-window, and save it to the disk.
- I can edit some more, and do a "recover file" to get back what I saved earlier, and it still works fine.
- Many of the the help menues under Ctl-H work fine. However, Ctl-H r makes it hang. After that I have to wait some time before it again starts properly.
- The window splitting commands work fine.

However, there are certain commands that always make Emacs hang:

- Find file (Ctl-X Ctl-F)
- Visit File (Ctl-X Ctl-V)
- Dired
- Sending of Mail
- Ctl-H r (Display the Emacs manual in Info mode.)

[Colin Bell (colbell)]

>> Olof Staffans (olof-staffans) wrote 22 minutes ago:
>> Sorry for my ignorance, but how do I change the theme from oxygen to something else?

Go into the KDE System settings.
Then click "Application Appearance" under the "Common Appearance and Behavior"
Then click GTK.

I changed the GTK2 theme to Raleigh and the GTK3 to Emacs. I'm not sure which of the two was required but Emacs now works for me.

BTW I noticed that emacs-snapshot didn't have this problem.

[Olof Staffans (olof-staffans)]

For me it was enought to switch GTK3 to "Emacs". The GTK2 was already someting else than oxygen-gtk.

[Hugo Pereira Da Costa (hugo-pereira)]

we need a backtrace of what is really causing the failure to start.
Can you try run hime and gcin from gdb, then "bt" (after the program crashed), and post the result here ?

Also: what is the version of oxygen-gtk that you are using ?

[TomHarrison (l12436)]

actually it did not crash.
it just hang.
that why i did not upgrade the crash report :((

[Hugo Pereira Da Costa (hugo-pereira)]

ok. That is harder to help debug.
still need the version of oxygen-gtk :)
and if you feel daring, you can always try to download and build the latest version of oxygen-gtk from source (it is not difficult I promise). See: http://kde-look.org/content/show.php/?content=136216

There is a chance that the bug was fixed since then (although the version of oxygen-gtk above would help double-checking that).

[Hugo Pereira Da Costa (hugo-pereira)]

... note that I can't reproduce, here at least hime starts just fine, as seed at:
http://wstaw.org/m/2013/04/29/plasma-desktopay2362.png

[TomHarrison (l12436)]

(In reply to comment #15)
> ... note that I can't reproduce, here at least hime starts just fine, as
> seed at:
> http://wstaw.org/m/2013/04/29/plasma-desktopay2362.png

you can put my .gtkrc-2.0 in the home directory.
and try again.
this bug is only appear on the 13.04.
and it seems cause my the engine in the grkrc.

[TomHarrison (l12436)]

by the engine.
i input the wrong word.

[Hugo Pereira Da Costa (hugo-pereira)]

yes, that is the engine I am using, oxygen-gtk
(which conditions the appearance of the application).

[TomHarrison (l12436)]

(In reply to comment #18)
> yes, that is the engine I am using, oxygen-gtk
> (which conditions the appearance of the application).

also use my .gtkrc-2.0 and kde-config-gtk ?

[Hugo Pereira Da Costa (hugo-pereira)]

yes.
But I use latest version of oxygen-gtk.
Hence my asking about the version you are using.

[TomHarrison (l12436)]

ii gtk2-engines-oxygen:amd64 1.3.1-0ubuntu1 amd64 Oxygen widget theme for GTK+-based applications
ii gtk3-engines-oxygen:amd64 1.1.1-0ubuntu1 amd64 Oxygen widget theme for GTK3-based applications

maybe you can try the kubuntu iso.
i install from that.
and i have try in the livecd.
it will cause that problem too.

[TomHarrison (l12436)]

by the way, what OS did you use?

[Hugo Pereira Da Costa (hugo-pereira)]

no I will not.

These versions are obsolete, and wont be fixed.
Latest bugfix releases are 1.3.3 for gtk2-engine,
and 1.1.3 for gtk3-engine.

Please confirm whether or not the bug is still present with these versions. (either ask around for packages for these in ubuntu forums, or build them manually).

As for the second question: I use mageia, but that is irrelevant. As one of the two developpers of oxygen-gtk, I use only the latest code, compile from source, manually.

Cheers,

Hugo

[TomHarrison (l12436)]

1.3.3 but i use the ppa or offical release is 1.3.1.
only 1.3.1 could install.
could you offer a url that could install or build.

[TomHarrison (l12436)]

i see the 1.3.3 version.
actually the version i installed is 1.3.2.1.
i have build by myself.

and now i will build the 1.3.3 to try.

[TomHarrison (l12436)]

is it need to restart the computer or restart anything ?

[TomHarrison (l12436)]

it still cound not start.
i also file a bug on the ubuntu.
bug according to no crash report.
so i do not think they will bother me.

[Hugo Pereira Da Costa (hugo-pereira)]

in principle, nope
now, if you are using a 64 bits machine, make sure that the libraries are installed in /usr/lib64/gtk-2.0/2.10.0/engines/
and not in /usr/lib/gtk-2.0/2.10.0/engines/
you might need to add -DLIB_SUFFIX=64 as an extra option to cmake, before compiling.

[TomHarrison (l12436)]

it auto detect is install in /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/engines :))

[TomHarrison (l12436)]

is there any IRC or anything could online chat?

[TomHarrison (l12436)]

yes, also could not start either.

[Hugo Pereira Da Costa (hugo-pereira)]

ok. Since you have the source code built, and if you are willing to help tracking this down (thanks!), then you could try compile in debug mode, then start hime from a terminal (konsole), and post the output on screen here.

To compile in debug mode:

  cmake -DOXYGEN_DEBUG=1

As for IRC, #oxygen is the right channel, but sadly I have no time these days to log on it, so that it would not help much. (hugo_work is my nick)

Keep me posted concerning the above.

Hugo

[TomHarrison (l12436)]

there are a problem. i still did not see the debug XDDDD.
where did it output
.xsession-error ?

[TomHarrison (l12436)]

and the gcin has the same problem with the oxygen gtk

[TomHarrison (l12436)]

and this is the bug report that file by me.
because there is no run error.
so i did not know that if he could see this bug.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1173028

[Hugo Pereira Da Costa (hugo-pereira)]

the debug output should appear in the same terminal as the one from where you started hime.
if not it might mean that you are not using the oxygen-gtk version you just compiled.
to make sure of that, try run "oxygen-gtk-demo" from the same terminal and report if you see some debug output there. You should see a lot. Things like:

Oxygen::draw_flat_box - widget: 0x1061110 (GtkIconView) state: selected shadow: none detail: icon_view_item
Oxygen::draw_layout - widget: 0x1061110 (GtkIconView) state: active detail: cellrenderertext
...

[TomHarrison (l12436)]

i see the output

Oxygen::theme_init
Oxygen::RCStyle::registerType
Oxygen::StyleWrapper::registerType
Oxygen::StyleWrapper::registerType - done
Oxygen::Style::instance - creating new style.
Oxygen::StyleHelper::StyleHelper
Oxygen::Animations::Animations
Oxygen::ArgbHelper::ArgbHelper
Oxygen::ShadowHelper::ShadowHelper
Oxygen::WindowManager::WindowManager
Oxygen::StyleHelper::initializeRefSurface - screen: 0x1835000 window: 0x183f000
ApplicationName::initialize - from pid: hime_ from gtk: hime_
ApplicationName::initialize - from pid: hime_ from gtk: hime_ internal: Unknown version: 0x0

[TomHarrison (l12436)]

and this is gcin.

Oxygen::theme_init
Oxygen::ThemingEngine::registerType
Oxygen::create_engine
Oxygen::ThemingEngine::classInit
Oxygen::ThemingEngine::instanceInit
Oxygen::StyleHelper::StyleHelper
Oxygen::Animations::Animations
Oxygen::ArgbHelper::ArgbHelper
Oxygen::ShadowHelper::ShadowHelper
Oxygen::WindowManager::WindowManager
Oxygen::StyleHelper::initializeRefSurface - screen: 0xa6c0d0 window: 0xa78000

[Hugo Pereira Da Costa (hugo-pereira)]

thanks for the output.
Now, this is strange, and very early during startup.
For the record: what is the version of hime that you are using ?

[Hugo Pereira Da Costa (hugo-pereira)]

(here I have installed 0.9.10)

[Hugo Pereira Da Costa (hugo-pereira)]

(PS: I can start gcin just fine too. See: http://wstaw.org/m/2013/04/29/plasma-desktopIo2362.png)

[TomHarrison (l12436)]

same of your version.
download from the network.
and the gcin version is the offical verion
2.7.6

[TomHarrison (l12436)]

my kde using the color obsidian coast
so that i could figure out that the gtk is using the oxygen theme or not :)))

[Vasilis Vasaitis (vvas)]

Same problem here, with Kubuntu 13.04 and the oxygen-gtk theme. All the mentioned workarounds work, but of course they're just workarounds. (In my case I addressed this by using the emacs-snapshot package from ppa:cassou/emacs, which doesn't exhibit the problem for whatever reason).

[Ruslan (b7-10110111)]

I can't start gcin in Ubuntu 13.04 either. But even if I select GTK themes as Raleigh or Emacs, it doesn't start too. Also, in Ubuntu 13.04 at least, gcin is linked to gtk3 not gtk2.

[Ruslan (b7-10110111)]

OK. I can reproduce the problem with gcin. On correct startup it just makes tray icons, but doesn't show any windows - this is why I thought it doesn't start. Now I can see that oxygen-gtk makes it not start.
Here's a backtrace: http://pastebin.com/wfhpKRis

[Ruslan (b7-10110111)]

Hime backtrace is similar despite it's gtk2 based. Here's an updated backtrace from gcin with debug symbols and current git oxygen-gtk3: http://pastebin.com/yTrKygMV

[Hugo Pereira Da Costa (hugo-pereira)]

ok. So g_spawn_command_line_sync is the bad guy
this might actually be a glib issue, and not oxygen-gtk
What is the version you guys are using ?
Then we would need a workaround. We use g_spawn to get the list of kde config path, to look for configuration files. This is a way to launch eternal processes (here kde4-config) and wait for the result before proceceeding.

[Hugo Pereira Da Costa (hugo-pereira)]

(I have glib-2.34.3)

[Hugo Pereira Da Costa (hugo-pereira)]

reading the backtrace, you have glib 2.36 or so.
... that might explain.
Ruslan, any chance you can rollback or test on another computer ?
I'll try to update glib on my side (but likely not this evening).

[Ruslan (b7-10110111)]

My glib version is 2.36.0.
I've tried changing kde4-config command to true and asdfasdfadf, but it fails in the same way.
I in fact doubt it's a glib issue. I'd rather suspect the way these apps use threads. There might be some condition when we must not start any processes, but I'm not a threading guru and may be wrong.

[Hugo Pereira Da Costa (hugo-pereira)]

@Ruslan, yeah well, but I can't reproduce the issue on my side.
So not only the app, but "something else" at least must enter the game ...
I agree this is unlikely glib only otherwise all gtk applications would stop to work, since we use this all the time.

[Hugo Pereira Da Costa (hugo-pereira)]

Note: we could try use the good old "popen" command. That should not never fail

[Ruslan (b7-10110111)]

I've tested on Ubuntu 12.04.2 LTS with glib 2.32.3 and both apps work here (and gcin is gtk2-based here).

[Ruslan (b7-10110111)]

OK, popen does do the trick. I guess I'll clean it up and push.

[Hugo Pereira Da Costa (hugo-pereira)]

awesome !
Thanks !

[Ruslan (b7-10110111)]

Git commit 51b662b0cd86fd7a960cc2f0c436441d64b2dd44 by Ruslan Kabatsayev.
Committed on 29/04/2013 at 21:24.
Pushed by kabatsayev into branch 'gtk3'.

Use popen instead of g_spawn_command_line_sync()

M +18 -2 src/oxygenqtsettings.cpp
M +3 -0 src/oxygenqtsettings.h

http://commits.kde.org/oxygen-gtk/51b662b0cd86fd7a960cc2f0c436441d64b2dd44

[Ruslan (b7-10110111)]

Git commit a515ab451f54cbc930d0a09d250669255dd8a741 by Ruslan Kabatsayev.
Committed on 29/04/2013 at 21:24.
Pushed by kabatsayev into branch '1.3'.

Use popen instead of g_spawn_command_line_sync()

M +18 -2 src/oxygenqtsettings.cpp
M +3 -0 src/oxygenqtsettings.h

http://commits.kde.org/oxygen-gtk/a515ab451f54cbc930d0a09d250669255dd8a741

[Ruslan (b7-10110111)]

Git commit 5e22bbf8bf09663f2be9cd7510a956fc5ad4faba by Ruslan Kabatsayev.
Committed on 29/04/2013 at 21:24.
Pushed by kabatsayev into branch 'gtk3-1.1'.

Use popen instead of g_spawn_command_line_sync()

M +18 -2 src/oxygenqtsettings.cpp
M +3 -0 src/oxygenqtsettings.h

http://commits.kde.org/oxygen-gtk/5e22bbf8bf09663f2be9cd7510a956fc5ad4faba

[Ruslan (b7-10110111)]

@<email address hidden>
Please check if the bug is fixed for both apps and if yes, close this as fixed.

@Hugo
Please have a look at the patch, just in case I messed up ;)

[Hugo Pereira Da Costa (hugo-pereira)]

will do

[Hugo Pereira Da Costa (hugo-pereira)]

@Ruslan
will check
it likely needs some improvements, to accomodate "all" sizes as opposed to fixed size.
but I have the relevant code in place.
current patch is good enough for the time being (and technically correct), i'll just ellaborate upon this.
Thanks a bunch to go to the bottom of it.

[TomHarrison (l12436)]

thanks for help.
it work normal as usual.
the fatal problem is solve :)))

actually there another problem.
but no so fatal.
the libreoffice could not change its style.
it lock in oxygen :)))
i still find that why cause that problem.

[TomHarrison (l12436)]

because i did not know that the how to choose the option.
so i just change the confirm to resolved, the second i keep it on the first option.

[TomHarrison (l12436)]

and one thing ask.
is the fix version will in the ubuntu offical package release?
change the 1.3.1 to the newer version ?

[TomHarrison (l12436)]

and maybe you can contract the kde team that the g_spawn_command_line_sync bug

[TomHarrison (l12436)]

one thing to ask,
the three patch has different ?

[Ruslan (b7-10110111)]

> the libreoffice could not change its style.
Libreoffice is not related to KDE, it just uses some of its theme plugins which use Qt or GTK to render widgets.
> is the fix version will in the ubuntu offical package release?
We'll have to release this patch in a new version, then it depends on Ubuntu packagers whether they will take it and update their packages.
> and maybe you can contract the kde team that the g_spawn_command_line_sync bug
g_spawn_command_line_sync() is not related to KDE - it's a glib function.
> the three patch has different ?
These are patches in different branches, they are identical. It's just the way git-cherry-pick works, so that this was posted three times here for each copy of patch.

[TomHarrison (l12436)]

>g_spawn_command_line_sync() is not related to KDE - it's a glib function.
i mean that you could contract the kde team that the g_spawn_command_line_sync() has bug.
and tell the software maintainer to change the code.

[TomHarrison (l12436)]

and tell the software maintainer to change the code.(X
and tell the software maintainer to prevent using that function.

[Ruslan (b7-10110111)]

> i mean that you could contract the kde team that the g_spawn_command_line_sync() has bug.
It's likely not that this function has the bug. It may well be that it shouldn't be called when we do because of something special gcin and hime do before our method is called.
Oxygen-GTK, unfortunately, has many such invalid assumptions (but we might not know of their invalidity), which it has to do in order to implement the features we need. It's just a matter of complexity of features we put into it.

[TomHarrison (l12436)]

it seems the qtcurve has the same bug, too.
i am not sure.
i have try once.
and it not start either.

[Ruslan (b7-10110111)]

> it seems the qtcurve has the same bug, too.
Yeah, it should. It also uses this function. So you should report it to Craig (and point to possible fix here). Though he might instead devise some wittier fix :)

[Jan Schneider (yunosh)]

The same behavior can be seen when using the QtCurve GTK theme.

[5w-hugo (5w-hugo)]

Git commit 592490ea8d7dcd328b755cbb28b9be205d68168f by Hugo Pereira Da Costa.
Committed on 30/04/2013 at 14:18.
Pushed by hpereiradacosta into branch '1.3'.

Make sure that 'runCommand' reads the full output of the command (as opposed to fixed max size);
Changed first argument to std::string.

M +19 -9 src/oxygenqtsettings.cpp
M +1 -1 src/oxygenqtsettings.h

http://commits.kde.org/oxygen-gtk/592490ea8d7dcd328b755cbb28b9be205d68168f

[5w-hugo (5w-hugo)]

Git commit a8b7085a657bd7f27978c3a2765310758382e60d by Hugo Pereira Da Costa.
Committed on 30/04/2013 at 14:18.
Pushed by hpereiradacosta into branch 'gtk3'.

Make sure that 'runCommand' reads the full output of the command (as opposed to fixed max size);
Changed first argument to std::string.

M +19 -9 src/oxygenqtsettings.cpp
M +1 -1 src/oxygenqtsettings.h

http://commits.kde.org/oxygen-gtk/a8b7085a657bd7f27978c3a2765310758382e60d

[Hugo Pereira Da Costa (hugo-pereira)]

@Ruslan
Last two commits are just some tiny improvements upon your addition, to make sure the entire output of the comment is read. I have tested it works by reducing the initial size of the buffer to 16 and making sure one gets the same output.
Thanks again for the fix.

@l12436
Thanks for reporting the issue in the first place.

[TomHarrison (l12436)]

@Hugo Pereira Da Costa
> @l12436
> Thanks for reporting the issue in the first place.

you're welcome.
this problem cause me a lot of trouble.
i hope it could fix before the 4.10.3 release :)

>Yeah, it should. It also uses this function. So you should report it to Craig (and point to possible fix here). Though he might instead devise some wittier fix :)
ok, the bug report website is the same website, isn't it. :))
just change the report software. :))

[Ruslan (b7-10110111)]

@Hugo
Mm.. what's the point in converting char* to std::string just to then convert back to char* when calling popen? Looks like unnecessary redundancy to me.

@l12436
> ok, the bug report website is the same website, isn't it. :))
No it's not. AFAIK, QtCurve isn't related to KDE at all, especially its GTK part.

[TomHarrison (l12436)]

and one thing i need to ask.
how to create the runtime report like this
http://pastebin.com/wfhpKRis
i have try the gdb, but it only show the simple information.
or even no information.

[Ruslan (b7-10110111)]

@Hugo
BTW, setting size=4 instead of 4096 reveals that your improvement doesn't quite work, see output of result after fgets (repeated because of while loop):
result: "/home/r"
result: "uslan/.kde/shar"
result: "e/config/:/opt/kde4/share/confi"

[Ruslan (b7-10110111)]

@l12436
You just run the app like "gdb -ex r hime", wait until it settles, then press Ctrl+C to interrupt. Now you can do backtrace from the stage you interrupted the process. If the process is hung, you'll surely interrupt it somewhere where it loops.

[TomHarrison (l12436)]

it need to install the addition package ?
i use the command too.
it only show the interrupted.

[Ruslan (b7-10110111)]

@l12436
Can you use gdb, namely get the backtrace? See the pastebin example - it starts from ^C, which is where I pressed Ctrl+C, then you can see how to get the backtrace (bt command).

[TomHarrison (l12436)]

thanks for teaching.
now i got the backtrace too

[Ruslan (b7-10110111)]

Git commit 878b0e626311cdf847e00dfd6ff96184021c1667 by Ruslan Kabatsayev.
Committed on 30/04/2013 at 17:05.
Pushed by kabatsayev into branch '1.3'.

Fix command output reading for multi-read case

M +8 -6 src/oxygenqtsettings.cpp

http://commits.kde.org/oxygen-gtk/878b0e626311cdf847e00dfd6ff96184021c1667

[Ruslan (b7-10110111)]

Git commit f272b269cd26e783ffb811c4a3584a675fac7a2b by Ruslan Kabatsayev.
Committed on 30/04/2013 at 17:05.
Pushed by kabatsayev into branch 'gtk3'.

Fix command output reading for multi-read case

M +8 -6 src/oxygenqtsettings.cpp

http://commits.kde.org/oxygen-gtk/f272b269cd26e783ffb811c4a3584a675fac7a2b

[TomHarrison (l12436)]

(In reply to comment #85)
> Git commit f272b269cd26e783ffb811c4a3584a675fac7a2b by Ruslan Kabatsayev.
> Committed on 30/04/2013 at 17:05.
> Pushed by kabatsayev into branch 'gtk3'.
>
> Fix command output reading for multi-read case
>
> M +8 -6 src/oxygenqtsettings.cpp
>
> http://commits.kde.org/oxygen-gtk/f272b269cd26e783ffb811c4a3584a675fac7a2b

i see the repo not found

[Ruslan (b7-10110111)]

Yeah, me too. Maybe will appear later. You still can pull it in your local git and see the diff there.

[Hugo Pereira Da Costa (hugo-pereira)]

@Ruslan
Thanks for fixing. My bad.
Too bad I was fixing at the same time.
So now: using size *=2, rather than incrementing linearly the size is known to be more efficient algorithmically. So I'd rather push that. (will do on top of your changes after first discarding the ones I was about to push)

Concerning the use of std::string.
There is No conversion from const char* to std::string in the current code
the call runCommand( "..." ) implicitely calls the std::string directly
as for the call string.c_str() it access directly the const char* stored internally in the string

the advantage of using std::string instead of const char* is that it is freed automatically. You do not need to call neither malloc nor free anywhere. In the current code it makes no difference (but not overhead either), but it might makes some future use of the same method.
All in all, that's the whole idea behind using c++ instead of c, and limit c to where you have to (namely when calling gtk, glib or other functions).

[TomHarrison (l12436)]

i fix by manual :))))

[Ruslan (b7-10110111)]

> So now: using size *=2, rather than incrementing linearly the size is known to be more efficient algorithmically.
Yeah, surely, but with chunks of 512 bytes this isn't gonna increase much more than to 2KiB, so this inefficiency can be neglected in favor of cleaner code.

> There is No conversion from const char* to std::string in the current code
> the call runCommand( "..." ) implicitely calls the std::string directly
> as for the call string.c_str() it access directly the const char* stored internally in the string
Why no conversion? You call runCommand("str") and this calls std::string("str") potentially doing some initialization there. And then you call a function which needs const char*, in which case although you don't convert, but this still is redundant.

> All in all, that's the whole idea behind using c++ instead of c, and limit c to where you have
> to (namely when calling gtk, glib or other functions).
Yeah I do understand this, but you have a POSIX function here - this is just like gtk function, and we pass string literal here, for which std::string has no advantage at all.

[Hugo Pereira Da Costa (hugo-pereira)]

(In reply to comment #90)
> > So now: using size *=2, rather than incrementing linearly the size is known to be more efficient algorithmically.
> Yeah, surely, but with chunks of 512 bytes this isn't gonna increase much
> more than to 2KiB, so this inefficiency can be neglected in favor of cleaner
> code.

Depends how long the string you want to read, right ?
in principle runCommand could be re-used elsewhere for any type of command (like "cat very_long_file_with_no_linebreak")

>
> > There is No conversion from const char* to std::string in the current code
> > the call runCommand( "..." ) implicitely calls the std::string directly
> > as for the call string.c_str() it access directly the const char* stored internally in the string
> Why no conversion? You call runCommand("str") and this calls
> std::string("str") potentially doing some initialization there.

yes the initialization of the extra members of std::string on top of the const char* (which is kept unchanged, passed as a pointer).

> And then you
> call a function which needs const char*, in which case although you don't
> convert, but this still is redundant.
redundant with what ?
std::string is a pointer to const char* with a proper destructor and copy constructor. Nothing more. (well, more or less :))

>
> > All in all, that's the whole idea behind using c++ instead of c, and limit c to where you have
> > to (namely when calling gtk, glib or other functions).
> Yeah I do understand this, but you have a POSIX function here - this is just
> like gtk function, and we pass string literal here, for which std::string
> has no advantage at all.

But that's the point: disregarding of the internals of the function, I don't want it to spread.
I do not what to have to ask myself, every time I call runCommand, whether I need to free the string or not (disregarding whether it uses posix or gtk in there).

The idea is not about what's done internally, but what to expect when called by the rest of the world, without knowing what's done internally. With passing std::string, I know I don't have to care about allocation deallocation. That's the same spirit behind my writting of the oxygencairosurface, pattern, context; the timers, etc. In general, the more "self-deallocating" things you use for the arguments in your methods, the more stable your code will be. (my oppinion at least)

In any case, I'm not sure here is the right place to have this discussion.

[Ruslan (b7-10110111)]

> yes the initialization of the extra members of std::string on top of the const char* (which is kept unchanged, passed as a pointer).
It's copied in fact. You thus have first copy - a string literal, and second one - created in constructor. That's why my objection. Even though I recognize that command line is negligible in size, this way of handling string literals is just unclean.
And you don't need to worry about deletion since you can use std::string in caller and then pass it like mycmd.c_str() to runCommand().
In general, I do agree about using self-deallocating objects, but this case doesn't really look like the one which really needs this.

Anyway, if you still aren't convinced, then I won't argue anymore and will agree to have it left alone.

[Dan Parnham (teadriven)]

Looks like it's not specific to emacs, seeing the same issue with other GTK2 apps in kubuntu 13.04: https://sourceforge.net/p/codelite/bugs/895/

[Vertago1 (vertago1)]

This affects a lot more than emacs. I have had thunderbird and acroread both lockup repeatedly.

Here is the stack trace for acroread:
#0 0xf77b5425 in __kernel_vsyscall ()
#1 0xf5b5fdcb in poll () from /lib/i386-linux-gnu/libc.so.6
#2 0xf5dbe2db in g_poll () from /lib/i386-linux-gnu/libglib-2.0.so.0
#3 0xf5daf6d0 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#4 0xf5dafc2b in g_main_loop_run () from /lib/i386-linux-gnu/libglib-2.0.so.0
#5 0xf5df5c21 in g_spawn_sync () from /lib/i386-linux-gnu/libglib-2.0.so.0
#6 0xf5df6094 in g_spawn_command_line_sync () from /lib/i386-linux-gnu/libglib-2.0.so.0
#7 0xf332be4c in Oxygen::QtSettings::kdeConfigPathList() const ()
   from /usr/lib/i386-linux-gnu/gtk-2.0/2.10.0/engines/liboxygen-gtk.so
#8 0xf332e8f3 in Oxygen::QtSettings::initialize(unsigned int) ()
   from /usr/lib/i386-linux-gnu/gtk-2.0/2.10.0/engines/liboxygen-gtk.so
#9 0xf3341b18 in Oxygen::Style::initialize(unsigned int) () from /usr/lib/i386-linux-gnu/gtk-2.0/2.10.0/engines/liboxygen-gtk.so
#10 0xf3341ef3 in Oxygen::Style::fileChanged(_GFileMonitor*, _GFile*, _GFile*, GFileMonitorEvent, void*) ()
   from /usr/lib/i386-linux-gnu/gtk-2.0/2.10.0/engines/liboxygen-gtk.so
#11 0xf4c4e48e in ffi_call_SYSV () from /usr/lib/i386-linux-gnu/libffi.so.6
#12 0xf4c4e1ef in ffi_call () from /usr/lib/i386-linux-gnu/libffi.so.6
#13 0xf5e77a2a in g_cclosure_marshal_generic_va () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#14 0xf5e76ee1 in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#15 0xf5e9065a in g_signal_emit_valist () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#16 0xf5e91233 in g_signal_emit () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#17 0xf4d39229 in ?? () from /usr/lib/i386-linux-gnu/libgio-2.0.so.0
#18 0xf5dabf10 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#19 0xf5daf3b3 in g_main_context_dispatch () from /lib/i386-linux-gnu/libglib-2.0.so.0
#20 0xf5daf750 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#21 0xf5dafc2b in g_main_loop_run () from /lib/i386-linux-gnu/libglib-2.0.so.0
#22 0xf612c710 in gtk_main () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#23 0x0850d0bd in _start ()

Here is the trace for thunderbird:
#0 0x00007f9b459483cd in poll () at ../sysdeps/unix/syscall-template.S:81
#1 0x00007f9b404501dc in g_main_context_poll (n_fds=1, fds=0x7f9af37f6d28, timeout=-1, context=0x7f9af37a7680,
    priority=<optimized out>) at /build/buildd/glib2.0-2.36.0/./glib/gmain.c:3995
#2 g_main_context_iterate (context=0x7f9af37a7680, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
    at /build/buildd/glib2.0-2.36.0/./glib/gmain.c:3696
#3 0x00007f9b404506ba in g_main_loop_run (loop=0x7f9afb710370) at /build/buildd/glib2.0-2.36.0/./glib/gmain.c:3895
#4 0x00007f9b40491e41 in g_spawn_sync (working_directory=working_directory@entry=0x0, argv=<optimized out>, envp=envp@entry=0x0,
    flags=flags@entry=G_SPAWN_SEARCH_PATH, child_setup=child_setup@entry=0x0, user_data=user_data@entry=0x0,
    standard_output=standard_output@entry=0x7fff584be268, standard_error=standard_error@entry=0x0,
    exit_status=exit_status@entry=0x0, error=error@entry=0x0) at /build/buildd/glib2.0-2...

[Jtb (e-launchpad-jensthebrain-de)]

I've got lockups with Firefox and Thunderbird.

[Sam Azer (samazer)]

Enjoying k/ubuntu 13.04 very much. Switched to the development snapshot of emacs for now.

[Gabriele Tozzi (gabriele-tozzi)]

This is just to let you know that putty is also affected probably by this bug. I have exactly same problems described here for emacs.

[Ralf Jung (0tlwui8x-post-kj985rvy)]

Are there any plans of a new release with these patches anytime soon? This bug breaks using emacs with oxygen-gtk2 after upgrading libglib to version 2.36 in Debian. That update is already in unstable, so it will probably migrate to testing soon and start hitting Debian testing desktop users.

[Ruslan (b7-10110111)]

See also https://bugs.kde.org/show_bug.cgi?id=318891 . We've worked around this bug in oxygen-gtk, commits are in current git.

[Sergio Callegari (callegar)]

Seems rather serious to me. Currently there are at least three packages in the ubuntu repos (oxygen-gtk for gtk2 and gtk3 and qtcurve) that - once installed - may make many gtk applications stop working, in such a way that they silently hang.

A troublesome aspect is thatI would like to report that after upgrading to raring, some kde systems come out without the module that enables the configuration of the gtk themes in the kde systems settings (the deb is not installed). This means that working around the issue by inviting kde users to configure gtk not to use the oxygen or the qtcurve theme may be tricky. Here the workaround involves root permissions to force the uninstall of oxygen-gtk, qtcurve or the install of the kde system settings module, or alternatively inviting users to hand edit the gtkrc file.

[Rohan Garg (rohangarg)]

Hi everyone, I've uploaded the 1.3.3 package for gtk2-engines-oxygen to raring-proposed : https://launchpad.net/ubuntu/+source/gtk2-engines-oxygen/1.3.3-2ubuntu0.1

Please give your feedback on bug 963736 whether everything works fine now.

Regards
Rohan Garg

[Petr Sedlacek (piit79)]

I can confirm that with the new package gtk2-engines-oxygen_1.3.3-2ubuntu0.1_amd64.deb EasyTag is starting correctly (I'm not using Emacs but EasyTag had the exact same problem)

[Vasilis Vasaitis (vvas)]

The update of gtk2-engines-oxygen has no effect on emacs24, as it's compiled against GTK3. I've just checked, and indeed installing it doesn't make the problem go away, at least for me.

[Rohan Garg (rohangarg)]

Fix for oxyge-gtk3 uploaded to raring, waiting in approval queue

[Scott Kitterman (kitterman)]

Hello Paul, or anyone else affected,

Accepted into raring-proposed. The package will build now and be available in a few hours in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Paul White (paulw2u)]

Proposed already enabled and can confirm emacs23 now starts every time so oxygen-gtk2 fix works here.
Will test emacs24 when oxygen-gtk3 fix available.

Rohan/Scott, thanks for fixing.

[Rohan Garg (rohangarg)]

@Paul Fix should now be available via -proposed, once you've tested, please set the tag as verification-done.

[Paul White (paulw2u)]

Super! emacs24 now started 6 times in a row successfully. Thanks Rohan. Now setting tag.....

[Rohan Garg (rohangarg)]

Thanks Paul, Fix will migrate from -proposed to -release 7 days from now.

[Vasilis Vasaitis (vvas)]

Yeap, after upgrading gtk3-engines-oxygen, emacs24 starts ok here too.

[Scott Kitterman (kitterman)]

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package oxygen-gtk3 - 1.1.4-0ubuntu0.1

---------------
oxygen-gtk3 (1.1.4-0ubuntu0.1) raring; urgency=low

  [ Rohan Garg ]
  * New upstream release (LP: #1142213)
    - Fixes issues where gtk3 applications like emacs24 would not start

  [ Dmitry Smirnov ]
  * Corrected "Expat" license name in debian/copyright
 -- Rohan Garg <email address hidden> Wed, 05 Jun 2013 13:14:25 +0100

[Hugo Pereira Da Costa (hugo-pereira)]

Comming back to this bug, because I am not happy with the use of popen (which is less portable than g_spawn):
testing with g_spawn again and glib-2.36.2, I do not get the issue anymore.
could someone double check ?

(would require some oxygen-gtk checked-out at, e.g. a515ab451f54cbc930d0a09d250669255dd8a741^ and build from source, for gtk2 applications.)

[Hugo Pereira Da Costa (hugo-pereira)]

... digging:
https://bugzilla.gnome.org/show_bug.cgi?id=698081

seems, it was indeed a glib bug, that got fixed in glib.
I would be inclined to revert this change to popen, and close (again) this bug as upstream.
Ruslan ? oppinion ?

[Ruslan (b7-10110111)]

> Ruslan ? oppinion ?
Well, I'd in fact rather use "#define popen _popen" etc. on Windows (if this is what you mean by portability), not return to glib-specific code.
popen() is much less likely to fail, and this is why I'd prefer using it instead.

[Hugo Pereira Da Costa (hugo-pereira)]

@Ruslan
problem with popen:
- it is defined on windows (with mingw at least) and works, but opens a terminal to execute a command. (not so nice). And I'm not sure _popen would fix this, would it ?

- on unix, it does not allow to easily redirect stderr, so you get an error message (for every application) when kde4-config is not installed. So that I had to add a 2> /dev/null (committed), to hide the (armless) error message, in current master, because users were already complaining.
But this, in turn, is not portable to windows.

All this is nicely handled in g_spawn, when it works ...

popen being more likely to work on windows depends on MinGW (not even sure if it is implemented with VC ...). While g_spawn depends on glib. Which one is more error prone I do not know (I would assume glib, but ...)

So bottomline: if we want to stick to popen (to be more glib-error safe), we'd likely need more code (and more #ifdef) than what we have now ...

[Hugo Pereira Da Costa (hugo-pereira)]

PS: maybe we can revert the change in popen, in master only ...
(which will become our next feature release) ?

[Ruslan (b7-10110111)]

> - it is defined on windows (with mingw at least) and works, but opens a terminal to execute a command. (not so nice). And I'm not sure _popen would fix this, would it ?
Most likely it won't. But we can make something like this:
#ifdef _WIN32
    ShowWindow(GetConsoleWindow(),SW_HIDE);
#endif
before running popen(). (Ugly, but should do the trick.)
> - on unix, it does not allow to easily redirect stderr, so you get an error message (for every application) when kde4-config is not installed. So that I had to add a 2> /dev/null (committed), to hide the (armless) error message, in current master, because users were already complaining.
This is more serious. Not sure how to fix this well enough...
> popen being more likely to work on windows depends on MinGW (not even sure if it is implemented with VC ...).
_popen() is listed in MSDN, so this one should be available with VC.

> So bottomline: if we want to stick to popen (to be more glib-error safe), we'd likely need more code (and more #ifdef) than what we have now ...
Yeah, hard to decide. Seems you're right and we should go back to glib. (But we should make sure this doesn't break any distro again if they still use unfixed glib version).

[Hugo Pereira Da Costa (hugo-pereira)]

@Ruslan
So I'd suggest:
- keep current branches as they are (with popen).
- revert the change (sort of: I would like to keep the RunCommand method :)) for master (and gtk3 branch).
- if we want to be extra sure, add a minimal requirement on the glib version in our (master) CMakefiles.

What do you think ?

[Ruslan (b7-10110111)]

> if we want to be extra sure, add a minimal requirement on the glib version in our (master) CMakefiles.
No, that's bad. This way you'll disable any older distros from being able to use latest oxygen-gtk release.

I'd suggest that we leave both variants - via popen() and g_spawn...() - and use popen() only for that glib version(s) which fails (and warn user in cmake output that current glib version is bad).

[Hugo Pereira Da Costa (hugo-pereira)]

yeah well. More ifdefs ... not sure I want that. Especially if it is to bypass a bug that is present in only one _minor_ release of glib.

The only advantage of keeping popen is if other (future) versions of glib break, which the suggestion you propose would not prevent either ...

So in the end, gspawn it should be, and gspawn only, I'd say, assuming that upstream is reliable. (especially a low level library such as glib)

And too bad for the systems running with broken glib (in fact, I expect that if it also breaks pidgin, distros would be quite quick at patching glib)

[5w-hugo (5w-hugo)]

Git commit ccf7f9c46e521f3966751cbf822beb242579abe3 by Hugo Pereira Da Costa.
Committed on 19/06/2013 at 12:17.
Pushed by hpereiradacosta into branch 'gtk3'.

Re-added use of g_spawn_command_line_sync in place of popen, to execute an external comment.
This effectively reverts commit 51b662b0cd86fd7a960cc2f0c436441d64b2dd44
Rational:
- the failure of g_spawn_command_line_sync was a glib bug 3.6.0, that got fixed since then (3.6.2)
- the use of popen generates unnecessary console when compiled for windows
- the use of popen makes it difficult to redirect stderr, which results in error messages being printed
on screen when the executed command failed (for instance because the relevant application is not
installed.

M +3 -26 src/oxygenqtsettings.cpp

http://commits.kde.org/oxygen-gtk/ccf7f9c46e521f3966751cbf822beb242579abe3

[5w-hugo (5w-hugo)]

Git commit 2068101234271725def6fe91de4a26543b260cba by Hugo Pereira Da Costa.
Committed on 19/06/2013 at 12:17.
Pushed by hpereiradacosta into branch 'master'.

Re-added use of g_spawn_command_line_sync in place of popen, to execute an external comment.
This effectively reverts commit 51b662b0cd86fd7a960cc2f0c436441d64b2dd44
Rational:
- the failure of g_spawn_command_line_sync was a glib bug 3.6.0, that got fixed since then (3.6.2)
- the use of popen generates unnecessary console when compiled for windows
- the use of popen makes it difficult to redirect stderr, which results in error messages being printed
on screen when the executed command failed (for instance because the relevant application is not
installed.

M +3 -26 src/oxygenqtsettings.cpp

http://commits.kde.org/oxygen-gtk/2068101234271725def6fe91de4a26543b260cba

[TomHarrison (l12436)]

the 1.3.3 gtk engine in my system will cause stcok from the konsole to the whole kde GUI when i use the ctrl + z to try to move the hime to the background.
so i still decide to use the fix version.

[TomHarrison (l12436)]

the 1.3.3 gtk engine in my system will cause stock from the konsole to the whole kde GUI when i use the ctrl + z to try to move the hime to the background.
so i still decide to use the fix version.

[TomHarrison (l12436)]

because the konsole got stock, i can not be able get the backtrace.
even use the another konsole to open the new konsole.

[Paul Abrahams (abrahams)]

This problem also shows up with easytag (see Bug #1160729).

[aanno (thomas-pasch)]

I believe this is also a problem with Ubuntu 13.10/saucy, eclipse/java and oxgen-gtk2. See https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1245468 for details.

[Hugo Pereira Da Costa (hugo-pereira)]

is this bug still valid ?
It requires a recent enough version of glib, for g_spawn to be working properly.

[TomHarrison (l12436)]

now is fixed, i did not know why is reopened

[Hugo Pereira Da Costa (hugo-pereira)]

thanks. Closing then

[Paul White (paulw2u)]

Just cleaning up, emacs24 working ok in both Kubuntu 13.10 and 14.04. Marking as fix released.

[Rolf Leggewie (r0lf)]

raring has seen the end of its life and is no longer receiving any updates. Marking the raring task for this ticket as "Won't Fix".