Bug #68010 | memcached crashes | ||
---|---|---|---|
Submitted: | 2 Jan 2013 10:41 | Modified: | 4 Jul 2019 14:57 |
Reporter: | Davide F | Email Updates: | |
Status: | Can't repeat | Impact on me: | |
Category: | MySQL Cluster: Memcached | Severity: | S1 (Critical) |
Version: | 7.2.8 | OS: | Linux |
Assigned to: | MySQL Verification Team | CPU Architecture: | Any |
Tags: | cluster, crash, memcached, ndb |
[2 Jan 2013 10:41]
Davide F
[5 Aug 2013 18:15]
Hartmut Holzgraefe
This only happens with binaries built with debug enabled, right? The code is: [...] 402 /* Start the transaction */ 403 tx = op.startTransaction(wqitem->ndb_instance->db); 404 if(! tx) { 405 logger->log(LOG_WARNING, 0, "tx: %s \n", 406 wqitem->ndb_instance->db->getNdbError().message); >407 DEBUG_ASSERT(false); 408 } 409 410 if(wqitem->base.verb == OPERATION_REPLACE) { 411 DEBUG_PRINT(" [REPLACE] \"%.*s\"", wqitem->base.nkey, wqitem->key); 412 ndb_op = op.updateTuple(tx); [...] So a transaction is started, which can fail e.g. due to timeouts (as seen here) or as e.g. MaxNoOfConcurrentTransactions is exceeded, and the only error handling that is done is to throw an assertion failure if in debug mode? Otherwise the now invalid tx handle is used in followup instructions as if nothing happened, and only much later the followup operation failures are handled ... Not really my idea of error handling, why not simply return op_failed early on not being able to start a new cluster transaction instead of throwing an assertion failure?
[4 Jul 2019 14:57]
MySQL Verification Team
I cannot reproduce this on any of the modern binaries bogdan