[MDEV-12761] Error return from external_lock make the server crash Created: 2017-05-09  Updated: 2017-05-16  Resolved: 2017-05-16

Status: Closed
Project: MariaDB Server
Component/s: Server
Affects Version/s: 10.1.22
Fix Version/s: 10.1.24, 10.0.31, 10.2.7

Type: Bug Priority: Critical
Reporter: Olivier Bertrand Assignee: Sergei Golubchik
Resolution: Fixed Votes: 0
Labels: None
Environment:

Windows


 Description   

This is due to:

Assertion failed: m_lock_type == 3, file C:\MariaDB-10.1\MariaDB\sql\handler.cc, line 2564
 
by
 
  DBUG_ASSERT(m_lock_type == F_UNLCK);

Indeed, the m_lock_type variable is declared and described in handler.h as:

 
private:
 
  /**
 
    The lock type set by when calling::ha_external_lock(). This is 
    propagated down to the storage engine. The reason for also storing 
    it here, is that when doing MRR we need to create/clone a second handler
 
    object. This cloned handler object needs to know about the lock_type used.
 
  */
 
  int m_lock_type;

However, external_lock can be called in handler::ha_external_lock line 5828 with lock_type set to F_UNLCK but with this variable not having been set and still having a different value. On return, this function does set it line 5835 but only when there is no error.

 Comments   
Comment by Sergei Golubchik [ 2017-05-11 ]

bertrandop, I'm trying to understand what's happening:

1. server does external_lock(F_RDLCK or F_WRLCK),
2. server does external_lock(F_UNLCK),
it fails, so m_lock_type is not changed
3. server does close(), assert fires, because m_lock_type is not F_UNLCK

Is that correct?

If yes, then the fix should be, I guess, set m_lock_type=F_UNLCK even if external_lock(F_UNLCK) failed.

Comment by Olivier Bertrand [ 2017-05-11 ]

Correct.

But if so, what's the use of all these DBUG_ASSERT?

Generated at Thu Feb 08 08:00:15 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.