Description of problem: The test suite of syslog-ng (bug 714409 comments 4 to 7) exposes collisions problems in the GHashTable implementation of glib2-2.12.3. Version-Release number of selected component (if applicable): glib2-2.12.3-4 How reproducible: Always. Steps to Reproduce: See example code below. Actual results: Collisions. Expected results: No collisions (eg: glib2-2.22.5, glib2-2.28). Example code that exposes the problem: ---------- #include <stdio.h> #include <glib.h> // gcc -Wall -Wextra `pkg-config glib-2.0 --cflags` `pkg-config glib-2.0 --libs` ghashtable.c void insert(GHashTable *name_map, const gchar *name) { printf("hash insert: key = <%s>: ", name); gpointer p = g_hash_table_lookup(name_map, name); if (p) { printf("found (ARGH)\n"); } else { printf("not found\n"); g_hash_table_insert(name_map, (gpointer)name, (gpointer)name); } } int main(void) { int i; GHashTable *h = g_hash_table_new(g_str_hash, g_str_equal); for (i = 4; i < 15; i++) { gchar dyn_name[16]; g_snprintf(dyn_name, sizeof(dyn_name), "DYN%05d", i); insert(h, dyn_name); } printf("There are %d keys in the hash\n", g_hash_table_size(h)); g_hash_table_destroy(h); return 0; } ---------- Program output in EPEL 5 (glib2-devel-2.12.3-4): ---------- hash insert: key = <DYN00004>: not found hash insert: key = <DYN00005>: not found hash insert: key = <DYN00006>: not found hash insert: key = <DYN00007>: not found hash insert: key = <DYN00008>: not found hash insert: key = <DYN00009>: not found hash insert: key = <DYN00010>: found (ARGH) hash insert: key = <DYN00011>: not found hash insert: key = <DYN00012>: not found hash insert: key = <DYN00013>: not found hash insert: key = <DYN00014>: not found There are 10 keys in the hash ---------- Program output in EPEL 6 (glib2-devel-2.22.5-5) or in Fedora 15 (glib2-devel-2.28.8-1) ---------- hash insert: key = <DYN00004>: not found hash insert: key = <DYN00005>: not found hash insert: key = <DYN00006>: not found hash insert: key = <DYN00007>: not found hash insert: key = <DYN00008>: not found hash insert: key = <DYN00009>: not found hash insert: key = <DYN00010>: not found hash insert: key = <DYN00011>: not found hash insert: key = <DYN00012>: not found hash insert: key = <DYN00013>: not found hash insert: key = <DYN00014>: not found There are 11 keys in the hash ----------
This ticket can be closed (not a RHEL5 glib2 problem). The above example, showing similar behavior as the problematic syslog-ng test, is buggy: the keys/values inserted aren't being kept during the hash lifetime (missing at leat one g_strdup() before the hash_insert). ---------- - g_hash_table_insert(name_map, (gpointer)name, (gpointer)name); + gchar *dupname = g_strdup(name); + g_hash_table_insert(name_map, (gpointer)dupname, (gpointer)dupname); ---------- From the glib2 documentation: ... Note that neither keys nor values are copied when inserted into the GHashTable, so they must exist for the lifetime of the GHashTable. This means that the use of static strings is OK, but temporary strings (i.e. those created in buffers and those returned by GTK+ widgets) should be copied with g_strdup() before being inserted. If keys or values are dynamically allocated, you must be careful to ensure that they are freed when they are removed from the GHashTable, and also when they are overwritten by new insertions into the GHashTable. It is also not advisable to mix static strings and dynamically-allocated strings in a GHashTable, because it then becomes difficult to determine whether the string should be freed. ...
This bug/component is not included in scope for RHEL-5.11.0 which is the last RHEL5 minor release. This Bugzilla will soon be CLOSED as WONTFIX (at the end of RHEL5.11 development phase (Apr 22, 2014)). Please contact your account manager or support representative in case you need to escalate this bug.
Thank you for submitting this request for inclusion in Red Hat Enterprise Linux 5. We've carefully evaluated the request, but are unable to include it in RHEL5 stream. If the issue is critical for your business, please provide additional business justification through the appropriate support channels (https://access.redhat.com/site/support).
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days