This happens in 18.04 too. Bug #1650076 does also, and I’m not 100 % sure if these are two different issues or the same. I was able to reproduce #1650076 with the steps listed there, but just before that I had Evince following my scroll wheel despite being unfocussed, and I had not selected anything in the PDF before that (at least not knowingly). I haven’t found the steps to reproduce this without the selection though.

When acpica-tools is not installed, running acpidump or acpixtract produces no suggestions (in either Bionic or Cosmic):

$ acpixtract
acpixtract: command not found
$ apt-cache policy acpitools-ca
N: Unable to locate package acpitools-ca
$ apt-cache policy acpica-tools
acpica-tools:
Installed: (none)
Candidate: 20180629-1
Version table:
20180629-1 500
500 http://archive.ubuntu.com/ubuntu cosmic/universe amd64 Packages
$ sudo apt install acpica-tools
[sudo] password for jani:
Reading package lists… Done
Building dependency tree
Reading state information… Done
The following packages were automatically installed and are no longer required:
linux-headers-4.18.0-8 linux-headers-4.18.0-8-generic linux-image-4.18.0-8-generic linux-modules-4.18.0-8-generic
linux-modules-extra-4.18.0-8-generic
Use ’sudo apt autoremove’ to remove them.
The following NEW packages will be installed:
acpica-tools
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 851 kB of archives.
After this operation, 2782 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu cosmic/universe amd64 acpica-tools amd64 20180629-1 [851 kB]
Fetched 851 kB in 1s (1622 kB/s)
Selecting previously unselected package acpica-tools.
(Reading database … 207563 files and directories currently installed.)
Preparing to unpack …/acpica-tools_20180629-1_amd64.deb …
Unpacking acpica-tools (20180629-1) …
Setting up acpica-tools (20180629-1) …
update-alternatives: using /usr/bin/acpixtract-acpica to provide /usr/bin/acpixtract (acpixtract) in auto mode
update-alternatives: warning: skip creation of /usr/share/man/man1/acpixtract.1.gz because associated file /usr/share/man/man1/acpixtract-acpica.1 (of link group acpixtract) doesn’t exist
update-alternatives: using /usr/bin/acpidump-acpica to provide /usr/bin/acpidump (acpidump) in auto mode
update-alternatives: warning: skip creation of /usr/share/man/man1/acpidump.1.gz because associated file /usr/share/man/man1/acpidump-acpica.1 (of link group acpidump) doesn’t exist
Processing triggers for man-db (2.8.4-2) …
$ acpidump
Could not open table file: /sys/firmware/acpi/tables/SSDT
Could not get ACPI tables, AE_ACCESS
$ acpixtract

Intel ACPI Component Architecture
ACPI Binary Table Extraction Utility version 20180629
Copyright (c) 2000 – 2018 Intel Corporation

Usage: acpixtract [option] <InputFile>
Options:
-a Extract all tables, not just DSDT/SSDT
-f Force extraction, even if there are errors
-l List table summaries, do not extract
-m Extract multiple DSDT/SSDTs to a single file
-s <signature> Extract all tables with <signature>
-v Display version information
-vd Display build date and time

Extract binary ACPI tables from text acpidump output
Default invocation extracts the DSDT and all SSDTs

I’m seeing memory-related crashes when playing videos sliced (with ffmpeg -c copy) from mp4 streams (downloaded with youtube-dl). I’m attaching a sample clip which, granted, is pretty useless for a video, but which produces these crashes with 100% certainty for me; I just edited it down to a reasonable size and non-infringing content.

The errors reported just before core is dumped are (mostly) ”double free or corruption (fasttop)” or (less often) ”malloc_consolidate(): invalid chunk size”.

To be clear, my expectation here is not for the problematic clips to have useful content, or even to play back; just that vlc didn’t crash. (Totem for instance does not seem to crash with the same files.)

I’ll attach logs for both the double free and malloc_consolidate cases (which I’m producing by running LC_ALL=C vlc -vvv out.mp4 in a loop).

== The issue ==
Search and text selection highlighting visuals get mismatched with the actual selection in view-source when the value of `layout.css.devPixelsPerPx` is 1.2 or larger.

== Steps to reproduce ==
* Open `about:config`, find `layout.css.devPixelsPerPx` and change the value from default (-1.0) to 1.2.
* Open a view-source view with long lines: `view-source:https://www.youtube.com/user/10asti10`
* hit Ctrl+f, search for rss
* using the LMB, try selecting some text, then copy and paste it somewhere

== What happens ==
Screenshot 1: the highlighted text on the page is not ”rss”. The highlight doesn’t even adhere to letter widths.

Screenshot 2: the pasted text is not even close to what you’ve selected to copy.

== What I expect to happen ==
For the search to hightlight an occurence of ”rss”, and for the pasted text to correspond to what I’ve selected from the view-source view.

== Other info ==
* In my testing, a devPixelsPerPx value of 1.1 seems to not trigger this, whereas 1.2 and anything above does.
* In addition to 18.04 (whence the attached info is from) I’ve reproduced this in a VM running up-to-date 18.10.

Needless verbosity is the problem here, IMO. I’d expect to receive output from the installer only when the download or install fails for some reason, not when it succeeds.

(Also, to me the culprit here seems to be flashplugin-installer and not update-notifier, as plenty of other packages also report their installation progress, but only flashplugin’s seems to get forwarded to root’s mail even when nothing abnormal occurs.)

All right. Thanks, Jeremy!

Okay, did it! https://gitlab.gnome.org/GNOME/gnome-terminal/issues/30

Jeremy: If this is indeed the popular choice then I fully respect that. I just wanted to voice my disgruntlement, since I feel the way this was set by upstream is much simpler. Sorry for being late with it, didn’t realize this was getting overridden before the change already came into effect.

Urgh, I’d argue that changing this back *is* a regression. The merged menu item has been the default since (at least) 16.04, and now the cognitive load of opening a new tab has suddenly increased: instead of ”new terminal” I now again have to pick the one I want (which is always tabs for me) from two options each time, instead of just the one.

Thanks, I’ve now reported this at: https://gitlab.gnome.org/GNOME/gnome-shell/issues/287