I can reproduce the following symptoms:
- Windows (Super_L) key doesn't bring up the menu.
- Right-clicking on the menu button does nothing.
- Search works, but I can't press Enter to select the result. It does nothing.
- Mouseover the categories does nothing.
Disabling places and bookmarks fixes
I'm having the same problem with both my 2012 Nexus 7 and my HTC One M8.
If I connect the device, I get the error message "Unable to mount
Android Phone: Unable to open MTP device '[usb:005,120]'" for my HTC One
M8. The message changes to "Unable to mount Nexus 7" when I plug the
Nexus 7 in. The
"debdiff with memory leak fixed" appears to be identical to the original
debdiff.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1722411
Title:
gnutls28 in trusty no longer validates many valid
I'm pretty sure that it's the "compare_ca_name_and_key.patch", which
introduces "raw_spki", but doesn't seem to do anything to free it. I'll
do some more investigation today.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I'm trying it with the following extra patch:
diff -ruN gnutls28-3.2.11-orig/lib/x509/x509.c gnutls28-3.2.11/lib/x509/x509.c
--- gnutls28-3.2.11-orig/lib/x509/x509.c2014-01-01 17:14:59.0
+
+++ gnutls28-3.2.11/lib/x509/x509.c 2018-01-18 14:52:52.617834001 +
@@ -136,6
In my testing, that patch appears to fix the memory leak. I'm attaching
it properly.
I have no idea how to get it in a .debdiff. Also, does that require a
version bump to "ubuntu1.3"?
** Patch added: "compare_ca_name_and_key_free.patch"
> I'm pretty sure that it's the "compare_ca_name_and_key.patch", which
introduces "raw_spki", but doesn't seem to do anything to free it.
Oh, now I see how
https://gitlab.com/gnutls/gnutls/commit/cdd60f7013d5e64702f3b04e6fe93218e88a2213
fixes the leak -- by avoiding the allocation in the first
> I'll try with the updated debdiff. Thanks.
Looks good.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1722411
Title:
gnutls28 in trusty no longer validates many valid certificate chains,
such
The debdiff introduces a memory leak.
With the simple program at
https://gist.github.com/rlipscombe/78d6e3bbfc67e010f1e7a9ddd8c87099, the
previous version is fine, but this one leaks.
Valgrind reports the following:
==11134==
==11134== HEAP SUMMARY:
==11134== in use at exit: 1,014,363
With ALL extensions, it doesn't get slower. When it was getting slower,
I had the standard 'gnome-shell-extensions' package installed.
I'm going to reinstall it and see if that reproduces the problem.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
That should say "With ALL extensions uninstalled..."
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1869568
Title:
Unlock takes a long time
To manage notifications about this bug go to:
See https://github.com/home-sweet-gnome/dash-to-panel/issues/959,
wherein I discover that dash-to-panel seems to be the worst offender in
terms of leaking handlers, but there's a lower-grade steady leak anyway,
which might bear looking at.
** Bug watch added:
This is proving to be really difficult to reproduce -- it's getting
slower (but really slowly) on my spare PC. The memory use for gnome-
shell is, essentially, static.
So: I sampled some perf data from the PC where it consistently happens
and threw up a flame graph.
It spends a bunch of time in
> see if something's leaking registered handlers.
It looks like clutter handlers are stored in two different hash tables:
g_handlers and g_handler_list_bsa_ht.
On the PC that's really slow, g_handlers.size = 8388608 (that's ~8M); on
the PC that's not, g_handlers.size = 65536 (~65K). So, yeah,
Public bug reported:
I searched and found related bugs #1774188 and #1847566, but one of
those is against 19.04, which is end-of-support, and the other was
abandoned with no feedback from the OP. So, let's try again.
When unlocking my screen, it takes progressively longer to unlock. After
a
I can't do that on my primary PC -- I'm *using* those extensions.
I'll set up my spare PC the same way (with the extensions) and see if I
can repro. Then I'll disable them and see if the problem goes away (or
not).
Gonna take me about a week, though, since this only happens after a
bunch of
Some investigation and notes (and apologies for the noise; I need
somewhere to take notes):
I have the following extensions in /usr/share/gnome-shell/extensions:
alternate-...@gnome-shell-extensions.gcampax.github.com/
apps-m...@gnome-shell-extensions.gcampax.github.com/
I've also removed gnome-shell-extension-move-clock, gnome-shell-
extension-autohidetopbar and gnome-shell-extension-taskbar.
> I'm not sure what it means that I have an extension listed in both
locations.
I suspect that either I've installed it explicitly, or
extensions.gnome.org installed an
Update: my spare PC is definitely getting slower at unlocking, but
(possibly because I'm not using it as much) not as quickly.
Are there any logs/debug steps you want me to run on it? I know enough
gdb to be dangerous, if that helps.
--
You received this bug notification because you are a
19 matches
Mail list logo
