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 ......
>>
>>
>>
>
