- Remove bothersome warning messages. This change focuses on the warnings
that are covered by the ignore file: support-files/compiler_warnings.supp.
- Strings are guaranteed to be max uint in length
- Remove bothersome warning messages. This change focuses on the warnings
that are covered by the ignore file: support-files/compiler_warnings.supp.
- Strings are guaranteed to be max uint in length
Various parts of code used different 'precision' arguments for sprintf("%g") when converting
floating point numbers to a string. This led to differences in results in some cases
depending on whether the text-based or prepared statements protocol is used for a query.
Fixed by changing arguments to sprintf("%g") to always be 15 (DBL_DIG) so that results are
consistent regardless of the protocol.
This patch will be null-merged to 6.0 as the problem does not exists there (fixed by the
patch for WL#2934).
The problem here is that embedded server starts handle_thread manager
thread on mysql_library_init() does not stop it on mysql_library_end().
At shutdown, my_thread_global_end() waits for thread count to become 0,
but since we did not stop the thread it will give up after 5 seconds.
Solution is to move shutdown for handle_manager thread from kill_server()
(mysqld specific) to clean_up() that is used by both embedded and mysqld.
This patch also contains some refactorings - to avoid duplicate code,
start_handle_manager() and stop_handle_manager() functions are introduced.
Unused variables are eliminated. handle_manager does not rely on global
variable abort_loop anymore to stop (abort_loop is not set for embedded).
Note: Specifically on Windows and when using DBUG version of libmysqld,
the complete solution requires removing obsolete code my_thread_init()
from my_thread_var(). This has a side effect that a DBUG statement
after my_thread_end() can cause thread counter to be incremented, and
embedded will hang for some seconds. Or worse, my_thread_init() will
crash if critical sections have been deleted by the global cleanup
routine that runs in a different thread.
This patch also fixes and revert prior changes for Bug#38293
"Libmysqld crash in mysql_library_init if language file missing".
Root cause of the crash observed in Bug#38293 was bug in my_thread_init()
described above
Bug#33031 app linked to libmysql.lib crash if run as service in vista under
localsystem
There are some problems using DllMain hook functions on Windows that
automatically do global and per-thread initialization for libmysqld.dll
1)per-thread initialization(DLL_THREAD_ATTACH)
MySQL internally counts number of active threads that and causes a delay in in
my_end() if not all threads are exited. But,there are threads that can be
started either by Windows internally (often in TCP/IP scenarios) or by user
himself - those threads are not necessarily using libmysql.dll functionality,
but nonetheless the contribute to the count of open threads.
2)process-initialization (DLL_PROCESS_ATTACH)
my_init() calls WSAStartup that itself loads DLLs and can lead to a deadlock in
Windows loader.
Fix is to remove dll initialization code from libmysql.dll in general case. I
still leave an environment variable LIBMYSQL_DLLINIT, which if set to any value
will cause the old behavior (DLL init hooks will be called). This env.variable
exists only to prevent breakage of existing Windows-only applications that
don't do mysql_thread_init() and work ok today. Use of LIBMYSQL_DLLINIT is
discouraged and it will be removed in 6.0
Bug#33031 app linked to libmysql.lib crash if run as service in vista under
localsystem
There are some problems using DllMain hook functions on Windows that
automatically do global and per-thread initialization for libmysqld.dll
1)per-thread initialization(DLL_THREAD_ATTACH)
MySQL internally counts number of active threads that and causes a delay in in
my_end() if not all threads are exited. But,there are threads that can be
started either by Windows internally (often in TCP/IP scenarios) or by user
himself - those threads are not necessarily using libmysql.dll functionality,
but nonetheless the contribute to the count of open threads.
2)process-initialization (DLL_PROCESS_ATTACH)
my_init() calls WSAStartup that itself loads DLLs and can lead to a deadlock in
Windows loader.
Fix is to remove dll initialization code from libmysql.dll in general case. I
still leave an environment variable LIBMYSQL_DLLINIT, which if set to any value
will cause the old behavior (DLL init hooks will be called). This env.variable
exists only to prevent breakage of existing Windows-only applications that
don't do mysql_thread_init() and work ok today. Use of LIBMYSQL_DLLINIT is
discouraged and it will be removed in 6.0
PREPARE", review fixes:
- make the patch follow the specification of WL#4166 and remove
the new error that was originally introduced.
Now the client never gets an error from reprepare, unless it failed.
I.e. even if the statement at hand returns a completely different
result set, this is not considered a server error.
The C API library, that can not handle this situation, was modified to
return a client error.
Added additional test coverage.
The problem was that the COM_STMT_SEND_LONG_DATA was sending a response
packet if the prepared statement wasn't found in the server (due to
reconnection). The commands COM_STMT_SEND_LONG_DATA and COM_STMT_CLOSE
should not send any packets, even error packets should not be sent since
they are not expected by the client API.
The solution is to clear generated during the execution of the aforementioned
commands and to skip resend of prepared statement commands. Another fix is
that if the connection breaks during the send of prepared statement command,
the command is not sent again since the prepared statement is no longer in the
server.
Rename client_last_error to last_error and client_last_errno to last_errno
to not break connectors which use the internal net structure for error handling.
There was no way to return an error from the client library
if no MYSQL connections was established.
So here i added variables to store that king of errors and
made functions like mysql_error(NULL) to return these.
value" error even though the value was correct): a C function in my_getopt.c
was taking bool* in parameter and was called from C++ sql_plugin.cc,
but on some Mac OS X sizeof(bool) is 1 in C and 4 in C++, giving funny
mismatches. Fixed, all other occurences of bool in C are removed, future
ones are blocked by a "C-bool-catcher" in my_global.h (use my_bool).
cause ROLLBACK of statement", part 1. Review fixes.
Do not send OK/EOF packets to the client until we reached the end of
the current statement.
This is a consolidation, to keep the functionality that is shared by all
SQL statements in one place in the server.
Currently this functionality includes:
- close_thread_tables()
- log_slow_statement().
After this patch and the subsequent patch for Bug#12713, it shall also include:
- ha_autocommit_or_rollback()
- net_end_statement()
- query_cache_end_of_result().
In future it may also include:
- mysql_reset_thd_for_next_command().
Remove the mysql_odbc_escape_string() function. The function
has multi-byte character escaping issues, doesn't honor the
NO_BACKSLASH_ESCAPES mode and is not used anymore by the
Connector/ODBC as of 3.51.17.
crashes.
MySQL distributions contain a number of programs that are used only by
the MySQL test suite internally, i.e. they are not indended to be
invoked directly by a user. As a result, such programs are not
documented, do not have any built-in help or proper error reporting,
which may confuse users.
This patch fixes the problem with the following changes:
- mytest, libmysqltest and all references to them were removed from the
distribution since they are not used anymore
- bug25714 now displays an error message when run with incorrect
arguments or with the --help option
- mysql_client_test now does not call abort() in case of errors,
instead it does a clean exit() with a proper error status.
