[Pacemaker] [Problem]When Pacemaker uses a new version of glib, g_source_remove fails.

renayama19661014 at ybb.ne.jp renayama19661014 at ybb.ne.jp
Tue Oct 7 02:15:02 UTC 2014


Hi Andrew,

> Not quite. Returning FALSE from the callback also removes the source from glib.
> So your test case effectively removes t1 twice: once implicitly by returning 
> FALSE in timer_func1() and then again explicitly in timer_func3()


Your opinion is right.


If Pacemaker repeats and does not remove the resources which timer concluded in FALSE, glib does not return the error.


Many Thanks,
Hideo Yamauchi.


----- Original Message -----
> From: Andrew Beekhof <andrew at beekhof.net>
> To: renayama19661014 at ybb.ne.jp
> Cc: The Pacemaker cluster resource manager <pacemaker at oss.clusterlabs.org>
> Date: 2014/10/7, Tue 11:06
> Subject: Re: [Pacemaker] [Problem]When Pacemaker uses a new version of glib, g_source_remove fails.
> 
> 
> On 7 Oct 2014, at 1:03 pm, renayama19661014 at ybb.ne.jp wrote:
> 
>>  Hi Andrew,
>> 
>>>>  These problems seem to be due to a correction of next glib somehow 
> or 
>>>  other.
>>>>    * 
>>> 
> https://github.com/GNOME/glib/commit/393503ba5bdc7c09cd46b716aaf3d2c63a6c7f9c
>>>   
>>>  The glib behaviour on unbuntu seems reasonable, removing a source 
> multiple times 
>>>  IS a valid error.
>>>  I need the stack trace to know where/how this situation can occur in 
> pacemaker.
>> 
>> 
>>  Pacemaker does not remove resources several times as far as I confirmed it.
>>  In Ubuntu(glib2.40), an error occurs just to remove resources first.
> 
> Not quite. Returning FALSE from the callback also removes the source from glib.
> So your test case effectively removes t1 twice: once implicitly by returning 
> FALSE in timer_func1() and then again explicitly in timer_func3()
> 
>> 
>>  Confirmation and the deletion of resources seem to be necessary not to 
> produce an error in Ubuntu.
>>  And this works well in glib of RHEL6.x.(and RHEL7.0)
>> 
>>          if (g_main_context_find_source_by_id (NULL, t1) != NULL) {
>>                  g_source_remove(t1);
>>          }
>> 
>>  I send it to you after acquiring stack trace.
>> 
>>  Many Thanks!
>>  Hideo Yamauchi.
>> 
>>  ----- Original Message -----
>>>  From: Andrew Beekhof <andrew at beekhof.net>
>>>  To: renayama19661014 at ybb.ne.jp; The Pacemaker cluster resource manager 
> <pacemaker at oss.clusterlabs.org>
>>>  Cc: 
>>>  Date: 2014/10/7, Tue 09:44
>>>  Subject: Re: [Pacemaker] [Problem]When Pacemaker uses a new version of 
> glib, g_source_remove fails.
>>> 
>>> 
>>>  On 6 Oct 2014, at 4:09 pm, renayama19661014 at ybb.ne.jp wrote:
>>> 
>>>>  Hi All,
>>>> 
>>>>  When I move the next sample in RHEL6.5(glib2-2.22.5-7.el6) and 
>>>  Ubuntu14.04(libglib2.0-0:amd64 2.40.0-2), movement is different.
>>>> 
>>>>    * Sample : test2.c
>>>>  {{{
>>>>  #include <stdio.h>
>>>>  #include <stdlib.h>
>>>>  #include <glib.h>
>>>>  #include <sys/times.h>
>>>>  guint t1, t2, t3;
>>>>  gboolean timer_func2(gpointer data){
>>>>           printf("TIMER EXPIRE!2\n");
>>>>           fflush(stdout);
>>>>           return FALSE;
>>>>  }
>>>>  gboolean timer_func1(gpointer data){
>>>>           clock_t         ret;
>>>>           struct tms buff;
>>>> 
>>>>           ret = times(&buff);
>>>>           printf("TIMER EXPIRE!1 %d\n", (int)ret);
>>>>           fflush(stdout);
>>>>           return FALSE;
>>>>  }
>>>>  gboolean timer_func3(gpointer data){
>>>>           printf("TIMER EXPIRE 3!\n");
>>>>           fflush(stdout);
>>>>           printf("remove timer1!\n");
>>>> 
>>>>           fflush(stdout);
>>>>           g_source_remove(t1);
>>>>           printf("remove timer2!\n");
>>>>           fflush(stdout);
>>>>           g_source_remove(t2);
>>>>           printf("remove timer3!\n");
>>>>           fflush(stdout);
>>>>           g_source_remove(t3);
>>>>           return FALSE;
>>>>  }
>>>>  int main(int argc, char** argv){
>>>>           GMainLoop *m;
>>>>           clock_t         ret;
>>>>           struct tms buff;
>>>>           gint64 t;
>>>>           m = g_main_new(FALSE);
>>>>           t1 = g_timeout_add(1000, timer_func1, NULL);
>>>>           t2 = g_timeout_add(60000, timer_func2, NULL);
>>>>           t3 = g_timeout_add(5000, timer_func3, NULL);
>>>>           ret = times(&buff);
>>>>           printf("START! %d\n", (int)ret);
>>>>           g_main_run(m);
>>>>  }
>>>> 
>>>>  }}}
>>>>    * Result
>>>>  ---- RHEL6.5(glib2-2.22.5-7.el6) ---- 
>>>>  [root at snmp1 ~]# ./test2
>>>>  START! 429576012
>>>>  TIMER EXPIRE!1 429576112
>>>>  TIMER EXPIRE 3!
>>>>  remove timer1!
>>>>  remove timer2!
>>>>  remove timer3!
>>>> 
>>>>  ---- Ubuntu14.04(libglib2.0-0:amd64 2.40.0-2) ----
>>>>  root at a1be102:~# ./test2
>>>>  START! 1718163089
>>>>  TIMER EXPIRE!1 1718163189
>>>>  TIMER EXPIRE 3!
>>>>  remove timer1!
>>>> 
>>>>  (process:1410): GLib-CRITICAL **: Source ID 1 was not found when 
> attempting 
>>>  to remove it
>>>>  remove timer2!
>>>>  remove timer3!
>>>> 
>>>> 
>>>>  These problems seem to be due to a correction of next glib somehow 
> or 
>>>  other.
>>>>    * 
>>> 
> https://github.com/GNOME/glib/commit/393503ba5bdc7c09cd46b716aaf3d2c63a6c7f9c
>>> 
>>>  The glib behaviour on unbuntu seems reasonable, removing a source 
> multiple times 
>>>  IS a valid error.
>>>  I need the stack trace to know where/how this situation can occur in 
> pacemaker.
>>> 
>>>> 
>>>>  In g_source_remove() until before change, the deletion of the timer 
> which 
>>>  practice completed is possible, but g_source_remove() after the change 
> causes an 
>>>  error.
>>>> 
>>>>  Under this influence, we get the following crit error in the 
> environment of 
>>>  Pacemaker using a new version of glib.
>>>> 
>>>>  lrmd[1632]:    error: crm_abort: crm_glib_handler: Forked child 
> 1840 to 
>>>>  record non-fatal assert at logging.c:73 : Source ID 51 was not 
> found when 
>>>>  attempting to remove it
>>>>  lrmd[1632]:    crit: crm_glib_handler: GLib: Source ID 51 was not 
> found 
>>>>  when attempting to remove it
>>>> 
>>>>  It seems that some kind of coping is necessary in Pacemaker when I 
> think 
>>>  about next.
>>>>    * Distribution using a new version of glib including Ubuntu.
>>>>    * Version up of future glib of RHEL.
>>>> 
>>>>  A similar problem is reported in the ML.
>>>>    * 
> http://www.gossamer-threads.com/lists/linuxha/pacemaker/91333#91333
>>>>    * http://www.gossamer-threads.com/lists/linuxha/pacemaker/92408
>>>> 
>>>>  Best Regards,
>>>>  Hideo Yamauchi.
>>>> 
>>>>  _______________________________________________
>>>>  Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
>>>>  http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>>>> 
>>>>  Project Home: http://www.clusterlabs.org
>>>>  Getting started: 
> http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>>>>  Bugs: http://bugs.clusterlabs.org
>>> 
> 




More information about the Pacemaker mailing list