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 build-android target calls the pre-build target as pre-buid, resulting in build failure for the build-android target. This PR fixes the issue.

(PR #2272 did the same for a typo in the build-pr target.)

== 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.

The push proxy codebase refers to notifications as ”notificaitons” once in the README and once in a LogInfo() call.

Steps to reproduce

$ git clone https://github.com/mattermost/mattermost-push-proxy.git
$ cd mattermost-push-proxy/
$ git rev-parse HEAD
41affc6595fc927a75de1184292cec89278b40a8
nothing to commit, working tree clean
$ git rev-parse HEAD
41affc6595fc927a75de1184292cec89278b40a8
$ grep -Ri "notificaiton" .

Expected behavior

$ grep -Ri "notificaiton" .
$

Observed behavior (that appears unintentional)

$ grep -Ri "notificaiton" .
./server/android_notification_server.go:	LogInfo(fmt.Sprintf("Initializing Android notificaiton server for type=%v", me.AndroidPushSettings.Type))
./README.md:For more in-depth instructions on setting up push notificaitons with your own build please follow the directions at [docs.mattermost.com](https://docs.mattermost.com/developer/mobile-developer-setup.html#push-notifications-with-your-own-build)

Possible fixes

Here’s a link to the line in server/android_notification_server.go, README.md link unavailable because Github doesn’t allow per-line linking to Markdown files (that I know of). I think this should be pretty easy to fix and I can provide a pull request.

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.)

Server Setup Information:

• Wekan version: 1.53
• Deployment Method: snap (tracking stable)
• Operating System: Ubuntu 16.04
• Http frontend: Apache 2.4
• ROOT_URL environment variable https://my-domain.com/kan

Screen recording:

Steps to reproduce:

1. Create a card
2. Click on the comment field, enter ”some text”
3. Click on the description field
4. Close the card
5. Open the card
6. Try to delete the ”some text” comment draft, either by selecting and clearing out the text, or by posting the comment (by selecting ’Comment’)
7. Close the card, open it again

What happens:
The comment draft remains in the comment field. If you posted it at step 6 above, you now have the posted comment plus the same comment as draft.

What I expect to happen:
For the comment draft to have been deleted. If you skip step 3 (i.e. don’t click on the description field but close the card directly), the draft is deleted. While I’d actually prefer the draft to remain in this situation, this is slightly better than the undeleteable draft.

Web Console contents:
Upon closing the card at step 4, console shows this:

remove failed: Internal server error 9f30bda751070caba2631cd997a9c88102b36537.js:1:6261
insert failed: i@https://my-domain.com/kan/9f30bda751070caba2631cd997a9c88102b36537.js?meteor_js_resource=true:89:2640
t@https://my-domain.com/kan/9f30bda751070caba2631cd997a9c88102b36537.js?meteor_js_resource=true:89:2478
c.Collection.prototype[i]@https://my-domain.com/kan/9f30bda751070caba2631cd997a9c88102b36537.js?meteor_js_resource=true:89:6720
@https://my-domain.com/kan/9f30bda751070caba2631cd997a9c88102b36537.js?meteor_js_resource=true:111:4415
n/</i[n]@https://my-domain.com/kan/9f30bda751070caba2631cd997a9c88102b36537.js?meteor_js_resource=true:111:1717
set@https://my-domain.com/kan/9f30bda751070caba2631cd997a9c88102b36537.js?meteor_js_resource=true:299:385103
t@https://my-domain.com/kan/9f30bda751070caba2631cd997a9c88102b36537.js?meteor_js_resource=true:299:165991
inlinedform.js/<@https://my-domain.com/kan/9f30bda751070caba2631cd997a9c88102b36537.js?meteor_js_resource=true:299:375381
9f30bda751070caba2631cd997a9c88102b36537.js:1:6261

Other info

• I’d rate this Severity:Inconvenient
• There is at least one way to delete the draft: after clearing out the text, click the description field, then close the card. This again results in the above errors being reported in the console, but opening the card reveals that the draft is now gone.
• This is slightly reminiscient of issue #1287 (also reported by me way back when), though my guess would be that these are completely unrelated, and I’m only making the link here just in case the solutions happen to be similar (as both deal with drafts and saving).
• I’m attaching snap logs output from today (while testing this), although the events there do not seem to coincide with the draft problem (just card deletion).

All of my devices are affected by this, or something very similar. My server is running Ubuntu 16.06 with Nextcloud 14.0.1 (in a subdirectory). Here’s logs from my

• Nexus 5X (Android 8.0.1 @ Oct 2018 level patches)
• Moto G (2013 model, LineageOS 14.1 / Android 7.1.2)
• Samsung Galaxy Tab 4 (SM-T530, Android 5.0.2. @ Jan 2017 level)

I trimmed them down to (what appears to me as) the essential, filtered out some noise and replaced my username and the server hostname.

Steps to reproduce:

1. (On desktop) Create a new subdirectory under the sync directory, add two JPEG files into it. Wait for changes to sync.
2. (On mobile) Open Nextcloud, select the newly created directory, switch to grid view.

Replace instruction using ln -s to enable Apache site to use a2ensite instead in Debian and derivatives. Closes #884.

Under Apache Web server configuration, there’s a prompt to create a symlink to enable the newly created site:

ln -s /etc/apache2/sites-available/nextcloud.conf /etc/apache2/sites-enabled/nextcloud.conf

As the instructions in this section are written for Debian, Ubuntu, and their derivatives, a2ensite should be used instead:

a2ensite nextcloud.conf

The commands are currently functionally equivalent (AFAIK), but should this change sometime, the latter would be more future proof, besides being much shorter and easier to type.

Additionally, immediately following the ln -s there is a section about Additional Apache configurations, which correctly instructs the use of a2enmod to create the symlinks. Replacing ln -s with a2ensitewould thus harmonize the two sections.

All right. Thanks, Jeremy!