1. 10 Jan, 2013 5 commits
    • Venkata Sidagam's avatar
      Bug #14553380 MYSQL C API LIBRARY EXITS AT NET_CLEAR AT NET_SERV.CC:223 · 3fa76fd0
      Venkata Sidagam authored
      Problem description: When client loses the connection to the MySQL server or 
      if the server gets shutdown after mysql_stmt_prepare() then the next 
      mysql_stmt_prepare() will return an error(as expected) but consecutive call 
      mysql_stmt_execute(), will crash the client program. 
      The expected behavior would be, it should through an error.
      
      Analysis: The mysql_stmt_prepare() interns calls the function end_server() 
      and net->vio and net->buff are freed and set to NULL. Then the next call 
      mysql_stmt_execute() will interns call net_clear() where we are "net->vio" 
      with out validating it.
      
      Fix: we are validating the net->vio, before calling net_clear().
      3fa76fd0
    • Praveenkumar Hulakund's avatar
      Merge from 5.1 to 5.5 · 6988c9cc
      Praveenkumar Hulakund authored
      6988c9cc
    • Praveenkumar Hulakund's avatar
      Bug#11749556: DEBUG ASSERTION WHEN ACCESSING A VIEW AND · 5e399d1c
      Praveenkumar Hulakund authored
                    AVAILABLE MEMORY IS TOO LOW 
      
      Analysis:
      ---------
      In function "mysql_make_view", "table->view" is initialized
      after parsing(using File_parser::parse) the view definition.
      If "::parse" function fails then control is moved to label 
      "err:". Here we have assert (table->view == thd->lex). 
      This assert fails if "::parse" function fails, as 
      table->view is not initialized yet.
      
      File_parser::parse fails if data being parsed is incorrect/
      corrupted or when memory allocation fails. In this scenario
      its failing because of failure in memory allocation.
      
      Fix:
      ---------
      In case of failure in function "File_parser::parse", moving
      to label "err:" is incorrect. Modified code to move
      to label "end:".
      5e399d1c
    • Annamalai Gurusami's avatar
      Bug #16004999 ASSERT STATE == TRX_STATE_NOT_STARTED, UNLOCK_ROW() · 9a0f3d3d
      Annamalai Gurusami authored
      Problem:
      
      During the index intersect access method, the SQL layer will access one row,
      that satisfies a set of conditions, using an index i1.  And then it will try to
      access the same row, with other set of conditions using the next index i2.  If
      the fetch from i2 fails (we are talking about an error situation here and not
      simply an unmatched row situation), then it will unlock the row accessed via
      i1.  This will work in all situations except deadlock error.
      
      When a deadlock happens, InnoDB will rollback the transaction.  InnoDB intimates
      the SQL layer about this through the THD::transaction_rollback_request member.
      But this is not currently used by the SQL layer.
      
      Solution:
      
      When an error happens, the SQL layer must check the 
      THD::transaction_rollback_request member, before calling handler::unlock_row().
      We have also added a debug assert in ha_innobase::unlock_row() checking that
      it must be called only when the transaction is in active state.
      
      rb#1773 approved by Marko and Sunny.
      9a0f3d3d
    • prabakaran thirumalai's avatar
      Bug#16064876 MAIN.KILL FAILS OCCASIONALLY ON SOL10 SPARC64 · f112ae8e
      prabakaran thirumalai authored
      Analysis:
      On solaris, killing a connection which waits on debug sync
      (waits on condition variable) is neglected. Subsequent kill
      connection to that thread succeeds. Debug sync code is not
      included in release build hence it is not an customer issue.
      Also verified that except this case, other cases succeed in
      main.kill test script. So moving this test to experimental
      state on solaris platform only in mysql-5.5 branch.
      f112ae8e
  2. 09 Jan, 2013 2 commits
  3. 08 Jan, 2013 3 commits
  4. 07 Jan, 2013 4 commits
  5. 04 Jan, 2013 5 commits
  6. 03 Jan, 2013 1 commit
  7. 02 Jan, 2013 4 commits
    • Venkatesh Duggirala's avatar
      BUG#11753923-SQL THREAD CRASHES ON DISK FULL · ce7e7a99
      Venkatesh Duggirala authored
      Merging fix from mysql-5.1
      ce7e7a99
    • Venkatesh Duggirala's avatar
      BUG#11753923-SQL THREAD CRASHES ON DISK FULL · 39323920
      Venkatesh Duggirala authored
      Problem:If Disk becomes full while writing into the binlog,
      then the server instance hangs till someone frees the space.
      After user frees up the disk space, mysql server crashes
      with an assert (m_status != DA_EMPTY)
      
      Analysis: wait_for_free_space is being called in an
      infinite loop i.e., server instance will hang until
      someone frees up the space. So there is no need to
      set status bit in diagnostic area.
      
      Fix: Replace my_error/my_printf_error with
      sql_print_warning() which prints the warning in error log.
      
      include/my_sys.h:
        Provision to call sql_print_warning from mysys files
      mysys/errors.c:
        Replace my_error/my_printf_error with
        sql_print_warning() which prints the warning in error log.
      mysys/my_error.c:
        implementation of my_printf_warning
      mysys/my_write.c:
        Adding logic to break infinite loop in the simulation
      sql/mysqld.cc:
        Provision to call sql_print_warning from mysys files
      39323920
    • Marc Alff's avatar
      Bug#16060864 SEGMENTATION FAULT IN PERFORMANCE_SCHEMA WITH HISTORY SIZE 0 · cc2df006
      Marc Alff authored
      Before this fix, configuring the server with:
      - performance_schema_events_waits_history_size=0
      - performance_schema_events_waits_history_long_size=0
      could cause a crash in the performance schema.
      
      These settings to 0 are intended to be valid and supported,
      and are in fact working properly in mysql 5.6 and up already.
      
      This fix backports the code fix and test cases from mysql 5.6
      to the mysql 5.5 release.
      cc2df006
    • Kent Boortz's avatar
      5ff0148e
  8. 01 Jan, 2013 2 commits
  9. 29 Dec, 2012 2 commits
  10. 28 Dec, 2012 2 commits
  11. 27 Dec, 2012 4 commits
  12. 26 Dec, 2012 4 commits
  13. 24 Dec, 2012 2 commits