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. 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 will print >> >> a lot of info to the standard output >> >> of mysqld. That may help me to find >> >> the bug. The program should still assert, >> >> I did not make it to ignore the error >> >> yet. >> >> >> >> Another option is that I log on >> >> your computer and run mysqld inside >> >> gdb? That is an old and proven >> >> method in bug fixing. >> >> >> >> I assume your data files are so big >> >> (even when compressed with gzip) that >> >> that they cannot be uploaded to >> >> the 'secret' dir at ftp.mysql.com? >> >> You could try compressing them. >> >> >> >> Regards, >> >> >> >> Heikki >> >> >> >> At 01:24 PM 9/27/01 -0400, you wrote: >> >> >Heikki, >> >> > >> >> >> Does it assert immediately after the startup >> >> >> with no other database activity? >> >> >Yes. >> >> > >> >> >> Do you compile MySQL yourself? >> >> >Yes. We're dropping release builds w/o symbols. >> >> > >> >> >Chris >> >> > >> >> > >> >> >On Thu, 27 Sep 2001, Heikki Tuuri wrote: >> >> > >> >> >> Hi! >> >> >> >> >> >> It is not just a possible bug, but definitely >> >> >> a bug. >> >> >> >> >> >> Does it assert immediately after the startup >> >> >> with no other database activity? >> >> >> >> >> >> It tries to merge records in the insert >> >> >> buffer to your index tree. But for some >> >> >> reason repositioning of the cursor in the >> >> >> insert buffer fails. >> >> >> >> >> >> I will look to this now. It may be that >> >> >> your database is not corrupted, and the bug >> >> >> is actually in the insert buffer merge >> >> >> algorithm. >> >> >> >> >> >> Do you compile MySQL yourself? I can send >> >> >> you a patched ibuf0ibuf.c which will print >> >> >> more info of the error. And I can also make >> >> >> it to ignore the error altogether so that >> >> >> you get your database up again. >> >> >> >> >> >> Regards, >> >> >> >> >> >> Heikki >> >> >> >> >> >> At 08:37 AM 9/27/01 -0400, you wrote: >> >> >> >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
