hcq/MaxScale
hcq/MaxScale
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fix possible writes to closed DCBs

Browse Source 
When persistent connections were used, it was possible that the injection
of COM_CHANGE_USER statements caused a crash when a DCB in the wrong state
was accessed.

For MySQL protocol modules, the `data` member of the client DCB points to
the shared session data, a MYSQL_session struct, but for sessions in the
persistent pool, it points to NULL. The boolean, `was_persistent`, tells
whether a DCB was just taken from the pool or it has been in use.

The `was_persistent` status wasn't properly reset for connections that
were put into the pool which caused a COM_CHANGE_USER statement to be
injected for stale connections in the pool which caused a crash when the
NULL `data` member was accessed.
This commit is contained in:
Markus Makela 2016-11-08 09:24:00 +02:00
parent 7358d932e6
commit 689366b6b7
2 changed files with 3 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
server/core/dcb.c
View File

@ -1827,6 +1827,7 @@ dcb_maybe_add_persistent(DCB *dcb)
MXS_DEBUG("%lu [dcb_maybe_add_persistent] Adding DCB to persistent pool, user %s.\n",
pthread_self(),
dcb->user);
dcb->was_persistent = false;
dcb->dcb_is_zombie = false;
dcb->persistentstart = time(NULL);
if (dcb->session)

3
server/modules/protocol/MySQL/MySQLBackend/mysql_backend.c
View File

@ -947,8 +947,9 @@ static int gw_MySQLWrite_backend(DCB *dcb, GWBUF *queue)
CHK_DCB(dcb);
spinlock_acquire(&dcb->authlock);
if (dcb->was_persistent)
if (dcb->was_persistent && dcb->state == DCB_STATE_POLLING)
{
ss_dassert(dcb->persistentstart == 0);
/**
* This is a DCB that was just taken out of the persistent connection pool.
* We need to sent a COM_CHANGE_USER query to the backend to reset the