| Bug #35593 | Memory leak in failed NDB execute() with blobs. | ||
|---|---|---|---|
| Submitted: | 27 Mar 2008 9:52 | Modified: | 31 May 2008 10:46 |
| Reporter: | Kristian Nielsen | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Cluster: Cluster (NDB) storage engine | Severity: | S3 (Non-critical) |
| Version: | mysql-5.1, mysql-5.1-telco-*, mysql-6.0 | OS: | Any |
| Assigned to: | Kristian Nielsen | CPU Architecture: | Any |
[27 Mar 2008 11:02]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/44504 ChangeSet@1.2593, 2008-03-27 12:01:11+01:00, knielsen@ymer.(none) +1 -0 BUG#35593: Memory leak in failed NDB execute() with blobs. During NdbTransaction::execute() with blobs, the code keeps temporary lists of operations in local variables. In case of errors in the execute(), in some scenarios these lists of operations were not linked back into the transaction object, causing them to memory leak.
[27 Mar 2008 11:42]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/44508 ChangeSet@1.2533, 2008-03-27 12:41:00+01:00, knielsen@ymer.(none) +3 -0 BUG#35593: Memory leak in failed NDB execute() with blobs. During NdbTransaction::execute() with blobs, the code keeps temporary lists of operations in local variables. In case of errors in the execute(), in some scenarios these lists of operations were not linked back into the transaction object, causing them to memory leak.
[27 Mar 2008 13:01]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/44513 ChangeSet@1.2529, 2008-03-27 13:59:31+01:00, knielsen@ymer.(none) +3 -0 BUG#35593: Memory leak in failed NDB execute() with blobs. During NdbTransaction::execute() with blobs, the code keeps temporary lists of operations in local variables. In case of errors in the execute(), in some scenarios these lists of operations were not linked back into the transaction object, causing them to memory leak.
[27 Mar 2008 13:42]
Kristian Nielsen
Pushed to mysql-5.1-new-ndb, mysql-5.1-telco-6.2, mysql-5.1-telco-6.3, mysql-5.1-telco-6.4, and mysql-6.0-ndb. For documentation: If an error occured during a statement involving BLOB/TEXT in an NDB table, a memory leak could result.
[4 Apr 2008 21:16]
Jon Stephens
Documented in the 5.1.23-ndb-6.3.11 changelog as follows:
If an error occured while executing a statement involving BLOB or TEXT
column in an NDB table, a memory leak could result.
Left status as Patch Queued pending additional merges.
[4 Apr 2008 22:45]
Jon Stephens
Fix also noted in the 5.1.23-ndb-6.2.15 changelog.
[31 May 2008 10:46]
Jon Stephens
Closed per yesterday's discussion with Jonas.
[12 Dec 2008 23:27]
Bugs System
Pushed into 6.0.6-alpha (revid:sp1r-knielsen@ymer.(none)-20080327125931-19338) (version source revid:sp1r-tomas@poseidon.ndb.mysql.com-20080516085603-30848) (pib:5)
Description: Valgrind found a memory leak in NDB. It occurs when there is a failure in NdbTransaction::execute(), ie. deadlock timeout. I think it might be related to blobs and the way that one application-level execute() is split into multiple internal execute()'s dealing with the blob parts. But not 100% sure. How to repeat: Run this mysql-test-run.pl test case under Valgrind: --source include/have_ndb.inc --disable_warnings drop table if exists t1; --enable_warnings create table t1 ( a int not null primary key, b text not null ) engine=ndbcluster; # Force a deadlock. connect (con1,localhost,root,,test); connect (con2,localhost,root,,test); connection con2; begin; insert into t1 values (2, repeat("w", 8000)); connection con1; --error 1205 insert into t1 values (1, repeat("x", 10000)), (2, repeat("y", 5000)), (3, repeat("z", 15000)); rollback; connection con2; commit; drop table t1;