https://bugzilla.balabit.com/show_bug.cgi?id=269 Summary: some code doesn't follow glib recomendations Product: syslog-ng Version: 3.5.x Platform: PC OS/Version: Linux Status: NEW Severity: major Priority: unspecified Component: syslog-ng AssignedTo: bazsi@balabit.hu ReportedBy: iippolitov@gmail.com Type of the Report: bug Estimated Hours: 0.0 I'm using rhel 5.9 and syslog-ng 3.5.3. tests/unit/test_nvtable fails on line 69. It is a know bug: https://bugzilla.redhat.com/show_bug.cgi?id=714409#c4 . As per https://bugzilla.redhat.com/show_bug.cgi?id=716447 :
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. ... The code in lib/nv_table.c uses a pointer to a string that is changed during a program execution to insert values into GHashTable. This causes some unit tests to fail at least in rhel5. nv_registry_alloc_handle was obviously fixed to g_strdup() string from function parameters, while nv_registry_add_alias still uses a pointer the function gets as a parameter: Here is a workaround: void nv_registry_add_alias(NVRegistry *self, NVHandle handle, const gchar *alias) { g_static_mutex_lock(&nv_registry_lock); - g_hash_table_insert(self->name_map, (gchar*)alias, GUINT_TO_POINTER((glong) handle)); + gchar * st_alias = g_strdup(alias); + g_hash_table_insert(self->name_map, st_alias, GUINT_TO_POINTER((glong) handle)); g_static_mutex_unlock(&nv_registry_lock); } AFAIK, g_hash_table_insert is used widely around syslog-ng code. Could someone please look it through and ensure that any value added into gHashTable is not changed during hashtable lifetime? Feel free to contact me via email or gtalk to find out any details I might miss. Thanks in advance. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.