After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 740317 - GSlice is not valgrind-friendly even when going through system malloc
GSlice is not valgrind-friendly even when going through system malloc
Status: RESOLVED DUPLICATE of bug 627423
Product: glib
Classification: Platform
Component: general
2.43.x
Other Linux
: Normal minor
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2014-11-18 14:11 UTC by Rocco Carbone
Modified: 2014-11-18 15:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
The output of the execution with valgrind without G_SLICE Undefined variable (same as G_SLICE set to always-malloc) (2.84 KB, text/plain)
2014-11-18 14:11 UTC, Rocco Carbone
Details

Description Rocco Carbone 2014-11-18 14:11:34 UTC
Created attachment 290910 [details]
The output of the execution with valgrind without G_SLICE Undefined variable (same as G_SLICE set to always-malloc)

The simply program can be used to reproduce the problem.

/* The program creates a hash table and than destroy it */ 
#include <stdio.h> 
#include <stdlib.h> 
 
/* GLIB - Library of useful routines for C programming - v. 2.43.0 - Oct 2014 */ 
#include "glib.h" 
 

int main (int argc, char * argv [])
{
  GHashTable * ht;
  char * g_slice = getenv ("G_SLICE");
 
  printf ("This program creates a hash table and then destroy it\n");
  if (g_slice)
    printf ("The [G_SLICE] environment variable is set to %s\n", g_slice);
  else
    printf ("The [G_SLICE] environment variable is not set\n");
 
  /* Create a hash table */
  ht = g_hash_table_new (NULL, NULL);
 
  /* Destroy the hash table */
  g_hash_table_destroy (ht);

  return 0;
}
Comment 1 Emmanuele Bassi (:ebassi) 2014-11-18 14:28:30 UTC
this is a one-off allocation in thread-local storage. it needs to be performed to initialize the GSlice allocator, so it has to come before the check on the configuration to see if the allocation should go through the system malloc or not.

since it's a one-off, it's not a leak — even if it's not overly valgrind-friendly.
Comment 2 Emmanuele Bassi (:ebassi) 2014-11-18 14:29:04 UTC
re-titling for clarity.
Comment 3 Dan Winship 2014-11-18 15:32:52 UTC
we've already got one of those

*** This bug has been marked as a duplicate of bug 627423 ***