Bug #781397 “Help opens web browser (Epiphany, Konqueror), Inksc...” : Bugs : Inkscape

su_v (suv-lp) on 2011-05-12

tags:

added: extensions-plugins
removed: browser epiphany gnome hangs help konqueror

Revision history for this message

su_v (suv-lp) wrote on 2011-05-12:

#1

Which python version do you have installed?

The browser process is spawned from this python script:
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/RELEASE_0_48_BRANCH/view/head:/share/extensions/launch_webbrowser.py>

Earlier related reports:
Bug #449986 “"[...] working, please wait..." windows invoked by Help are blocking, and can not be closed”
Bug #306867 “when Help menu item opens in browser, inkscape dialog stuck until browser quits”
Bug #168226 “Launching Firefox freezes inkscape until browser exits”

<off-topic>
> "(inkscape:3504): Gtk-CRITICAL **: gtk_misc_set_alignment: assertion `GTK_IS_MISC (misc)' failed"

Which GTK+ version do you have installed? That's a bug in GTK+ (see bug #576852), fixed in GTK+ >= 2.22.0
</off-topic>

Revision history for this message

Tomasz Sztejka (sztejkat) wrote on 2011-05-14:

#2

Download full text (6.7 KiB)

(...)Which GTK+ version do you have installed? That's a bug in GTK+ (see bug #576852), fixed in GTK+ >= 2.22.0(...)

2.20.1-2. Unfortunately using Debian stable means I'm a bit back in time. Thanks for information, I will check if it will disappear when I finally will do an upgrade.

(...)Which python version do you have installed?(...)
Python 2.6 is set as a default.

About lauch.... py script.

I'm not a pro with a python. Done few lines only. But from other experiences with other programming languages I do know, that starting a new thread is not enough to get in a background - the process will not terminate until all non-daemon threads are terminated. And if threads are daemon, they will be killed when all non-daemon threads terminates. In this case inkscape fires new process (python interpreter) and awaits for it's completion. So python interpreter must terminate while browser must go to another, independent process.

Also python manual says: "(...)global interpreter lock(...) The mechanism used by the CPython interpreter to assure that only one thread executes Python bytecode at a time.(...)" what suggests that doing threads in python when not doing I/O or awaiting for an external process is ridiculous. Again, I'm not a pro with python.

I did modified script to remove threading and it works the same way: iceweasel behaves as typed in terminal - shows and returns. Epiphany exposes incorrect behavior.

The webbrowser.py module used in script is using subprocess.py to spawn subprocess with shell==false. Manual says, that it is reasonable because of safety but will result in os.execvp(). As expected on Unix clone, manual says that os.execvp do not return. However subprocess _execute_child do os.fork() so it is correct and cannot be a source of problem.

But some pieces of webbrowser.py contains dangerous "return not p.wait()". It seems it assumes that some style of calling, named "remote", will fork by itself and others will not. I do not understand WHY such a distinction. Closer look shows, that following classes of browsers defined in this webbrowser.py module will await till child process completes:

GenericBrowser
UnixBrowser (depening on arguments)

Selection of class is made by get() and available set is prepared by register_X_browsers() during module initialization. This method applies distinct assumptions about distinct commands. I do not understand why to wait for some browsers to complete? Does it matter? We are only willing to fire it up and forget, right? I think it is for python code running in terminal. That's the problem with a generic code - it does too much and is too uncertain.

For GNOME default browser is available through "gnome-open" system script. When checked in command line this script is always forking and returning. The webbrowser.py module recognizes it as a BackgroundBrowser what should be ok, as BackgroundBrowser do not wait for subprocess to complete. But it should not matter anyway, since "gnome-open" forks for both iceweasel and epiphany.

Unfortunately I did confirm, modifying launchwebbrowser to:
(...)
from webbrowser import BackgroundBrowser
bb=BackgroundBrowser("gnome-open")
bb.open(url=opt.url)
(...)
th...

(...)Which GTK+ version do you have installed? That's a bug in GTK+ (see bug #576852), fixed in GTK+ >= 2.22.0(...)

2.20.1-2. Unfortunately using Debian stable means I'm a bit back in time. Thanks for information, I will check if it will disappear when I finally will do an upgrade.

(...)Which python version do you have installed?(...)
Python 2.6 is set as a default.

About lauch.... py script.

I'm not a pro with a python. Done few lines only. But from other experiences with other programming languages I do know, that starting a new thread is not enough to get in a background - the process will not terminate until all non-daemon threads are terminated. And if threads are daemon, they will be killed when all non-daemon threads terminates. In this case inkscape fires new process (python interpreter) and awaits for it's completion. So python interpreter must terminate while browser must go to another, independent process.

Also python manual says: "(...)global interpreter lock(...) The mechanism used by the CPython interpreter to assure that only one thread executes Python bytecode at a time.(...)" what suggests that doing threads in python when not doing I/O or awaiting for an external process is ridiculous. Again, I'm not a pro with python.

I did modified script to remove threading and it works the same way: iceweasel behaves as typed in terminal - shows and returns. Epiphany exposes incorrect behavior.

The webbrowser.py module used in script is using subprocess.py to spawn subprocess with shell==false. Manual says, that it is reasonable because of safety but will result in os.execvp(). As expected on Unix clone, manual says that os.execvp do not return. However subprocess _execute_child do os.fork() so it is correct and cannot be a source of problem.

But some pieces of webbrowser.py contains dangerous "return not p.wait()". It seems it assumes that some style of calling, named "remote", will fork by itself and others will not. I do not understand WHY such a distinction. Closer look shows, that following classes of browsers defined in this webbrowser.py module will await till child process completes:

GenericBrowser
UnixBrowser (depening on arguments)

Selection of class is made by get() and available set is prepared by register_X_browsers() during module initialization. This method applies distinct assumptions about distinct commands. I do not understand why to wait for some browsers to complete? Does it matter? We are only willing to fire it up and forget, right? I think it is for python code running in terminal. That's the problem with a generic code - it does too much and is too uncertain.

For GNOME default browser is available through "gnome-open" system script. When checked in command line this script is always forking and returning. The webbrowser.py module recognizes it as a BackgroundBrowser what should be ok, as BackgroundBrowser do not wait for subprocess to complete. But it should not matter anyway, since "gnome-open" forks for both iceweasel and epiphany.

Unfortunately I did confirm, modifying launchwebbrowser to:
(...)
from webbrowser import BackgroundBrowser
bb=BackgroundBrowser("gnome-open")
bb.open(url=opt.url)
(...)
that it is a location of a problem - inkscape awaits for browser to be closed.

Changed to:
(...)
cmdline =["gnome-open",opt.url]
subprocess.Popen(cmdline)
(...)
and this one is also awaiting for browser to be closed.

Changed then to:
(...)
if os.fork() == 0:
   os.execvp("gnome-open",["gnome-open",opt.url])
(...)
and to my great surprise it ALSO do wait.

The stand alone simple script run from outside of inkscape:

#!/usr/bin/env python
import os
if os.fork()==0:
	os.execvp("gnome-open",["gnome-open","http://www.wp.pl"])
else:	
	print "waiting"

forks as expected.

Ok, let's try what can prevent a process (inkscape) observing a child process from detecting it's completion when a sub-child process is still running? Maybe pipes still opened? In linux child process are having their stdin/stdout/stderr exactly the same as a parent process. Try to run this script:

#!/usr/bin/env python
import os
import time
if os.fork()==0:
  	print "forked exec"
  	time.sleep(10)
  	print "forked complete"
else:	
	print "non-forked"

It nicely forks into a background, but text "forked completed" is popping to terminal after 10 seconds.

But EXACTLY THE SAME CODE placed inside launch_webbrowser.py makes inkscape to wait for 10 seconds with a dialog opened and then reporting expected error capture: "non-forked".

Ok, so maybe pipes are causing troubles. Code:

if os.fork()==0:
        os.close(0)
        os.close(1)
        os.close(2)
        os.execvp("gnome-open",["gnome-open","http://www.wp.pl"])
else:	
	print "non-forked"

is crashing in inkscape. Browser obviously needs some kind of stdin/stdout/stderr. But code:

if os.fork()==0:
        devnull = os.open("/dev/null",os.O_RDWR)
        os.dup2(devnull,0)
        os.dup2(devnull,1)
        os.dup2(devnull,2)
        os.execvp("gnome-open",["gnome-open","http://www.wp.pl"])

works exactly as expected.

Why then standard code do not work? The subprocess.py DO redirect stdin/stdout/stderr ONLY if it is TOLD TO. The BackgroundBrowser do not say that. It says to close all files EXCEPT those three and do not touch them. In effect inkscape is waiting (I suppose, since it is grabbing and showing stderr)  for those pipes to be closed as a sign of interpreter completion but they are passed to child process (browser) which keeps them opened and alive.

Solution to this problem:

1.The launch_webbrowser.py should be (but do not have to be) stripped from threading code to a plain call:

#!/usr/bin/env python
import webbrowser, threading
from optparse import OptionParser

parser = OptionParser()                                                                                                   	
parser.add_option("-u", "--url", action="store", type="string",
                  default="http://www.inkscape.org/",
                  dest="url", help="The URL to open in web browser")                                       		
(opt, args)=parser.parse_args()
webbrowser.open(opt.url)

2.The bug report for Phyton 2.6 & 2.7 webbrowser.py module should be filled:

The BackgroundBrowser class should have line:

p = subprocess.Popen(cmdline, close_fds=True, preexec_fn=setsid)

changed to:
        
        devnull = os.open(os.devnull,os.O_RDWR)
    	p = subprocess.Popen(cmdline, close_fds=True, preexec_fn=setsid,
    			    stdin=devnull,stdout=devnull,stderr=devnull)

After those changes everything works fine. Note: I wasn't able to test it on windows so I don't know whether os.devnull exists there and how does it work. Developers should decide if it would not be better to create GnomeBrowser class instead.

3.Python 2.7 - the same faulty behaviour.

With regards,
  Tomasz Sztejka

Revision history for this message

Tomasz Sztejka (sztejkat) wrote on 2011-05-14:

#3

Note: Alternatively please check, what Inkscape is doing with I/O pipes passed to it's child process. It is beyond my capabilities to look at it. If it is in fact waiting for EOF then change it to wait for process completion regardless of stream state. The current python behavior is not ideal, as background browser is not 100% background, but it is acceptable. So maybe there is a cleaner solution at inkscape team side possible to achive?

Regards,
Tomasz Sztejka.

su_v (suv-lp) on 2011-05-14

summary:

- Help opens web browser, Inkscape stays in modal state.
+ Help opens web browser (Epiphany, Konqueror), Inkscape stays in modal
+ state .

Alex Valavanis (valavanisalex) on 2011-06-01

Changed in inkscape (Ubuntu):
status:	New → Triaged
importance:	Undecided → Low

Alex Valavanis (valavanisalex) on 2011-08-21

Changed in inkscape:
status:	New → Confirmed
importance:	Undecided → Low
importance:	Low → Medium

Bug Watch Updater (bug-watch-updater) on 2011-08-21

Changed in inkscape (Debian):
status:	Unknown → Confirmed

Revision history for this message

Cojnel (cojnel) wrote on 2013-11-30:

#4

Except for inkscape freezing,
this sounds very similar to the popup i'm getting.

When clicking on an item in the help menu that opens a webpage,
then two popups open in the center of the inkscape window,
and the webpage opens in the browser.

The first popup says:
'Keys and Mouse Reference' working, please wait...
[Cancel]

the text between the '' signs refers to what was clicked.

The second one says:
Inkscape has received additional data from the
script executed. The script did not return an error,
but this may indicate the results will not be as
expected.

(process:9189): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed
[OK]

If the second popup is moved then one can see that the first one is still open behind it.

If one clicks OK on the first popup,
then they both go away, and inkscape works fine.

Tested with:
r12833 on linux mint 15 cinnamon 32bit
Firefox v25.0.1 is the default browser.

Revision history for this message

Hachmann (marenhachmann) wrote on 2014-12-10:

#5

Getting the same (but longer :) ) error message with Inkscape 0.91pre3 opening firefox for manual/other websites on LM17:

(process:2824): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
Error: No running window found
(process:2828): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
(firefox:2828): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::sm-connect after class was initialised
(firefox:2828): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::show-crash-dialog after class was initialised
(firefox:2828): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::display after class was initialised
(firefox:2828): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::default-icon after class was initialised

Revision history for this message

Trent W. Buck (twb) wrote on 2015-02-11: subscribe

#6

subscribe

Inkscape

Help opens web browser (Epiphany, Konqueror), Inkscape stays in modal state .

Bug Description

Duplicates of this bug

Other bug subscribers

Remote bug watches

	Status	Importance	Assigned to
Inkscape	Confirmed	Medium	Unassigned
inkscape (Debian)	Confirmed	Unknown	debbugs #466174
inkscape (Ubuntu)	Triaged	Low	Unassigned