>>> On 8/7/2008 at 11:44 AM, in message <[EMAIL PROTECTED]>, Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote: > On Thu, Aug 07, 2008 at 09:51:14AM -0600, Brad Nicholes wrote: >> I reverted the workaround in hash.c > > I think we should leave that one in there anyway (maybe as an assert?) as a > hash lookup in a NULL pointer hash is invalid anyway and will result in a > segfault (if we make a mistake somewhere else that goes that path) >
I could go either way on that. If we leave it in, then we run the risk of masking any future problems rather than quickly detecting it because of a segfault. It may make problems harder to find. >> and fixed process_xml.c to process the EXTRA_ELEMENT tag correctly. >> The problem was the fact that the EXTRA_ELEMENT data should only be >> processing this tag if gmetad is in authority mode. It was missing >> a simple check for authority mode that the other tags included. > > nice, does this mean that all other tags were confirmed to have the check? > and could we in this cases get rid as well of the "EXTRA_DATA" tags? > All of the other tags from CLUSTER on down to EXTRA_ELEMENT all include a check for the authority flag. I'm not sure what you mean by "get rid as well of the "EXTRA_DATA" tags". The EXTRA_DATA tag is used to encapsulate multiple EXTRA_ELEMENT tags. Even though the EXTRA_DATA tag does carry a value, it is still needed. >> Everything should be good now with gmetad and once the backport has been >> reviewed, we can included it in the next 3.1.1 release. > > verified it works as expected, at least in the configuration that was > reported > with problems, will be interesting to see how it behaves with sources that > have no authority information (like 2.5 gmetad) though. > > tried it with "scalable off" and seems to be doing the right thing (even if > it > is triggering a double update bug while updating rrds), but that is probably > not a regression specifically from this fix. > > in any case, since 3.1.0 has packages published in fedora, debian and gentoo > as soon as we get an official backport patch will be a good idea to forward > that to them, so that fixed 3.1.0 packages could be used instead of the > current broken ones. > The backport is already in the STATUS file. It does include the revert of hash.c, but I can create a patch that just applies to process_xml.c. Where should be put the patch file? Should it go into www.ganglia.info/releases with the gmond.conf patch file or should we create a www.ganglia.info/patches/3.1.0 location? Brad ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
