Planet MySQL Planet MySQL: Meta Deutsch Español Français Italiano 日本語 Русский Português 中文
Showing entries 1 to 10 of 18 Next 8 Older Entries

Displaying posts with tag: crash (reset)

On responsible bugs reporting
+1 Vote Up -0Vote Down
Let me start with questions related to responsible MySQL bugs reporting that I'd like to be discussed and then present a history behind them.

Assuming that you, my dear reader from MySQL Community, noted or found some simple sequence of SQL statements that, when executed by authenticated MySQL user explicitly having all the privileges needed to execute these statements, crashes some version of your favorite MySQL fork, please, answer the following questions:
  • Do you consider this kind of a bug a "security vulnerability"?
  • Should you share complete test case at any public site (MySQL bugs database, Facebook, your personal blog, any)?
  • Should you share just a description of possible "attack vector", as Oracle does when they publish security bug fixes?
  • Should you share just a stack trace or failed assertion information,



  •   [Read more...]
    Are MariaDB tests adding anything extra over Oracle MySQL tests?
    +3 Vote Up -0Vote Down

    I grabbed all the tests introduced in MariaDB 5.5.32 (i.e. “bzr diff -rtag:mariadb-5.5.31..mariadb-5.5.32 mysql-test/” and some foo) and threw them in their own test file. I only kept tests for crashing bugs and ignored those that required plugins (there were two or three, but nothing major). So now I have a test file that should crash MariaDB 5.5.31 and probably before. But, the question is: does this crash Percona Server or MySQL?

    While it is excellent to see the MariaDB guys including tests for their crashing bugs, are these MariaDB specific or do they affect other MySQL flavours?

    I built a release build of top of trunk Percona Server and ran the test against it. I got no crashes. In a debug build,

      [Read more...]
    Initial Reactions to MySQL 5.6
    +3 Vote Up -0Vote Down

    New versions of MySQL are always interesting to try out. Often they have features which I may have asked for myself so it’s satisfying to see them eventually appear on a system I use. Often other new features make life easier for the DBA. Finally we hope overall performance will improve and managing the server(s) will be come easier.

    So I had a system which needs to make heavy writes, and performance was a problem, even when writing to SSDs. Checkpointing seemed to be the big issue and the ib_logfile size in MySQL 5.5 is limited to 4 GB. That seems a lot, but once MySQL starts to fill these files (and this happens at ~70% of the total I believe),  checkpointing kicks in heavily, and slows things down.  So the main reason for trying out MySQL 5.6 was to see how things performed with larger ib_logfiles. (Yes, MariaDB 5.5 can do this too.)

    Things improved a lot for my

      [Read more...]
    Nasty Regression Bug Seems Fixed in 5.5.18
    +7 Vote Up -0Vote Down

    For those who saw my previous post about the crashing (regression) bug with SELECT COUNT(DISTINCT) on InnoDB with Primary Key (PK), you’ll be interested to know my test case does not crash in 5.5.18 (which was just released).

    I’ve only tested my test case thus far, but it seems fine.

    Unfortunately, the fix is not mentioned in the 5.5.18 changelogs though.

    And there is no mention (yet, anyway) of a fix in the bug report I filed (though it was designated a ‘duplicate’, so it wouldn’t necessarily be updated).

    I’m trying to get confirmation from the MySQL Dev Team on this (via the bug report), and will update this post if/when I hear anything.

    I’ll also perform some of

      [Read more...]
    Nasty Regression Bug: SELECT COUNT(DISTINCT) crashes InnoDB when WHERE operand is in Primary Key or Unique Index
    +8 Vote Up -0Vote Down

    In 5.5, a crashing, regression bug exists if you use SELECT COUNT(DISTINCT) *and* one of the WHERE operands is in the Primary Key (or just a unique index).

    This simple crash (if only one row is in the table) will crash mysqld.

    Of course I’ve filed a bug report, but that has been nearly 3 months and no updates yet.

    Here is the bug I filed (which you won’t be able to view):

    http://bugs.mysql.com/bug.php?id=61842

    Really, the only thing that happened to my bug report was that it was designated a duplicate of another bug (which we also cannot view):

    http://bugs.mysql.com/bug.php?id=61101

    Based on the id, and the submitted dates of bugs 61100 and 61102, this initial bug (61101) was filed on May 9, 2011. So, in fact, this bug has been present for over 5

      [Read more...]
    Unexpected mysqld crashing in 5.5
    +3 Vote Up -2Vote Down

    An update of MySQL from 5.0 to 5.5 on CentOS 5.5 64bit has not resulted in a good experience. The mysqld process would then crash every few minutes with the following message.

    101120 8:29:27 InnoDB: Operating system error number 22 in a file operation.
    InnoDB: Error number 22 means ‘Invalid argument’.
    InnoDB: Some operating system error numbers are described at
    InnoDB: http://dev.mysql.com/doc/refman/5.1/en/operating-system-error-codes.html
    InnoDB: File name /tmpfs/#sql6cf3_5c_0.ibd
    InnoDB: File operation call: ‘aio write’.
    InnoDB: Cannot continue operation.
    

    The work around was to change the tmpdir=/tmpfs (which was a 16G tmpfs filesystem) to a physical disk.

    The referenced URL didn’t provide any more information of help. Unlike Bug #26662 O_DIRECT is not specified as the flush method.

    A Quick Review of Stack Traces
    Employee +5 Vote Up -0Vote Down
    I'll try to pass on some basic knowledge about those confusing stack traces we sometimes see in the mysql error logs.  What can you tell from them, what are they useful for, and how to validate them?
    Debugging Crashes
    We tried to improve postmortem debugging of crashes + stack traces in the error log:o) old versions of mysqld only printed numerical numbers instead of function names (if you're lucky!)o) some platforms/architectures printed no stack trace what-so-ever!o)

      [Read more...]
    How to crash mysqld intentionally
    +0 Vote Up -0Vote Down

    While some may think I’m daft, I have a legitimate reason for wanting to crash mysqld. However first we need to find a way to crash it.

    Great thanks to Alan K, Mark L, Harrison and Hartmut on #mysql-dev for several suggestions and a config option I was unaware of. My investigation even lead to a documentation bug logged as #51739.

    My first thought was to find a known bug and if necessary install the correct version to test that. A good one was suggested, Bug #48508 which fails on several versions that I will use to demonstrate with, however the simplest way is to issue kill -11

    By default, no core file will be produced which is what I’m seeking but with the right options this is possible. First, the user running mysqld probably has a

      [Read more...]
    How to tell when using INFORMATION_SCHEMA might crash your database
    +8 Vote Up -2Vote Down

    There are those that are very adamant about letting people know that using INFORMATION_SCHEMA can crash your database. For example, in making changes to many tables at once Baron writes:

    “querying the INFORMATION_SCHEMA database on MySQL can completely lock a busy server for a long time. It can even crash it. It is very dangerous.”

    Though Baron is telling the truth here, he left out one extremely important piece of information: you can actually figure out how dangerous your INFORMATION_SCHEMA query will be, ahead of time, using EXPLAIN.


    In MySQL 5.1.21 and higher, not only were optimizations made to the INFORMATION_SCHEMA, but new values were added so that EXPLAIN had better visibility into what MySQL is actually

      [Read more...]
    Crash recovery, again
    +5 Vote Up -0Vote Down

    There’s one stage in InnoDB crash recovery where it reads log file, you know, this one:

    InnoDB: Doing recovery: scanned up to log sequence number 354164119040
    InnoDB: Doing recovery: scanned up to log sequence number 354169361920
    

    On a machine with bigger logs it will start spending nearly 100% CPU somewhere in recv_scan_log_recs. Guess what it does…. -fno-inline builds to the rescue:

    #0  mem_block_get_len at ./include/mem0mem.ic:86
    #1  mem_heap_get_size at ./include/mem0mem.ic:591
    #2  recv_scan_log_recs at log/log0recv.c:2727
    

    And:

    samples  %        symbol name
    8467     72.9222  mem_heap_get_size
    291       2.5062  recv_add_to_hash_table
    95        0.8182  mem_block_get_len
    

    To speak in layman’s terms, InnoDB does SUM(LENGTH(allocation)) on its relatively wide memory (tens, hundreds of thousands of entries) arena,

      [Read more...]
    Showing entries 1 to 10 of 18 Next 8 Older Entries

    Planet MySQL © 1995, 2014, Oracle Corporation and/or its affiliates   Legal Policies | Your Privacy Rights | Terms of Use

    Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.