- 17 Feb, 2011 9 commits
-
-
Vasil Dimov authored
-
Vasil Dimov authored
-
Vasil Dimov authored
-
Vasil Dimov authored
-
Magne Mahre authored
-
Magne Mahre authored
memory reference There are two issues present here. 1) There is a possibility that we test a byte beyond the allocated buffer 2) We compare a byte that might never have been initalized to see if it's 0. The first issue is not triggered by existing code, but an ASSERT has been added to safe-guard against introducing new code that triggers it. The second issue is what triggers the Valgrind warnings reported in the bug report. A buffer is allocated in class String to hold the value. This buffer is populated by the character data constituting the string, but is not zero-terminated in most cases. Testing if it is indeed zero-terminated means that we check a byte that has never been explicitly set, thus causing Valgrind to trigger. Note that issue 2 is not a serious problem. The variable is read, and if it's not zero, we will set it to zero. There are no further consequences. Note that this patch does not fix the underlying problems with issue 1, as it is deemed too risky to fix at this point (as noted in the bug report). As discussed in the report, the c_ptr() method should probably be replaced, but this requires a thorough analysis of the ~200 calls to the method. sql/set_var.cc: These two cases have been reported to fail with Valgrind.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Tor Didriksen authored
With --mem if fails with +UNEXPECTED ERROR NUMBER: 1290 In var/log/mysqld.2.err we have: [ERROR] LOAD DATA INFILE in the slave SQL Thread can only read from --slave-load-tmpdir. Please, report a bug. [ERROR] Slave SQL: Error 'The MySQL server is running with the --slave-load-tmpdir option so it cannot execute this statement' on query. Default database: 'test'. Query: 'LOAD DATA INFILE '../../tmp/SQL_LOAD-2-1-1.data' INTO TABLE `t1` FIELDS TERMINATED BY '\t' ENCLOSED BY '' ESCAPED BY '\\' LINES TERMINATED BY '\n' (`a`, `b`)', Error_code: 1290 getcwd() in the server yields something like: /dev/shm/var_auto_iv5Q/mysqld.2/data
-
- 16 Feb, 2011 15 commits
-
-
Jonathan Perkin authored
-
Jonathan Perkin authored
-
Jonathan Perkin authored
-
Bjorn Munch authored
-
Bjorn Munch authored
-
Jon Olav Hauglid authored
No conflicts
-
Jon Olav Hauglid authored
Assertion `bitmap_is_set_all(&table->s->all_set)' failed in handler::ha_reset This followup fixes the compilation warning 'test_bit' may be used uninitialized in this function introduced by the previous patch.
-
Sven Sandberg authored
Removes SHOW NEW MASTER statement and all related code. Also removes the unused function update_slave_list from repl_failsafe.cc. mysql-test/r/signal_code.result: Updated result file. The output of SHOW PROCEDURE CODE has changed, because the numerical values of some SQLCOM_ commands have changes. This is not a problem, because SHOW PROCEDURE CODE only exists in debug builds and the numerical values of SQLCOM_ constants are not exposed elsewhere. mysql-test/r/sp-code.result: Updated result file. The output of SHOW PROCEDURE CODE has changed, because the numerical values of some SQLCOM_ commands have changes. This is not a problem, because SHOW PROCEDURE CODE only exists in debug builds and the numerical values of SQLCOM_ constants are not exposed elsewhere. sql/mysqld.cc: Remove SQLCOM_SHOW_NEW_MASTER. sql/repl_failsafe.cc: Remove show_new_master, which was only used by the removed SHOW NEW MASTER statement. Remove translate_master, which was only used by show_new_master. Remove find_slave_event, which was only used by translate_master. Remove find_target_pos, which was only used by translate_master. Remove cmp_master_pos, which was only used by translate_master. Remove update_slave_list, which was not used at all. sql/repl_failsafe.h: Remove declarations of functions removed by this patch: update_slave_list, show_new_master, translate_master, update_slave_list Remove declarations of functions that did not exist before this patch: handle_failsafe_rpl, load_master_data Remove declaration of function that is static in slave.cc: connect_to_master sql/sp_head.cc: Removed SQLCOM_SHOW_NEW_MASTER sql/sql_lex.h: Removed SQLCOM_SHOW_NEW_MASTER sql/sql_parse.cc: Removed SQLCOM_SHOW_NEW_MASTER sql/sql_repl.cc: Removed cmp_master_pos(char*,ulonglong,char*,ulonglong), which was only used by cmp_master_pos*Slave_log_event* sev, LEX_MASTER_INFO* mi) in repl_failsafe.cc, which has been removed. sql/sql_repl.h: removed cmp_master_pos sql/sql_yacc.yy: removed syntax SHOW NEW MASTER.
-
Jon Olav Hauglid authored
Text conflict in include/my_bit.h Text conflict in include/my_bitmap.h Text conflict in mysys/my_bitmap.c
-
Jon Olav Hauglid authored
Assertion `bitmap_is_set_all(&table->s->all_set)' failed in handler::ha_reset This assertion could be triggered if two connections simultaneously executed two bitmap test functions on the same bitmap. For example, the assertion could be triggered if one connection executed UPDATE while a second connection executed SELECT on the same table. Even if bitmap test functions have read-only semantics and have const bitmaps as parameter, several of them modified the internal state of the bitmap. With interleaved execution of two such functions it was possible for one function to modify the state of the same bitmap that the other function had just modified. This lead to an inconsistent state and could trigger the assert. Internally the bitmap uses 32 bit words for storage. Since bitmaps can contain any number of bits, the last word in the bitmap may not be fully used. A 32 bit mask is maintained where a bit is set if the corresponding bit in the last bitmap word is unused. The problem was that several test functions applied this mask to the last word. Sometimes the mask was negated and used to zero out the remainder of the last word and sometimes the mask was used as-is to fill the remainder of the last word with 1's. This meant that if a function first used the negated mask and another function then used the mask as-is (or vice-versa), the first function would then get the wrong result. This patch fixes the problem by changing the implementation of 9 bitmap functions that modified the bitmap state even if the bitmap was declared const. These functions now preserve the internal state of the bitmap. This makes it possible for two connections to concurrently execute two of these functions on the same bitmap without issues. The patch also removes dead testing code from my_bitmap.c. These tests have already been moved to unittest/mysys/bitmap-t.c. Existing test coverage of my_bitmap has been extended. No MTR test case added as this would require adding several sync points to the bitmap functions. The patch has been tested with a non-deterministic test case posted on the bug report. include/my_bit.h: Removed my_count_bits_ushort() which is not needed anymore. Added my_count_bits_uint32(). unittest/mysys/bitmap-t.c: Extended test coverage of my_bitmap.
-
Tor Didriksen authored
extra/comp_err.c: Initialize er_last to zero (which is the correct value if we never enter the loop).
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Tor Didriksen authored
post-push fix: make it work in out-of-source builds. mysql-test/mysql-test-run.pl: Set MYSQL_BINDIR, to be used by tests. mysql-test/t/file_contents.test: Use MYSQL_BINDIR, which is different from MYSQL_LIBDIR for out-of-source builds.
-
Bjorn Munch authored
-
- 15 Feb, 2011 9 commits
-
-
Dmitry Lenev authored
fix for bug @59888.
-
Dmitry Lenev authored
create spatial index on char > 31 bytes". Did after-merge fixes.
-
Luis Soares authored
Backporting the patch from BUG#11753506 into mysql-5.5 as it is already in mysql-trunk but not in mysql-5.5.
-
Luis Soares authored
Backporting the patch from BUG#11753489 into mysql-5.5 as it is already in mysql-trunk but not in mysql-5.5.
-
Dmitry Lenev authored
attempt to create spatial index on char > 31 bytes". Attempt to create spatial index on char field with length greater than 31 byte led to assertion failure on server compiled with safemutex support. The problem occurred in mi_create() function which was called to create a new version of table being altered. This function failed since it detected an attempt to create a spatial key on non-binary column and tried to return an error. On its error path it tried to unlock THR_LOCK_myisam mutex which has not been not locked at this point. Indeed such an incorrect behavior was caught by safemutex wrapper and caused assertion failure. This patch fixes the problem by ensuring that mi_create() doesn't releases THR_LOCK_myisam mutex on error path if it was not acquired. mysql-test/r/gis.result: Added test for bug @59888 "debug assertion when attempt to create spatial index on char > 31 bytes". mysql-test/t/gis.test: Added test for bug @59888 "debug assertion when attempt to create spatial index on char > 31 bytes". storage/myisam/mi_create.c: Changed mi_create() not to release THR_LOCK_myisam mutex on error path if it was not acquired.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
rw_lock_create_func(): Initialize lock->writer_thread, so that Valgrind will not complain even when Valgrind instrumentation is not enabled. Flag lock->writer_thread uninitialized, so that Valgrind can complain when it is used uninitialized. rw_lock_set_writer_id_and_recursion_flag(): Revert the bogus Valgrind instrumentation that was pushed in the first attempt to fix this bug.
-
- 14 Feb, 2011 4 commits
-
-
Joerg Bruehe authored
-
Jon Olav Hauglid authored
Assert in Diagnostics_area::set_ok_status() for XA COMMIT This assert was triggered if XA COMMIT was issued when an XA transaction already had encountered an error (e.g. a deadlock) which required the XA transaction to be rolled back. In general, the assert is triggered if a statement tries to send OK to the client when an error has already been reported. It was triggered in this case because the trans_xa_commit() function first reported an error, then rolled back the transaction and finally returned FALSE, indicating success. Since trans_xa_commit() reported success, mysql_execute_command() tried to report OK, triggering the assert. This patch fixes the problem by fixing trans_xa_commit() to return TRUE if it encounters an error that requires rollback, even if the rollback itself is successful. Test case added to xa.test.
-
Jimmy Yang authored
-
Jimmy Yang authored
index gives failures. Approved by Marko
-
- 11 Feb, 2011 3 commits
-
-
Joerg Bruehe authored
With this change, there will be new files "INFO_SRC" and "INFO_BIN", which describe the source and the binaries. They will be contained in all packages: - in "tar.gz" and derived packages, in "docs/", - in RPMs, in "/usr/share/doc/packages/MySQL-server". "INFO_SRC" is also part of a source tarball. It gives the version as exact as possible, preferably by calling "bzr version-info" on the source tree. If that is not possible, it just contains the three level version number. "INFO_BIN" contains some info when and where the binaries were built, the options given to the compiler, and the flags controlling the included features. The tests (test "mysql" in the main suite) are extended to verify the existence of both "INFO_SRC" and "INFO_BIN", as well as some of the expected contents. CMakeLists.txt: For the new files describing the source and the build ("INFO_SRC" and "INFO_BIN"), we need a new file "cmake/info_macros.cmake.in" with the build rules. 1) This file must be configured with the current variables. 2) "INFO_SRC" can be created during the cmake phase, but this should be repeated with each "make" to protect against a developer doing only "make" after a "bzr pull" (or "bzr commit"). So have it both as a cmake rule and as a custom target. 3) "INFO_BIN" must be created during the make phase only, because it contains information from files which will be written at the end of the cmake phase only. Therefore, it must be a custom target which is included in all "make" targets. 4) The resulting "INFO_*" files must be included in packages. cmake/info_bin.cmake: This is the file to create "INFO_BIN", by calling the "CREATE_INFO_BIN()" macro. It must be a separate file, so that the macro definitions can be included in other cmake scripts without that file inclusion causing a side effect, the macro call. That call would modify the source tree which should be trated read-only. cmake/info_macros.cmake.in: This new file contains the macros to create the "INFO_*" files during various steps of the build, the calls will be at other places. 1) For source: If running from a BZR tree, always create (update) "INFO_SRC" by running "bzr version-info". Outside a BZR tree, try to take it from exported sources, and create it only if missing, in that case put the three level version number into it. 2) "INFO_BIN" contains - date/time and host name of the build host, - information about the platform, - information about the C and CXX compiler and the options given to them (Unix only), - the feature flags as reported by "cmake -L". cmake/info_src.cmake: This is the file to create "INFO_SRC", by calling the "CREATE_INFO_SRC()" macro. It must be a separate file, so that the macro definitions can be included in other cmake scripts without that file inclusion causing a side effect, the macro call. That call would modify the source tree which should be trated read-only. cmake/make_dist.cmake.in: Create a "VERSION_src" file during "make dist". In case it already exists from a preceding "cmake" run or tree export (which is quite likely), a new "make dist" must not modify it. mysql-test/r/file_contents.result: Result of test for bug#42969. mysql-test/t/file_contents.test: Perl test scriptlet for bug#42969. support-files/mysql.spec.sh: Add "INFO_SRC" and "INFO_BIN" to the RPM contents.
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-