Jeremy,

it looks like this crash can happen if you use MySQL 'user level locks'
which are kind of semaphores. In that case MySQL will write a binlog entry
even after THD::cleanup where the transaction handle is freed.

>From the manual:
"You can also solve some cases by using the user-level lock functions
GET_LOCK() and RELEASE_LOCK()."

I believe the patch below to ha_innobase.cc fixes the problem.

Regards,

Heikki

----- Original Message -----
From: "Heikki Tuuri" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, May 29, 2002 1:16 PM
Subject: Re: InnoDB crash repeated under 3.23.51...


> Jeremy,
>
> I think this happens because the InnoDB transaction handle has already
been
> freed in end_thread when MySQL still writes one log item for the
connection.
> Please test the following patch. Replace the function
> innobase_close_connection with the one below. I forgot to set innobase_tid
> to NULL when the handle is freed.
>
> Best regards,
>
> Heikki
>
> /*********************************************************************
> Frees a possible InnoDB trx object associated with the current
> THD. */
>
> int
> innobase_close_connection(
> /*======================*/
>    /* out: 0 or error number */
>  THD* thd) /* in: handle to the MySQL thread of the user
>    whose transaction should be rolled back */
> {
>  if (NULL != thd->transaction.all.innobase_tid) {
>
>          trx_rollback_for_mysql((trx_t*)
>     (thd->transaction.all.innobase_tid));
>   trx_free_for_mysql((trx_t*)
>     (thd->transaction.all.innobase_tid));
>   thd->transaction.all.innobase_tid = NULL;
>  }
>
>  return(0);
> }
>
>
> ----- Original Message -----
> From: "Jeremy Zawodny" <[EMAIL PROTECTED]>
> To: "Heikki Tuuri" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Wednesday, May 29, 2002 10:13 AM
> Subject: InnoDB crash repeated under 3.23.51...
>
>
> > Heikki,
> >
> > After a good 6-8 hours of runnning, the server just restarted itself
> > (running the most recent build from the 3.23.xx tree, as you
> > suggested).  I got this message:
> >
> > InnoDB: Assertion failure in thread 42527756 in file ha_innobase.cc
> > line 316
> > InnoDB: We intentionally generate a memory trap.
> > InnoDB: Send a detailed bug report to [EMAIL PROTECTED]
> > mysqld got signal 11;
> >
> > And then the stack trace, which resolved as:
> >
> > 0x807d764 handle_segfault__Fi + 428
> > 0x824cc98 pthread_sighandler + 176
> > 0x80cc16a innobase_commit__FP3THDPv + 174
> > 0x80ceba6 innobase_report_binlog_offset_and_commit__FP3THDPvPcUx + 42
> > 0x80c774c ha_report_binlog_offset_and_commit__FP3THDPcUx + 44
> > 0x80b11d2 write__9MYSQL_LOGP15Query_log_event + 1346
> > 0x8051a90 item_user_lock_release__FP3ULL + 548
> > 0x807502d _._3THD + 277
> > 0x807d444 end_thread__FP3THDb + 64
> > 0x80830c1 handle_one_connection__FPv + 1109
> >
> > I hope that's meaningful to you...
> >
> > The machine was doig about 800 - 1,000 queries per second when this
> > happened.  Most of them were *not* InnoDB, but some were.
> >
> > Let me know if there's any other data I can send you to help track
> > this down.  I'll probably convert my tables back to MyISAM soon.
> >
> > Jeremy
> > --
> > Jeremy D. Zawodny, <[EMAIL PROTECTED]>
> > Technical Yahoo - Yahoo Finance
> > Desk: (408) 349-7878   Fax: (408) 349-5454   Cell: (408) 685-5936
> >
> > MySQL 3.23.51: up 0 days, processed 318,464 queries (1061/sec. avg)
>



---------------------------------------------------------------------
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

Reply via email to