- 15 Apr, 2011 1 commit
-
-
Sergey Glukhov authored
Some multibyte sequences could be considered by my_mbcharlen() functions as multibyte character but more exact my_ismbchar() does not think so. In such a case this multibyte sequences is pushed into 'stack' buffer which is too small to accommodate the sequence. The fix is to allocate stack buffer in compliance with max character length.
-
- 14 Apr, 2011 3 commits
-
-
Tor Didriksen authored
Valgrind warnings were caused by comparing index values to an un-initialized field.
-
Serge Kozlov authored
-
Sergey Glukhov authored
There are two problems with ANALYSE(): 1. Memory leak it happens because do_select() can overwrite JOIN::procedure field(with zero value in our case) and JOIN destructor don't free the memory allocated for JOIN::procedure. The fix is to save original JOIN::procedure before do_select() call and restore it after do_select execution. 2. Wrong result If ANALYSE() procedure is used for the statement with LIMIT clause it could retrun empty result set. It happens because of missing analyse::end_of_records() call. First end_send() function call returns NESTED_LOOP_QUERY_LIMIT and second call of end_send() with end_of_records flag enabled does not happen. The fix is to return NESTED_LOOP_OK from end_send() if procedure is active.
-
- 13 Apr, 2011 1 commit
-
-
Serge Kozlov authored
-
- 12 Apr, 2011 3 commits
-
-
Sven Sandberg authored
-
Sergey Glukhov authored
When we create temporary result table for UNION incorrect max_length for YEAR field is used and it leads to incorrect field value and incorrect result string length as YEAR field value calculation depends on field length. The fix is to use underlying item max_length for Item_sum_hybrid::max_length intialization.
-
Sergey Glukhov authored
Valgrind warning happens due to early null values check in Item_func_in::fix_length_and_dec(before item evaluation). As result null value items with uninitialized values are placed into array and it leads to valgrind warnings during value array sorting. The fix is to check null value after item evaluation, item is evaluated in in_array::set() method.
-
- 11 Apr, 2011 5 commits
-
-
Sven Sandberg authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
- 08 Apr, 2011 2 commits
-
-
Gleb Shchepa authored
Select from a view with the underlying HAVING clause failed with a message: "1356: View '...' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them" The bug is a regression of the fix for bug 11750328 - 40825 (similar case, but the HAVING cause references an aliased field). In the old fix for bug 40825 the Item_field::name_length value has been used in place of the real length of Item_field::name. However, in some cases Item_field::name_length is not in sync with the actual name length (TODO: combine name and name_length into a solid String field). The Item_ref::print() method has been modified to calculate actual name length every time.
-
Nirbhay Choubey authored
create_schema if auto-generate-sql also set. mysqlslap uses a schema to run its tests on and later drops it if auto-generate-sql is used. This can be a problem, if the schema is an already existing one. If create-schema is used with auto-generate-sql option, mysqlslap while performing the cleanup, drops the specified database. Fixed by introducing an option --no-drop, which, if used, will prevent the dropping of schema at the end of the test.
-
- 07 Apr, 2011 1 commit
-
-
Bjorn Munch authored
-
- 05 Apr, 2011 1 commit
-
-
Bjorn Munch authored
-
- 04 Apr, 2011 2 commits
-
-
Georgi Kodinov authored
on lctn2 systems There was a local variable in get_all_tables() to store the "original" value of the database name as it can get lowercased depending on the lower_case_table_name value. get_all_tables() iterates over database names and for each database iterates over the tables in it. The "original" db name was assigned in the table names loop. Thus the first table is ok, but the second and subsequent tables get the lowercased name from processing the first table. Fixed by moving the assignment of the original database name from the inner (table name) to the outer (database name) loop. Test suite added.
-
Vasil Dimov authored
-
- 31 Mar, 2011 4 commits
-
-
Gleb Shchepa authored
In the string context the MIN() and MAX() functions don't take into account the unsignedness of the UNSIGNED BIGINT argument column. I.e.: CREATE TABLE t1 (a BIGINT UNSIGNED); INSERT INTO t1 VALUES (18446668621106209655); SELECT CONCAT(MAX(a)) FROM t1; returns -75452603341961.
-
Bjorn Munch authored
-
Bjorn Munch authored
-
Bjorn Munch authored
-
- 30 Mar, 2011 5 commits
-
-
Magne Mahre authored
The patch fixes a build problem on MacOSX, where the compiler complains about unused parameters.
-
Bjorn Munch authored
-
Marko Mäkelä authored
sync_array_print_long_waits(): Return the longest waiting thread ID and the longest waited-for lock. Only if those remain unchanged between calls in srv_error_monitor_thread(), increment fatal_cnt. Otherwise, reset fatal_cnt. Background: There is a built-in watchdog in InnoDB whose purpose is to kill the server when some thread is stuck waiting for a mutex or rw-lock. Before this fix, the logic was flawed. The function sync_array_print_long_waits() returns TRUE if it finds a lock wait that exceeds 10 minutes (srv_fatal_semaphore_wait_threshold). The function srv_error_monitor_thread() will kill the server if this happens 10 times in a row (fatal_cnt reaches 10), checked every 30 seconds. This is wrong, because this situation does not mean that the server is hung. If the server is very busy for a little over 15 minutes, it will be killed. Consider this example. Thread T1 is waiting for mutex M. Some time later, threads T2..Tn start waiting for the same mutex M. If T1 keeps waiting for 600 seconds, fatal_cnt will be incremented to 1. So far, so good. Now, if M is granted to T1, the server was obviously not stuck. But, T2..Tn keeps waiting, and their wait time will be longer than 600 seconds. If 5 minutes later, some Tn has still been waiting for more than 10 minutes for the mutex M, the server can be killed, even though it is not stuck. rb:622 approved by Jimmy Yang
-
Sergey Glukhov authored
Valgrind warning happens due to missing NULL value check in Item::get_date. The fix is to add this check.
-
Sergey Glukhov authored
Valgrind warning happens because null values check happens too late in Item_func_month::val_str(after result string calculation).The fix is to check null value before result string calculation.
-
- 29 Mar, 2011 1 commit
-
-
Jon Olav Hauglid authored
ASSERTION TABLE->DB_STAT FAILED IN SQL_BASE.CC::OPEN_TABLE() DURING I_S Q This assert could be triggered if a statement requiring a name lock on a table (e.g. DROP TRIGGER) executed concurrently with an I_S query which also used the table. One connection first started an I_S query that opened a given table. Then another connection started a statement requiring a name lock on the same table. This statement was blocked since the table was in use by the I_S query. When the I_S query resumed and tried to open the table again as part of get_all_tables(), it would encounter a table instance with an old version number representing the pending name lock. Since I_S queries ignore version checks and thus pending name locks, it would try to continue. This caused it to encounter the assert. The assert checked that the TABLE instance found with a different version, was a real, open table. However, since this TABLE instance instead represented a pending name lock, the check would fail and trigger the assert. This patch fixes the problem by removing the assert. It is ok for TABLE::db_stat to be 0 in this case since the TABLE instance can represent a pending name lock. Test case added to lock_sync.test.
-
- 28 Mar, 2011 11 commits
-
-
Mayank Prasad authored
Issue: ====== Test case Correction for bug#11751148.
-
Sergey Glukhov authored
Valgrind warning happens due to missing NULL value check in Item_func::val_decimal. The fix is to add this check.
-
Sergey Glukhov authored
Valgrind warning happens due to uninitialized cached_format_type field which is used later in Item_func_str_to_date::val_str method. The fix is to init cached_format_type field.
-
Georgi Kodinov authored
Fixed RelWithDebugInfo bzr ignores.
-
Georgi Kodinov authored
Bug #11766769
-
Georgi Kodinov authored
-
Sergey Glukhov authored
-
Magne Mahre authored
The LGPL license is used in some legacy code, and to adhere to current licensing polity, we remove those files that are no longer used, and reorganize the remaining LGPL code so it will be GPL licensed from now on. Note: This patch only removed LGPL licensed files in MySQL 5.1, and is the second of a set of patches to remove LGPL from all trees. (See Bug# 11840513 for details)
-
Sergey Glukhov authored
Assert fails due to overflow which happens in Item_func_int_val::fix_num_length_and_dec() as geometry functions have max_length value equal to max_field_size(4294967295U). The fix is to skip max_length calculation for some boundary cases.
-
Vasil Dimov authored
This problem was introduced in marko.makela@oracle.com-20100514130815-ym7j7cfu88ro6km4 and is probably the reason for the following valgrind warning: from http://bugs.mysql.com/52691 , http://bugs.mysql.com/file.php?id=16880 : Version: '5.6.3-m5-valgrind-max-debug' socket: '/tmp/mysql.sock' port: 3306 Source distribution ==14947== Thread 18: ==14947== Conditional jump or move depends on uninitialised value(s) ==14947== at 0x4A06318: __GI_strlen (mc_replace_strmem.c:284) ==14947== by 0x9F3D7A: fill_innodb_trx_from_cache(trx_i_s_cache_struct*, THD*, TABLE*) (i_s.cc:591) ==14947== by 0x9F4D7D: trx_i_s_common_fill_table(THD*, TABLE_LIST*, Item*) (i_s.cc:1238) ==14947== by 0x7689F3: get_schema_tables_result(JOIN*, enum_schema_table_state) (sql_show.cc:6745) ==14947== by 0x715A75: JOIN::exec() (sql_select.cc:2861) ==14947== by 0x7185BD: mysql_select(THD*, Item***, TABLE_LIST*, unsigned int, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*) (sql_select.cc:3609) ==14947== by 0x70E823: handle_select(THD*, LEX*, select_result*, unsigned long) (sql_select.cc:319) ==14947== by 0x6F2305: execute_sqlcom_select(THD*, TABLE_LIST*) (sql_parse.cc:4557) ==14947== by 0x6EAED4: mysql_execute_command(THD*) (sql_parse.cc:2135) ==14947== by 0x6F44C9: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:5597) ==14947== by 0x6E864B: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1093) ==14947== by 0x6E785E: do_command(THD*) (sql_parse.cc:815) ==14947== by 0x6C18DD: do_handle_one_connection(THD*) (sql_connect.cc:771) ==14947== by 0x6C146E: handle_one_connection (sql_connect.cc:707) ==14947== by 0x30E1807760: start_thread (pthread_create.c:301) ==14947== by 0x35EA670F: ??? ==14947== Uninitialised value was created by a heap allocation ==14947== at 0x4A0515D: malloc (vg_replace_malloc.c:195) ==14947== by 0xB4B948: mem_area_alloc (mem0pool.c:385) ==14947== by 0xB4A27C: mem_heap_create_block (mem0mem.c:333) ==14947== by 0xB4A530: mem_heap_add_block (mem0mem.c:446) ==14947== by 0xB0D2A4: mem_heap_alloc (mem0mem.ic:186) ==14947== by 0xB0D9C2: ha_storage_put_memlim (ha0storage.c:118) ==14947== by 0xA479D8: fill_trx_row (trx0i_s.c:521) ==14947== by 0xA490E9: fetch_data_into_cache (trx0i_s.c:1319) ==14947== by 0xA491BA: trx_i_s_possibly_fetch_data_into_cache (trx0i_s.c:1352) ==14947== by 0x9F4CE7: trx_i_s_common_fill_table(THD*, TABLE_LIST*, Item*) (i_s.cc:1221) ==14947== by 0x7689F3: get_schema_tables_result(JOIN*, enum_schema_table_state) (sql_show.cc:6745) ==14947== by 0x715A75: JOIN::exec() (sql_select.cc:2861) ==14947== by 0x7185BD: mysql_select(THD*, Item***, TABLE_LIST*, unsigned int, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*) (sql_select.cc:3609) ==14947== by 0x70E823: handle_select(THD*, LEX*, select_result*, unsigned long) (sql_select.cc:319) ==14947== by 0x6F2305: execute_sqlcom_select(THD*, TABLE_LIST*) (sql_parse.cc:4557) ==14947== by 0x6EAED4: mysql_execute_command(THD*) (sql_parse.cc:2135) ==14947== by 0x6F44C9: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:5597) ==14947== by 0x6E864B: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1093) ==14947== by 0x6E785E: do_command(THD*) (sql_parse.cc:815) ==14947== by 0x6C18DD: do_handle_one_connection(THD*) (sql_connect.cc:771) ==14947== by 0x6C146E: handle_one_connection (sql_connect.cc:707) ==14947== by 0x30E1807760: start_thread (pthread_create.c:301) ==14947== by 0x35EA670F: ??? (gdb) bt #0 0x0000000004a06318 in _vgrZU_libcZdsoZa___GI_strlen (str=0x3026bfa0 "insert into `blobtest` set `data`='pkefxxpkalpabzgrczlxefkreqljeqbvzrcnhvhsjsfnvxzjsltfuincffigdkmhvvcmnseluzgbtedrfmxvnrdmzesbinjgwvharkpgjplrlnqudfidbqwgbykupycxzyikzqincnsjrxgncqzlgyqwjdbjulztgsffxpjgymsnntdibvklwqylmwhsmdskmllxuwafabdjnwlyofknwuixiyrgnplmerfdewgizkdhznitesfqepsqbbwkdepkmjoseyxjofmmjaqdipwopfrwidmhqbtovdslvayxcnpewzhppeetblccppniamezibuoinvlxkafpcmozawtplfpepxwlwhymsuraezcwvjqzwogsozodlsfzjiyrcaljjhqwdrcjawvelhefzzaexvcbyorlcyupqwgjuamiqpiputtndjwcsuyzdfhuxswuowhrzdvriwrxqmcqthvzzzvivbabbnhdbtcfdtgssvmirrcddnytnctcvqplwytxxzxelldhwahalzxvgynaiwjyezhxqhlsqudngekocfvlbqprxqhyhwbaomgqiwkpfguohuvlnhtrsszgacxhhzeppyqwfwabiqzgyzkperiidyunrykopysvlcxwhrcboetjltawdjergalsfvaxncmzoznryumrjmncvhvxqvqhhbznnifkguuiffmlrbmgwtzvnuwlaguixqadkupfhasbbxnwkrvsfhrqanfmvjtzfqodtutkjlxfcogtsjywrdgmzgszjtsmimaelsveayqrwviqwwefeziuaqsqpauxpnzhaxjtkdfvvodniwezskbxfxszyniyzkzxngcfwgjlyrlskmrzxqnptwlilsxybuguafxxkvryyjrnkhhcmxuusitaflaiuxjhyfnzkahlgmaszujqmfdhyppdnpweqanmvzgjfyzjolbmprhnuuxextcaxzicfvsuochprmlf"...) at mc_replace_strmem.c:284 #1 0x00000000009f3d7b in fill_innodb_trx_from_cache (cache=0x1462440, thd=0x2a495000, table=0x2a422500) at /home/sbester/build/bzr/mysql-trunk/storage/innobase/handler/i_s.cc:591 #2 0x00000000009f4d7e in trx_i_s_common_fill_table (thd=0x2a495000, tables=0x2a4c3ec0) at /home/sbester/build/bzr/mysql-trunk/storage/innobase/handler/i_s.cc:1238 #3 0x00000000007689f4 in get_schema_tables_result (join=0x30f90c40, executed_place=PROCESSED_BY_JOIN_EXEC) at /home/sbester/build/bzr/mysql-trunk/sql/sql_show.cc:6745 #4 0x0000000000715a76 in JOIN::exec (this=0x30f90c40) at /home/sbester/build/bzr/mysql-trunk/sql/sql_select.cc:2861 #5 0x00000000007185be in mysql_select (thd=0x2a495000, rref_pointer_array=0x2a497590, tables=0x2a4c3ec0, wild_num=1, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2684619520, result=0x30319720, unit=0x2a496d28, select_lex=0x2a497378) at /home/sbester/build/bzr/mysql-trunk/sql/sql_select.cc:3609 #6 0x000000000070e824 in handle_select (thd=0x2a495000, lex=0x2a496c78, result=0x30319720, setup_tables_done_option=0) at /home/sbester/build/bzr/mysql-trunk/sql/sql_select.cc:319 #7 0x00000000006f2306 in execute_sqlcom_select (thd=0x2a495000, all_tables=0x2a4c3ec0) at /home/sbester/build/bzr/mysql-trunk/sql/sql_parse.cc:4557 #8 0x00000000006eaed5 in mysql_execute_command (thd=0x2a495000) at /home/sbester/build/bzr/mysql-trunk/sql/sql_parse.cc:2135 #9 0x00000000006f44ca in mysql_parse (thd=0x2a495000, rawbuf=0x30d80060 "select * from innodb_trx", length=24, parser_state=0x35ea5540) at /home/sbester/build/bzr/mysql-trunk/sql/sql_parse.cc:5597 #10 0x00000000006e864c in dispatch_command (command=COM_QUERY, thd=0x2a495000, packet=0x30bb4e31 "select * from innodb_trx", packet_length=24) at /home/sbester/build/bzr/mysql-trunk/sql/sql_parse.cc:1093 #11 0x00000000006e785f in do_command (thd=0x2a495000) at /home/sbester/build/bzr/mysql-trunk/sql/sql_parse.cc:815 #12 0x00000000006c18de in do_handle_one_connection (thd_arg=0x2a495000) at /home/sbester/build/bzr/mysql-trunk/sql/sql_connect.cc:771 #13 0x00000000006c146f in handle_one_connection (arg=0x2a495000) at /home/sbester/build/bzr/mysql-trunk/sql/sql_connect.cc:707 #14 0x00000030e1807761 in start_thread (arg=0x35ea6710) at pthread_create.c:301 #15 0x00000030e14e14ed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 (gdb) frame 1 #1 0x00000000009f3d7b in fill_innodb_trx_from_cache (cache=0x1462440, thd=0x2a495000, table=0x2a422500) at /home/sbester/build/bzr/mysql-trunk/storage/innobase/handler/i_s.cc:591 591 row->trx_query_cs); (gdb) list 586 if (row->trx_query) { 587 /* store will do appropriate character set 588 conversion check */ 589 fields[IDX_TRX_QUERY]->store( 590 row->trx_query, strlen(row->trx_query), 591 row->trx_query_cs); 592 fields[IDX_TRX_QUERY]->set_notnull(); 593 } else { 594 fields[IDX_TRX_QUERY]->set_null(); 595 }
-
Sergey Glukhov authored
Assertion happens due to missing initialization of unsigned_flag for Item_func_set_user_var object. It leads to incorrect calculation of decimal field size. The fix is to add initialization of unsigned_flag.
-