1. 23 Apr, 2014 2 commits
    • Tor Didriksen's avatar
      Backport from trunk: · c006e3f2
      Tor Didriksen authored
        Bug#18396916 MAIN.OUTFILE_LOADDATA TEST FAILS ON ARM, AARCH64, PPC/PPC64
        
        The recorded results for the failing tests were wrong.
        They were introduced by the patch for
        Bug#30946 mysqldump silently ignores --default-character-set when used with --tab
        
        Correct results were returned for platforms where 'char' is implemented as unsigned.
        This was reported as 
        Bug#46895 Test "outfile_loaddata" fails (reproducible)
        Bug#11755168 46895: TEST "OUTFILE_LOADDATA" FAILS (REPRODUCIBLE)
        The patch for that bug fixed only parts of the problem,
        leaving the incorrect results in the .result file.
        
        Solution: use 'uchar' for field_terminator and line_terminator on all platforms.
        Also: remove some un-necessary casts, leaving the ones we actually need.
      c006e3f2
    • Igor Solodovnikov's avatar
      Bug #17514920 MYSQL_THREAD_INIT() CALL WITHOUT MYSQL_INIT() IS CRASHING IN WINDOWS · b264c3e1
      Igor Solodovnikov authored
      It is error to call mysql_thread_init() before libmysql is initialized with mysql_library_init(). Thus to fix this bug we need to detect if library was initialized and return error result if mysql_thread_init() is called with uninitialized library.
      
      Fixed by checking my_thread_global_init_done and returning nonzero if the library is not initialized.
      b264c3e1
  2. 17 Apr, 2014 1 commit
  3. 15 Apr, 2014 1 commit
    • Sujatha Sivakumar's avatar
      Bug#17942050:KILL OF TRUNCATE TABLE WILL LEAD TO BINARY LOG · 58b98078
      Sujatha Sivakumar authored
      WRITTEN WHILE ROWS REMAINS
      
      Problem:
      ========
      When truncate table fails while using transactional based
      engines even though the operation errors out we still
      continue and log it to binlog. Because of this master has
      data but the truncate will be written to binary log which
      will cause inconsistency.
      
      Analysis:
      ========
      Truncate table can happen either through drop and create of
      table or by deleting rows. In the second case the existing
      code is written in such a way that even if an error occurs
      the truncate statement will always be binlogged. Which is not
      correct.
      
      Binlogging of TRUNCATE TABLE statement should check whether
      truncate is executed "transactionally or not". If the table
      is transaction based we log the TRUNCATE TABLE only on
      successful completion.
      
      If table is non transactional there are possibilities that on
      error we could have partial changes done hence in such cases
      we do log in spite of errors as some of the lines might have
      been removed, so the statement has to be sent to slave.
      
      Fix:
      ===
      Using table handler whether truncate table is being executed
      in transaction based mode or not is identified and statement
      is binlogged accordingly.
      58b98078
  4. 11 Apr, 2014 1 commit
  5. 10 Apr, 2014 2 commits
    • Georgi Kodinov's avatar
      Bug #18359924: INNODB AND MYISAM CORRUPTION ON PREFIX INDEXES · 29694eeb
      Georgi Kodinov authored
      The problem was in the validation of the input data for blob types.
      When assigned binary data, the character blob types were only checking if 
      the length of these data is a multiple of the minimum char length for the 
      destination charset. 
      And since e.g. UTF-8's minimum character length is 1 (becuase it's 
      variable length) even byte sequences that are invalid utf-8 strings (e.g. 
      wrong leading byte etc) were copied verbatim into utf-8 columns when
      coming from binary strings or fields.
      Storing invalid data into string columns was having all kinds of ill effects 
      on code that assumed that the encoding data are valid to begin with.
      
      Fixed by additionally checking the incoming binary string for validity when 
      assigning it to a non-binary string column.
      Made sure the conversions to charsets with no known "invalid" ranges 
      are not covered by the extra check.
      Removed trailing spaces.
      
      Test case added.
      29694eeb
    • Arun Kuruvila's avatar
      Description: When we execute a correlated subquery on an · e12156e7
      Arun Kuruvila authored
      archive table which is using an auto increment column, the
      server hangs. In order to recover the mysqld process, it
      has to be terminated abnormally using SIGKILL. The problem
      is observed in mysql-5.5.
      Bug #18065452 "PREPARING" STATE HOGS CPU WITH ARCHIVE
                     + SUBQUERY
      
      Analysis: This happens because the server is trapped inside
      an infinite loop in the function,
      "subselect_indexsubquery_engine::exec()". This function
      resolves the correlated suquery by doing an index lookup
      for the appropriate engine. In  case of archive engine,
      after reaching the end of records, "table->status" is not
      set to STATUS_NOT_FOUND. As a result the loop is not 
      terminated.
      
      Fix: The "table->status" is set to STATUS_NOT_FOUND when
      the end of records is reached.
      e12156e7
  6. 04 Apr, 2014 1 commit
  7. 01 Apr, 2014 2 commits
  8. 27 Mar, 2014 1 commit
  9. 19 Mar, 2014 1 commit
    • Praveenkumar Hulakund's avatar
      Bug#11759519 - INFINITE HANG WITH 100% CPU USAGE WITH LOAD DATA · e73df7d9
      Praveenkumar Hulakund authored
                     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".
      e73df7d9
  10. 17 Mar, 2014 1 commit
    • Marc Alff's avatar
      Bug#18319790 QUERY TO INFORMATION_SCHEMA CRASHES SERVER · 659bee49
      Marc Alff authored
      Before this fix, specially crafted queries
      using the INFORMATION_SCHEMA could crash the server.
      
      The root cause was a buffer overflow,
      see the (private) bug comments for details.
      
      With this fix, the buffer overflow condition is properly handled,
      and the queries involved do return the expected result.
      659bee49
  11. 14 Mar, 2014 1 commit
  12. 12 Mar, 2014 1 commit
  13. 06 Mar, 2014 2 commits
  14. 05 Mar, 2014 1 commit
    • Tor Didriksen's avatar
      Backport of: · 1a8ae4d7
      Tor Didriksen authored
        Bug#17894997 CMAKE WARNING WRT INTERFACE_LINK_LIBRARIES
        Bug#17905155 CMAKE WARNING WHEN GENERATING MAKEFILE
        Bug#71089 CMake warning when generating Makefile
      
      Use old policy for LINK_INTERFACE_LIBRARIES.
      1a8ae4d7
  15. 04 Mar, 2014 3 commits
  16. 03 Mar, 2014 1 commit
  17. 28 Feb, 2014 1 commit
  18. 25 Feb, 2014 2 commits
  19. 17 Feb, 2014 2 commits
  20. 12 Feb, 2014 2 commits
    • Vamsikrishna Bhagi's avatar
      Bug #18186103 BUFFER OVERFLOW IN CLIENT · c187840b
      Vamsikrishna Bhagi authored
      Problem: While printing the Server version, mysql client
               doesn't check for the buffer overflow in a
               String variable.
      
      Solution: Used a different print function which checks the
                allocated length before writing into the string.
      c187840b
    • Neeraj Bisht's avatar
      Bug#17075846 - UNQUOTED FILE NAMES FOR VARIABLE VALUES ARE · a3123b84
      Neeraj Bisht authored
      	       ACCEPTED BUT PARSED INCORRECTLY
      
      When we are setting the value in a system variable, 
      We can set it like 
      
      set sys_var="Iden1.Iden2";		//1
      set sys_var='Iden1.Iden2';		//2
      set sys_var=Iden1.Iden2;		//3
      set sys_var=.ident1.ident2; 		//4
      set sys_var=`Iden1.Iden2`;		//5
      
      
      While parsing, for case 1(when ANSI_QUOTES is enable) and 2,
      we will take as string literal(we will make item of type Item_string).
      for case 3 & 4, taken as Item_field, where Iden1 is a table name and
      iden2 is a field name.
      for case 5, again Item_field type, where iden1.iden2 is taken as
      field name.
      
      
      Now in case 1, when we are assigning some value to system variable
      (which can take string or enumerate type data), we are setting only 
      field part.
      This means only iden2 value will be set for system variable. This 
      result in wrong result.
      
      Solution:
      
      (for string type) We need to Document that we are not allowed to set 
      system variable which takes string as identifier, otherwise result 
      in unexpected behaviour.
      
      (for enumerate type)
      if we pass iden1.iden2, we will give an error ER_WRONG_TYPE_FOR_VAR
      (Incorrect argument type to variable).
      a3123b84
  21. 11 Feb, 2014 3 commits
  22. 10 Feb, 2014 1 commit
    • Thirunarayanan B's avatar
      Bug #14049391 INNODB MISCALCULATES AUTO-INCREMENT AFTER DECREASING · 7c12a9e5
      Thirunarayanan B authored
                              AUTO_INCREMENT_INCREMENT
      Problem:
      =======
      When auto_increment_increment system variable decreases,
      immediate next value of auto increment column is not affected.
      
      Solution:
      ========
      	Get the previous inserted value of auto increment column by
      subtracting the previous auto_increment_increment from next
      auto increment value. After that calculate the current autoinc value
      using newly changed auto_increment_increment variable.
      
      	Approved by Sunny [rb#4394]
      7c12a9e5
  23. 06 Feb, 2014 2 commits
    • Murthy Narkedimilli's avatar
    • Anirudh Mangipudi's avatar
      Bug#14211271 ISSUES WITH SSL ON DEBIAN WHEEZY I386 AND KFREEBSD-I386 · 1747a456
      Anirudh Mangipudi authored
      Problem:
      It was reported that on Debian and KFreeBSD platforms, i386 architecture 
      machines certain SSL tests are failing. main.ssl_connect  rpl.rpl_heartbeat_ssl
      rpl.rpl_ssl1 rpl.rpl_ssl main.ssl_cipher, main.func_encrypt were the tests that
       were reportedly failing (crashing). The reason for the crashes are said to be
      due to the assembly code of yaSSL.
      
      Solution:
      There was initially a workaround suggested i.e., to enable 
      -DTAOCRYPT_DISABLE_X86ASM flag which would prevent the crash, but at an expense
       of 4X reduction of speed. Since this was unacceptable, the fix was the 
      functions using assembly, now input variables from the function call using 
      extended inline assembly on GCC instead of relying on direct assembly code.
      1747a456
  24. 04 Feb, 2014 2 commits
  25. 03 Feb, 2014 1 commit
  26. 31 Jan, 2014 2 commits
    • 's avatar
      Merge from mysql-5.5.36-release · 1db027f3
      authored
      1db027f3
    • Praveenkumar Hulakund's avatar
      Bug#14117012 - CHILD PROCESS MYSQL UTILITIES PICKING UP LOCAL · ff4040ee
      Praveenkumar Hulakund authored
                     CONFIG FILES CAUSES TEST
      
      Utility as "mysql_upgrade" forks "mysql"/"mysqlcheck". Attaching
      "mysql_upgrade" shows following calls after forking "mysql" or
      "mysql_check" when configuration file information is passed as
      first argument to "mysql_upgrade".
      
      strace -f ./mysql_upgrade --defaults-file=../pdb/my.cnf --socket=../pdb/mysql.sock -f
      
      [pid  6254] stat("/etc/my.cnf", 0x7fff8e772680) = -1 ENOENT (No such file or directory)
      [pid  6254] stat("/etc/mysql/my.cnf", 0x7fff8e772680) = -1 ENOENT (No such file or directory)
      [pid  6254] stat("/usr/local/mysql/etc/my.cnf", 0x7fff8e772680) = -1 ENOENT (No such file or directory)
      [pid  6254] stat("/home/user_name/.my.cnf", {st_mode=S_IFREG|0664, st_size=19, ...}) = 0
      [pid  6254] open("/home/user_name/.my.cnf", O_RDONLY) = 3
      
      
      But when tool forks "mysqlcheck"/"mysql", "--no-defaults" is passed
      as first argument. Before forking, in function "find_tool" of
      "mysql_upgrade", check is made to verify whether tool can be
      executable or not by calling "mysqlcheck --help" and "mysql --help".
      But argument "--no-defaults", "--defaults-file" or
      "defaults-extra-file" is not passed to "mysql" and "mysqlcheck".
      So my.cnf is searched in default paths.
      
      Fix:
      ------
      Modified code to pass "--no-defaults" as first argument to "mysql"
      and "mysqlcheck" while checking tool can be executed or not.
      ff4040ee