Commit graph

2748 commits

Author SHA1 Message Date
Sujatha Sivakumar
2e84cf8674 merge from 5.1 to 5.5 2012-07-10 14:37:35 +05:30
Sujatha Sivakumar
13f7f00288 BUG#11762670:MY_B_WRITE RETURN VALUE IGNORED
Problem:
=======
The return value from my_b_write is ignored by: `my_b_write_quoted',
`my_b_write_bit',`Query_log_event::print_query_header'

Most callers of `my_b_printf' ignore the return value. `log_event.cc' 
has many calls to it. 

Analysis:
========
`my_b_write' is used to write data into a file. If the write fails it
sets appropriate error number and error message through my_error()
function call and sets the IO_CACHE::error == -1.
`my_b_printf' function is also used to write data into a file, it
internally invokes my_b_write to do the write operation. Upon
success it returns number of characters written to file and on error
it returns -1 and sets the error through my_error() and also sets
IO_CACHE::error == -1.  Most of the event specific print functions
for example `Create_file_log_event::print', `Execute_load_log_event::print'
etc are the ones which make several calls to the above two functions and
they do not check for the return value after the 'print' call. All the above 
mentioned abuse cases deal with the client side.

Fix:
===
As part of bug fix a check for IO_CACHE::error == -1 has been added at 
a very high level after the call to the 'print' function.  There are 
few more places where the return value of "my_b_write" is ignored
those are mentioned below.

+++ mysys/mf_iocache2.c    2012-06-04 07:03:15 +0000
@@ -430,7 +430,8 @@
           memset(buffz, '0', minimum_width - length2);
         else
           memset(buffz, ' ', minimum_width - length2);
-        my_b_write(info, buffz, minimum_width - length2);

+++ sql/log.cc	2012-06-08 09:04:46 +0000
@@ -2388,7 +2388,12 @@
     {
       end= strxmov(buff, "# administrator command: ", NullS);
       buff_len= (ulong) (end - buff);
-      my_b_write(&log_file, (uchar*) buff, buff_len);

At these places appropriate return value handlers have been added.

client/mysqlbinlog.cc:
  check for IO_CACHE::error == -1 has been added after the call to
  the event specific print functions
mysys/mf_iocache2.c:
  Added handler to check the written value of `my_b_write'
sql/log.cc:
  Added handler to check the written value of `my_b_write'
sql/log_event.cc:
  Added error simulation statements in `Create_file_log_event::print`
  and `Execute_load_query_log_event::print'
sql/rpl_utility.h:
  Removed the extra ';'
2012-07-10 14:23:17 +05:30
Georgi Kodinov
048577429f Bug #13889741: HANDLE_FATAL_SIGNAL IN _DB_ENTER_ |
HANDLE_FATAL_SIGNAL IN STRNLEN

Fixed the following bounds checking problems :
1. in check_if_legal_filename() make sure the null terminated
string is long enough before accessing the bytes in it.
Prevents pottential read-past-buffer-end
2. in my_wc_mb_filename() of the filename charset check
for the end of the destination buffer before sending single
byte characters into it.
Prevents write-past-end-of-buffer (and garbaling stack in
the cases reported here) errors.

Added test cases.
2012-07-05 13:41:16 +03:00
Georgi Kodinov
5a496caeb5 merge 2012-07-05 14:41:04 +03:00
Rohit Kalhans
484a79415b upmerge from mysql-5.1 branch -> mysql-5.5 branch 2012-05-29 12:21:17 +05:30
Rohit Kalhans
d8b2d4a069 Bug#11762667: MYSQLBINLOG IGNORES ERRORS WHILE WRITING OUTPUT
Problem: mysqlbinlog exits without any error code in case of
file write error. It is because of the fact that the calls
to Log_event::print() method does not return a value and the
thus any error were being ignored.

Resolution: We resolve this problem by checking for the 
IO_CACHE::error == -1 after every call to Log_event:: print()
and terminating the further execution.

client/mysqlbinlog.cc:
  - handled error conditions during event->print() calls
  - added check for error in end_io_cache()
mysys/my_write.c:
  Added debug code to simulate file write error.
  error returned will be ENOSPC=> error no space on the disk
sql/log_event.cc:
  Added debug code to simulate file write error, by reducing the size of io cache.
2012-05-29 12:11:30 +05:30
Georgi Kodinov
7fa28bcf56 merge mysql-5.5->mysql-5.5-security 2012-04-10 14:23:17 +03:00
Marc Alff
7553f9eefd Bug#13898343 THREAD LOOPS ENDLESSLY IN LF_PINBOX_PUT_PINS WHILE HOLDING
LOCK_THREAD_COUNT

When using the performance schema file io instrumentation in MySQL 5.5,
a thread would loop forever inside lf_pinbox_put_pins, when disconnecting.
It would also hold LOCK_thread_count while doing so, effectively killing the
server.

The root cause of the loop in lf_pinbox_put_pins() is a leak of LF_PINS,
when used with the filename_hash LF_HASH table in the performance schema.

This fix contains the following changes:

1)
Added the missing call to lf_hash_search_unpin(), to prevent the leak.

2)
In mysys/lf_alloc-pin.c, there was some extra debugging code
(MY_LF_EXTRA_DEBUG) written to detect precisely this kind of issues,
but it was never used.
Replaced MY_LF_EXTRA_DEBUG with DBUG_OFF, so that leaks similar to this one
can be always detected in regular debug builds.

3)
Backported the fix for the following bug, from 5.6 to 5.5:
Bug#13417446 - 63339: INCORRECT FILE PATH IN PEFORMANCE_SCHEMA ON WINDOWS
2012-03-28 17:54:30 +02:00
Georgi Kodinov
9c366f7921 merge mysql-5.5->mysql-5.5-security 2012-03-08 17:19:54 +02:00
Georgi Kodinov
4b5306fd6e merge mysql-5.1->mysql-5.1-security 2012-03-08 17:16:53 +02:00
Tor Didriksen
84c6c75979 Merge 5.1 => 5.5
storage/innobase/include/sync0rw.ic:
  Prerequisite for compiling with gcc4 on solaris: ignore result from
  os_compare_and_swap_ulint
storage/myisam/mi_dynrec.c:
  Prerequisite for compiling with gcc4 on solaris: cast to void*
2012-03-06 13:47:57 +01:00
Tor Didriksen
c657f00458 Bug#11761576 54082: HANDLE_SEGFAULT MAKES USE OF UNSAFE FUNCTIONS
Post-push fixes.


mysys/stacktrace.c:
  Missing comma after "%s" format specifier.
sql/mysqld.cc:
  Move #define to signal_handler.cc
sql/signal_handler.cc:
  Missing #define UNSAFE_DEFAULT_LINUX_THREADS 200
2012-03-06 13:30:30 +01:00
Annamalai Gurusami
7e36c4bdb0 Bug#13635833: MULTIPLE CRASHES IN FOREIGN KEY CODE WITH CONCURRENT DDL/DML
There are two threads.  In one thread, dml operation is going on 
involving cascaded update operation.  In another thread, alter 
table add foreign key constraint is happening.  Under these 
circumstances, it is possible for the dml thread to access a 
dict_foreign_t object that has been freed by the ddl thread.  
The debug sync test case provides the sequence of operations.  
Without fix, the test case will crash the server (because of 
newly added assert).  With fix, the alter table stmt will return 
an error message.  
      
Backporting the fix from MySQL 5.5 to 5.1

rb:961
rb:947
2012-03-01 11:05:51 +05:30
Annamalai Gurusami
c1615df32c Bug#13635833: MULTIPLE CRASHES IN FOREIGN KEY CODE WITH CONCURRENT DDL/DML
There are two threads.  In one thread, dml operation is going on 
involving cascaded update operation.  In another thread, alter 
table add foreign key constraint is happening.  Under these 
circumstances, it is possible for the dml thread to access a 
dict_foreign_t object that has been freed by the ddl thread.  
The debug sync test case provides the sequence of operations.  
Without fix, the test case will crash the server (because of 
newly added assert).  With fix, the alter table stmt will return 
an error message.  
      
rb:947
approved by Jimmy Yang
2012-02-27 17:23:56 +05:30
MySQL Build Team
7a35cb9150 Updated/added copyright headers 2012-02-16 10:48:16 +01:00
Kent Boortz
6a003dd8ef Updated/added copyright headers 2012-02-15 17:21:38 +01:00
MySQL Build Team
7177a2b9d7 Updated/added copyright headers 2012-02-15 17:13:47 +01:00
Ramil Kalimullin
882ef63e70 Fix for BUG#13596377: MYSQL CRASHES ON STARTUP ON FREEBSD IN PB2
Fix for #36428/#38364 backported into 5.0.
2012-01-30 22:52:33 +04:00
Alexander Barkov
31a1f8ef54 Merging Bug#11752408 from mysql-5.1 2012-01-23 13:23:50 +04:00
Alexander Barkov
e449cf48af Bug#11752408 - 43593: DUMP/BACKUP/RESTORE/UPGRADE TOOLS FAILS BECAUSE OF UTF8_GENERAL_CI
Introducing new collations:
utf8_general_mysql500_ci and ucs2_general_mysql500_ci,
to reproduce behaviour of utf8_general_ci and ucs2_general_ci
from mysql-5.1.23 (and earlier).

The collations are added to simplify upgrade from mysql-5.1.23 and earlier.

Note: The patch does not make new server start over old data automatically.
Some manual upgrade procedures are assumed.

Paul: please get in touch with me to discuss upgrade procedures
when documenting this bug.

modified:
  include/m_ctype.h
  mysql-test/r/ctype_utf8.result
  mysql-test/t/ctype_utf8.test
  mysys/charset-def.c
  strings/ctype-ucs2.c
  strings/ctype-utf8.c
2012-01-23 13:07:10 +04:00
Tor Didriksen
b522a6ce78 Bug#11761576 54082: HANDLE_SEGFAULT MAKES USE OF UNSAFE FUNCTIONS
handle_segfault is the signal handler code of mysqld.  however, it makes
calls to potentially unsafe functions localtime_r, fprintf, fflush.



include/my_stacktrace.h:
  Add safe versions of itoa() write() and snprintf().
libmysqld/CMakeLists.txt:
  Move signal handler to separate file.
mysys/stacktrace.c:
  Remove unsafe function calls.
sql/CMakeLists.txt:
  Move signal handler to separate file.
sql/mysqld.cc:
  Move signal handler to separate file.
sql/set_var.h:
  Add missing #include dependency.
sql/sys_vars.cc:
  Cleanup .h and .cc files.
sql/sys_vars.h:
  Cleanup .h and .cc files.
2011-12-02 14:16:48 +01:00
Tor Didriksen
9a15f2492b Bug#11761576 54082: HANDLE_SEGFAULT MAKES USE OF UNSAFE FUNCTIONS
handle_segfault is the signal handler code of mysqld.  however, it makes
calls to potentially unsafe functions localtime_r, fprintf, fflush.



include/my_stacktrace.h:
  Add safe versions of itoa() write() and snprintf().
libmysqld/CMakeLists.txt:
  Move signal handler to separate file.
mysys/stacktrace.c:
  Remove unsafe function calls.
sql/CMakeLists.txt:
  Move signal handler to separate file.
sql/Makefile.am:
  Move signal handler to separate file.
sql/mysqld.cc:
  Move signal handler to separate file.
sql/signal_handler.cc:
  Remove unsafe function calls.
2011-11-30 15:39:29 +01:00
Marko Mäkelä
247ada63af Bug#12547647 UPDATE LOGGING COULD EXCEED LOG PAGE SIZE
This fix was accidentally pushed to mysql-5.1 after the 5.1.59 clone-off in
bzr revision id marko.makela@oracle.com-20110829081642-z0w992a0mrc62s6w
with the fix of Bug#12704861 Corruption after a crash during BLOB update
but not merged to mysql-5.5 and upwards.

In the Barracuda formats, the clustered index record no longer
contains a prefix of off-page columns. Because of this, the undo log
must contain these prefixes, so that purge and multi-versioning will
continue to work. However, this also means that an undo log record can
become too big to fit in an undo log page. (It is a limitation of the
undo log that undo records cannot span across multiple pages.)

In case the checks for undo log size fail when CREATE TABLE or CREATE
INDEX is executed, we need a fallback that blocks a modification
operation when the undo log record would exceed the maximum size.

trx_undo_free_last_page_func(): Renamed from trx_undo_free_page_in_rollback().
Define the trx_t parameter only in debug builds.

trx_undo_free_last_page(): Wrapper for trx_undo_free_last_page_func().
Pass the trx_t parameter only in debug builds.

trx_undo_truncate_end_func(): Renamed from trx_undo_truncate_end().
Define the trx_t parameter only in debug builds. Rewrite a for(;;) loop
as a while loop for clarity.

trx_undo_truncate_end(): Wrapper for from trx_undo_truncate_end_func().
Pass the trx_t parameter only in debug builds.

trx_undo_erase_page_end(): Return TRUE if the page was non-empty
to begin with. Refuse to erase empty pages.

trx_undo_report_row_operation(): If the page for which the undo log
was too big was empty, free the undo page and return DB_TOO_BIG_RECORD.

rb:749 approved by Inaam Rana
2011-09-01 21:48:04 +03:00
Jimmy Yang
95fa7fab3b Fix bug #11830883, SUPPORT "CORRUPTED" BIT FOR INNODB TABLES AND INDEXES.
Also addressed issues in bug #11745133, where we could mark a table
corrupted instead of crashing the server when found a corrupted buffer/page
if the table created with innodb_file_per_table on.
2011-08-16 18:07:59 -07:00
Jon Olav Hauglid
aee88a4cc6 Bug#12779790 COMPILATION FAILS OS X 10.7 - IMPLICIT DECLARATION OF
FUNCTION 'PTHREAD_INIT' 

The problem was that compilation would fail with a warning:
Implicit declaration of function 'pthread_init' if MySQL was
compiled on OS X 10.7 (Lion). The reason was that pthread_init()
is now part of an internal OS X pthread library so it was found
by CMake.

This patch fixes the problem by removing HAVE_PTHREAD_INIT and
related code. pthread_init() was specific to MIT-pthreads which
has not been supported since 4.1 and was therefore no longer
relevant.

No test case added.
2011-07-21 17:45:38 +02:00
Sunanda Menon
af6ddeca48 Merge from mysql-5.0.94-release 2011-07-06 11:36:39 +02:00
unknown
7d605ec45f Merge from mysql-5.5.14-release 2011-07-06 01:13:50 +02:00
Karen Langford
f6398a86dd Merge from mysql-5.1.58-release 2011-07-06 00:56:51 +02:00
Kent Boortz
027b5f1ed4 Updated/added copyright headers 2011-07-03 17:47:37 +02:00
Kent Boortz
bb3723835e Updated/added copyright headers 2011-06-30 21:27:04 +02:00
Kent Boortz
68f00a5686 Updated/added copyright headers 2011-06-30 17:37:13 +02:00
Kent Boortz
44135d4725 Updated/added copyright headers 2011-06-30 17:31:31 +02:00
Georgi Kodinov
54729bbc60 merged mysql-5.5->mysql-5.5-security 2011-06-06 16:17:58 +03:00
Jimmy Yang
9e2b7fa7d5 Implement worklog #5743 InnoDB: Lift the limit of index key prefixes.
With this change, the index prefix column length lifted from 767 bytes
to 3072 bytes if "innodb_large_prefix" is set to "true".

rb://603 approved by Marko
2011-05-31 02:12:32 -07:00
Mikael Ronström
c51c4a77af merge 2011-05-19 10:49:43 +02:00
Marc Alff
b1307dc0e1 Fixed code review comments 2011-05-16 22:47:59 +02:00
Kent Boortz
789aa8c485 Updated/added copyright headers 2011-07-04 01:25:49 +02:00
Kent Boortz
02e07e3b51 Updated/added copyright headers 2011-06-30 17:46:53 +02:00
Dmitry Shulga
44ed935b21 Fixed bug#12403662 (formerly known as bug#60987): LOAD DATA LOCAL INFILE
can't parse relative paths "higher" than 3 levels up

When trying to LOAD DATA LOCAL INFILE using a relative path with 3 or
more levels up in the directory hierarchy, mysqld wrongly parses 
the path and as a consequence, can't find the file.

This bug was introduced by patch for bug#58205.
The reason for bug is that implementaiton of function cleanup_dirname()
doesn't take into account the begin of buffer being processed during
handling of path to file.


mysys/mf_pack.c:
  function cleanup_dirname() was modified: fixed wrong comparison
  condition when handling substring "../" at the begining of the buffer.
2011-06-15 16:18:08 +07:00
Marc Alff
d343f5e372 Bug#12552516 LF_HASH REQUIRES MY_THREAD_INIT()
Before this fix, a thread instrumented for the performance schema,
that would perform file io operations, could crash inside the LF_HASH
implementation, in cases when my_thread_init is not called.

The crash itself has not been reported in 5.5 but similar crashes have
been found in 5.6-based development branches, using LF_HASH for
more instrumentation.

The possibility of a crash in 5.5 is confirmed by code analysis.

The problem is that, when my_thread_init() is not called,
which can happen for threads in storage engines or thirs party code,
my_thread_var is NULL.

Using my_thread_var->stacks_ends_here in mysys/lf_alloc-pin.c is unsafe.

Given that my_thread_var is used:
- only for stacks_ends_here
- only on platform with HAVE_ALLOCA
- only when there is enough room on the stack
and given that the LF_HASH implementation has a fallback
algorythm implemented already when using alloca is not possible,
using my_thread_var->stacks_ends_here is in fact not a strict requirement,
and can be relaxed.

The fix is to:
- test explicitly if my_thread_var is NULL, to account for cases
  when my_thread_init() is not used by the calling thread.
- not use alloca in this case, and rely on the fall back code already in place.
  so that the LF_HASH can be supported even without my_thread_init().

The implementation of mysys/lf_alloc-pin.c has been fixed to support this new usage.
The units tests in unittest/mysys/lf-t.c have been adjusted accordingly.
2011-05-13 18:04:49 +02:00
Georgi Kodinov
c4c808d606 weave merge of mysql-5.5->mysql-5.5-security 2011-05-10 17:20:26 +03:00
Georgi Kodinov
2da8ba6404 merge mysql-5.1-security->mysql-5.5-security 2011-05-04 15:59:00 +03:00
Georgi Kodinov
e76cd16967 Merged 5.0-security->5.1-security 2011-05-04 14:29:23 +03:00
Georgi Kodinov
59d7516005 Bug #11764517: 57359: POSSIBLE TO CIRCUMVENT SECURE_FILE_PRIV
USING '..' ON WINDOWS

Backport of the fix to 5.0 (to be null-merged to 5.1).
Moved the test into the main test suite. 
Made mysql-test-run.pl to not use symlinks for sdtdata as the symlinks
are now properly recognized by secure_file_priv.
Made sure the paths in load_file(), LOAD DATA and SELECT .. INTO OUTFILE 
that are checked against secure_file_priv in a correct way similarly to 5.1 
by the extended is_secure_file_path() backport before the comparison.
Added an extensive test with all the variants of upper/lower case, 
slash/backslash and case sensitivity.
Added few comments to the code.
2011-04-28 12:22:41 +03:00
Mikael Ronström
70ed67e1cc Merge 5.5 2011-04-15 15:46:11 +02:00
Davi Arnaut
8aadfb4065 Remove some leftovers from the removal of the gethostbyname wrappers. 2011-04-13 16:05:26 -03:00
Georgi Kodinov
5321b3a57a Bug #11758687: 50924: object names not resolved correctly
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.
2011-04-04 16:04:15 +03:00
Magne Mahre
b8faa8f2c6 Fix-up after commit of Bug#11900714
The patch fixes a build problem on MacOSX, where
the compiler complains about unused parameters.
2011-03-30 16:14:13 +02:00
Magne Mahre
517c5c247c Bug#11933945 REMOVE LGPL LICENSED FILES IN MYSQL 5.5
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.5 and later, and is the third of a 
       set of patches to remove LGPL from all trees.
       (See Bug# 11840513 for details)
2011-03-29 14:43:49 +02:00
Magne Mahre
9ff72a1acf Bug#11900714 REMOVE LGPL LICENSED FILES IN MYSQL 5.1
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)
2011-03-28 10:47:30 +02:00