On Mon, Apr 08, 2002 at 05:10:14PM -0700, matt massie wrote:
> asaph-
>
> > I think the problem still exists even with this fix.
>
> did you test that this problem still exists and if so can you give me the
> platform and error? please make it clearer when you post to the list
> whether the bug you are reporting is real or theoretical.
At this point the problem is "theoretical" in gmond - I did not
encounter it in practice when using ganglia.
I have encountered instances of this style of problem
in other programs so I know it is potentially real.
>
> even if this is a theoretical bug it is important. to be absolutely sure
> there is no problems in the future, i've declare two separate barrier
> pointers and i don't ever free the data they point to. this increases the
> memory footprint of gmond by 96 bytes but i think that we can live with
> that.
>
When you say "two barriers" I take it you are referring to the code
in gmond.c lines 107-121. If so, I think you'd be fine with
changing those to:
107 barrier_init(&b1, args_info.mcast_threads_arg );
108 for ( i = 0 ; i < args_info.mcast_threads_arg; i++ )
109 {
110 pthread_create(&tid, &attr, mcast_listen_thread, (void *)b1);
111 }
>>>>> REMOVED 112 barrier_destroy(b);
113 debug_msg("listening thread(s) have been started");
114
115 /* threads to answer requests for XML */
116 barrier_init(&b2, args_info.xml_threads_arg);
117 for ( i=0 ; i < args_info.xml_threads_arg; i++ )
118 {
119 pthread_create(&tid, &attr, server_thread, (void *)b2);
120 }
>>>>> REMOVED 121 barrier_destroy(b);
i.e. using two different barriers which you never free. In this
case the master need not participate in the barrier.
Thanks!
Asaph
On Mon, Apr 08, 2002 at 05:10:14PM -0700, matt massie wrote:
> asaph-
>
> > I think the problem still exists even with this fix.
>
> did you test that this problem still exists and if so can you give me the
> platform and error? please make it clearer when you post to the list
> whether the bug you are reporting is real or theoretical.
> thanks for your technical expertise
> -matt
>
> > You don't know the order by which threads leave the barrier,
> > so you might still be calling barrier_destroy() while there
> > are threads accessing b.
> >
> > In general this kind of scheme:
> >
> > thread1:
> > b = allocate_barrier();
> > spawn_threads(b);
> > wait_barrier(b);
> > free(b);
> >
> >
> > threadnN:
> > wait_barrier(b);
> >
> > can't work because you have threads 1..N all accessing the
> > data structure pointed to by b simultaneously, and you have
> > no control over which one will exit wait_barrier() first.
> > If it happens to be thread1, then it will free() b while
> > other threads are still reading the data pointed to by b.
> >
> > If you REALLY want to solve this, I think you'd need two
> > barriers:
> >
> >
> > thread1:
> > b2 = static_barrier;
> > b1 = allocate_barrier();
> > spawn_threads(b1,b2);
> > wait_barrier(b1);
> > wait_barrier(b2);
> > free(b1);
> > // b2 is never freed
> >
> >
> > threadnN:
> > wait_barrier(b1);
> > wait_barrier(b2);
> >
> > Of course, this is only interesting if you can't make do with just
> > having only static barriers. If you are in a situation that you
> > absolutely must allocate and free the memory held by the barriers
> > I don't know of another safe way to do this.
> >
> >
> > On Mon, Apr 08, 2002 at 03:48:41PM -0700, matt massie wrote:
> > > mike-
> > >
> > > you can blame me for the problem you were having. i didn't code the
> > > barriers correctly in gmond. the machines i tested gmond on before i
> > > released it didn't display the problem so i released it with this bug...
> > >
> > > if you look at line 108 of gmond you'll see i initialize a barrier and
> > > then pass it to the mcast_threads that i spin off. directly afterwards i
> > > run a barrier_destroy(). bad.
> > >
> > > if the main gmond runs the barrier_destroy() BEFORE all the mcast_threads
> > > can run a barrier_barrier() then you will have a problem. the mcast
> > > threads will be operating on freed memory... otherwise.. everthing is
> > > peachy.
> > >
> > > the fix was just to increase the barrier count by one and place a
> > > barrier_barrier() just before the barrier_destroy() to force the main
> > > thread to wait until all the mcast threads are started.
> > >
> > > thanks so much for the feedback.
> > >
> > > also, i added the --no_setuid and --setuid flags in order to give you
> > > more
> > > debugging power. i know you were having trouble creating a core file
> > > because gmond sets the uid to the uid of "nobody". you can prevent gmond
> > > from starting up as nobody with the "--no_setuid" flag.
> > >
> > > good luck! and please let me know if i didn't solve your problem!
> > > -matt
> > >
> > > Saturday, Mike Snitzer wrote forth saying...
> > >
> > > > gmond segfaults 50% of the time at startup. The random nature of it
> > > > suggests to me that their is a race condition when the gmond threads
> > > > startup. When I tried to strace or run gmond through gdb the problem
> > > > wasn't apparant.. which is what led me to believe it's a threading
> > > > problem
> > > > that strace or gdb masks.
> > > >
> > > > Any recommendations for accurately debugging gmond would be great; cause
> > > > when running through strace and gdb I can't get it to segfault.
> > > >
> > > > FYI, I'm running gmond v2.2.2 on 48 nodes of those 16 of the nodes'
> > > > gmond
> > > > segfaulted at startup...
> > > >
> > > > Mike
> > > >
> > > > ps.
> > > > here's an example:
> > > > `which gmond` --debug_level=1 -i eth0
> > > >
> > > > mcast_listen_thread() received metric data cpu_speed
> > > > mcast_value() mcasting cpu_user value
> > > > 2051 pre_process_node() remote_ip=192.168.0.28encoded 8 XDR
> > > > bytespre_process_node() has saved the hostname
> > > > pre_process_node() has set the timestamp
> > > > pre_process_node() received a new node
> > > >
> > > >
> > > > XDR data successfully sent
> > > > set_metric_value() got metric key 11
> > > > set_metric_value() exec'd cpu_nice_func (11)
> > > > Segmentation fault
> > > >
> > > >
> > > > _______________________________________________
> > > > Ganglia-general mailing list
> > > > [email protected]
> > > > https://lists.sourceforge.net/lists/listinfo/ganglia-general
> > > >
> > >
> > >
> > > _______________________________________________
> > > Ganglia-general mailing list
> > > [email protected]
> > > https://lists.sourceforge.net/lists/listinfo/ganglia-general
> > >
> > > Sponsored by http://www.ThinkGeek.com/
> >
>
