Bug #74179 [Opn->Dup]: Large mysql requests broken after update to 7.0.x

From: Date: Mon, 27 Feb 2017 21:47:42 +0000
Subject: Bug #74179 [Opn->Dup]: Large mysql requests broken after update to 7.0.x
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-207597@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=74179&edit=1

 ID:                 74179
 Updated by:         nikic@php.net
 Reported by:        nish dot aravamudan at canonical dot com
 Summary:            Large mysql requests broken after update to 7.0.x
-Status:             Open
+Status:             Duplicate
 Type:               Bug
 Package:            MySQL related
 Operating System:   Ubuntu 16.04
 PHP Version:        7.0.16
 Block user comment: N
 Private report:     N

 New Comment:

This is a duplicate of bug #74021, which was a regression introduced in 7.0.15 (due to an incorrect
fix for bug #73800). The issue is fixed by https://github.com/php/php-src/commit/01c1afa79f614fe8376e73f4e73f392160923745,
which will be part of PHP 7.0.17.


Previous Comments:
------------------------------------------------------------------------
[2017-02-27 21:39:39] spam2 at rhsoft dot net

smells like https://bugs.php.net/bug.php?id=74021 which was
still not fixed with 71.2. / 7.0.16

------------------------------------------------------------------------
[2017-02-27 21:27:28] nish dot aravamudan at canonical dot com

Description:
------------
Original bug report: https://bugs.launchpad.net/ubuntu/+source/php7.0/+bug/1668017

Roughly, we produced a security/update update of the PHP7.0 package in Ubuntu which bumped up to
7.0.15. A user reported that this regressed their installation, specifically:

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)

---

The prior (working) version was 7.0.8 based.

Test script:
---------------
The reporter provided a relatively straightforward 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 the 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.



------------------------------------------------------------------------



--
Edit this bug report at https://bugs.php.net/bug.php?id=74179&edit=1


Thread (4 messages)

« previous php.bugs (#207597) next »