- 30 Jan, 2012 2 commits
-
-
Gopal Shankar authored
-
Gopal Shankar authored
KEY HANDLING ON SUBSEQUENT CREATE TABLE IF NOT EXISTS PROBLEM: -------- Consider a SP routine which does CREATE TABLE with REFERENCES clause. The first call to this routine invokes parser and the parsed items are cached, so as to avoid parsing for the second execution of the routine. It is obsevered that valgrind reports a warning upon read of thd->lex->alter_info->key_list->Foreign_key object, which seem to be pointing to a invalid memory address during second time execution of the routine. Accessing this object theoretically could cause a crash. ANALYSIS: --------- The problem stems from the fact that for some reason elements of ref_columns list in thd->lex->alter_info-> key_list->Foreign_key object are changed to point to objects allocated on runtime memory root. During the first execution of routine we create a copy of thd->lex->alter_info object. As part of this process we create a clones of objects in Alter_info::key_list and of Foreign_key object in particular. Then Foreign_key object is cloned for some reason we perform shallow copies of both Foreign_key::ref_columns and Foreign_key::columns list. So new instance of Foreign_key object starts to SHARE contents of ref_columns and columns list with the original instance. After that as part of cloning process we call list_copy_and_replace_each_value() for elements of ref_columns list. As result ref_columns lists in both original and cloned Foreign_key object start to contain pointers to Key_part_spec objects allocated on runtime memory root because of shallow copy. So when we start copying of thd->lex->alter_info object during the second execution of stored routine we indeed encounter pointer to the Key_part_spec object allocated on runtime mem-root which was cleared during at the end of previous execution. This is done in sp_head::execute(), by a call to free_root(&execute_mem_root,MYF(0)); As result we get valgrind warnings about accessing unreferenced memory. FIX: ---- The safest solution to this problem is to fix Foreign_key(Foreign_key, MEM_ROOT) constructor to do a deep copy of columns lists, similar to Key(Key, MEM_ROOT) constructor.
-
- 27 Jan, 2012 2 commits
-
-
Tor Didriksen authored
-
Tor Didriksen authored
Bug#13011410 CRASH IN FILESORT CODE WITH GROUP BY/ROLLUP The assert in 13580775 is visible in 5.6 only, but shows that all versions are vulnerable. 13011410 crashes in all versions. filesort tries to re-use the sort buffer between invocations in order to save malloc/free overhead. The fix for Bug 11748783 - 37359: FILESORT CAN BE MORE EFFICIENT. added an assert that buffer properties (num_records, record_length) are consistent between invocations. Indeed, they are not necessarily consistent. Fix: re-allocate the sort buffer if properties change. mysql-test/r/partition.result: New tests. mysql-test/t/partition.test: New tests. sql/filesort.cc: If we already have allocated a sort buffer in a previous execution, then verify that it is big enough for the current one. sql/table.h: Add sort_keys_size; Number of bytes allocated for the sort_keys buffer.
-
- 12 Jan, 2012 8 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
merge of Nirbhay's AIX compilation fix for 5.1.61
-
Georgi Kodinov authored
-
Alexander Barkov authored
Fixing the 5.5 part (the 5.6 part will go in a separate commit soon). Problem: Item_direct_ref::get_date() incorrectly calculated its "null_value", which made UNIX_TIMESTAMP(view_column) incorrectly return NULL for a NOT NULL view_column. Fix: Make Item_direct_ref::get_date() calculate null_value in the similar way with the other methods (val_real,val_str,val_int,val_decimal): copy null_value from the referenced Item. modified: mysql-test/r/func_time.result mysql-test/t/func_time.test sql/item.cc
-
- 11 Jan, 2012 4 commits
-
-
Karen Langford authored
-
unknown authored
-
Karen Langford authored
-
Bjorn Munch authored
-
- 10 Jan, 2012 5 commits
-
-
Nirbhay Choubey authored
-
Nirbhay Choubey authored
routines. mysqldump in xml mode did not dump routines, events or triggers. This patch fixes this issue by fixing the if conditions that disallowed the dump of above mentioned objects in xml mode, and added the required code to enable dump in xml format. client/mysqldump.c: BUG#11760384 - 52792: mysqldump in XML mode does not dump routines. Fixed some if conditions to allow execution of dump methods for xml and further added the relevant code at places to produce the dump in xml format. mysql-test/r/mysqldump.result: Added a test case for Bug#11760384. mysql-test/t/mysqldump.test: Added a test case for Bug#11760384.
-
Sneha Modi authored
Moving query_cache_size_basic_32.test and query_cache_size_basic_64.test from experimental to disabled as a solution has still not been found.
-
Yasufumi Kinoshita authored
If we meet DB_TOO_MANY_CONCURRENT_TRXS during the execution tab_create_graph from row_create_table_for_mysql(), .ibd file for the table should be created already but was not deleted for the error handling. rb:875 approved by Jimmy Yang
-
Yasufumi Kinoshita authored
If we meet DB_TOO_MANY_CONCURRENT_TRXS during the execution tab_create_graph from row_create_table_for_mysql(), .ibd file for the table should be created already but was not deleted for the error handling. rb:875 approved by Jimmy Yang
-
- 09 Jan, 2012 2 commits
-
-
Jon Olav Hauglid authored
Text conflict in sql/sql_yacc.yy
-
Jon Olav Hauglid authored
------------------------------------------------------------ revno: 3258 committer: Jon Olav Hauglid <jon.hauglid@oracle.com> branch nick: mysql-trunk-bug12663165 timestamp: Thu 2011-07-14 10:05:12 +0200 message: Bug#12663165 SP DEAD CODE REMOVAL DOESN'T UNDERSTAND CONTINUE HANDLERS When stored routines are loaded, a simple optimizer tries to locate and remove dead code. The problem was that this dead code removal did not work correctly with CONTINUE handlers. If a statement triggers a CONTINUE handler, the following statement will be executed after the handler statement has completed. This means that the following statement is not dead code even if the previous statement unconditionally alters control flow. This fact was lost on the dead code removal routine, which ended up with removing instructions that could have been executed. This could then lead to assertions, crashes and generally bad behavior when the stored routine was executed. This patch fixes the problem by marking as live code all stored routine instructions that are in the same scope as a CONTINUE handler. Test case added to sp.test.
-
- 06 Jan, 2012 4 commits
-
-
Hemant Kumar authored
Null merge from 5.1 for Bug 12872803 - 62154: FEDERATED.FEDERATED_SERVER TEST FAILS WITH RUN --REPEAT=2
-
Hemant Kumar authored
Fixed it to work with "--repeat" option.
-
Hemant Kumar authored
Fixed the testcase using timestamp logic while doing grep from the error file.
-
Hemant Kumar authored
Fixed the testcase using timestamp logic while doing grep from the error file.
-
- 05 Jan, 2012 1 commit
-
-
Bjorn Munch authored
-
- 04 Jan, 2012 1 commit
-
-
Bjorn Munch authored
Use new syntax to mask different error output in affected tests
-
- 03 Jan, 2012 1 commit
-
-
Bjorn Munch authored
-
- 02 Jan, 2012 2 commits
-
-
Tatjana Azundris Nuernberg authored
-
Tatjana Azundris Nuernberg authored
If init_command was incorrect, we couldn't let users execute queries, but we couldn't report the issue to the client either as it does not expect error messages before even sending a command. Thus, we simply disconnected them without throwing a clear error. We now go through the proper sequence once (without executing any user statements) so we can report back what the problem is. Only then do we disconnect the user. As always, root remains unaffected by this as init_command is (still) not executed for them. mysql-test/r/init_connect.result: We now report a proper error if init_command fails. Expect as much. mysql-test/t/init_connect.test: We now report a proper error if init_command fails. Expect as much. sql/sql_connect.cc: If init_command fails, throw an error explaining this to the user.
-
- 29 Dec, 2011 5 commits
-
-
Vasil Dimov authored
Port vasil.dimov@oracle.com-20111205083046-jtgi1emlvtfnjatt from mysql-trunk
-
Vasil Dimov authored
Port vasil.dimov@oracle.com-20111205082900-lx9om1joscejr25e from mysql-trunk
-
Vasil Dimov authored
Port vasil.dimov@oracle.com-20111205082831-7v1qu50hvd9hjr3g from mysql-trunk
-
Vasil Dimov authored
Port vasil.dimov@oracle.com-20111205082756-wtlg8isyn4yohyny from mysql-trunk
-
Vasil Dimov authored
Port vasil.dimov@oracle.com-20111205082626-87j5f48dq1ouk86r from mysql-trunk
-
- 28 Dec, 2011 2 commits
-
-
Marko Mäkelä authored
-
Marko Mäkelä authored
InnoDB: Remove HAVE_purify, UNIV_INIT_MEM_TO_ZERO, UNIV_SET_MEM_TO_ZERO. The compile-time setting HAVE_purify can mask potential bugs. It is being set in PB2 Valgrind runs. We should simply get rid of it, and replace it with UNIV_MEM_INVALID() to declare uninitialized memory as such in Valgrind-instrumented binaries. os_mem_alloc_large(), ut_malloc_low(): Remove the parameter set_to_zero. ut_malloc(): Define as a macro that invokes ut_malloc_low(). buf_pool_init(): Never initialize the buffer pool frames. All pages must be initialized before flushing them to disk. mem_heap_alloc(): Never initialize the allocated memory block. os_mem_alloc_nocache(), ut_test_malloc(): Unused function, remove. rb:813 approved by Jimmy Yang
-
- 26 Dec, 2011 1 commit
-
-
Rohit Kalhans authored
The rpl.rpl_known_bugs_detection fails on pb2 as warnings were found in the mysqld log file. We fix this problem by suppressing the warning.
-