developers

Download

developers@lists.mariadb.org

1 participants
6832 discussions

[Maria-developers] Fw: Launchpad offline 00.00 - 01.00 UTC 26th February 2009
by Kurt von Finck 25 Feb '09

25 Feb '09

Begin forwarded message: Date: Tue, 24 Feb 2009 18:09:57 +0000 From: Matthew Revell To: redacted internal Canonical list Subject: Launchpad offline 00.00 - 01.00 UTC 26th February 2009 Launchpad will be offline from 00.00 - 01.00 UTC on Thursday 26th February. This is to allow us to roll-out the code for our latest release, Launchpad 2.2.2. Please see the Launchpad blog -- http://blog.launchpad.net -- for details of the release! -- Matthew Revell - Launchpad.net - free software collaboration and project hosting -- Launchpad-announce mailing list Launchpad-announce(a)lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/launchpad-announce -- ./k kurt von finck http://www.mneptok.com public key: keyserver.ubuntu.com key id: 5229D26A fingerprint: 127A A484 ADBF A5AD E7FB 8CD2 8913 18F4 5229 D26A Music is the space between the notes. - Debussy

1 0

Re: [Maria-developers] bzr commit into MySQL/Maria:mysql-maria branch (monty:2725) Bug#40711
by Michael Widenius 25 Feb '09

25 Feb '09

Hi! >>>>> "Guilhem" == Guilhem Bichot <guilhem(a)sun.com> writes: <cut> >> +++ b/storage/maria/ma_close.c 2009-02-01 07:29:56 +0000 >> @@ -155,7 +155,7 @@ int maria_close(register MARIA_HA *info) >> MARIA_STATE_HISTORY_CLOSED *history; >> /* >> Here we ignore the unlikely case that we don't have memory to >> - store the case. In the worst case what happens is that any transaction >> + store the state. In the worst case what happens is that any transaction >> that tries to access this table will get a wrong status information. >> */ >> if ((history= (MARIA_STATE_HISTORY_CLOSED *) >> @@ -166,6 +166,8 @@ int maria_close(register MARIA_HA *info) >> if (my_hash_insert(&maria_stored_state, (uchar*) history)) >> my_free(history, MYF(0)); >> } >> + /* Marker for concurrent checkpoint */ >> + share->state_history= 0; >> } >> } >> pthread_mutex_unlock(&THR_LOCK_maria); Guilhem> So, what was the scenario? Guilhem> I imagined this one: Thread1 has just closed the table, but Thread2 had Guilhem> started a checkpoint, so Thread1 leaves the share in existence; Thread2 Guilhem> looks at share->state_history, but why would that point to freed memory? Guilhem> Is it because there is a Thread3 which did this freeing? No, the problem happens with only two threads. T1 one goes into the above code and creates a history entry that points to share->state_history. In checkpoint thread we will then execute the following code: _ma_remove_not_visible_states_with_lock(share, FALSE); Which uses share->state_history entry and may even free it. If free happens, we are likely to get a crash as history entry now points to freed memory. Regards, Monty

1 0

Jump to page: