1. 01 Dec, 2008 1 commit
    • unknown's avatar
      Do not use MY_WME in the stat call which errors we process on high level. · 2b511502
      unknown authored
      (BUG#41127: Maria: assertion when SHOW ENGINE MARIA LOGS and missing logs)
      
      mysql-test/suite/maria/r/maria_showlog_error.result:
        test suite for the BUG#41127
      mysql-test/suite/maria/t/maria_showlog_error.test:
        test suite for the BUG#41127
      storage/maria/ha_maria.cc:
        Do not use MY_WME in the stat call which errors we process on high level.
      2b511502
  2. 28 Nov, 2008 1 commit
    • Sergei Golubchik's avatar
      Bug#34374: mysql generates incorrect warning · f1906c62
      Sergei Golubchik authored
      an item was evaluated unnecessary, fix that by checking preconditions before evaluating the item
      
      sql/sql_select.cc:
        an item was evaluated unnecessary, fix that by checking preconditions before evaluating the item
      f1906c62
  3. 27 Nov, 2008 1 commit
    • Guilhem Bichot's avatar
      Fix for BUG#40661 "Maria: crash in embedded server (when detecting deadlock?)" · 255f8feb
      Guilhem Bichot authored
      bug is actually a weirdness in test system, so moving test portion into maria_notembedded.test
      
      mysql-test/suite/maria/r/maria.result:
        result update
      mysql-test/suite/maria/r/maria_notembedded.result:
        result update
      mysql-test/suite/maria/t/maria.test:
            Removing test portion into maria_notembedded.test. Explanation below.
            Running maria.test with --mem --embedded --valgrind I got:
            ==378== Invalid read of size 4
            ==378==    at 0x857C755: _lf_pinbox_real_free (lf_alloc-pin.c:342)
            ==378==    by 0x857C640: _lf_pinbox_free (lf_alloc-pin.c:267)
            ==378==    by 0x857D50C: ldelete (lf_hash.c:226)
            ==378==    by 0x857DBC1: lf_hash_delete (lf_hash.c:429)
            ==378==    by 0x8243D82: unlock_lock_and_free_resource
            (waiting_threads.c:676)
            ==378==    by 0x8244A79: wt_thd_release (waiting_threads.c:948)
            ==378==    by 0x83F301D: wt_thd_release_self (trnman.c:98)
            ==378==    by 0x83F3D49: trnman_end_trn (trnman.c:431)
            ==378==    by 0x837C437: ma_commit (ma_commit.c:60)
            ==378==    by 0x835F082: ha_maria::external_lock(THD*, int)
            (ha_maria.cc:2387)
            ==378==    by 0x84D1011: handler::ha_external_lock(THD*, int)
            (handler.cc:4433)
            ==378==    by 0x856DA92: unlock_external(THD*, st_table**, unsigned)
            (lock.cc:786)
            ==378==    by 0x856DD6F: mysql_unlock_tables(THD*, st_mysql_lock*)
            (lock.cc:389)
            ==378==    by 0x8274A57: close_thread_tables(THD*) (sql_base.cc:1307)
            ==378==    by 0x82ABEC3: unlock_locked_tables(THD*) (sql_parse.cc:99)
            ==378==    by 0x82B0BB3: mysql_execute_command(THD*)
            (sql_parse.cc:3372)
            ==378==  Address 0x5894a0c is 164 bytes inside a block of size 184
            free'd
            ==378==    at 0x40233FC: free (vg_replace_malloc.c:323)
            ==378==    by 0x823CF92: my_thread_end (my_thr_init.c:348)
            ==378==    by 0x8200FEE: mysql_thread_end (libmysql.c:250)
            ==378==    by 0x81A9487: send_one_query (mysqltest.c:535)
            ==378==    by 0x4050111: start_thread (in /lib/libpthread-2.5.so)
            ==378==    by 0x41A52ED: clone (in /lib/libc-2.5.so)
            
            (among other errors). The line where the invalid read happens is:
              if (available_stack_size(&pinbox, *pins->stack_ends_here) >
            alloca_size)
            and stack_ends_here was previously set here:
              el->stack_ends_here= & my_thread_var->stack_ends_here;
            The mysqltest "send" command, in embedded mode, is implemented this way
            (mysqltest.c:do_send_query()): a *new OS thread* is created in
            mysqltest, and does this:
            
              mysql_thread_init();
              VOID(mysql_send_query(&cn->mysql, cn->cur_query,
            cn->cur_query_len));
              mysql_thread_end();
            
            So, con_d "send insert t1 values (2)" creates a new OS thread, which
            gets a thread-specific data (mysql_thread_init()), then sends the
            query; in particular, this sets el->stack_ends_here to a pointer inside
            the thread-specific data (see my_thread_var above), that is, thd->pins
            depends on the thread-specific data.
            This sent "insert" blocks as expected, thread-specific data is free()d
            (my_thread_end() above), OS thread terminates.
            Then "default" connection runs "insert t1 values (3)"
            which blocks on the 3 already inserted by the con_d.
            This blocking (see waiting_threads.c) creates a WT_RESOURCE, which has,
            as owner, con_d's WT_THD.
            When con_d calls "unlock tables" (see stack trace), it wants to release
            this resource, which involves con_d's thd->pins, so it ends up reading
            stack_ends_here which points inside the freed thread-specific data =>
            Valgrind error, crashes...
            So this is an effect of having one single connection (con_d) for which
            two queries:
            send insert t1 values (2)
            unlock tables
            are done by different OS threads. That is indeed weird design of
            mysqltest, and it breaks on the dependency of lf_alloc-pin.c on
            thread-specific data. It is maybe already explained in those comments
            in lf_alloc-pin.c:
            "  It is assumed that pins belong to a THD and are not transferable
              between THD's (LF_PINS::stack_ends_here being a primary reason
              for this limitation)."
            "    It is assumed that pins belong to a thread and are not
            transferable
                between threads."
            
            In correct usage of libmysqld (no two queries sent for one connection
            by two threads), this problem would not happen, so I call it a
            deficiency of the test system.
      mysql-test/suite/maria/t/maria_notembedded.test:
        moving test portion into maria_notembedded.test
      255f8feb
  4. 25 Nov, 2008 2 commits
    • unknown's avatar
      Fix of the small merge bug. · bb7ae40a
      unknown authored
      bb7ae40a
    • Guilhem Bichot's avatar
      Manually applying the patch for BUG40954 "Crash in MyISAM index code with... · 3c1e153a
      Guilhem Bichot authored
      Manually applying the patch for BUG40954 "Crash in MyISAM index code with concurrency test using partitioned tables"
      so that it stops crashing pushbuild2/5.1-maria and we can see the other failures which it hid.
      
      mysql-test/r/partition.result:
        Manually applying the patch for BUG40954 "Crash in MyISAM index code with concurrency test using partitioned tables"
      mysql-test/t/partition.test:
        Manually applying the patch for BUG40954 "Crash in MyISAM index code with concurrency test using partitioned tables"
      sql/ha_partition.cc:
        Manually applying the patch for BUG40954 "Crash in MyISAM index code with concurrency test using partitioned tables"
      3c1e153a
  5. 24 Nov, 2008 5 commits
  6. 22 Nov, 2008 1 commit
  7. 21 Nov, 2008 1 commit
  8. 20 Nov, 2008 1 commit
    • Guilhem Bichot's avatar
      During Maria's checkpoint, use the proper mutex to read transaction's short_id · 8d96bcda
      Guilhem Bichot authored
      storage/maria/trnman.c:
        During Maria's checkpoint, we walk the list of active transactions; in this list we may find a transaction with a short_id of 0 which means "uninitialized" (is being created right now) and want to ignore this transaction. Such short_id is set under trn->state_lock, so use this mutex to reliably read short_id during checkpoint.
      8d96bcda
  9. 12 Nov, 2008 2 commits
  10. 11 Nov, 2008 1 commit
  11. 10 Nov, 2008 3 commits
  12. 07 Nov, 2008 4 commits
  13. 06 Nov, 2008 17 commits