List:Commits« Previous MessageNext Message »
From:Sergei Golubchik Date:August 5 2007 4:29pm
Subject:Re: bk commit into 5.0 tree (svoj:1.2487) BUG#28812
View as plain text  
Hi!

On Jul 31, Sergey Vojtovich wrote:
> ChangeSet@stripped, 2007-07-31 17:04:24+05:00, svoj@stripped +1 -0
>   BUG#28812 - rpl_ssl fails due to assert in
>               extra/yassl/src/socket_wrapper.cpp:117
>   
>   yaSSL related part of this problem was fixed by Damien (see BUG29579).
>   
>   MySQL server part of this problem is:
>   Issuing STOP SLAVE may cause assertion failure in debug builds on following
>   platforms: HPUX, MacOS X, Windows.
>   
>   Fixed by disabling assertion on these platforms.
> 
>   vio/viosocket.c@stripped, 2007-07-31 17:04:18+05:00, svoj@stripped +12 -1
>     We may enter vio_close() concurrently on platforms with active_vio hack
>     enabled. This may happen for example with the following stack trace:
>     thr1: STOP SLAVE/THD::awake()/close_active_vio()/vio_close()

This touches a suspicious code:

THD::awake(NOT_KILLED) -> close_active_vio()
The condition in THD::awake() is

  if (state_to_set != THD::KILL_QUERY)
  {
    thr_alarm_kill(real_id);
#ifdef SIGNAL_WITH_VIO_CLOSE
    close_active_vio();
#endif    
  }

which doesn't look correct to me. Indeed, close_active_vio() implies
we're disconnecting, and if() prevents it when the intention is to kill
the query only, not the connection. But also, we don't want to
disconnect if state_to_set is KILL_BAD_DATA or NOT_KILLED, do we ?
Should this if() really be

     if (state_to_set == THD::KILL_CONNECTION)

perhaps ?

Regards / Mit vielen Grüssen,
Sergei

-- 
   __  ___     ___ ____  __
  /  |/  /_ __/ __/ __ \/ /   Sergei Golubchik <serg@stripped>
 / /|_/ / // /\ \/ /_/ / /__  Principal Software Developer
/_/  /_/\_, /___/\___\_\___/  MySQL GmbH, Radlkoferstr. 2, D-81373 München
       <___/                  Geschäftsführer: Kaj Arnö - HRB
München 162140
Thread
bk commit into 5.0 tree (svoj:1.2487) BUG#28812Sergey Vojtovich31 Jul
  • Re: bk commit into 5.0 tree (svoj:1.2487) BUG#28812Sergei Golubchik6 Aug