← Back to team overview

maria-developers team mailing list archive

Re: bzr commit into MySQL/Maria:mysql-maria branch (monty:2725) Bug#40711

 

Hi!

>>>>> "Guilhem" == Guilhem Bichot <guilhem@xxxxxxx> 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