memory leak

[Seppo Jaakola]

memory leak was detected during 0.7pre RC testing

valgrind shows following suspicious warning:

==29312== 104 bytes in 1 blocks are possibly lost in loss record 10 of 20
==29312== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==29312== by 0x2D812E41: ???
==29312== by 0x2D184071: ???
==29312== by 0x2D1848B5: ???
==29312== by 0x2CF7008E: ???
==29312== by 0x84D60A: ha_innobase::update_row(unsigned char const*, unsigned char*) (ha_innodb.cc:4366)
==29312== by 0x761653: handler::ha_update_row(unsigned char const*, unsigned char*) (handler.cc:4648)
==29312== by 0x6E2DF4: mysql_update(THD*, TABLE_LIST*, List<Item>&, List<Item>&, Item*, unsigned int, st_order*, unsigned long long, enum_duplicates, bool) (sql_update.cc:647)
==29312== by 0x62BA8F: mysql_execute_command(THD*) (sql_parse.cc:3374)
==29312== by 0x633C71: mysql_parse(THD*, char const*, unsigned int, char cons

This relates to local state transaction management.

[Seppo Jaakola (seppo-jaakola)]

The leak happens also with single node dummy backend test.
However, leak is present only with several clients and very high conflict rate.
(Tested with sqlgen, 10 row table and 8 clients)

Looks as if natural deadlocks are not solved correctly inside galera library.
Some resources don't get freed if transaction rolls back voluntarily.

[Seppo Jaakola (seppo-jaakola)]

The leak was diagnosed to be due to unreleased resources during rollback processing. Th problem was fixed fully in galera library part, so no commits will happen in codership-mysql, because of this.

Further testing shows that high connection rates can cause a different type of memory leak. A separate LP bug will be opened for that case.