List:Cluster« Previous MessageNext Message »
From:Martin Skold Date:July 2 2004 9:05pm
Subject:Re: init_key_cache: Assertion `key_cache_block_size >= 512' failed
View as plain text  
I think all the tests are done in alphabetical order so the next
test should be keywords, again nothing MySQL Cluster specific.

You can turn on debugging --debug to check what it is doing.
You can also look in the test files and try running manually to see what
is happening.
You can try running just the ndb tests by --do-test=ndb.
Hard to say what is the problem. How do you start mysql-test-run?
You should also have the flag --with-ndbcluster.

BR
-- Martin

Devananda wrote:

> Hi,
>
> I have just now built mysql on 2 identical machines, images111 
> configured with
>
> ./configure --mandir=/usr/local/mysql/man 
> --infodir=/usr/local/mysql/info --enable-assembler --with-gnu-ld 
> --without-debug --enable-thread-safe-client --with-ndbcluster 
> --without-ndb-test --with-ndb-docs --with-innodb --without-bench 
> --with-docs --without-extra-tools --without-query-cache --with-server 
> --with-mysqld-user=mysql --with-extra-charsets=all
>
> and images107 configured with these differences:  --without-ndbcluster 
> --without-ndb-docs
>
> 107 ran all tests, failed on system_mysql_db_fix but passed (or 
> skipped) all others, while 111 still hangs right after "key ... 
> [pass]". I let it run overnight and it made no progress.
>
> Both cases of mysql-test-run were run with no command line options 
> (ie, ndb was not enabled on 111). The only difference I can see is 
> that 111 was compiled with support for ndb.
>
>
>
> Devananda
> Neopets, Inc
>
>
> Martin Skold wrote:
>
>> Hi,
>>
>> The problems you have do not seem to be MySQL Cluster
>> specific. Have you managed to build just the MySQL server
>> and run all the tests?
>>
>> BR
>> -- Martin
>>
>> Devananda wrote:
>>
>>> Hi,
>>>
>>> I have compiled the current bk source (pulled this morning) and 
>>> built twice (I'll explain that in a sec). I wanted to bring this up 
>>> here, even though it seems to be working now, sort of. Firstly, 
>>> mysql-test-run failed hard with one set of configure options.
>>>
>>> CC=gcc CXX=gcc ./configure  --prefix=/usr/local/ --bindir=/usr/bin 
>>> --mandir=/usr/local/mysql/man --infodir=/usr/local/mysql/info 
>>> --enable-assembler --with-gnu-ld --with-debug 
>>> --enable-thread-safe-client --with-ndbcluster --with-ndb-test 
>>> --with-ndb-docs --with-innodb --without-bench --with-docs 
>>> --with-extra-tools --without-query-cache --with-server 
>>> --with-mysqld-user=mysql --with-extra-charsets=all
>>>
>>> However, mysql-test-run seems to work when I change these to 
>>> "--without-ndb-test --without-debug" (leaving all the rest untouched)
>>>
>>> What follows is the output of the crash when compiled --with-debug 
>>> --with-ndb-test
>>>
>>> [root@images111 mysql-test]# ./mysql-test-run
>>> Ndb.cfg missing
>>> Installing Test Databases
>>> Removing Stale Files
>>> Installing Master Databases
>>> running  ../libexec/mysqld --no-defaults --bootstrap 
>>> --skip-grant-tables     --basedir=.. 
>>> --datadir=mysql-test/var/master-data --skip-innodb --skip-ndbcluster 
>>> --skip-bdb    *mysqld: mf_keycache.c:295: init_key_cache: Assertion 
>>> `key_cache_block_size >= 512' failed.*
>>> mysqld got signal 6;
>>> This could be because you hit a bug. It is also possible that this 
>>> binary
>>> or one of the libraries it was linked against is corrupt, improperly 
>>> built,
>>> or misconfigured. This error can also be caused by malfunctioning 
>>> hardware.
>>> We will try our best to scrape up some info that will hopefully help 
>>> diagnose
>>> the problem, but since we have already crashed, something is 
>>> definitely wrong
>>> and this may fail.
>>>
>>> key_buffer_size=0
>>> read_buffer_size=131072
>>> max_used_connections=0
>>> max_connections=100
>>> threads_connected=0
>>> It is possible that mysqld could use up to
>>> key_buffer_size + (read_buffer_size + 
>>> sort_buffer_size)*max_connections = 217599 K
>>> bytes of memory
>>> Hope that's ok; if not, decrease some variables in the equation.
>>>
>>> thd=(nil)
>>> Attempting backtrace. You can use the following information to find out
>>> where mysqld died. If you see no messages after this, something went
>>> terribly wrong...
>>> Cannot determine thread, fp=0xbfffe618, backtrace may not be correct.
>>> Stack range sanity check OK, backtrace follows:
>>> 0x81698ce
>>> 0x400244ec
>>> 0x4010bd71
>>> 0x40021b8b
>>> 0x4010bb04
>>> 0x4010d1e0
>>> 0x401050ad
>>> 0x8405fb5
>>> 0x81f0a18
>>> 0x81739ca
>>> 0x816b0b0
>>> 0x816b3b6
>>> 0x400f8c57
>>> 0x80ef521
>>> New value of fp=(nil) failed sanity check, terminating stack trace!
>>>
>>> (cropped here, since the rest looks extraneous)
>>>
>>> To top matters off, when compiled with --without-ndb-test 
>>> --without-debug, mysql-test-run runs for a while, then seems to get 
>>> stuck right after
>>>
>>> key                            [ pass ]
>>>
>>> with no further output, AND "ps aux" reveals something rather odd ...
>>>
>>> root      6741  0.0  0.1  2784 1624 pts/3    S    16:59   0:00 
>>> /bin/sh ./mysql-test-run
>>> root      9200  0.0  0.1  2416 1148 pts/3    S    17:03   0:00 /bin/sh
>>> root      9202  0.0  2.4 58508 25456 pts/3   S    17:03   0:00 
>>> /usr/local/libexec/mysqld --no-defaults --log-bin=/usr/local/mysql-t
>>> root      9203  0.0  2.4 58508 25456 pts/3   S    17:03   0:00 
>>> /usr/local/libexec/mysqld --no-defaults --log-bin=/usr/local/mysql-t
>>> root      9204  0.0  2.4 58508 25456 pts/3   S    17:03   0:00 
>>> /usr/local/libexec/mysqld --no-defaults --log-bin=/usr/local/mysql-t
>>> root      9205  0.0  2.4 58508 25456 pts/3   S    17:03   0:00 
>>> /usr/local/libexec/mysqld --no-defaults --log-bin=/usr/local/mysql-t
>>> root      9206  0.0  2.4 58508 25456 pts/3   S    17:03   0:00 
>>> /usr/local/libexec/mysqld --no-defaults --log-bin=/usr/local/mysql-t
>>> root      9207  0.0  2.4 58508 25456 pts/3   S    17:03   0:00 
>>> /usr/local/libexec/mysqld --no-defaults --log-bin=/usr/local/mysql-t
>>> root      9208  0.0  2.4 58508 25456 pts/3   S    17:03   0:00 
>>> /usr/local/libexec/mysqld --no-defaults --log-bin=/usr/local/mysql-t
>>> root      9209  0.0  2.4 58508 25456 pts/3   S    17:03   0:00 
>>> /usr/local/libexec/mysqld --no-defaults --log-bin=/usr/local/mysql-t
>>> root      9210  0.0  2.4 58508 25456 pts/3   S    17:03   0:00 
>>> /usr/local/libexec/mysqld --no-defaults --log-bin=/usr/local/mysql-t
>>> root      9211  0.0  2.4 58508 25456 pts/3   S    17:03   0:00 
>>> /usr/local/libexec/mysqld --no-defaults --log-bin=/usr/local/mysql-t
>>> root      9214  0.0  0.1  2784 1624 pts/3    S    17:03   0:00 
>>> /bin/sh ./mysql-test-run
>>> root      9215  0.0  0.1  3364 1164 pts/3    S    17:03   0:00 
>>> /usr/local/bin/mysqltest --no-defaults --socket=/usr/local/mysql-tes
>>> *root      9216 99.9  2.4 58508 25456 pts/3   R    17:03  11:21 
>>> /usr/local/libexec/mysqld --no-defaults --log-bin=/usr/local/mysql-t*
>>>
>>> the last line ... mysqld using 99.9% cpu? stuck in an infinite loop 
>>> maybe? It fails to respond to "kill" but dies with "kill -9".
>>>
>>>
>>>
>>> I'm at a loss of what to do next ......
>>>
>>>
>>>
>>
>
>
>

-- 
Martin Sköld, Software Engineer
MySQL AB, www.mysql.com
Office: +46 (0)730 31 26 21



Thread
init_key_cache: Assertion `key_cache_block_size >= 512' failedDevananda2 Jul
  • Re: init_key_cache: Assertion `key_cache_block_size >= 512' failedDevananda2 Jul
  • Re: init_key_cache: Assertion `key_cache_block_size >= 512' failedMartin Skold2 Jul
    • Re: init_key_cache: Assertion `key_cache_block_size >= 512' failedDevananda2 Jul
      • Re: init_key_cache: Assertion `key_cache_block_size >= 512' failedMartin Skold2 Jul