1
0
mirror of https://github.com/MariaDB/server.git synced 2025-07-10 04:22:00 +03:00
Commit Graph

162 Commits

Author SHA1 Message Date
06b7fce9f2 Merge branch '10.1' into 10.2 2016-09-09 08:33:08 +02:00
a350e53b61 Merge branch 'mysql/5.5' into 5.5
without a fix for Bug#12818255 (MDEV-6581)
2016-08-03 20:38:25 +02:00
9f7288e2e0 BUG#23080148 - BACKPORT BUG 14653594 AND BUG 20683959 TO
MYSQL-5.5

The bug asks for a backport of bug#1463594 and bug#20682959. This
is required because of the fact that if replication is enabled, master
transaction can commit whereas slave can't commit due to not exact
'enviroment'. This manifestation is seen in bug#22024200.
2016-06-20 11:35:43 +05:30
5d16592d44 mysql-5.5.38 merge 2014-06-03 09:55:08 +02:00
95e99e1263 Bug#11759519 - INFINITE HANG WITH 100% CPU USAGE WITH LOAD DATA
LOCAL AND IMPORT ERRORS

Description:
-----------
This bug happens due to the fact that current algorithm is designed
that in the case of LOCAL load of data, in case of the error, the
remaining part of the file is read in order to return the proper
error message to the client side.

But, the problem with current implementation is that data stream
for the client side is cleared only in the case where line delimiters
exist, which is not a case with, for example fixed width
fields.

Fix:
----
Ported patch provided by Sinisa Milivojevic n bug report for this
issue to 5.5+ versions.

As part of this patch code is changed to clear the data stream
by calling new member function "READ_INFO::skip_data_till_eof".
2014-03-19 12:30:30 +05:30
e73df7d9d0 Bug#11759519 - INFINITE HANG WITH 100% CPU USAGE WITH LOAD DATA
LOCAL AND IMPORT ERRORS

Description:
-----------
This bug happens due to the fact that current algorithm is designed
that in the case of LOCAL load of data, in case of the error, the
remaining part of the file is read in order to return the proper
error message to the client side.

But, the problem with current implementation is that data stream
for the client side is cleared only in the case where line delimiters
exist, which is not a case with, for example fixed width
fields.

Fix:
----
Ported patch provided by Sinisa Milivojevic n bug report for this
issue to 5.5+ versions.

As part of this patch code is changed to clear the data stream
by calling new member function "READ_INFO::skip_data_till_eof".
2014-03-19 12:30:30 +05:30
aca8e7ed6b 5.3 merge 2013-01-15 19:07:46 +01:00
2e11ca36f2 mysql-5.1.67 merge 2013-01-09 23:51:51 +01:00
422e6b520d Description:
-----------
After compiling from source, during make test I got the following error:

test main.loaddata failed with error
CURRENT_TEST: main.loaddata
mysqltest: At line 592: query 'LOAD DATA INFILE 'tmpp.txt' INTO TABLE t1
CHARACTER SET ucs2
(@b) SET a=REVERSE(@b)' failed: 1115: Unknown character set: 'ucs2'

I noticed other tests are skipped because of no ucs2
main.mix2_myisam_ucs2                    [ skipped ]  Test requires:'
have_ucs2'

Should main.loaddata be skipped if there is no ucs2

How To Repeat:
-------------
Run make test on compiled source that doesn't have ucs2

Suggested fix:
-------------
the failing piece of the test should be moved from mysql-test/t/loaddata.test to
mysql-test/t/ctype_ucs.test.
2012-09-26 16:38:42 +05:30
4f327600ea Description:
-----------
After compiling from source, during make test I got the following error:

test main.loaddata failed with error
CURRENT_TEST: main.loaddata
mysqltest: At line 592: query 'LOAD DATA INFILE 'tmpp.txt' INTO TABLE t1
CHARACTER SET ucs2
(@b) SET a=REVERSE(@b)' failed: 1115: Unknown character set: 'ucs2'

I noticed other tests are skipped because of no ucs2
main.mix2_myisam_ucs2                    [ skipped ]  Test requires:'
have_ucs2'

Should main.loaddata be skipped if there is no ucs2

How To Repeat:
-------------
Run make test on compiled source that doesn't have ucs2

Suggested fix:
-------------
the failing piece of the test should be moved from mysql-test/t/loaddata.test to
mysql-test/t/ctype_ucs.test.
2012-09-26 17:04:19 +05:30
a246d1544d Description:
-----------
After compiling from source, during make test I got the following error:

test main.loaddata failed with error
CURRENT_TEST: main.loaddata
mysqltest: At line 592: query 'LOAD DATA INFILE 'tmpp.txt' INTO TABLE t1
CHARACTER SET ucs2
(@b) SET a=REVERSE(@b)' failed: 1115: Unknown character set: 'ucs2'

I noticed other tests are skipped because of no ucs2
main.mix2_myisam_ucs2                    [ skipped ]  Test requires:'
have_ucs2'

Should main.loaddata be skipped if there is no ucs2

How To Repeat:
-------------
Run make test on compiled source that doesn't have ucs2

Suggested fix:
-------------
the failing piece of the test should be moved from mysql-test/t/loaddata.test to
mysql-test/t/ctype_ucs.test.
2012-09-26 17:04:19 +05:30
39739a423f Description:
-----------
After compiling from source, during make test I got the following error:

test main.loaddata failed with error
CURRENT_TEST: main.loaddata
mysqltest: At line 592: query 'LOAD DATA INFILE 'tmpp.txt' INTO TABLE t1
CHARACTER SET ucs2
(@b) SET a=REVERSE(@b)' failed: 1115: Unknown character set: 'ucs2'

I noticed other tests are skipped because of no ucs2
main.mix2_myisam_ucs2                    [ skipped ]  Test requires:'
have_ucs2'

Should main.loaddata be skipped if there is no ucs2

How To Repeat:
-------------
Run make test on compiled source that doesn't have ucs2

Suggested fix:
-------------
the failing piece of the test should be moved from mysql-test/t/loaddata.test to
mysql-test/t/ctype_ucs.test.
2012-09-26 16:38:42 +05:30
9809f05199 5.5-merge 2011-07-02 22:08:51 +02:00
e415ba0fb2 Merge with MySQL 5.1.57/58
Moved some BSD string functions from Unireg
2011-05-02 20:58:45 +03:00
dc65d9217c Fix for Bug#11765141 - "58072: LOAD DATA INFILE: LEAKS IO CACHE MEMORY WHEN ERROR OCCURS"
mysql-test/t/loaddata.test:
  test for bug; without fix, running the test with --valgrind would show the leak
  and make the test fail.
sql/sql_load.cc:
  * In READ_INFO class, 'need_end_io_cache' is true as long as init_io_cache() was called,
  so if it's true, we need to call end_io_cache(), to free memory allocated
  by init_io_cache(). No matter the value of 'error'. In the bug's scenario,
  'error' was set to true in read_sep_field() because
  '1' (read from file) isn't suitable to load into a geometric column. Because of
  'error', end_io_cache() was not called.
  Note: end_io_cache() calls my_b_flush_io_cache(), which will do nothing wrong given
  that the file is opened for reads only; see the init_io_cache() call which uses
  only those read-only types:
  (get_it_from_net) ? READ_NET : (is_fifo ? READ_FIFO : READ_CACHE).
  IF the cache were rather used to write to the file, my_b_flush_io_cache() may
  write to it, and it may be questionable to write to the file
  if 'error' is true. But here there's no problem.
  * Now that 'need_end_io_cache' is checked even if 'error' is true, it needs
  to be initialized in all cases.
  * Bonus: move some variables to the initialization list.
2011-04-07 15:09:19 +02:00
bba7b9ca0c Bug#11765139 58069: LOAD DATA INFILE: VALGRIND REPORTS INVALID MEMORY READS AND WRITES WITH U
Some multibyte sequences could be considered by my_mbcharlen() functions
as multibyte character but more exact my_ismbchar() does not think so.
In such a case this multibyte sequences is pushed into 'stack' buffer which
is too small to accommodate the sequence.
The fix is to allocate stack buffer in
compliance with max character length.


mysql-test/r/loaddata.result:
  test case
mysql-test/t/loaddata.test:
  test case
sql/sql_load.cc:
  allocate stack buffer in compliance with max character length.
2011-04-15 12:51:34 +04:00
08bf3ddde9 Fix for Bug#11765141 - "58072: LOAD DATA INFILE: LEAKS IO CACHE MEMORY WHEN ERROR OCCURS" 2011-04-07 15:09:19 +02:00
12a6e0d90e Bug#11765139 58069: LOAD DATA INFILE: VALGRIND REPORTS INVALID MEMORY READS AND WRITES WITH U
Some multibyte sequences could be considered by my_mbcharlen() functions
as multibyte character but more exact my_ismbchar() does not think so.
In such a case this multibyte sequences is pushed into 'stack' buffer which
is too small to accommodate the sequence.
The fix is to allocate stack buffer in
compliance with max character length.
2011-04-15 12:51:34 +04:00
acabfc75f5 merge from 5.1 2011-04-26 11:52:58 +02:00
98d524599a 5.1 -> 5.5 merge 2011-04-15 12:55:21 +04:00
52d51b75e8 merge from 5.1 2011-04-26 11:52:58 +02:00
df28a9d804 5.1 -> 5.5 merge 2011-04-15 12:55:21 +04:00
65ca700def merge.
checkpoint.
does not compile.
2010-11-25 18:17:28 +01:00
401c69e49b Fixed test failure
mysql-test/t/loaddata.test:
  Don't run test if ucs2 is not compiled
2010-08-30 16:25:23 +03:00
11b6ff0f67 merge 2010-07-14 15:05:20 +03:00
a1414d519f merge 2010-07-14 15:05:20 +03:00
dbb643d64e Bug #51876: crash/memory underrun when loading data with ucs2
and reverse() function
      
3 problems fixed : 
1. The reported problem : caused by incorrect parsing of 
the file as ucs data resulting in wrong length of the parsed
string. Fixed by truncating the invalid trailing bytes 
(non-complete multibyte characters) when reading from the file
2. LOAD DATA when reading from a proper UCS2 file wasn't 
recognizing the new line characters. Fixed by first looking 
if a byte is a new line (or any other special) character before
reading it as a part of a multibyte character.
3. When using user variables to hold the column data in LOAD
DATA the character set of the user variable was set incorrectly
to the database charset. Fixed by setting it to the charset
specified by LOAD DATA (if any).
2010-07-14 14:54:51 +03:00
b4766fc36a Bug #51876: crash/memory underrun when loading data with ucs2
and reverse() function
      
3 problems fixed : 
1. The reported problem : caused by incorrect parsing of 
the file as ucs data resulting in wrong length of the parsed
string. Fixed by truncating the invalid trailing bytes 
(non-complete multibyte characters) when reading from the file
2. LOAD DATA when reading from a proper UCS2 file wasn't 
recognizing the new line characters. Fixed by first looking 
if a byte is a new line (or any other special) character before
reading it as a part of a multibyte character.
3. When using user variables to hold the column data in LOAD
DATA the character set of the user variable was set incorrectly
to the database charset. Fixed by setting it to the charset
specified by LOAD DATA (if any).
2010-07-14 14:54:51 +03:00
344127f371 merge 2010-06-09 11:41:24 +03:00
fdbef84347 merge 2010-06-09 11:41:24 +03:00
04f4786c08 Merge 2010-06-09 11:29:27 +03:00
5932330839 Merge 2010-06-09 11:29:27 +03:00
a08c47a3ac A follow-up for Bug#50373: remove a commented-out part of the loaddata.test. 2010-05-12 15:13:47 +04:00
a68a68bf45 A follow-up for Bug#50373: remove a commented-out part of the loaddata.test. 2010-05-12 15:13:47 +04:00
5dd5d70506 Bug#50373 --secure-file-priv=""
Iterative patch improvement. Previously committed patch
caused wrong result on Windows. The previous patch also
broke secure_file_priv for symlinks since not all file
paths which must be compared against this variable are
normalized using the same norm.

The server variable opt_secure_file_priv wasn't
normalized properly and caused the operations
LOAD DATA INFILE .. INTO TABLE ..
and
SELECT load_file(..)
to do different interpretations of the 
--secure-file-priv option.
     
The patch moves code to the server initialization
routines so that the path always is normalized
once and only once.
      
It was also intended that setting the option
to an empty string should be equal to 
lifting all previously set restrictions. This
is also fixed by this patch.


mysql-test/r/loaddata.result:
  * Removed test code which will currently break the much used --mem feature of mtr.
mysql-test/t/loaddata.test:
  * Removed test code which will currently break the much used --mem feature of mtr.
sql/item_strfunc.cc:
  * Replaced string comparing code on opt_secure_file_priv with an interface which guarantees that both file paths are normalized using the same norm on all platforms.
sql/mysql_priv.h:
  * Added signature for is_secure_file_path()
sql/mysqld.cc:
  * New function for checking if a path compatible with the secure path restriction.
  * Added initialization of the opt_secure_file_priv variable.
sql/sql_class.cc:
  * Replaced string comparing code on opt_secure_file_priv with an interface which guarantees that both file paths are normalized using the same norm on all platforms.
sql/sql_load.cc:
  * Replaced string comparing code on opt_secure_file_priv with an interface which guarantees that both file paths are normalized using the same norm on all platforms.
2010-05-03 18:14:39 +02:00
5b6ebdf086 Bug#50373 --secure-file-priv=""
Iterative patch improvement. Previously committed patch
caused wrong result on Windows. The previous patch also
broke secure_file_priv for symlinks since not all file
paths which must be compared against this variable are
normalized using the same norm.

The server variable opt_secure_file_priv wasn't
normalized properly and caused the operations
LOAD DATA INFILE .. INTO TABLE ..
and
SELECT load_file(..)
to do different interpretations of the 
--secure-file-priv option.
     
The patch moves code to the server initialization
routines so that the path always is normalized
once and only once.
      
It was also intended that setting the option
to an empty string should be equal to 
lifting all previously set restrictions. This
is also fixed by this patch.
2010-05-03 18:14:39 +02:00
287fa3caf5 Bug #52512: Assertion `! is_set()' in Diagnostics_area::set_ok_status
on LOAD DATA

Two problems :
1. LOAD DATA was not checking for SQL errors and was sending an OK
packet even when there were errors reported already. Fixed to check for
SQL errors in addition to the error conditions already detected.
2. There was an over-ambitious assert() on the server to check if the 
protocol is always followed by the client. This can cause crashes on 
debug servers by clients not completing the protocol exchange for some
reason (e.g. --send command in mysqltest). Fixed by keeping the assert
only on client side, since the server always completes the protocol 
exchange.
2010-04-07 18:17:56 +03:00
257363e6c4 Bug #52512: Assertion `! is_set()' in Diagnostics_area::set_ok_status
on LOAD DATA

Two problems :
1. LOAD DATA was not checking for SQL errors and was sending an OK
packet even when there were errors reported already. Fixed to check for
SQL errors in addition to the error conditions already detected.
2. There was an over-ambitious assert() on the server to check if the 
protocol is always followed by the client. This can cause crashes on 
debug servers by clients not completing the protocol exchange for some
reason (e.g. --send command in mysqltest). Fixed by keeping the assert
only on client side, since the server always completes the protocol 
exchange.
2010-04-07 18:17:56 +03:00
d4d5df0a3e merge 2010-03-30 15:10:25 +03:00
89989ffb16 Bug #51893: crash with certain characters given to load_file
function on windows
               
When making sure that the directory path ends up with a 
slash/backslash we need to check for the correct length of 
the buffer and trim at the appropriate location so we don't
write past the end of the buffer.
2010-03-30 15:03:50 +03:00
e32e9cdc66 merge 2010-03-30 15:10:25 +03:00
2d035bf78d Bug #51893: crash with certain characters given to load_file
function on windows
               
When making sure that the directory path ends up with a 
slash/backslash we need to check for the correct length of 
the buffer and trim at the appropriate location so we don't
write past the end of the buffer.
2010-03-30 15:03:50 +03:00
5167451a92 Bug #51893: crash with certain characters given to load_file
function on windows

When making sure that the directory path ends up with a 
slash/backslash we need to check for the correct length of 
the buffer and trim at the appropriate location so we don't
write past the end of the buffer.
2010-03-23 16:54:16 +02:00
a9a2ceae1f Bug #51850: crash/memory overlap when using load data infile and set
col equal to itself!

There's no need to copy the value of a field into itself.
While generally harmless (except for some performance penalties)
it may be dangerous when the copy code doesn't expect this.
Fixed by checking if the source field is the same as the destination
field before copying the data.
Note that we must preserve the order of assignment of the null 
flags (hence the null_value assignment addition).
2010-03-23 17:07:00 +02:00
d95bed0215 Bug #51893: crash with certain characters given to load_file
function on windows

When making sure that the directory path ends up with a 
slash/backslash we need to check for the correct length of 
the buffer and trim at the appropriate location so we don't
write past the end of the buffer.
2010-03-23 16:54:16 +02:00
d9175c2147 Bug #51850: crash/memory overlap when using load data infile and set
col equal to itself!

There's no need to copy the value of a field into itself.
While generally harmless (except for some performance penalties)
it may be dangerous when the copy code doesn't expect this.
Fixed by checking if the source field is the same as the destination
field before copying the data.
Note that we must preserve the order of assignment of the null 
flags (hence the null_value assignment addition).
2010-03-23 17:07:00 +02:00
32c161f3ea Merging 5.1 main into 5.1-rpl 2008-10-23 21:27:09 +02:00
1f29c52581 Merging 5.1 main into 5.1-rpl 2008-10-23 21:27:09 +02:00
7a40f2610e manual merge 2008-09-18 11:32:54 +02:00
4661508601 manual merge 2008-09-18 11:32:54 +02:00