- 16 May, 2011 1 commit
-
-
Guilhem Bichot authored
In sql_class.cc, 'row_count', of type 'ha_rows', was used as last argument for ER_TRUNCATED_WRONG_VALUE_FOR_FIELD which is "Incorrect %-.32s value: '%-.128s' for column '%.192s' at row %ld". So 'ha_rows' was used as 'long'. On SPARC32 Solaris builds, 'long' is 4 bytes and 'ha_rows' is 'longlong' i.e. 8 bytes. So the printf-like code was reading only the first 4 bytes. Because the CPU is big-endian, 1LL is 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 so the first four bytes yield 0. So the warning message had "row 0" instead of "row 1" in test outfile_loaddata.test: -Warning 1366 Incorrect string value: '\xE1\xE2\xF7' for column 'b' at row 1 +Warning 1366 Incorrect string value: '\xE1\xE2\xF7' for column 'b' at row 0 All error-messaging functions which internally invoke some printf-life function are potential candidate for such mistakes. One apparently easy way to catch such mistakes is to use ATTRIBUTE_FORMAT (from my_attribute.h). But this works only when call site has both: a) the format as a string literal b) the types of arguments. So: func(ER(ER_BLAH), 10); will silently not be checked, because ER(ER_BLAH) is not known at compile time (it is known at run-time, and depends on the chosen language). And func("%s", a va_list argument); has the same problem, as the *real* type of arguments is not known at this site at compile time (it's known in some caller). Moreover, func(ER(ER_BLAH)); though possibly correct (if ER(ER_BLAH) has no '%' markers), will not compile (gcc says "error: format not a string literal and no format arguments"). Consequences: 1) ATTRIBUTE_FORMAT is here added only to functions which in practice take "string literal" formats: "my_error_reporter" and "print_admin_msg". 2) it cannot be added to the other functions: my_error(), push_warning_printf(), Table_check_intact::report_error(), general_log_print(). To do a one-time check of functions listed in (2), the following "static code analysis" has been done: 1) replace my_error(ER_xxx, arguments for substitution in format) with the equivalent my_printf_error(ER_xxx,ER(ER_xxx), arguments for substitution in format), so that we have ER(ER_xxx) and the arguments *in the same call site* 2) add ATTRIBUTE_FORMAT to push_warning_printf(), Table_check_intact::report_error(), general_log_print() 3) replace ER(xxx) with the hard-coded English text found in errmsg.txt (like: ER(ER_UNKNOWN_ERROR) is replaced with "Unknown error"), so that a call site has the format as string literal 4) this way, ATTRIBUTE_FORMAT can effectively do its job 5) compile, fix errors detected by ATTRIBUTE_FORMAT 6) revert steps 1-2-3. The present patch has no compiler error when submitted again to the static code analysis above. It cannot catch all problems though: see Field::set_warning(), in which a call to push_warning_printf() has a variable error (thus, not replacable by a string literal); I checked set_warning() calls by hand though. See also WL 5883 for one proposal to avoid such bugs from appearing again in the future. The issues fixed in the patch are: a) mismatch in types (like 'int' passed to '%ld') b) more arguments passed than specified in the format. This patch resolves mismatches by changing the type/number of arguments, not by changing error messages of sql/share/errmsg.txt. The latter would be wrong, per the following old rule: errmsg.txt must be as stable as possible; no insertions or deletions of messages, no changes of type or number of printf-like format specifiers, are allowed, as long as the change impacts a message already released in a GA version. If this rule is not followed: - Connectors, which use error message numbers, will be confused (by insertions/deletions of messages) - using errmsg.sys of MySQL 5.1.n with mysqld of MySQL 5.1.(n+1) could produce wrong messages or crash; such usage can easily happen if installing 5.1.(n+1) while /etc/my.cnf still has --language=/path/to/5.1.n/xxx; or if copying mysqld from 5.1.(n+1) into a 5.1.n installation. When fixing b), I have verified that the superfluous arguments were not used in the format in the first 5.1 GA (5.1.30 'bteam@astra04-20081114162938-z8mctjp6st27uobm'). Had they been used, then passing them today, even if the message doesn't use them anymore, would have been necessary, as explained above.
-
- 14 May, 2011 1 commit
-
-
Vinay Fisrekar authored
Impementing Test Review Comment. Bug test scenario: SELECT is not returning result set for "equal" (=) and "NULL safe equal operator" (<=>) on BIT data type. Extending this scenario for all data types
-
- 13 May, 2011 1 commit
-
-
Bjorn Munch authored
-
- 12 May, 2011 3 commits
-
-
Bjorn Munch authored
-
Tatjana Azundris Nuernberg authored
-
Tatjana Azundris Nuernberg authored
-
- 10 May, 2011 2 commits
-
-
Serge Kozlov authored
-
Georgi Kodinov authored
-
- 09 May, 2011 1 commit
-
-
Serge Kozlov authored
Replaced the error code by error name
-
- 06 May, 2011 2 commits
-
-
Sunanda Menon authored
-
Karen Langford authored
-
- 05 May, 2011 4 commits
-
-
Luis Soares authored
Automerged bzr bundle from bug report: luis.soares@oracle.com-20110505224815-6ob90n7suxsoizvs.bundle
-
Luis Soares authored
Fix for all "postion" in Oracle files (s/postion/position). Updated the copyright notices where needed.
-
Luis Soares authored
WORK WITH --START-POSITION If setting --start-position to start after the FD event, mysqlbinlog will output an error stating that it has not found an FD event. However, its not that mysqlbinlog does not find it but rather that it does not processes it in the regular way (i.e., it does not print it). Given that one is using --base64-output=DECODE-ROWS then not printing it is actually fine. To fix this, we make mysqlbinlog not to complain when it has not printed the FD event, is outputing in base64, but is decoding the rows.
-
Tatiana Azundris Nurnberg authored
-
- 04 May, 2011 1 commit
-
-
Alexander Nozdrin authored
The problem was that wrong structure of mysql.event was not detected and the server continued to use wrongly-structured data. The fix is to check the structure of mysql.event after opening before any use. That makes operations with events more strict -- some operations that might work before throw errors now. That seems to be Ok. Another side-effect of the patch is that if mysql.event is corrupted, unrelated DROP DATABASE statements issue an SQL warning about inability to open mysql.event table.
-
- 03 May, 2011 2 commits
-
-
Bjorn Munch authored
The originally reported dirs have been removed But found suite/bugs, removed from mysql-test/Makefile.am
-
Kent Boortz authored
-
- 02 May, 2011 1 commit
-
-
Vasil Dimov authored
-
- 29 Apr, 2011 5 commits
-
-
Nirbhay Choubey authored
.editrc on linux. MySQL client when build with libedit support ignores .editrc at startup. The reason for this regression was the incluison of a safety check, issetugid(), which is not available on some linux platforms. Fixed by adding an equivalent check for platforms which have get[e][u|g]id() set of functions.
-
Bjorn Munch authored
-
Vasil Dimov authored
Add extra codes to wait_until_disconnected.inc that are present in 5.5, but not in 5.1. The missing codes cause innodb_bug59641 to fail in 5.1 on Windows PB2 runs. The addition of those codes in 5.5 was done in luis.soares@sun.com-20090930233215-aup3kxy4j6ltvjfp
-
Bjorn Munch authored
-
Mattias Jonsson authored
-
- 27 Apr, 2011 3 commits
-
-
Mattias Jonsson authored
Partitions can have different ref_length (position data length). Removed DBUG_ASSERT which crashed debug builds when using MAX_ROWS on some partitions.
-
Nirbhay Choubey authored
FAILS WITH LIBEDIT Fixed by checking the return value of the write() function calls and handling the open files and fd appropriately.
-
Sergey Glukhov authored
calc_daynr() function returns negative result if malformed date with zero year and month is used. Attempt to calculate week day on negative value leads to crash. The fix is return NULL for 'W', 'a', 'w' specifiers if zero year and month is used. Additional fix for calc_daynr(): --added assertion that result can not be negative --return 0 if zero year and month is used
-
- 26 Apr, 2011 3 commits
-
-
Guilhem Bichot authored
-
Mattias Jonsson authored
-
Mattias Jonsson authored
-
- 25 Apr, 2011 1 commit
-
-
Serge Kozlov authored
-
- 23 Apr, 2011 1 commit
-
-
Mattias Jonsson authored
-
- 22 Apr, 2011 1 commit
-
-
Sergey Glukhov authored
Before sorting HAVING condition is split into two parts, first part is a table related condition and the rest of is HAVING part. Extraction of HAVING part does not take into account the fact that some of conditions might be non-const but have 'used_tables' == 0 (independent subqueries) and because of that these conditions are cut off by make_cond_for_table() function. The fix is to use (table_map) 0 instead of used_tables in third argument for make_cond_for_table() function. It allows to extract elements which belong to sorted table and in addition elements which are independend subqueries.
-
- 21 Apr, 2011 1 commit
-
-
Vasil Dimov authored
-
- 20 Apr, 2011 6 commits
-
-
Mattias Jonsson authored
-
Mattias Jonsson authored
-
Mattias Jonsson authored
Update for previous patch according to reviewers comments. Updated the constructors for ha_partitions to use the common init_handler_variables functions Added use of defines for size and offset to get better readability for the code that reads and writes the .par file. Also refactored the get_from_handler_file function.
-
Bjorn Munch authored
Replaced the hardcoded 9 with 'KILL'
-
Jon Olav Hauglid authored
FAILS ON SOLARIS This assertion was triggered if gethostbyaddr_r cannot do a reverse lookup on an ip address. The reason was a missing DBUG_RETURN macro. The problem affected only debug versions of the server. This patch fixes the problem by replacing return with DBUG_RETURN. No test case added.
-
Sergey Glukhov authored
Bug#11764671 57533: UNINITIALISED VALUES IN COPY_AND_CONVERT (SQL_STRING.CC) WITH CERTAIN CHA When ROUND evaluates decimal result it uses Item::decimal value as fraction value for the result. In some cases Item::decimal is greater than real result fraction value and uninitialised memory of result(decimal) buffer can be used in further calculations. Issue is introduced by Bug33143 fix. The fix is to remove erroneous assignment.
-