| Bug #82792 | Compressed protocol can't read packets of size 0xffffff | ||
|---|---|---|---|
| Submitted: | 29 Aug 2016 22:55 | Modified: | 30 Aug 2016 6:33 |
| Reporter: | Aaron Balsara | Email Updates: | |
| Status: | Verified | Impact on me: | |
| Category: | MySQL Server: C API (client library) | Severity: | S3 (Non-critical) |
| Version: | 5.6, 5.6.32, 5.7.14 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
[30 Aug 2016 6:33]
MySQL Verification Team
Hello Aaron, Thank you for the report and test case. Thanks, Umesh
[10 Jan 2018 11:37]
Daniƫl van Eeden
Shouldn't this bug be closed as the bug below is fixing this issue via a contribution? Bug #88092 Contribution by Facebook: Read compressed packets of size 0xffffff

Description: When using the compressed protocol mysql buffers received packets and returns them to callers one at time. As it does this it saves the first char of the next packet and replaces it with the null byte, and restores this character when the next packet is requested. If the packet it is returning is a multi packet and the last packet is of size 0 (i.e. the total size of the packet is some multiple of 0xffffff) then the wrong character is saved and the header of the next packet is clobbered when the character is restored How to repeat: Using the compressed protocol with the following test set global max_allowed_packet = 33554432; connect(con1, localhost, root,,); connection con1; SELECT REPEAT('X', 16777211); disconnect con1; connection default; Instead of succeeding the query will fail with Lost Connection to MySQL Server Suggested fix: When saving the character check if the current packet is split over multiple packets and if the last packet size was 0. If this is the case you need to save the character that is 4 bytes (NET_HEADER_SIZE) further along in the buffer