Hi!
In 3.23.41 there was a serious BLOB bug which
corrupted the table if you updated the primary key
of a long row.
There was also another bug in 3.23.41 which could
crash a query if you selected two long columns in the
same query.
There is a special page for bug reports at
the InnoDB website:
http://www.innodb.com/bugfixes.html
That often helps in this kind of situation.
These bugs are fixed in 3.23.42. Please download it and
try again!
Heikki
Innobase Oy
postgres wrote in message <9oo5et$2n6m$[EMAIL PROTECTED]>...
>>Description:
>This is the log file (some characters are cyrillic KOI8):
>
>Number of processes running now: 0
>010924 21:57:51 mysqld restarted
>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 3160039
>010924 21:57:52 InnoDB: Started
>/usr/local/libexec/mysqld: На связи!
>InnoDB: Assertion failure in thread 9226 in file btr0cur.c line 3032
>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=12288
>record_buffer=131072
>sort_buffer=65528
>max_used_connections=0
>max_connections=100
>threads_connected=1
>It is possible that mysqld could use up to
>key_buffer_size + (record_buffer + sort_buffer)*max_connections = 19211 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:
>0x80c9628
>0x4002c552
>0x81e91fb
>0x81e9350
>0x81cd5dd
>0x81cebff
>0x8119ff4
>0x810c506
>0x80eda6d
>0x80ed7a6
>0x80e6d76
>0x80cfe09
>0x80d3c3d
>0x80cf219
>0x80ce73b
>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 0x839fba8 = select
product_id,name,size,description,price,weight,active,availability,image from
products
>thd->thread_id=1
>
>
>Successfully dumped variables, if you ran with --log, take a look at the
>details of what thread 1 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
>010924 21:59:43 mysqld restarted
>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 3160049
>010924 21:59:44 InnoDB: Started
>/usr/local/libexec/mysqld: На связи!
>InnoDB: Assertion failure in thread 9226 in file btr0cur.c line 3032
>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=12288
>record_buffer=131072
>sort_buffer=65528
>max_used_connections=0
>max_connections=100
>threads_connected=1
>It is possible that mysqld could use up to
>key_buffer_size + (record_buffer + sort_buffer)*max_connections = 19211 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:
>0x80c9628
>0x4002c552
>0x81e91fb
>0x81e9350
>0x81cd5dd
>0x81cebff
>0x8119ff4
>0x810c506
>0x80f739c
>0x80d0f48
>0x80d3c3d
>0x80cf219
>0x80ce73b
>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 0x839fba8 = update products set image=NULL
>thd->thread_id=1
>
>
>Successfully dumped variables, if you ran with --log, take a look at the
>details of what thread 1 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
>010924 22:00:04 mysqld restarted
>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 3160059
>010924 22:00:05 InnoDB: Started
>/usr/local/libexec/mysqld: На связи!
>InnoDB: Assertion failure in thread 9226 in file btr0cur.c line 3032
>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=12288
>record_buffer=131072
>sort_buffer=65528
>max_used_connections=0
>max_connections=100
>threads_connected=1
>It is possible that mysqld could use up to
>key_buffer_size + (record_buffer + sort_buffer)*max_connections = 19211 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:
>0x80c9628
>0x4002c552
>0x81e91fb
>0x81e9350
>0x81cd5dd
>0x81cebff
>0x8119ff4
>0x810c506
>0x8122c8a
>0x812197a
>0x80d0947
>0x80d3c3d
>0x80cf219
>0x80ce73b
>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 0x839fba8 = alter table products drop image
>thd->thread_id=1
>
>
>Successfully dumped variables, if you ran with --log, take a look at the
>details of what thread 1 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
>
>010924 22:01:07 mysqld restarted
>010924 22:01:09 InnoDB: Started
>/usr/local/libexec/mysqld: На связи!
>InnoDB: Assertion failure in thread 9226 in file btr0cur.c line 3032
>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=12288
>record_buffer=131072
>sort_buffer=32768
>max_used_connections=0
>max_connections=100
>threads_connected=1
>It is possible that mysqld could use up to
>key_buffer_size + (record_buffer + sort_buffer)*max_connections = 16012 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:
>0x80c9628
>0x4002c552
>0x81e91fb
>0x81e9350
>0x81cd5dd
>0x81cebff
>0x8119ff4
>0x810c506
>0x80eda6d
>0x80ed7a6
>0x80e6d76
>0x80d04ad
>0x80d3c3d
>0x80cf219
>0x80ce73b
>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 0x839fba8 = create table products2 as select * from products
>thd->thread_id=1
>
>
>Successfully dumped variables, if you ran with --log, take a look at the
>details of what thread 1 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
>
>The problem was that mysqld crashes and restarted when running query on
>innodb table "products".
>The problem was probably in corrupted "image" field.
>This is the table definition:
>
>create table products (
> product_id varchar(16) not null,
> name varchar(64),
> description text,
> price float,
> image mediumblob,
> weight float,
> active char(1) default 'N',
> size tinyint not null default 0,
> availability mediumint not null,
>
> primary key (product_id)
>) type=innodb;
>create index i_products_active on products (active);
>create index i_products_size on products (size);
>
>I stored images in the image field, approx. 150-160 kb each.
>There were around 10-15 records in the table.
>
>When I subsequentally tried to perform
>select product_id from products;
>select product_id,name from products;
>... etc. up to select product_id,..,price from products
>it was ok. When I tried to select image from products, mysqld was crashing
>and restarting. All the times it put to log different messages. The
difference
>was in the query, equation with memory sizes and sometimes it
>shows line number with assertion (sometimes not - see above).
>
>Before it was working ok around 2 or 3 weeks without any faults.
>Note that I don't use mysql in production environment;
>I'm web-developer and use mysql for development.
>
>I recovered from this by creating second table without image field and
>selecting all the data from first table into it, and then dropping
>corrupted table and so on.
>
>Sorry that this is probably little informative bug report, however
>I do not have much time to recompile mysqld with --debug option and
>produce a trace. Also, I had stripped mysqld with strip, so symbolic
>information is absent :-(((
>
>>How-To-Repeat:
>Unknown.
>>Fix:
>Unknown.
>
>>Submitter-Id: Max Rudensky <[EMAIL PROTECTED]>
>>Originator: root
>>Organization:
>>MySQL support: none
>>Synopsis: crashes when executing query on innodb table; probably corrupted
table
>>Severity: critical
>>Priority: medium
>>Category: mysql
>>Class: support
>>Release: mysql-3.23.41 (Source distribution)
>
>>Environment:
>
>System: Linux petrusha.localdomain 2.2.19 #1 Thu May 17 11:49:34 EEST 2001
i686 unknown
>Architecture: i686
>
>Some paths: /usr/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/egcs-2.91.66/specs
>gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
>Compilation info: CC='gcc' CFLAGS='-march=pentiumpro -O3' CXX='gcc'
CXXFLAGS='' LDFLAGS=''
>LIBC:
>lrwxrwxrwx 1 root root 13 Май 13 2000 /lib/libc.so.6 ->
libc-2.1.3.so
>-rwxr-xr-x 1 root root 4101324 Фев 29 2000 /lib/libc-2.1.3.so
>-rw-r--r-- 1 root root 20272704 Фев 29 2000 /usr/lib/libc.a
>-rw-r--r-- 1 root root 178 Фев 29 2000 /usr/lib/libc.so
>Configure command:
./configure --with-innodb --with-berkeley-db --with-charset=koi8_ru --with-
mysqld-user=dba
>Perl: This is perl, version 5.005_03 built for i386-linux
>
>---------------------------------------------------------------------
>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
>
---------------------------------------------------------------------
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
