Christopher, ----- Original Message ----- From: ""Christopher Stephan"" <[EMAIL PROTECTED]> Newsgroups: mailing.database.mysql Sent: Saturday, December 21, 2002 6:00 PM Subject: Bug Report
> Hello, > following problem occurs using MySql. > Can you help me with that Error? this is memory corruption, possibly a memory overrun by the memory buffer which is being freed when the assertion fails. Can you repeat the crash? It would be very valuable to trace a memory corruption bug. I can send a special memory debug version of mysqld which makes it easier. I have now also added diagnostic code to this assertion in 4.0.7. What distro of MySQL-Max-4.0.6 you are using? Please do the following to resolve the stack dump: go to the directory where the MySQL binaries are and: shell> gzip -d mysqld.sym.gz shell> resolve_stack_dump mysqld.sym <paste the stack dump here> Now it should print a resolved stack dump. If it was a memory overrun, the stack dump would be very valuable. Regards, Heikki Innobase Oy sql query > Betriebssystem: [ SuSE Linux 7.3 (i386) ] > MySql Verision: MySql Max 4.0.6 > OMEGA.ERR: > 021221 14:24:21 InnoDB: Assertion failure in thread 16401 in file > mem0pool.c line 491 > InnoDB: We intentionally generate a memory trap. > InnoDB: Send a detailed bug report to [EMAIL PROTECTED] > InnoDB: Thread 10251 stopped in file row0mysql.c line 92 > 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 against 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=16777216 > read_buffer_size=131072 > sort_buffer_size=524280 > max_used_connections=6 > max_connections=100 > threads_connected=7 > It is possible that mysqld could use up to > key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = > 80383 K > bytes of memory > Hope that's ok; if not, decrease some variables in the equation. > > thd=0x87cea58 > 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... > Cannot determine thread, fp=0xbd9fe508, backtrace may not be correct. > Stack range sanity check OK, backtrace follows: > 0x80da95a > 0x40040bc4 > 0x830e0e5 > 0x830cbd2 > 0x8222d0d > 0x822784b > 0x813ce03 > 0x813f9cf > 0x810cb65 > 0x8106b39 > 0x81067e3 > 0x80ff7b0 > 0x810c099 > 0x80e69c6 > 0x80e8908 > 0x80e4123 > 0x80e9df2 > 0x80e32ff > 0x4003df37 > 0x40199baa > 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 > Trying to get some variables. > Some pointers may be invalid and cause the dump to abort... > thd->query at 0x87db350 = INSERT INTO xselected1 ( issueid, accesskey ) > SELECT xissue.issueid, '1040477060015' FROM xissue INNER JOIN xstatus ON > xissue.attributevalue = xstatus.statusid WHERE (((xissue.projectID)=26) AND > (xissue.deleted <> 'on') AND ((xissue.attributeid=128) And ( > ((xstatus.statusid)<>45) And ((xstatus.statusid)<>46) And > ((xstatus.statusid)<>42) And ((xstatus.statusid)<>42) And > ((xstatus.statusid)<>43) And ((xstatus.statusid)<>44) And > ((xstatus.statusid)<>42) And ((xstatus.statusid)<>42) And > ((xstatus.statusid)<>42) And ((xstatus.statusid)<>42) And > ((xstatus.statusid)<>46) And ((xstatus.statusid)<>42) And > ((xstatus.statusid)<>42) And ((xstatus.statusid)<>42) And > ((xstatus.statusid)<>49) And ((xstatus.statusid)<>49) And > ((xstatus.statusid)<>46) And ((xstatus.statusid)<>43) And > ((xstatus.statusid)<>48) And ((xstatus.statusid)<>48) And > ((xstatus.statusid)<>45) And ((xstatus.statusid)<>45)) Or > (((xissue.attributeid)=128) And ((xstatus.name) Like'%closed%')))) GROUP BY > xissue.issueid > thd->thread_id=7 > > Successfully dumped variables, if you ran with --log, take a look at the > details of what thread 7 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. > > > > Christopher Stephan > [EMAIL PROTECTED] > http://www.xudoo.com > > > --------------------------------------------------------------------- > 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
