Re:Possible bug in ORDER BY timestamp
Thanks for the help everyone. I tried changing the type to timestamp¹ and that did not fix the problem, however when I changed the type to int¹ and it worked as it was suppose to. Thanks, Lael
Re:Possible bug?
Hi! The log sequence number is only 300 000 bytes :). You have data and log files which are almost completely full of zeros, and consequently if you compress them with gzip, you are able to send them to me as attachments. Some notes on possible Linux bugs: I notice that you are running the Linux kernel 2.2.14. MySQL AB people recently sent the following advisory which is now also in the manual: http://www.mysql.com/doc/B/i/Binary_notes-Linux.html WARNING: We have have reports from some MySQL users that they have got serious stability problems with MySQL with Linux kernel 2.2.14. If you are using this kernel you should upgrade to 2.2.19 (or newer) or to a 2.4 kernel. If you have a multi-cpu box, then you should seriously consider using 2.4 as this will give you a significant speed boost. My development platform is a 2-way Xeon with Linux 2.4.4-64GB-SMP i686. I have not seen any strange thread crashes or database page corruption in it. In a 2-way Red Hat 6.2 box with software RAID I got both file corruption and thread crashes in my tests. InnoDB calls often fsync and has more threads than MyISAM. That may make it more susceptible to kernel bugs. You could also try downloading a binary from the MySQL site www.mysql.com. Monty tries to compile them in the best way to keep Linux bugs at bay. Regards, Heikki At 02:21 PM 10/2/01 -0400, you wrote: >Heikki, > >Update on this. Managed to get this to happen with the file updates you >sent, on an internal box(same config as original problem rpt), log info >follows: > >//Log file starts >011002 13:28:19 mysqld started >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 293003 >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=314568704 >record_buffer=16773120 >sort_buffer=67108856 >max_used_connections=0 >max_connections=100 >threads_connected=0 >It is possible that mysqld could use up to >key_buffer_size + (record_buffer + sort_buffer)*max_connections = 110187 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... >Bogus stack limit or frame pointer, fp=0xbfffd830, stack_bottom=0x49d856f0, thread_stack=131072, aborting backtrace. >Trying to get some variables. >Some pointers may be invalid and cause the dump to abort... >thd->query at 0x49040760 is invalid pointer >thd->thread_id=137794600 > > >Successfully dumped variables, if you ran with --log, take a look at the >details of what thread 137794600 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 >011002 13:28:19 mysqld ended > >011002 13:28:53 mysqld started >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 293003 >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=314568704 >record_buffer=16773120 >sort_buffer=67108856 >max_used_connections=0 >max_connections=100 >threads_connected=0 >It is possible that mysqld could use up to >key_buffer_size + (record_buffer + sort_buffer)*max_connections = 110187 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... >Bogus stack limit or frame pointer, fp=0xbfffd830, stack_bottom=0x49d856f0, thread_stack=131072, aborting backtrace. >Trying to get some variables. >Some pointers may be invalid and cause the dump to abort... >thd->query at 0x49040760 is invalid pointer >thd->thread_id=137794600 > >Successfully dumped variables, if you ran with --log, take a look at the >details of what thread 137794600 did to cause the crash. I
Re:Possible bug?
Heikki, Update on this. Managed to get this to happen with the file updates you sent, on an internal box(same config as original problem rpt), log info follows: //Log file starts 011002 13:28:19 mysqld started 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 293003 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=314568704 record_buffer=16773120 sort_buffer=67108856 max_used_connections=0 max_connections=100 threads_connected=0 It is possible that mysqld could use up to key_buffer_size + (record_buffer + sort_buffer)*max_connections = 110187 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... Bogus stack limit or frame pointer, fp=0xbfffd830, stack_bottom=0x49d856f0, thread_stack=131072, aborting backtrace. Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd->query at 0x49040760 is invalid pointer thd->thread_id=137794600 Successfully dumped variables, if you ran with --log, take a look at the details of what thread 137794600 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 011002 13:28:19 mysqld ended 011002 13:28:53 mysqld started 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 293003 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=314568704 record_buffer=16773120 sort_buffer=67108856 max_used_connections=0 max_connections=100 threads_connected=0 It is possible that mysqld could use up to key_buffer_size + (record_buffer + sort_buffer)*max_connections = 110187 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... Bogus stack limit or frame pointer, fp=0xbfffd830, stack_bottom=0x49d856f0, thread_stack=131072, aborting backtrace. Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd->query at 0x49040760 is invalid pointer thd->thread_id=137794600 Successfully dumped variables, if you ran with --log, take a look at the details of what thread 137794600 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 011002 13:28:54 mysqld ended //Log file ends Thanks, Chris On Thu, 27 Sep 2001, Heikki Tuuri wrote: > Ok, > > I have added some debug code to the upcoming > 3.23.43 so that if the bug reappears, mysqld > will print a lot of diagnostic info. That is > the best solution. I could also put some > fault tolerance in, but I am afraid people > would not send bug reports then. > > Regards, > > Heikki > > At 03:36 PM 9/27/01 -0400, you wrote: > >On Thu, 27 Sep 2001, Heikki Tuuri wrote: > >Heikki, > > > >I'll give it a shot. I probably won't be able to recreate very quickly, I > >had to take some more drastic steps to get everything back up. It happened > >on a field-trial system, so we wiped the db clean and recreated it. > > > >I'll probably load it into a in-house machine too. > > > >Wish I could give you access to the offending system, but it's behind > >someone else's security perimeter. > > > >Thanks, > >Chris > > > >> Chris, > >> > >> I have attached > >> > >> mysql/innobase/btr/btr0pcur.c > >> > >> and > >> > >> mysql/innobase/ibuf/ibuf0ibuf.c > >> > >> (maybe it comes as 'ibuf0i~1.c' since > >> Eudora does not understand > 8-char > >> file names). > >> > >> Recompile with these. They wil
Re:Possible bug?
Heikki, Here's the details from the .err log: New value of fp=(nil) failed sanity check, terminating stack trace! 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 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 010926 14:37:09 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 11 535599548 010926 14:37:09 InnoDB: Started /usr/sbin/mysqld-max: ready for connections InnoDB: Assertion failure in thread 5126 in file ibuf0ibuf.c line 2339 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 I'm assuming that this happens to be occurring b/c of a Innodb file corruption, b/c when I comment the innodb config out of the my.cnf the mysqld starts up ok(albeit w/o all my data). Thanks, Chris On Thu, 27 Sep 2001, Heikki Tuuri wrote: > Chris, > > what is the exact error message? How do you know that > it comes from ibuf0ibuf.c, line 2339? Have you compiled > yourself? > > Regards, > > Heikki > Innobase Oy > > >Getting an error message in the log saying...fp=(nil), etc, etc, possible bug > >from ibuf0ibuf.c, line 2339 > >What're the possible reasons I could be getting this bug?Oh, forgot... > >MySQL-max 3.23.42innodbRed Hat 6.2(2.2.14-6.1.1.smp) > >Intel 866Mhz, 512MB Ram, 20+ GB SCSI HDD > > > >Thanks, > >Chris > > - 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
Re:Possible bug?
Chris, what is the exact error message? How do you know that it comes from ibuf0ibuf.c, line 2339? Have you compiled yourself? Regards, Heikki Innobase Oy >Getting an error message in the log saying...fp=(nil), etc, etc, possible bug >from ibuf0ibuf.c, line 2339 >What're the possible reasons I could be getting this bug?Oh, forgot... >MySQL-max 3.23.42innodbRed Hat 6.2(2.2.14-6.1.1.smp) >Intel 866Mhz, 512MB Ram, 20+ GB SCSI HDD > >Thanks, >Chris - 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
Re:Possible bug with InnoDB table
Tianlin, you are right. If InnoDB did a scan from a secondary index to an empty table, then it returned an error code MySQL did not accept in this context. I changed now the error code and it will be right in the next release .38, if Monty has not yet gotten it out. Regards, Heikki I am running MySQL 3.23.37 compiled by myself on Linux platform. Here is a repeatable example: mysql> create table test (id int not null, -> KEY id (id)) type=InnoDB; mysql> SELECT id FROM test WHERE id<1; ERROR 1032: Can't find record in 'test' I am expecting something like the following: Empty set (0.00 sec) You need the following combination to repeat this bug: (1) InnoDB table (MyISAM works OK) (2) where clause (without WHERE clause works OK) (3) < or <= comparison operator (= or > or >= work OK) (4) NOT NULL in column definition(wothout NOT NULL works OK) (5) KEY id (id) in column definition (otherwise it works OK) I also noticed that in C API, mysql_store_result() fails with query "ELECT id FROM test WHERE id<1". Regards, Tianlin WANG - 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
