No subject

...
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.