1. 18 Jan, 2011 1 commit
  2. 13 Jan, 2011 5 commits
    • Luis Soares's avatar
      6246d224
    • Nirbhay Choubey's avatar
      Bug#59109 : mysqlslap crashes on mysql_fetch_row after ignoring · a0f62be6
      Nirbhay Choubey authored
                  null from mysql_store_result.
      
      mysqlslap segfaults at a point when it tries to fetch rows from
      the result set.
      
      Under some circumstances, mysql_store_result can return 'NULL',
      even after query execution (mysql_query) succeeds, and eventually
      a segfault might occur if same unchecked return value is passed
      to mysql_fetch_row.
      
      Fixed by adding a check on mysql_store_result's return value.
      
      
      client/mysqlslap.c:
        Bug#59109 : mysqlslap crashes on mysql_fetch_row after ignoring
                    null from mysql_store_result.
        
        Added a check on mysql_store_result's return value. A 'NULL' return
        value here shows an erroneous situation as mysql_field_count has already
        reported a non-zero value.
      a0f62be6
    • Georgi Kodinov's avatar
      bumped up the version to 5.1.56 · eba42c14
      Georgi Kodinov authored
      eba42c14
    • Georgi Kodinov's avatar
      bumped up the version to 5.0.93 · 85943d75
      Georgi Kodinov authored
      85943d75
    • Martin Hansson's avatar
      Bug#58165: "my_empty_string" gets modified and causes LOAD DATA to fail and · 6ed5b556
      Martin Hansson authored
      other crashes
      
      Some string manipulating SQL functions use a shared string object intended to
      contain an immutable empty string. This object was used by the SQL function
      SUBSTRING_INDEX() to return an empty string when one argument was of the wrong
      datatype. If the string object was then modified by the sql function INSERT(),
      undefined behavior ensued.
      
      Fixed by instead modifying the string object representing the function's
      result value whenever string manipulating SQL functions return an empty
      string.
      
      Relevant code has also been documented.
      6ed5b556
  3. 12 Jan, 2011 6 commits
    • Bjorn Munch's avatar
      merge from 5.1-mtr · 7def3081
      Bjorn Munch authored
      7def3081
    • Luis Soares's avatar
      BUG#59177: mysqlbinlog_row_big fails on Windows with out of memory · 86f4bcd4
      Luis Soares authored
            
      The test case fails with out of memory while updating a table
      with several multi-megabytes sized rows. This can probably be too
      exhausting for PB2 env.
            
      The quick fix here is to reduce the size of the biggest
      row (256MB) so that it becomes a little smaller (64MB).
      86f4bcd4
    • Bjorn Munch's avatar
      merge from 5.1 · c144d37f
      Bjorn Munch authored
      c144d37f
    • Dmitry Lenev's avatar
      Fix for bug #58499 "DEFINER-security view selecting from · d4c75324
      Dmitry Lenev authored
      INVOKER-security view access check wrong".
      
      When privilege checks were done for tables used from an 
      INVOKER-security view which in its turn was used from 
      a DEFINER-security view connection's active security
      context was incorrectly used instead of security context
      with privileges of the second view's creator.
      
      This meant that users which had enough rights to access
      the DEFINER-security view and as result were supposed to 
      be able successfully access it were unable to do so in 
      cases when they didn't have privileges on underlying tables 
      of the INVOKER-security view.
      
      This problem was caused by the fact that for INVOKER-security
      views TABLE_LIST::security_ctx member for underlying tables
      were set to 0 even in cases when particular view was used from 
      another DEFINER-security view. This meant that when checks of
      privileges on these underlying tables was done in
      setup_tables_and_check_access() active connection security 
      context was used instead of context corresponding to the 
      creator of caller view.
      
      This fix addresses the problem by ensuring that underlying
      tables of an INVOKER-security view inherit security context
      from the view and thus correct security context is used for
      privilege checks on underlying tables in cases when such view 
      is used from another view with DEFINER-security.
      
      mysql-test/r/view_grant.result:
        Added coverage for various combinations of DEFINER and
        INVOKER-security views, including test for bug #58499
        "DEFINER-security view selecting from INVOKER-security
        view access check wrong".
      mysql-test/t/view_grant.test:
        Added coverage for various combinations of DEFINER and
        INVOKER-security views, including test for bug #58499
        "DEFINER-security view selecting from INVOKER-security
        view access check wrong".
      sql/sql_view.cc:
        When opening a non-suid view ensure that its underlying 
        tables will get the same security context as use for
        checking privileges on the view, i.e. security context
        of view invoker. This context can be different from the
        security context which is currently active for connection 
        in cases when this non-suid view is used from a view with
        suid security. Inheriting security context in such situation
        allows correctly apply privileges of creator of suid view
        in checks for tables of non-suid view (since in this 
        situation creator/definer of suid view serves as invoker
        for non-suid view).
      d4c75324
    • Alexey Botchkov's avatar
      Bug #57321 crashes and valgrind errors from spatial types · 8b5db960
      Alexey Botchkov authored
              Item_func_spatial_collection::fix_length_and_dec didn't call parent's method, so
              the maybe_null was set to '0' after it. But in this case the result was
              just NULL, that caused wrong behaviour.
      
      per-file comments:
        mysql-test/r/gis.result
      Bug #57321 crashes and valgrind errors from spatial types 
              test result updated.
      
        mysql-test/t/gis.test
      Bug #57321 crashes and valgrind errors from spatial types 
              test case added.
        sql/item_geofunc.h
      Bug #57321 crashes and valgrind errors from spatial types 
              Item_func_geometry::fix_length_and_dec() called in
              Item_func_spatial_collection::fix_length_and_dec().
      8b5db960
    • Martin Hansson's avatar
      Bug#58207: invalid memory reads when using default column value and · 73d88e80
      Martin Hansson authored
      tmptable needed
      
      The function DEFAULT() works by modifying the the data buffer pointers (often
      referred to as 'record' or 'table record') of its argument. This modification
      is done during name resolution (fix_fields().) Unfortunately, the same
      modification is done when creating a temporary table, because default values
      need to propagate to the new table.
      
      Fixed by skipping the pointer modification for fields that are arguments to
      the DEFAULT function.
      73d88e80
  4. 11 Jan, 2011 7 commits
  5. 10 Jan, 2011 3 commits
  6. 08 Jan, 2011 2 commits
  7. 07 Jan, 2011 6 commits
  8. 06 Jan, 2011 3 commits
  9. 05 Jan, 2011 4 commits
  10. 04 Jan, 2011 3 commits
    • unknown's avatar
      43818 - Patch for mysql-5.1-innodb · 4aef2023
      unknown authored
      Avoid handler::info() call for three Information Schema tables;
      TABLE_CONSTRAINTS, KEY_COLUMN_USAGE, & REFERENTIAL_CONTRAINTS
      4aef2023
    • Jon Olav Hauglid's avatar
      Bug #50619 assert in handler::update_auto_increment · 2bbc6f38
      Jon Olav Hauglid authored
      This assert could be triggered if -1 was inserted into
      an auto increment column by a statement writing more than
      one row.
      
      Unless explicitly given, an interval of auto increment values
      is generated when a statement first needs an auto increment
      value. The triggered assert checks that the auto increment
      counter is equal to or higher than the lower bound of this
      interval.
      
      Generally, the auto increment counter starts at 1 and is
      incremented by 1 each time it is used. However, inserting an
      explicit value into the auto increment column, sets the auto
      increment counter to this value + 1 if this value is higher
      than the current value of the auto increment counter.
      
      This bug was triggered if the explicit value was -1. Since the
      value was converted to unsigned before any comparisons were made,
      it was found to be higher than the current vale of the auto
      increment counter and the counter was set to -1 + 1. This value
      was below the reserved interval and caused the assert to be
      triggered the next time the statement tried to write a row.
      
      With the patch for Bug#39828, this bug is no longer repeatable.
      Now, -1 + 1 is detected as an "overflow" which causes the auto
      increment counter to be set to ULONGLONG_MAX. This avoids hitting
      the assert for the next insert and causes a new interval of
      auto increment values to be generated. This resolves the issue.
      
      This patch therefore only contains a regression test and no code
      changes. Test case added to auto_increment.test.
      2bbc6f38
    • Mattias Jonsson's avatar
      merge · 2eba1e8b
      Mattias Jonsson authored
      2eba1e8b