Rpmbuild syslog-ng-3.2.4-1.el6: FAIL: test_nvtable
I'm trying to get the EPEL6 syslog-ng-3.2.4-1.el6.src.rpm [1] to rpmbuild on CentOS-5 (eventlog-0.2.12-1.el6.src.rpm worked fine). I'm trying to do that because the EPEL5 version is old syslog-ng-2.1.4-9.el5.src.rpm, and of the very many syslog-ng.spec files I've looked at, I like the EPEL6 one the best. The BB tarball spec seems to require building as root (for chown and ./install) which I don't like, and the EPEL5 and Fedora spec files have a bunch of stuff that I believe is cruft from a CentOS-5 perspective. (And yes, I know that the EPEL6 spec is just an evolution of the previous ones. It's still a lot cleaner and was fixed by someone how knows more about them than I do. :) First, I had to comment out "BuildRequires: tcp_wrappers-devel" since that does not exist in CentOS-5. I am assuming/hoping that that's simply because the packages were split in RHEL6. I've tried with the above comment change, commenting out "--enable-tcp-wrapper" and changing that to "--disable-tcp-wrapper" on both 32 and 64 bit and it *almost* works, but I always get: [...] Assertion strcmp(name, dyn_name) == 0 failed at line 69 FAIL: test_nvtable [...] ==================== 1 of 19 tests failed ==================== make[3]: *** [check-TESTS] Error 1 make[3]: Leaving directory `/home/rpmbuild/BUILD/syslog-ng-3.2.4/tests/unit' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/home/rpmbuild/BUILD/syslog-ng-3.2.4/tests/unit' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/rpmbuild/BUILD/syslog-ng-3.2.4/tests' make: *** [check-recursive] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.4153 (%check) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.4153 (%check) I can't find anything on that in Google, and when I eyeball test_nvtable.c I see where the error is coming from but I have no clue what's causing it to fail. I could probably disable that test, but they are there for a reason. I'm building on both 32 and 64 bit: CentOS release 5.5 (Final) Linux hostname 2.6.18-194.26.1.el5 #1 SMP Tue Nov 9 12:54:40 EST 2010 i686 i686 i386 GNU/Linux Linux hostname 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:52:25 EST 2011 x86_64 x86_64 x86_64 GNU/Linux Any clues anyone? _____________ [1] 'http://download.fedora.redhat.com/pub/epel/6/SRPMS/syslog-ng-3.2.4-1.el6.src...' 'http://download.fedora.redhat.com/pub/epel/6/SRPMS/eventlog-0.2.12-1.el6.src...' 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.
On 2011-06-17 22:30, JP Vossen wrote:
I'm trying to get the EPEL6 syslog-ng-3.2.4-1.el6.src.rpm [1] to rpmbuild on CentOS-5 (eventlog-0.2.12-1.el6.src.rpm worked fine). I'm
FYI: You already have eventlog-0.2.12-1 in the EPEL5 stable repositories.
trying to do that because the EPEL5 version is old syslog-ng-2.1.4-9.el5.src.rpm, and of the very many syslog-ng.spec files I've looked at, I like the EPEL6 one the best. The BB tarball spec seems to require building as root (for chown and ./install) which I don't like, and the EPEL5 and Fedora spec files have a bunch of stuff that I believe is cruft from a CentOS-5 perspective. (And yes, I know that the EPEL6 spec is just an evolution of the previous ones. It's still a lot cleaner and was fixed by someone how knows more about them than I do. :)
;)
First, I had to comment out "BuildRequires: tcp_wrappers-devel" since that does not exist in CentOS-5. I am assuming/hoping that that's simply because the packages were split in RHEL6.
tcp_wrappers in RHEL 5 is still monolithic: just drop the "-devel" substring from the build requirement name. See also: https://bugzilla.redhat.com/show_bug.cgi?id=705486
I've tried with the above comment change, commenting out "--enable-tcp-wrapper" and changing that to "--disable-tcp-wrapper" on both 32 and 64 bit and it *almost* works, but I always get: [...] Assertion strcmp(name, dyn_name) == 0 failed at line 69 FAIL: test_nvtable [...] ==================== 1 of 19 tests failed ==================== make[3]: *** [check-TESTS] Error 1 make[3]: Leaving directory `/home/rpmbuild/BUILD/syslog-ng-3.2.4/tests/unit' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/home/rpmbuild/BUILD/syslog-ng-3.2.4/tests/unit' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/rpmbuild/BUILD/syslog-ng-3.2.4/tests' make: *** [check-recursive] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.4153 (%check) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.4153 (%check)
I can't find anything on that in Google, and when I eyeball test_nvtable.c I see where the error is coming from but I have no clue what's causing it to fail. I could probably disable that test, but they are there for a reason.
I'm building on both 32 and 64 bit: CentOS release 5.5 (Final) Linux hostname 2.6.18-194.26.1.el5 #1 SMP Tue Nov 9 12:54:40 EST 2010 i686 i686 i386 GNU/Linux Linux hostname 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:52:25 EST 2011 x86_64 x86_64 x86_64 GNU/Linux
Any clues anyone?
I still haven't found the time to look into the test failure (low priority item in my todo list) but maybe someone from Balabit could ;) You should be aware that you will be plagued by at least two more problems by building syslog-ng for EPEL5 using the EPEL6 specfile: a logrotate related problem and a nasty macro expansion that causes the pidfile to be created in the wrong directory. Feel free to create a ticket against the EPEL5 syslog-ng package [1] requesting the update to version 3.2.4 and I'll keep up to date. Regards, jpo [1] - Red Hat Bugzilla https://bugzilla.redhat.com/ -- José Pedro Oliveira * mailto:jpo@di.uminho.pt *
On 2011-06-18 03:45, Jose Pedro Oliveira wrote:
On 2011-06-17 22:30, JP Vossen wrote: ---[snip]--- You should be aware that you will be plagued by at least two more problems by building syslog-ng for EPEL5 using the EPEL6 specfile: a logrotate related problem and a nasty macro expansion that causes the pidfile to be created in the wrong directory.
Correction: not the pidfile but the files syslog-ng.ctl and syslog-ng.persist. jpo -- José Pedro Oliveira * mailto:jpo@di.uminho.pt *
On 06/17/2011 10:45 PM, Jose Pedro Oliveira wrote:
On 2011-06-17 22:30, JP Vossen wrote:
I'm trying to get the EPEL6 syslog-ng-3.2.4-1.el6.src.rpm [1] to rpmbuild on CentOS-5 (eventlog-0.2.12-1.el6.src.rpm worked fine). I'm
FYI: You already have eventlog-0.2.12-1 in the EPEL5 stable repositories.
Oh thanks, I didn't even think to look because the target machines don't use EPEL and I'll need to rebuild anyway for policy reasons. ...
First, I had to comment out "BuildRequires: tcp_wrappers-devel" since that does not exist in CentOS-5. I am assuming/hoping that that's simply because the packages were split in RHEL6.
tcp_wrappers in RHEL 5 is still monolithic: just drop the "-devel" substring from the build requirement name. See also: https://bugzilla.redhat.com/show_bug.cgi?id=705486
Duh, that's a better idea. ...
[...] Assertion strcmp(name, dyn_name) == 0 failed at line 69 FAIL: test_nvtable [...] ...
I still haven't found the time to look into the test failure (low priority item in my todo list) but maybe someone from Balabit could ;)
So that's a known issue that is not a problem? RHEL5 only, or 6 too? If 6, how does the rpm even build with that spec file?
You should be aware that you will be plagued by at least two more problems by building syslog-ng for EPEL5 using the EPEL6 specfile: a logrotate related problem and a nasty macro expansion that causes the pidfile to be created in the wrong directory.
OK, thanks for the head's up, I'll look for those.
Feel free to create a ticket against the EPEL5 syslog-ng package [1] requesting the update to version 3.2.4 and I'll keep up to date.
Oh I like that idea even more. I'll do that tomorrow. Thanks for the quick reply! JP
On 06/17/2011 11:19 PM, JP Vossen wrote:
On 06/17/2011 10:45 PM, Jose Pedro Oliveira wrote:
On 2011-06-17 22:30, JP Vossen wrote:
First, I had to comment out "BuildRequires: tcp_wrappers-devel" since that does not exist in CentOS-5. I am assuming/hoping that that's simply because the packages were split in RHEL6.
tcp_wrappers in RHEL 5 is still monolithic: just drop the "-devel" substring from the build requirement name.
Did that, worked fine. ...
[...] Assertion strcmp(name, dyn_name) == 0 failed at line 69 FAIL: test_nvtable [...] ...
I still haven't found the time to look into the test failure (low priority item in my todo list) but maybe someone from Balabit could ;)
So that's a known issue that is not a problem? RHEL5 only, or 6 too? If 6, how does the rpm even build with that spec file?
I got it to build on both archs, but I'm not sure I trust it because I had to comment out 3 parts of test_nvtable.c with the following patch: ----- cut here ----- diff -ruN syslog-ng-3.2.4/tests/unit/test_nvtable.c syslog-ng-3.2.4.jp/tests/unit/test_nvtable.c --- syslog-ng-3.2.4/tests/unit/test_nvtable.c 2010-07-14 03:47:35.000000000 -0400 +++ syslog-ng-3.2.4.jp/tests/unit/test_nvtable.c 2011-06-19 01:46:08.000000000 -0400 @@ -66,7 +66,7 @@ prev_handle = handle; } name = nv_registry_get_handle_name(reg, handle, &len); - TEST_ASSERT(strcmp(name, dyn_name) == 0); +// TEST_ASSERT(strcmp(name, dyn_name) == 0); TEST_ASSERT(strlen(name) == len); g_snprintf(dyn_name, sizeof(dyn_name), "ALIAS%05d", i); @@ -90,13 +90,13 @@ prev_handle = handle; } name = nv_registry_get_handle_name(reg, handle, &len); - TEST_ASSERT(strcmp(name, dyn_name) == 0); +// TEST_ASSERT(strcmp(name, dyn_name) == 0); TEST_ASSERT(strlen(name) == len); } fprintf(stderr, "One error message about too many values is to be expected\n"); handle = nv_registry_alloc_handle(reg, "too-many-values"); - TEST_ASSERT(handle == 0); +// TEST_ASSERT(handle == 0); nv_registry_free(reg); } ----- cut here -----
You should be aware that you will be plagued by at least two more problems by building syslog-ng for EPEL5 using the EPEL6 specfile: a logrotate related problem and a nasty macro expansion that causes [syslog-ng.ctl and syslog-ng.persist] to be created in the wrong directory.
I haven't installed or tested my RPMs yet, so I haven't see these yet. I did see the same results from 'rpm --showrc | grep sharedstatedir' listed in https://bugzilla.redhat.com/show_bug.cgi?id=704690, but I don't see either syslog-ng.ctl or syslog-ng.persist in 'rpm -qlp <my rpm>'. I see /sbin/syslog-ng-ctl though. And I'll be doing my own logrotate and config files post RPM install anyway.
Feel free to create a ticket against the EPEL5 syslog-ng package [1] requesting the update to version 3.2.4 and I'll keep up to date.
https://bugzilla.redhat.com/show_bug.cgi?id=714409 Thanks again, 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.
On Sun, 2011-06-19 at 02:27 -0400, JP Vossen wrote:
On 06/17/2011 11:19 PM, JP Vossen wrote:
On 06/17/2011 10:45 PM, Jose Pedro Oliveira wrote:
On 2011-06-17 22:30, JP Vossen wrote:
...
[...] Assertion strcmp(name, dyn_name) == 0 failed at line 69 FAIL: test_nvtable [...] ...
I still haven't found the time to look into the test failure (low priority item in my todo list) but maybe someone from Balabit could ;)
So that's a known issue that is not a problem? RHEL5 only, or 6 too? If 6, how does the rpm even build with that spec file?
I got it to build on both archs, but I'm not sure I trust it because I had to comment out 3 parts of test_nvtable.c with the following patch:
----- cut here ----- diff -ruN syslog-ng-3.2.4/tests/unit/test_nvtable.c syslog-ng-3.2.4.jp/tests/unit/test_nvtable.c --- syslog-ng-3.2.4/tests/unit/test_nvtable.c 2010-07-14 03:47:35.000000000 -0400 +++ syslog-ng-3.2.4.jp/tests/unit/test_nvtable.c 2011-06-19 01:46:08.000000000 -0400 @@ -66,7 +66,7 @@ prev_handle = handle; } name = nv_registry_get_handle_name(reg, handle, &len); - TEST_ASSERT(strcmp(name, dyn_name) == 0); +// TEST_ASSERT(strcmp(name, dyn_name) == 0); TEST_ASSERT(strlen(name) == len);
g_snprintf(dyn_name, sizeof(dyn_name), "ALIAS%05d", i);
Can you please print the values "name" and "dyn_name" at the failed assertion? Those should really be the same. I can't reproduce it, it runs just fine. (perhaps, a step through the nv_register_get_handle_name function with the relevant variables should help). -- Bazsi
On 2011-06-20 14:55, Balazs Scheidler wrote:
On Sun, 2011-06-19 at 02:27 -0400, JP Vossen wrote:
On 06/17/2011 11:19 PM, JP Vossen wrote:
On 06/17/2011 10:45 PM, Jose Pedro Oliveira wrote:
On 2011-06-17 22:30, JP Vossen wrote:
...
[...] Assertion strcmp(name, dyn_name) == 0 failed at line 69 FAIL: test_nvtable [...] ...
I still haven't found the time to look into the test failure (low priority item in my todo list) but maybe someone from Balabit could ;)
So that's a known issue that is not a problem? RHEL5 only, or 6 too? If 6, how does the rpm even build with that spec file?
I got it to build on both archs, but I'm not sure I trust it because I had to comment out 3 parts of test_nvtable.c with the following patch:
----- cut here ----- diff -ruN syslog-ng-3.2.4/tests/unit/test_nvtable.c syslog-ng-3.2.4.jp/tests/unit/test_nvtable.c --- syslog-ng-3.2.4/tests/unit/test_nvtable.c 2010-07-14 03:47:35.000000000 -0400 +++ syslog-ng-3.2.4.jp/tests/unit/test_nvtable.c 2011-06-19 01:46:08.000000000 -0400 @@ -66,7 +66,7 @@ prev_handle = handle; } name = nv_registry_get_handle_name(reg, handle, &len); - TEST_ASSERT(strcmp(name, dyn_name) == 0); +// TEST_ASSERT(strcmp(name, dyn_name) == 0); TEST_ASSERT(strlen(name) == len);
g_snprintf(dyn_name, sizeof(dyn_name), "ALIAS%05d", i);
Can you please print the values "name" and "dyn_name" at the failed assertion? Those should really be the same.
Changing the test to print the variable values: ---------- $ diff -u ./tests/unit/test_nvtable.c.orig ./tests/unit/test_nvtable.c--- ./tests/unit/test_nvtable.c.orig 2010-07-14 08:47:35.000000000 +0100 +++ ./tests/unit/test_nvtable.c 2011-06-20 17:56:28.000000000 +0100 @@ -66,6 +66,8 @@ prev_handle = handle; } name = nv_registry_get_handle_name(reg, handle, &len); + fprintf(stderr, "name=<%s> dyn_name=<%s>\n", name, dyn_name); + fflush(stderr); TEST_ASSERT(strcmp(name, dyn_name) == 0); TEST_ASSERT(strlen(name) == len); ---------- produces: ---------- ... name=<DYN00004> dyn_name=<DYN00004> name=<DYN00005> dyn_name=<DYN00005> name=<DYN00006> dyn_name=<DYN00006> name=<DYN00007> dyn_name=<DYN00007> name=<DYN00008> dyn_name=<DYN00008> name=<DYN00009> dyn_name=<DYN00009> name=<DYN00010> dyn_name=<DYN00010> name=<DYN00011> dyn_name=<DYN00011> name=<DYN00012> dyn_name=<DYN00012> name=<DYN00004> dyn_name=<DYN00013> Assertion strcmp(name, dyn_name) == 0 failed at line 71 ... ----------
I can't reproduce it, it runs just fine.
Only fails in EPEL5 (RHEL 5.x / CentOS 5.x ); doesn't fail in EPEL6 or in Fedora 13 (or newer)
(perhaps, a step through the nv_register_get_handle_name function with the relevant variables should help).
/jpo -- José Pedro Oliveira * mailto:jpo@di.uminho.pt *
On 2011-06-20 14:55, Balazs Scheidler wrote:
On Sun, 2011-06-19 at 02:27 -0400, JP Vossen wrote:
On 06/17/2011 11:19 PM, JP Vossen wrote:
On 06/17/2011 10:45 PM, Jose Pedro Oliveira wrote:
On 2011-06-17 22:30, JP Vossen wrote:
...
[...] Assertion strcmp(name, dyn_name) == 0 failed at line 69 FAIL: test_nvtable [...] ...
I still haven't found the time to look into the test failure (low priority item in my todo list) but maybe someone from Balabit could ;)
So that's a known issue that is not a problem? RHEL5 only, or 6 too? If 6, how does the rpm even build with that spec file?
I got it to build on both archs, but I'm not sure I trust it because I had to comment out 3 parts of test_nvtable.c with the following patch:
----- cut here ----- diff -ruN syslog-ng-3.2.4/tests/unit/test_nvtable.c syslog-ng-3.2.4.jp/tests/unit/test_nvtable.c --- syslog-ng-3.2.4/tests/unit/test_nvtable.c 2010-07-14 03:47:35.000000000 -0400 +++ syslog-ng-3.2.4.jp/tests/unit/test_nvtable.c 2011-06-19 01:46:08.000000000 -0400 @@ -66,7 +66,7 @@ prev_handle = handle; } name = nv_registry_get_handle_name(reg, handle, &len); - TEST_ASSERT(strcmp(name, dyn_name) == 0); +// TEST_ASSERT(strcmp(name, dyn_name) == 0); TEST_ASSERT(strlen(name) == len);
g_snprintf(dyn_name, sizeof(dyn_name), "ALIAS%05d", i);
Can you please print the values "name" and "dyn_name" at the failed assertion? Those should really be the same.
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 jpo -- José Pedro Oliveira * mailto:jpo@di.uminho.pt *
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:
Thanks for the information, if it's a glib bug then, can I help you in any way? Or I can "close" the issue? -- Bazsi
On 2011-06-24 12:19, Balazs Scheidler 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:
Thanks for the information, if it's a glib bug then, can I help you in any way? Or I can "close" the issue?
You can close the issue. I have re-assigned the problem to the glib2 component of RHEL5. jpo -- José Pedro Oliveira * mailto:jpo@di.uminho.pt *
On 06/24/2011 07:19 AM, Balazs Scheidler 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:
Thanks for the information, if it's a glib bug then, can I help you in any way? Or I can "close" the issue?
I see that Jose already forwarded the bug, but I wonder; can you tell me what impact the failed test (and thus failed or potentially failed code block) may have on syslog-ng run-time on CentOS-5/RHEL5? 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... 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.
Hi, On Sat, 2011-06-25 at 04:49 -0400, JP Vossen wrote:
On 06/24/2011 07:19 AM, Balazs Scheidler 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:
Thanks for the information, if it's a glib bug then, can I help you in any way? Or I can "close" the issue?
I see that Jose already forwarded the bug, but I wonder; can you tell me what impact the failed test (and thus failed or potentially failed code block) may have on syslog-ng run-time on CentOS-5/RHEL5?
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. 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. -- Bazsi
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?
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. 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.
----- 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
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.
On Thu, 2011-07-14 at 21:56 -0400, JP Vossen wrote:
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
Well, syslog-ng uses hash tables a number of ways, but so does a lot of different programs. I think there's a different issue here. I've tried to recompile syslog-ng against the glib src.rpm coming from CentOS 5. The tests passed correctly. The program that is in the quoted bug report is however not completely correct. It formats the hash key in a static variable, inserts it into the hash, and then changes the key in place, effectively modifying the hash key. This is different from the unit test, which had the failure in the first place. There the key is duped in nv_registry_alloc_handle(), so the same corruption wouldn't happen. I don't have more time to take care about issue right now, any further investigation would be appreciated. Thanks in advance. -- Bazsi
On 2011-06-18 04:19, JP Vossen wrote:
On 06/17/2011 10:45 PM, Jose Pedro Oliveira wrote:
On 2011-06-17 22:30, JP Vossen wrote: ...
[...] Assertion strcmp(name, dyn_name) == 0 failed at line 69 FAIL: test_nvtable [...] ...
I still haven't found the time to look into the test failure (low priority item in my todo list) but maybe someone from Balabit could ;)
So that's a known issue that is not a problem? RHEL5 only, or 6 too? If 6, how does the rpm even build with that spec file?
I have only seen this test fail in EPEL5 (no problems in Fedora 13,14,15,rawhide and in EPEL6). jpo -- José Pedro Oliveira * mailto:jpo@di.uminho.pt *
participants (3)
-
Balazs Scheidler
-
Jose Pedro Oliveira
-
JP Vossen