|
From: Kjartan M. <km...@br...> - 2005-06-06 21:07:29
|
Hi.
First of all, I'm using valgrind 2.4.0 from Fedora Core 4 test (rawhide)
and this run was done using --tool=memcheck
I discussed some leaks reported by valgrind with one of the gnome-panel
maintainers today and we found that we couldn't really explain why
valgrind is reporting this as a leak. There are two similar cases in
different parts of the gnome stack:
==2047== 1619 (276 direct, 1343 indirect) bytes in 4 blocks are definitely lost in loss record 136 of 218
==2047== at 0x1B909222: malloc (vg_replace_malloc.c:130)
==2047== by 0x1C2445C1: g_malloc (gmem.c:137)
==2047== by 0x1B96097D: make_environment_for_screen (gnome-multiscreen.c:65)
==2047== by 0x1B960A88: gnome_url_show_on_screen (gnome-multiscreen.c:108)
==2047== by 0x8083714: activate_uri (panel-menu-items.c:100)
which translates to this piece of code:
* Returns: a newly-allocated %NULL-terminated array of strings or
* %NULL on error. Use g_strfreev() to free it.
**/
static char **
make_environment_for_screen (GdkScreen *screen)
{
char **retval = NULL;
char *display_name;
int i, env_len;
int display_index = -1;
g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL);
for (env_len = 0; environ [env_len]; env_len++)
if (!strncmp (environ [env_len], "DISPLAY", 7))
display_index = env_len;
if (display_index == -1)
display_index = env_len++;
retval = g_new (char *, env_len + 1);
retval [env_len] = NULL;
display_name = gdk_screen_make_display_name (screen);
for (i = 0; i < env_len; i++)
if (i == display_index)
retval [i] = g_strconcat ("DISPLAY=", display_name, NULL);
else
retval [i] = g_strdup (environ [i]);
g_assert (i == env_len);
g_free (display_name);
return retval;
}
This is called in this function:
gboolean
gnome_url_show_on_screen (const char *url,
GdkScreen *screen,
GError **error)
{
char **env;
gboolean retval;
env = make_environment_for_screen (screen);
retval = gnome_url_show_with_env (url, env, error);
g_strfreev (env);
return retval;
}
Where the environment is clearly free'd using the function that the
first one suggests to use. Could this be a false positive from valgrind
or am I missing some subtlety in the gnome functions?
Cheers
Kjartan
|
|
From: Jeremy F. <je...@go...> - 2005-06-06 22:00:43
|
Kjartan Maraas wrote:
>Where the environment is clearly free'd using the function that the
>first one suggests to use. Could this be a false positive from valgrind
>or am I missing some subtlety in the gnome functions?
>
You might want to try --leak-resolution=high. It could be that
Valgrind is commoning up two distinct cases and only presenting one
message for it (ie, the problem is in some other caller).
It would be a definite bug if Valgrind reports a block as leaked if it
had been freed; it's possible it might report a block as leaked if it
hasn't been freed but V didn't find any references (but this fairly rare).
J
|