| msg87561 - (view) |
Author: (dontbugme) |
Date: 2009-05-11 03:57 |
| the webbrowser library produces a zombie process when opening urls. please see http://dev.deluge-torrent.org/ticket/928 and the original bug report (by me) on ubuntu's launchpad (https:// bugs.launchpad.net/bugs/313149) for details. could not find any references in your tracker, but i did not test it in newer versions than the one supplied in ubuntu atm (2.6.2), so please forgive me, if it is already fixed :) |
|
|
| msg91017 - (view) |
Author: Eivind Tagseth (eivindt) |
Date: 2009-07-28 21:20 |
| The problem seems to be that there are no way to wait() for browser processes that have died, and there is no mention of needing to wait() in the documentation. In my case, webbrowser finds my gnome-setting for the http-url handler and sets up [ "firefox", "%s" ] as a BackgroundBrowser named 'gnome'. BackgroundBrowser.open() creates a Popen object and calls p.poll(). The Popened firefox process finds my existing firefox process, and asks it to open the url, then terminates. It doesn't act quickly enough to terminate before p.poll() is called though, and I end up with a zombie firefox process, that keeps me from ending firefox unless I also kill my python process. If this is how this is intended to work, there should at least be a section in the documentation warning users to call os.waitX() themselves to avoid zombie processes. |
|
|
| msg110859 - (view) |
Author: Mark Lawrence (BreamoreBoy) * |
Date: 2010-07-20 03:43 |
| Assigned as per maintainers list. |
|
|
| msg184662 - (view) |
Author: Marc Adam Anderson (marcadam) * |
Date: 2013-03-19 18:59 |
| Unable to reproduce this bug on Mac OS X 10.8.3 (12D78) using Python 3.4.0a0 and the following browsers: - Google Chrome 25.0.1364.172 - Firefox 13.0.1 - Safari 6.0.3 (8536.28.10) |
|
|
| msg184666 - (view) |
Author: Andrew Gorcester (andrewsg) * |
Date: 2013-03-19 19:44 |
| I was able to reproduce on Ubuntu with Python 3.4 compiled from trunk 2013-03-17, but only with Firefox and not with Chrome. |
|
|
| msg186846 - (view) |
Author: Shaun Hickson (sphickson) * |
Date: 2013-04-13 21:07 |
| Just as an additional data point, I was also unable to recreate this on OS X 10.8.3 using any browser. |
|
|
| msg404441 - (view) |
Author: Christian Heimes (christian.heimes) *  |
Date: 2021-10-20 12:47 |
| Are Python 3.9 to 3.11 still affected by the issue? The webbrowser module now uses subprocess.Popen() to start browsers. The subprocess module calls wait() and performs additional cleanup to prevent zombies. |
|
|
| msg408975 - (view) |
Author: C.A.M. Gerlach (CAM-Gerlach) * |
Date: 2021-12-20 22:14 |
| I can verify that this still occurs on Linux under an up to date Python 3.9 env (unknown browser; I can inquire), while on my Windows machine running an essentially identical Python 3.9 env, I don't get the warning. The practical problem arises when we are using `-X dev`/`-W error` and/or strict `filterwarnings` with Pytest, and the user passes a custom `--open-browser` flag to our test suite to open the resulting output in their web browser to inspect it for themselves. See [spyder-ide/docrepr#33](https://github.com/spyder-ide/docrepr/pull/33#discussion_r772164817) for details. I'm concerned this is going to be difficult to work around without doing over-broad silencing of warnings on the Pytest, because the warning is raised when the object is GC'ed, which may happen at a non-deterministic time or even after or even Python invocation level, and I can't reproduce it on my machine to test it. |
|
|