SRU team: as this is a SRU and security regression, I'm hopeful we can bypass the 7-day waiting period, presuming @jbruijn or I can test the version from -proposed first.
[Impact]
* The prior SRU of 7.0.15 included an upstream regression to MySQL support with large blobs.
* The fix has not yet been published in an upstream release, but is planned for 7.0.17.
[Test Case]
- Ubuntu 16.04
- MariaDB Server (not tested on mysql, but I expect similar results)
- php 7.0 (7.0.15)
- phpMyAdmin
Configuration:
MariaDB: max_allowed_packet = 128M
php: post_max_size and upload_max_filesize raised to 128M
Import some SQL data, for instance: https://we.tl/vb37KISpUU.
This will build you a MyISAM table with 4 columns, 3x varchar(1) and 1 longblob. The table will have one big blob in it, with 32Mbyte worth of 0x20 (space)
Downloading the binary through phpMyAdmin on 7.0.15 will produce a file with a null-character inserted at (for my setup) 0xFFFFF6, the rest of the file is as expected.
[Regression Potential]
* This upload includes the upstream fix, as well as testcases for the same. As this is a fix to an existing regression, I do not believe there is any chance of regression and it should be caught by the test sutie.
---
I'm running a web application serving rather big binary blobs from a MariaDB table. After the unattended update (7.0.8-0ubuntu0.16.04.3 to 7.0.15-0ubuntu0.16.04.2), the application would routinely break while trying to fetch a >16Mbyte row from the database server.
Requests resulting in a row under 16Mbyte are processed normally, anything above it would return columns in the wrong order, and right around 0xFFFFF2 a null-character (0x00) is inserted into the stream (when the resulting file is compared to one served with the version used previously)
Rolling back to 7.0.4-7ubuntu2 immediately fixed the issue. I'm pretty sure the problem was introduced somewhere between 7.0.8 and 7.0.15, but I cant find anything relevant in the changelog for those versions.
Please let me know what I can do to assist!
Hi jbruijn,
first of all thanks for your report and your help to make Ubuntu better.
I'm subscribing Nish who was driving the php update, but I think he might be subscribed to php anyway.
The one thing you really could help us with very likely would be some steps to reproduce.
So if you could (e.g. in a fresh VM) check what commands you need to set up a very trivial DB, containing a 16M field the way you have it and a very trivial php to fetch that showing the issue - that would be great.
We often try to create such ourselves, but more often than not some unexpected small differences make them not trigger the issue - so if you could provide such a few steps to reproduce that would certainly help a lot!