[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: the memory leak bug affecting gdm3 upstream GNOME bug seems to have been disappeared.



On Mon, 25 Nov 2019 at 15:17:44 +0000, shirish शिरीष wrote:
> Few months back I came to know of #895990 specifically while trying to
> install gdm3.  The bug is still outstanding

Sorry, "GNOME Shell memory use increases" is not really an actionable bug.
It's a symptom that can appear for multiple reasons, and neither upstream
nor Debian can fix instances of that symptom without *considerably*
more information.

(An analogy: if you report a bug that just says "Firefox crashed", then
that is not an actionable bug, and you will not get useful results by
reporting it. However, if you report a bug "Firefox crashes when I visit
gnome.org, with this message ... and this backtrace ..."  then that's
specific enough to track, and is something that its maintainers might
be able to fix.)

The gjs Javascript runtime uses garbage-collection, not
reference-counting, so it does not return unused allocated memory
to the system until an unpredictable time has passed. That cannot be
fixed without extensive design changes: if I understand correctly, the
Javascript language definition means that all Javascript implementations
must use garbage-collection, so as long as GNOME Shell is partly
implemented in Javascript, unused allocated memory will not be returned
to the system immediately.

If you are aware of rapid memory growth when you carry out a specific
action (perhaps repeatedly), that might be a useful bug report: please
report it as a bug, with a title that is as specific as possible,
and specific steps to reproduce it. For example, if memory use grows
when you open and close the menu in the top right corner by clicking it
repeatedly, and does not return to normal after leaving the Shell idle
for a few minutes, then that would be an actionable bug report.

If you are aware of a patch or commit that fixes a memory leak, and
has been applied upstream but not in (some specific version in) Debian,
that is also a useful, actionable bug report.

A non-specific report like "a lot of memory gets allocated" is not
really something that we can ever fix or close, so it is not a useful
way to improve GNOME; and in the past, reports of that form have tended
to attract replies that mix up multiple root causes in an unhelpful way,
causing developers to either spend a lot of time dealing with replies
(which is time that they would have preferred to spend fixing bugs!),
or ignore the bug report and work on something more rewarding instead.

> and from the discussion
> appears needs to have other patches which are not in libgs which is
> part of gnome-shell. It referenced LP bug 1672297 which in turn
> referenced debian upstream bug 77537 on gitlab.com

You seem to be confusing a lot of different things. Debian bugs are not
the same as upstream bugs, gitlab.com is not the same as GNOME's
instance of Gitlab, bugs in GNOME's instance of Gitlab are unlikely
to have 5-digit bug numbers, and bugs in GNOME's old Bugzilla bug
tracker mostly don't have 5-digit bug numbers either.

There is no library called libgs. You might mean libgjs, which is part
of gjs and is used by GNOME Shell, or libgnome-shell, which is part of
GNOME Shell.

Please try to be precise.

> The upstream bug doesn't seem to be visible . Going to [1] I get a 404
> 1. https://gitlab.gnome.org/777537

Getting a 404 for that address is expected. That is not the format of a
GNOME Gitlab bug URL.

You might be looking for
<https://bugzilla.gnome.org/show_bug.cgi?id=777537> which was converted
into <https://gitlab.gnome.org/GNOME/gnome-shell/issues/64>.

The best summaries there are
<https://gitlab.gnome.org/GNOME/gnome-shell/issues/64#note_295977>
and <https://gitlab.gnome.org/GNOME/gnome-shell/issues/64#note_296648>.

    smcv


Reply to: