memory leak
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MySQL patches by Codership |
Fix Released
|
High
|
Seppo Jaakola |
Bug Description
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_
==29312== by 0x2D812E41: ???
==29312== by 0x2D184071: ???
==29312== by 0x2D1848B5: ???
==29312== by 0x2CF7008E: ???
==29312== by 0x84D60A: ha_innobase:
==29312== by 0x761653: handler:
==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_
==29312== by 0x633C71: mysql_parse(THD*, char const*, unsigned int, char cons
This relates to local state transaction management.
Changed in codership-mysql: | |
status: | New → In Progress |
importance: | Undecided → High |
assignee: | nobody → Seppo Jaakola (seppo-jaakola) |
milestone: | none → 0.7 |
Changed in codership-mysql: | |
status: | Fix Committed → Fix Released |
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.