----- Original message -----
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). More details in: * https://bugzilla.redhat.com/show_bug.cgi?id=714409#c7
[...]
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.
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. -- Bazsi