Hi Jared,

thanks for your ticket!
Would it be possible to provide some more information, e.g.

• version of MariaDB server
• if possible a reproducable test
• definition of underlying tables
• SQL statement which causes the problem
• a tcp dump

Thanks!

We ran this against the 10.5.9 version of the server, and we have trying to work out the circumstances that trigger the issue. Thus far looking at configuration differences between servers has not yielded the answer yet. I am preparing to run debugger on the server to step through what is happening from that side to see if I can come up with the reproducible steps.

We did run this previously against 10.2 without issue. That version does not share the extended metadata attribute which is required to trigger the processing of 9 fields instead of 8.

I am reticent to share the dumps I've taken directly, but I can share the portions of the server response where, after stepping through the connector code in debugger, I discovered what was happening, and where there might be a long standing issue in the server.

This is a redacted MySQL packet for the response where the connector throws an unknown error:

0000 5a 00 00 02 03 64 65 66 06 6e 6e 6e 6e 6e 6e 0e Z....def.nnnnnn.
0010 72 72 72 72 72 72 72 5f 63 63 63 63 63 63 0e 72 rrrrrrr_cccccc.r
0020 72 72 72 72 72 72 5f 63 63 63 63 63 63 11 72 72 rrrrrr_cccccc.rr
0030 72 72 72 72 72 5f 63 63 63 63 63 63 5f 69 69 11 rrrrr_cccccc_ii.
0040 72 72 72 72 72 72 72 5f 63 63 63 63 63 63 5f 69 rrrrrrr_cccccc_i
0050 69 0c 3f 00 0b 00 00 00 03 2b 42 00 00 00 4a 00 i.?......+B...J.

The connector reads through this packet reading the length encoded metadata fields denoted by addresses 0x04, 0x08, 0x0F, 0x1E, 0x2D, and 0x3F. The next set of fields to be read are packed fields with the length of those packed fields noted at 0x51. In all 3.1 versions of the connector, it treats this section as a length encoded field so reads the next 12 (0x0c) bytes as the 7th field. When it tries to read the 8th field, it is beyond the end of the packet and into the allocated buffer. In my runs this seems to always have been empty resulting in another 0 length field (0x00). For the 9th field it reads a value of the length in excess of the difference of end_to - to resulting in the unknown error.

The case in which the query "works" is nearly identical, except that instead of 0x0c at the 0x51 address, a null byte (0x00) in inserted, shifting the rest of the contents by one byte. In that scenario the 7th field is a 0 byte field and the 8th field is read as the 0x0c and the next 12 bytes are read for the 8th field. The 9th field is read as a 0 byte field and the loop completes without issue.

I will spend some time trying to figure out why the server gives different response for the same query and server configuration and if I can discover that, might be able to provide a reproducible scenario.