packet_size > DRIZZLE_MAX_BUFFER_SIZE kills connection

[Andrew Hutchings]

observed in a binlog with a 600KB event:

DEBUG: drizzle_state_packet_read
DEBUG: buffer_size= 6096, packet_size= 33, packet_number= 3
DEBUG: drizzle_state_packet_read
DEBUG: buffer_size= 6059, packet_size= 687906, packet_number= 4
DEBUG: drizzle_state_read
DEBUG: read fd=3 recv=16162 ssl= 0 errno=Resource temporarily unavailable
DEBUG: drizzle_state_read
DEBUG: read fd=3 recv=0 ssl= 0 errno=Resource temporarily unavailable

tests/unit/binlog.c:84: main Assertion 'DRIZZLE_RETURN_OK' != 'ret' [ Binlog error drizzle_state_read:libdrizzle/conn.cc:1179 lost connection to server (EOF)
 ]

Event is a query event which was caused by sysbench prepare command

[Andrew Hutchings (linuxjedi)]

read_size= recv(con->fd, (char *)con->buffer_ptr + con->buffer_size, available_buffer, MSG_NOSIGNAL);

available_buffer = 0 in this context:

(gdb) print con->buffer_size
$2 = 22217
(gdb) print con->buffer_ptr - con->buffer
$3 = 10551

size_t available_buffer= (size_t)DRIZZLE_MAX_BUFFER_SIZE - ((size_t)(con->buffer_ptr - con->buffer) + con->buffer_size);

So quite rightly we get a read of 0. recv return of 0 also means connection lost.

Need a much better way of handling large packets.

[Andrew Hutchings (linuxjedi)]

firstly we need an 'if' around available_buffer to throw an error or take some action. We should not ever request a 0 byte read.

[Andrew Hutchings (linuxjedi)]

all other send/recv function appear to have the same problem. Assumes the packet fits into tiny buffer. Either need a flexible buffer or a larger buffer with proper error handling (MySQL has MAX_PACKET_SIZE for this).

[Andrew Hutchings (linuxjedi)]

Need to accelerate plans for bug #1094633. Fix this by switching the buffer to a std::vector with a default and maximum size (say 1GB).