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
