| 2011-05-31 18:35:14 |
Philip Stoev |
bug |
|
|
added bug |
| 2011-05-31 18:35:43 |
Philip Stoev |
branch linked |
|
lp:~percona-dev/percona-server/mysql-55-eb |
|
| 2011-05-31 18:44:46 |
Philip Stoev |
description |
When executing a RQG stress test under valgrind, memory consumption grew rapidly and the following was produced in the server error log file:
110531 17:12:08 [ERROR] /home/philips/bzr/mysql-55-eb/sql/mysqld: Out of memory (Needed 129872 bytes)
==16380== Thread 19:
==16380== Invalid write of size 1
==16380== at 0x4007634: memcpy (mc_replace_strmem.c:497)
==16380== by 0x8617123: hp_process_field_data_to_chunkset (hp_record.c:173)
==16380== by 0x861733D: hp_process_record_data_to_chunkset (hp_record.c:276)
==16380== by 0x86173C4: hp_copy_record_data_to_chunkset (hp_record.c:306)
==16380== by 0x8618172: heap_update (hp_update.c:66)
==16380== by 0x860FEB8: ha_heap::update_row(unsigned char const*, unsigned char*) (ha_heap.cc:265)
==16380== by 0x835A24A: handler::ha_update_row(unsigned char const*, unsigned char*) (handler.cc:4806)
==16380== by 0x8293F8F: mysql_update(THD*, TABLE_LIST*, List<Item>&, List<Item>&, Item*, unsigned int, st_order*, unsigned long long, enum_duplicates, bool
, unsigned long long*, unsigned long long*) (sql_update.cc:713)
==16380== by 0x8204368: mysql_execute_command(THD*) (sql_parse.cc:2662)
==16380== by 0x820C025: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:5503)
==16380== by 0x82006ED: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1034)
==16380== by 0x81FFBDB: do_command(THD*) (sql_parse.cc:771)
==16380== by 0x82D03B8: do_handle_one_connection(THD*) (sql_connect.cc:776)
==16380== by 0x82D007B: handle_one_connection (sql_connect.cc:724)
==16380== by 0x821918: start_thread (in /lib/libpthread-2.12.1.so)
==16380== by 0x76ACCD: clone (in /lib/libc-2.12.1.so)
==16380== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==16380==
I interpret this to mean that a certain memory operation could not be completed, returned 0 and this 0 was subsequently used by the heap storage engine. A cursory code inspection showed that most of the return value of most memory management calls is checked, but not for all.
I will try to provide a test case for this bug, however a code inspection may be the best way to fix this situation.
If the same workload was run without --valgrind, memory consumption stayed within limits. |
When executing a RQG stress test under valgrind, memory consumption grew rapidly and the following was produced in the server error log file:
110531 17:12:08 [ERROR] /home/philips/bzr/mysql-55-eb/sql/mysqld: Out of memory (Needed 129872 bytes)
==16380== Thread 19:
==16380== Invalid write of size 1
==16380== at 0x4007634: memcpy (mc_replace_strmem.c:497)
==16380== by 0x8617123: hp_process_field_data_to_chunkset (hp_record.c:173)
==16380== by 0x861733D: hp_process_record_data_to_chunkset (hp_record.c:276)
==16380== by 0x86173C4: hp_copy_record_data_to_chunkset (hp_record.c:306)
==16380== by 0x8618172: heap_update (hp_update.c:66)
==16380== by 0x860FEB8: ha_heap::update_row(unsigned char const*, unsigned char*) (ha_heap.cc:265)
==16380== by 0x835A24A: handler::ha_update_row(unsigned char const*, unsigned char*) (handler.cc:4806)
==16380== by 0x8293F8F: mysql_update(THD*, TABLE_LIST*, List<Item>&, List<Item>&, Item*, unsigned int, st_order*, unsigned long long, enum_duplicates, bool
, unsigned long long*, unsigned long long*) (sql_update.cc:713)
==16380== by 0x8204368: mysql_execute_command(THD*) (sql_parse.cc:2662)
==16380== by 0x820C025: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:5503)
==16380== by 0x82006ED: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1034)
==16380== by 0x81FFBDB: do_command(THD*) (sql_parse.cc:771)
==16380== by 0x82D03B8: do_handle_one_connection(THD*) (sql_connect.cc:776)
==16380== by 0x82D007B: handle_one_connection (sql_connect.cc:724)
==16380== by 0x821918: start_thread (in /lib/libpthread-2.12.1.so)
==16380== by 0x76ACCD: clone (in /lib/libc-2.12.1.so)
==16380== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==16380==
I interpret this to mean that a certain memory operation could not be completed, returned 0 and this 0 was subsequently used by the heap storage engine. A cursory code inspection showed that most of the return value of most memory management calls is checked, but not for all.
I will try to provide a test case for this bug, however a code inspection may be the best way to fix this situation.
If the same workload was run without --valgrind, memory consumption stayed within limits.
The core and the binary are available if needed both locally and remotely -- compressed size is 2gb. |
|
| 2011-06-01 07:18:19 |
Philip Stoev |
description |
When executing a RQG stress test under valgrind, memory consumption grew rapidly and the following was produced in the server error log file:
110531 17:12:08 [ERROR] /home/philips/bzr/mysql-55-eb/sql/mysqld: Out of memory (Needed 129872 bytes)
==16380== Thread 19:
==16380== Invalid write of size 1
==16380== at 0x4007634: memcpy (mc_replace_strmem.c:497)
==16380== by 0x8617123: hp_process_field_data_to_chunkset (hp_record.c:173)
==16380== by 0x861733D: hp_process_record_data_to_chunkset (hp_record.c:276)
==16380== by 0x86173C4: hp_copy_record_data_to_chunkset (hp_record.c:306)
==16380== by 0x8618172: heap_update (hp_update.c:66)
==16380== by 0x860FEB8: ha_heap::update_row(unsigned char const*, unsigned char*) (ha_heap.cc:265)
==16380== by 0x835A24A: handler::ha_update_row(unsigned char const*, unsigned char*) (handler.cc:4806)
==16380== by 0x8293F8F: mysql_update(THD*, TABLE_LIST*, List<Item>&, List<Item>&, Item*, unsigned int, st_order*, unsigned long long, enum_duplicates, bool
, unsigned long long*, unsigned long long*) (sql_update.cc:713)
==16380== by 0x8204368: mysql_execute_command(THD*) (sql_parse.cc:2662)
==16380== by 0x820C025: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:5503)
==16380== by 0x82006ED: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1034)
==16380== by 0x81FFBDB: do_command(THD*) (sql_parse.cc:771)
==16380== by 0x82D03B8: do_handle_one_connection(THD*) (sql_connect.cc:776)
==16380== by 0x82D007B: handle_one_connection (sql_connect.cc:724)
==16380== by 0x821918: start_thread (in /lib/libpthread-2.12.1.so)
==16380== by 0x76ACCD: clone (in /lib/libc-2.12.1.so)
==16380== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==16380==
I interpret this to mean that a certain memory operation could not be completed, returned 0 and this 0 was subsequently used by the heap storage engine. A cursory code inspection showed that most of the return value of most memory management calls is checked, but not for all.
I will try to provide a test case for this bug, however a code inspection may be the best way to fix this situation.
If the same workload was run without --valgrind, memory consumption stayed within limits.
The core and the binary are available if needed both locally and remotely -- compressed size is 2gb. |
When executing a RQG stress test under valgrind, memory consumption grew suddenly (most likely due to trying to insert too ma ny 2MB blobs in a table) and the following was produced in the server error log file:
110531 17:12:08 [ERROR] /home/philips/bzr/mysql-55-eb/sql/mysqld: Out of memory (Needed 129872 bytes)
==16380== Thread 19:
==16380== Invalid write of size 1
==16380== at 0x4007634: memcpy (mc_replace_strmem.c:497)
==16380== by 0x8617123: hp_process_field_data_to_chunkset (hp_record.c:173)
==16380== by 0x861733D: hp_process_record_data_to_chunkset (hp_record.c:276)
==16380== by 0x86173C4: hp_copy_record_data_to_chunkset (hp_record.c:306)
==16380== by 0x8618172: heap_update (hp_update.c:66)
==16380== by 0x860FEB8: ha_heap::update_row(unsigned char const*, unsigned char*) (ha_heap.cc:265)
==16380== by 0x835A24A: handler::ha_update_row(unsigned char const*, unsigned char*) (handler.cc:4806)
==16380== by 0x8293F8F: mysql_update(THD*, TABLE_LIST*, List<Item>&, List<Item>&, Item*, unsigned int, st_order*, unsigned long long, enum_duplicates, bool
, unsigned long long*, unsigned long long*) (sql_update.cc:713)
==16380== by 0x8204368: mysql_execute_command(THD*) (sql_parse.cc:2662)
==16380== by 0x820C025: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:5503)
==16380== by 0x82006ED: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1034)
==16380== by 0x81FFBDB: do_command(THD*) (sql_parse.cc:771)
==16380== by 0x82D03B8: do_handle_one_connection(THD*) (sql_connect.cc:776)
==16380== by 0x82D007B: handle_one_connection (sql_connect.cc:724)
==16380== by 0x821918: start_thread (in /lib/libpthread-2.12.1.so)
==16380== by 0x76ACCD: clone (in /lib/libc-2.12.1.so)
==16380== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==16380==
I interpret this to mean that a certain memory operation could not be completed, returned 0 and this 0 was subsequently used by the heap storage engine. A cursory code inspection showed that most of the return value of most memory management calls is checked, but not for all.
I will try to provide a test case for this bug, however a code inspection may be the best way to fix this situation.
If the same workload was run without --valgrind, memory consumption stayed within limits.
The core and the binary are available if needed both locally and remotely -- compressed size is 2gb. |
|
| 2011-06-01 07:18:57 |
Philip Stoev |
description |
When executing a RQG stress test under valgrind, memory consumption grew suddenly (most likely due to trying to insert too ma ny 2MB blobs in a table) and the following was produced in the server error log file:
110531 17:12:08 [ERROR] /home/philips/bzr/mysql-55-eb/sql/mysqld: Out of memory (Needed 129872 bytes)
==16380== Thread 19:
==16380== Invalid write of size 1
==16380== at 0x4007634: memcpy (mc_replace_strmem.c:497)
==16380== by 0x8617123: hp_process_field_data_to_chunkset (hp_record.c:173)
==16380== by 0x861733D: hp_process_record_data_to_chunkset (hp_record.c:276)
==16380== by 0x86173C4: hp_copy_record_data_to_chunkset (hp_record.c:306)
==16380== by 0x8618172: heap_update (hp_update.c:66)
==16380== by 0x860FEB8: ha_heap::update_row(unsigned char const*, unsigned char*) (ha_heap.cc:265)
==16380== by 0x835A24A: handler::ha_update_row(unsigned char const*, unsigned char*) (handler.cc:4806)
==16380== by 0x8293F8F: mysql_update(THD*, TABLE_LIST*, List<Item>&, List<Item>&, Item*, unsigned int, st_order*, unsigned long long, enum_duplicates, bool
, unsigned long long*, unsigned long long*) (sql_update.cc:713)
==16380== by 0x8204368: mysql_execute_command(THD*) (sql_parse.cc:2662)
==16380== by 0x820C025: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:5503)
==16380== by 0x82006ED: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1034)
==16380== by 0x81FFBDB: do_command(THD*) (sql_parse.cc:771)
==16380== by 0x82D03B8: do_handle_one_connection(THD*) (sql_connect.cc:776)
==16380== by 0x82D007B: handle_one_connection (sql_connect.cc:724)
==16380== by 0x821918: start_thread (in /lib/libpthread-2.12.1.so)
==16380== by 0x76ACCD: clone (in /lib/libc-2.12.1.so)
==16380== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==16380==
I interpret this to mean that a certain memory operation could not be completed, returned 0 and this 0 was subsequently used by the heap storage engine. A cursory code inspection showed that most of the return value of most memory management calls is checked, but not for all.
I will try to provide a test case for this bug, however a code inspection may be the best way to fix this situation.
If the same workload was run without --valgrind, memory consumption stayed within limits.
The core and the binary are available if needed both locally and remotely -- compressed size is 2gb. |
When executing a RQG stress test under valgrind, memory consumption grew suddenly (most likely due to trying to insert too ma ny 2MB blobs in a table) and the following was produced in the server error log file:
110531 17:12:08 [ERROR] /home/philips/bzr/mysql-55-eb/sql/mysqld: Out of memory (Needed 129872 bytes)
==16380== Thread 19:
==16380== Invalid write of size 1
==16380== at 0x4007634: memcpy (mc_replace_strmem.c:497)
==16380== by 0x8617123: hp_process_field_data_to_chunkset (hp_record.c:173)
==16380== by 0x861733D: hp_process_record_data_to_chunkset (hp_record.c:276)
==16380== by 0x86173C4: hp_copy_record_data_to_chunkset (hp_record.c:306)
==16380== by 0x8618172: heap_update (hp_update.c:66)
==16380== by 0x860FEB8: ha_heap::update_row(unsigned char const*, unsigned char*) (ha_heap.cc:265)
==16380== by 0x835A24A: handler::ha_update_row(unsigned char const*, unsigned char*) (handler.cc:4806)
==16380== by 0x8293F8F: mysql_update(THD*, TABLE_LIST*, List<Item>&, List<Item>&, Item*, unsigned int, st_order*, unsigned long long, enum_duplicates, bool
, unsigned long long*, unsigned long long*) (sql_update.cc:713)
==16380== by 0x8204368: mysql_execute_command(THD*) (sql_parse.cc:2662)
==16380== by 0x820C025: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:5503)
==16380== by 0x82006ED: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1034)
==16380== by 0x81FFBDB: do_command(THD*) (sql_parse.cc:771)
==16380== by 0x82D03B8: do_handle_one_connection(THD*) (sql_connect.cc:776)
==16380== by 0x82D007B: handle_one_connection (sql_connect.cc:724)
==16380== by 0x821918: start_thread (in /lib/libpthread-2.12.1.so)
==16380== by 0x76ACCD: clone (in /lib/libc-2.12.1.so)
==16380== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==16380==
I interpret this to mean that a certain memory operation could not be completed, returned 0 and this 0 was subsequently used by the heap storage engine. A cursory code inspection showed that most of the return value of most memory management calls is checked, but not for all.
I can provide a test case for this bug, however a code inspection may be the best way to fix this situation.
The core and the binary are available if needed both locally and remotely -- compressed size is 2gb. |
|
| 2011-06-01 08:14:11 |
Laurynas Biveinis |
percona-projects-qa: milestone |
|
5.5.13-eb |
|
| 2011-06-01 18:16:22 |
Alexey Kopytov |
percona-projects-qa: assignee |
|
Alexey Kopytov (akopytov) |
|
| 2011-06-01 18:16:26 |
Alexey Kopytov |
percona-projects-qa: importance |
Undecided |
Low |
|
