On 07/14/2011 03:14 PM, Balazs Scheidler wrote:
On 07/14/2011 03:16 AM, Balazs Scheidler wrote:
On Sat, 2011-06-25 at 04:49 -0400, JP Vossen wrote:
On Mon, 2011-06-20 at 20:59 +0100, Jose Pedro Oliveira wrote:
There is a problem with the hash table implementation of glib2 version 2.12.3-4 (version that ships in RHEL 5.x).
Is this hash problem going to cause critical failures? Under what circumstances? Or is it, well, it'd be nice if that hash problem didn't happen, but it's not a big deal...
Well, it probably mostly depends on why the hashtable collides in that glib version. This hash is a global hash that maps name-value pairs to their own unique IDs, which is then used to track name-value pairs in log messages.
Sorry if I am being dense. What name-value pairs used for what? Would this impact a basic syslog-ng config that emulates the sysklogd config? What syslog-ng features need to be in use to trigger this?
For syslog-ng a log message is a set of name-value pairs. Basic syslog properties like $HOST or $MSG as well. The only exceptions are the $PRI and $DATE fields.
But syslog-ng uses hash tables for a number of other things, so this can cause other bugs as well.
Ouch, that sounds like a show-stopper for using 3.2.x. on un-fixed RHEL-5/CentOS-5. So I wondered what I can use safely? Or am I over-reacting? First I tried looking for any '*nvtable*' file, and 3.0.9 has none while 3.1.4 and 3.2.4 have some. But then I looked at https://bugzilla.redhat.com/show_bug.cgi?id=716447 and started looking for 'g_hash_table' and that's not too good. I found lots of hits for 'g_hash_table' [1] in every version of syslog-ng I had laying around: syslog-ng-2.1.4 syslog-ng-3.0.9 syslog-ng-3.1.4 syslog-ng-3.2.4 [1] $ grep -Rc 'g_hash_table' syslog-ng-2.1.4/* syslog-ng-3.0.9/* syslog-ng-3.1.4/* syslog-ng-3.2.4/* | grep -v ':0$' Does anyone know what is the latest syslog-ng that can safely be used on un-fixed RHEL-5/CentOS-5? What is a valid test to look for this problem (if nvtable files or g_hash_table isn't)?
In case the hash table returns non-matching elements, it means that two (or more) different name-value pairs will map to the same id, effectively one overwriting the other. Whether it happens in practice actually depends on what the exact bug in glib is.
Given how old CentOS-5 is, I wonder that this hasn't been noticed and reported before now. Perhaps that means it's rare to hit it in practice? Or maybe just really hard to identify the root cause.
I think the misbehaviour is difficult to notice, and the root cause is not easy either.
I've checked the glib history, but I've found no patch that jumped out.
The bug is still open (but also brand new): https://bugzilla.redhat.com/show_bug.cgi?id=716447 Thanks, JP ----------------------------|:::======|------------------------------- JP Vossen, CISSP |:::======| http://bashcookbook.com/ My Account, My Opinions |=========| http://www.jpsdomain.org/ ----------------------------|=========|------------------------------- "Microsoft Tax" = the additional hardware & yearly fees for the add-on software required to protect Windows from its own poorly designed and implemented self, while the overhead incidentally flattens Moore's Law.