[MXS-1825] test_wl4435_3 case from mysql_client_test.c lead to crash Created: 2018-04-25  Updated: 2018-04-29  Resolved: 2018-04-29

Status: Closed
Project: MariaDB MaxScale
Component/s: readwritesplit
Affects Version/s: 2.2
Fix Version/s: 2.2.6

Type: Bug Priority: Major
Reporter: xiangzhong Assignee: markus makela
Resolution: Fixed Votes: 0
Labels: None
Environment:

linux + make debug



 Description   

bt:

#0 0x00007fb6a62cf6ab in raise () from /lib64/libpthread.so.0
#1 0x00007fb6a1db9944 in log_unexpected_response (dcb=0x7fb6880249e0, buffer=0x7fb688026650)
at /home/xiangzhong.wxd/gitlab/MaxScale/server/modules/routing/readwritesplit/readwritesplit.cc:1155
#2 0x00007fb6a1db9bba in clientReply (instance=0x21b3940, router_session=0x7fb688024d50, writebuf=0x7fb688026650, backend_dcb=0x7fb6880249e0)
at /home/xiangzhong.wxd/gitlab/MaxScale/server/modules/routing/readwritesplit/readwritesplit.cc:1190
#3 0x00007fb6a131c974 in gw_read_and_write (dcb=0x7fb6880249e0) at /home/xiangzhong.wxd/gitlab/MaxScale/server/modules/protocol/MySQL/mariadbbackend/mysql_backend.c:976
#4 0x00007fb6a131b581 in gw_read_backend_event (dcb=0x7fb6880249e0) at /home/xiangzhong.wxd/gitlab/MaxScale/server/modules/protocol/MySQL/mariadbbackend/mysql_backend.c:484
#5 0x00007fb6a67e2f55 in dcb_process_poll_events (dcb=0x7fb6880249e0, events=5) at /home/xiangzhong.wxd/gitlab/MaxScale/server/core/dcb.cc:3146

this case have SERVER_PS_OUT_PARAMS for stmt_exec



 Comments   
Comment by markus makela [ 2018-04-25 ]

I was able to reproduce this only with MySQL 5.6 but this is due to the fact that the server appears to send a broken result to the client. The last EOF packet before the final OK packet is missing the more results exist flag. All MariaDB versions correctly return the flag and MaxScale works as expected.

Here's the output of 5.6 with the relevant line highlighted:

Network Trace

1
T 127.0.0.1:37798 -> 127.0.0.1:3000 [AP]
2
  11 00 00 00 16 43 41 4c    4c 20 70 32 28 3f 2c 20    .....CALL p2(?, 
3
  3f 2c 20 3f 29                                        ?, ?)           
4
#
5
T 127.0.0.1:3000 -> 127.0.0.1:37798 [AP]
6
  0c 00 00 01 00 02 00 00    00 00 00 03 00 00 00 00    ................
7
  17 00 00 02 03 64 65 66    00 00 00 01 3f 00 0c 3f    .....def....?..?
8
  00 00 00 00 00 fd 80 00    00 00 00 17 00 00 03 03    ................
9
  64 65 66 00 00 00 01 3f    00 0c 3f 00 00 00 00 00    def....?..?.....
10
  fd 80 00 00 00 00 17 00    00 04 03 64 65 66 00 00    ...........def..
11
  00 01 3f 00 0c 3f 00 00    00 00 00 fd 80 00 00 00    ..?..?..........
12
  00 05 00 00 05 fe 00 00    02 00                      ..........      
13
#
14
T 127.0.0.1:37798 -> 127.0.0.1:3000 [AP]
15
  11 00 00 00 03 53 45 54    20 4e 41 4d 45 53 20 62    .....SET NAMES b
16
  69 6e 61 72 79                                        inary           
17
#
18
T 127.0.0.1:3000 -> 127.0.0.1:37798 [AP]
19
  07 00 00 01 00 00 00 02    00 00 00                   ...........     
20
#
21
T 127.0.0.1:37798 -> 127.0.0.1:3000 [AP]
22
  23 00 00 00 17 02 00 00    00 00 01 00 00 00 00 01    #...............
23
  fe 00 fe 00 fe 00 0e ee    d5 2c 20 da c1 20 d2 d9    ........., .. ..
24
  c2 c1 cc cb d5 00 00                                  .......         
25
#
26
T 127.0.0.1:3000 -> 127.0.0.1:37798 [AP]
27
  01 00 00 01 02 2c 00 00    02 03 64 65 66 0e 63 6c    .....,....def.cl
28
  69 65 6e 74 5f 74 65 73    74 5f 64 62 02 70 32 02    ient_test_db.p2.
29
  70 32 02 6f 31 02 6f 31    0c 3f 00 ff 00 00 00 fd    p2.o1.o1.?......
30
  00 00 00 00 00 2c 00 00    03 03 64 65 66 0e 63 6c    .....,....def.cl
31
  69 65 6e 74 5f 74 65 73    74 5f 64 62 02 70 32 02    ient_test_db.p2.
32
  70 32 02 6f 32 02 6f 32    0c 3f 00 ff 00 00 00 fd    p2.o2.o2.?......
33
  80 00 00 00 00 05 00 00    04 fe 00 00 0a 10 20 00    .............. .
34
  00 05 00 00 0e cd f3 2c    20 e7 e0 20 f0 fb e1 e0    ......., .. ....
35
  eb ea f3 0e ee d5 2c 20    da c1 20 d2 d9 c2 c1 cc    ......, .. .....
36
  cb d5 05 00 00 06 fe 00    00 02 00                   ...........     
37
#
38
T 127.0.0.1:3000 -> 127.0.0.1:37798 [AP]
39
  07 00 00 07 00 00 00 02    00 00 00                   ...........     

Comment by markus makela [ 2018-04-26 ]

Turns out that this is intended (and documented) behavior for MySQL. If the first EOF packet has the flag for PS output parameters, it needs to be interpreted as a more results exist flag in the second EOF packet. MariaDB just has the more results exist flag in the last packet.

Generated at Thu Feb 08 04:09:40 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.