Hi,
Having some problems with a particular BDB table, which crashes once in a
while. Just wondering if anyone has experienced such BDB table crashes?
The relevant info is included below for troubleshooting. Let me know if I
need to send anything else. Appreciate any help. Thanks!
>Description:
BDB table crashes on delete query, such delete queries execute flawlessly
but once in a while, the table crashes on a delete, and causes a restart of
MySQL
>How-To-Repeat:
Not very repeatable, happens intermittently and at random.
>Fix:
No fix yet.
>Submitter-Id: <submitter ID>
>Originator:
>Organization: Ufinity Pte Ltd
>MySQL support: none
>Synopsis: bdb table crashes
>Severity: serious
>Priority: medium
>Category: mysql
>Class: sw-bug
>Release: mysql-3.23.42 (Source distribution)
>Environment:
<machine, os, target, libraries (multiple lines)>
System: Linux axle 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686 unknown
Architecture: i686
Some paths: /usr/local/bin/perl /usr/bin/make /usr/bin/gmake /usr/bin/gcc
/usr/
bin/cc
GCC: Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81)
Compilation info: CC='gcc' CFLAGS='' CXX='c++' CXXFLAGS='' LDFLAGS=''
LIBC:
lrwxrwxrwx 1 root root 13 Sep 12 02:51 /lib/libc.so.6 ->
libc-2
.2.2.so
-rwxr-xr-x 2 root root 1236396 Apr 7 2001 /lib/libc-2.2.2.so
-rw-r--r-- 1 root root 26350254 Apr 7 2001 /usr/lib/libc.a
-rw-r--r-- 1 root root 178 Apr 7 2001 /usr/lib/libc.so
Configure command:
./configure --prefix=/home/mysql/mysql-lite --localstatedir=
/home/mysql/data/mysql-lite --with-berkeley-db --with-raid --enable-assemble
r --with-mysqld-ldflags=-all-static
Stack Trace :
0x806c666 handle_segfault__Fi + 258
0x818d3ee btr_cur_pessimistic_update + 386
0x80b4c6e delete_row__12ha_myisammrgPCc + 14
0x80feb28 txn_abort + 184
0x81429c2 __bam_repl_recover + 566
0x8138859 __bam_pgout + 41
0x8135204 __qam_c_get + 1008
0x8111a66 __db_rename + 926
0x80b6b65 update_row__11ha_berkeleyPCcPc + 1153
0x80b6d5a update_row__11ha_berkeleyPCcPc + 1654
0x809b2e1 generate_table__FP3THDP13st_table_listP8st_table + 673
0x8074115 mysql_execute_command__Fv + 5705
0x8075a73 my_yyoverflow__FPPsPP7YYSTYPEPi + 31
0x8072082 do_command__FP3THD + 862
0x80715a4 handle_one_connection__FPv + 180
Schema from table :
mysql> desc user_status;
+-----------+---------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------+---------------------+------+-----+---------+-------+
| userid | varchar(255) | | PRI | | |
| domain | varchar(150) | | PRI | | |
| password | varchar(100) | YES | | NULL | |
| timestamp | bigint(20) unsigned | YES | MUL | NULL | |
+-----------+---------------------+------+-----+---------+-------+
6 rows in set (0.00 sec)
Snippet from the error log :
> Errors from /home/mysql/data/mysql-lite/hotspring.err
> 020121 15:31:36 mysqld restarted
> /home/mysql/mysql-lite/libexec/mysqld: ready for connections
> 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=67104768
> record_buffer=131072
> sort_buffer=524280
> max_used_connections=73
> max_connections=100
> threads_connected=73
> It is possible that mysqld could use up to
> key_buffer_size + (record_buffer + sort_buffer)*max_connections = 129531 K
> bytes of memory
> Hope that's ok, if not, decrease some variables in the equation
>
> 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...
> Stack range sanity check OK, backtrace follows:
> 0x806c666
> 0x818d3ee
> 0x80b4c6e
> 0x80feb28
> 0x81429c2
> 0x8138859
> 0x8135204
> 0x8111a66
> 0x80b6b65
> 0x80b6d5a
> 0x809b2e1
> 0x8074115
> 0x8075a73
> 0x8072082
> 0x80715a4
> Stack trace seems successful - bottom reached
> Please read http://www.mysql.com/doc/U/s/Using_stack_trace.html and follow
instructions on how to resolve the stack trace. Resolved
> stack trace is much more helpful in diagnosing the problem, so please do
> resolve it
> Trying to get some variables.
> Some pointers may be invalid and cause the dump to abort...
> thd->query at 0x8375c48 = DELETE FROM user_status WHERE userid =
'91235434' AND domain = 'ufinity'
> thd->thread_id=30
>
>
> Successfully dumped variables, if you ran with --log, take a look at the
> details of what thread 30 did to cause the crash. In some cases of really
> bad corruption, the values shown above may be invalid
>
> The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains
> information that should help you find out what is causing the crash
>
> Number of processes running now: 0
> 020121 16:04:41 mysqld restarted
> /home/mysql/mysql-lite/libexec/mysqld: ready for connections
>
Cheers,
Geoffrey
__________________________________________________
Geoffrey Soh, Software Architect
Ufinity - http://www.ufinity.com
Leading Enterprise Access Management Software!
9 Scotts Road, Pacific Plaza, #06-01, Singapore 228210
Tel : +65 830-0341
Fax : +65 737-0213
__________________________________________________
---------------------------------------------------------------------
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
