Alex,
the assertion means that when InnoDB looks for a father node pointer to a
page in the B-tree, it ends up on a pointer which does not point to the
child page. In other words, the B-tree is corrupt.
I see that the lsn of your database is rather small. Did you do anything
special before the crash?
You can try addding the following code on line 572 of btr0btr.c so that we
see what index in what table is corrupt and how. That can give a clue what
might be the bug:
if (btr_node_ptr_get_child_page_no(node_ptr) !=
buf_frame_get_page_no(page))
{
printf("Table %s, index %s, father ptr page no %lu, child page no
%lu\n",
(UT_LIST_GET_FIRST(tree->tree_indexes))->table_name,
(UT_LIST_GET_FIRST(tree->tree_indexes))->name,
btr_node_ptr_get_child_page_no(node_ptr),
buf_frame_get_page_no(page));
page_rec_print(page_rec_get_next(page_get_infimum_rec(page)));
page_rec_print(node_ptr);
}
I have added the above code now to 3.23.50.
When you have printed the above info, you may want to recover your database.
Look in section 6.1 of http://www.innodb.com/ibman.html about forcing
recovery.
Regards,
Heikki Tuuri
Innobase Oy
-----Original Message-----
From: BAUMEISTER Alexandre <[EMAIL PROTECTED]>
To: Heikki Tuuri <[EMAIL PROTECTED]>; Michael Widenius
<[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Tuesday, March 19, 2002 11:51 AM
Subject: InnoDB: Assertion failure in thread 10 in file btr0btr.c line 574
>Bonjour,
>
> We have Mysql continually crashing with this assertion failure in
> InnoDB.
>
> Mysql-3.23.49 configured with by :
>===========================================================================
=
> ./configure --prefix=/usr/local/mysql --without-bench
> --enable-thread-safe-client --with-innodb --without-debug
> --without-berkeley-db --without-raid --enable-local-infile
>===========================================================================
=
>
> Here are the logs :
>===========================================================================
=
>020319 10:43:13 mysqld restarted
>020319 10:43:16 InnoDB: Database was not shut down normally.
>InnoDB: Starting recovery from log files...
>InnoDB: Starting log scan based on checkpoint at
>InnoDB: log sequence number 0 722513183
>InnoDB: Doing recovery: scanned up to log sequence number 0 722514672
>020319 10:43:16 InnoDB: Starting an apply batch of log records to the
database...
>InnoDB: Progress in percents: 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73
74
>75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
>InnoDB: Apply batch completed
>020319 10:43:18 InnoDB: Flushing modified pages from the buffer pool...
>020319 10:43:18 InnoDB: Started
>/usr/local/mysql/libexec/mysqld: ready for connections
>020319 10:43:18 Warning: Checking table: './popup/campagne'
>020319 10:43:24 Warning: Checking table: './boursoscan/abonnes'
>InnoDB: Assertion failure in thread 10 in file btr0btr.c line 574
>InnoDB: We intentionally generate a memory trap.
>InnoDB: Send a detailed bug report to [EMAIL PROTECTED]
>mysqld got signal 11;
>This could be because you hit a bug. It is also possible that this binary
>or one of the libraries it was linked agaist 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=134213632
>record_buffer=1044480
>sort_buffer=2097144
>max_used_connections=82
>max_connections=650
>threads_connected=32
>It is possible that mysqld could use up to
>key_buffer_size + (record_buffer + sort_buffer)*max_connections = 2125262 K
>bytes of memory
>Hope that's ok, if not, decrease some variables in the equation
>===========================================================================
=
>
>
> And here are the config options :
>===========================================================================
=
>[mysqld]
>port = 3306
>socket = /tmp/mysql.sock
>skip-locking
>skip-name-resolve
>local-infile
>set-variable = max_connections=650
>set-variable = key_buffer=128M
>set-variable = max_allowed_packet=5M
>set-variable = table_cache=512
>set-variable = sort_buffer=2M
>set-variable = record_buffer=1M
>set-variable = myisam_sort_buffer_size=64M
>set-variable = thread_cache=8
>set-variable = thread_concurrency=8 # Try number of CPU's*2
>myisam-recover = BACKUP,FORCE
>
>innodb_data_home_dir = /usr/local/mysql/innobase_var/innobase_data/
>innodb_data_file_path = ibdata1:2000M
>set-variable = innodb_mirrored_log_groups=1
>innodb_log_group_home_dir = /usr/local/mysql/innobase_var/innobase_logs/
>set-variable = innodb_log_files_in_group=5
>set-variable = innodb_log_file_size=30M
>set-variable = innodb_log_buffer_size=10M
>innodb_flush_log_at_trx_commit=0
>innodb_log_arch_dir = /usr/local/mysql/innobase_var/innobase_logs/
>innodb_log_archive=0
>set-variable = innodb_buffer_pool_size=256M
>set-variable = innodb_additional_mem_pool_size=10M
>set-variable = innodb_file_io_threads=8
>set-variable = innodb_lock_wait_timeout=50
>innodb_fast_shutdown=1
>===========================================================================
=
>
> Any idea ?
>
> Regards,
> Alex.
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
