After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 789893 - Memory leak in mediaplayer extension
Memory leak in mediaplayer extension
Status: RESOLVED INVALID
Product: gnome-shell
Classification: Core
Component: extensions
3.26.x
Other Linux
: Normal critical
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2017-11-04 01:33 UTC by Frank
Modified: 2017-11-10 11:43 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
htop screen shot (102.57 KB, image/png)
2017-11-04 01:33 UTC, Frank 		Details

Description Frank 2017-11-04 01:33:53 UTC 
Created attachment 362946 [details]
htop screen shot

I run Fedora 27b and since I upgraded from 26, I always run out of memory after some hours of mainly browsing and doing some 08/15 stuff, because Shell is eating all my memory. See my attached screen shot.

By the way: When I try to open some applications, I then get the error message “Forking not possible” and apps cannot be started, although I have enough swap (but they do start when I invoke them via CLI, whysoever).
Comment 1 Frank 2017-11-04 03:05:29 UTC 
Or can this be due to shell extensions?

Is there a better isolation planned for the future of extensions, by the way?
Comment 2 André Klapper 2017-11-04 10:17:57 UTC 
(In reply to Frank from comment #1)
> Or can this be due to shell extensions?

Anything can be. You'd find out by disabling them and comparing. :)
Comment 3 Frank 2017-11-09 18:41:44 UTC 
Could track it down to an extension. Still, could extensions get isolated somehow, so that they maybe can modify the shell or add/substract something to it, but run all the rest of the code via an interface in some kind of container, like it is done in Firefox for example?
Comment 4 André Klapper 2017-11-09 18:54:46 UTC 
(In reply to Frank from comment #3)
> Could track it down to an extension.

Ah great! Which one exactly?