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
