Valgrind and memory leaks

peoro · 2010-04-23 09:40:17

Hello,
running `valgrind --leak-check=full` on most graphical applications I get thousands of leak reports. It looks like the problem is related to glib.

I created an empty Qt window (the one that QtCreator creates by default when starting a new QtGui project), and look at here:

$ valgrind --leak-check=full ./qtEmptyWin &> /tmp/VALGRIND
$ wc -l /tmp/VALGRIND
19956 /tmp/VALGRIND
$ head -n 50 /tmp/VALGRIND 
==3098== Memcheck, a memory error detector
==3098== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==3098== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==3098== Command: ./qtEmptyWin
==3098== 
==3098== 
==3098== HEAP SUMMARY:
==3098==     in use at exit: 804,888 bytes in 8,306 blocks
==3098==   total heap usage: 46,586 allocs, 38,280 frees, 5,324,667 bytes allocated
==3098== 
==3098== 1 bytes in 1 blocks are possibly lost in loss record 2 of 4,535
==3098==    at 0x40238FC: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==3098==    by 0x4FEA423: g_malloc (in /usr/lib/libglib-2.0.so.0.2400.0)
==3098==    by 0x5002AC8: g_strdup (in /usr/lib/libglib-2.0.so.0.2400.0)
==3098==    by 0x5144019: g_param_spec_string (in /usr/lib/libgobject-2.0.so.0.2400.0)
==3098==    by 0x5C171D3: gtk_settings_class_intern_init (in /usr/lib/libgtk-x11-2.0.so.0.2000.0)
==3098==    by 0x515970D: g_type_class_ref (in /usr/lib/libgobject-2.0.so.0.2400.0)
==3098==    by 0x513F761: g_object_newv (in /usr/lib/libgobject-2.0.so.0.2400.0)
==3098==    by 0x513FCE7: g_object_new (in /usr/lib/libgobject-2.0.so.0.2400.0)
==3098==    by 0x5C15F27: gtk_settings_get_for_screen (in /usr/lib/libgtk-x11-2.0.so.0.2000.0)
==3098==    by 0x5BBC356: display_opened_cb (in /usr/lib/libgtk-x11-2.0.so.0.2000.0)
==3098==    by 0x51454C7: g_cclosure_marshal_VOID__OBJECT (in /usr/lib/libgobject-2.0.so.0.2400.0)
==3098==    by 0x51384E1: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.2400.0)
==3098== 
==3098== 1 bytes in 1 blocks are possibly lost in loss record 3 of 4,535
==3098==    at 0x40238FC: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==3098==    by 0x4FEA423: g_malloc (in /usr/lib/libglib-2.0.so.0.2400.0)
==3098==    by 0x5002AC8: g_strdup (in /usr/lib/libglib-2.0.so.0.2400.0)
==3098==    by 0x5B924F2: gtk_label_set_text (in /usr/lib/libgtk-x11-2.0.so.0.2000.0)
==3098==    by 0x5B97A45: gtk_label_init (in /usr/lib/libgtk-x11-2.0.so.0.2000.0)
==3098==    by 0x5159C1A: g_type_create_instance (in /usr/lib/libgobject-2.0.so.0.2400.0)
==3098==    by 0x513DCB7: g_object_constructor (in /usr/lib/libgobject-2.0.so.0.2400.0)
==3098==    by 0x513F429: g_object_newv (in /usr/lib/libgobject-2.0.so.0.2400.0)
==3098==    by 0x513FCE7: g_object_new (in /usr/lib/libgobject-2.0.so.0.2400.0)
==3098==    by 0x5B928FE: gtk_label_new (in /usr/lib/libgtk-x11-2.0.so.0.2000.0)
==3098==    by 0x5D3C594: gtk_tooltips_force_window (in /usr/lib/libgtk-x11-2.0.so.0.2000.0)
==3098==    by 0x5159C1A: g_type_create_instance (in /usr/lib/libgobject-2.0.so.0.2400.0)
==3098== 
==3098== 1 bytes in 1 blocks are possibly lost in loss record 4 of 4,535
==3098==    at 0x40238FC: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==3098==    by 0x4FEA423: g_malloc (in /usr/lib/libglib-2.0.so.0.2400.0)
==3098==    by 0x5002AC8: g_strdup (in /usr/lib/libglib-2.0.so.0.2400.0)
==3098==    by 0x5CBF434: gtk_tree_view_column_init (in /usr/lib/libgtk-x11-2.0.so.0.2000.0)
==3098==    by 0x5159C1A: g_type_create_instance (in /usr/lib/libgobject-2.0.so.0.2400.0)
==3098==    by 0x513DCB7: g_object_constructor (in /usr/lib/libgobject-2.0.so.0.2400.0)
==3098==    by 0x513F429: g_object_newv (in /usr/lib/libgobject-2.0.so.0.2400.0)
==3098==    by 0x513FCE7: g_object_new (in /usr/lib/libgobject-2.0.so.0.2400.0)
==3098==    by 0x5CC2D06: gtk_tree_view_column_new (in /usr/lib/libgtk-x11-2.0.so.0.2000.0)
==3098==    by 0x454894D: ??? (in /usr/lib/libQtGui.so.4.6.2)
==3098==    by 0x454B655: ??? (in /usr/lib/libQtGui.so.4.6.2)

What is going on?

Perberos · 2010-05-30 19:33:50

[perberos@maxima ~]$ valgrind --leak-check=full --show-reachable=yes gcalctool
==4125== Memcheck, a memory error detector
==4125== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==4125== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==4125== Command: gcalctool
==4125== 
==4125== Jump to the invalid address stated on the next line
==4125==    at 0xFFFFFFFFFF600000: ???
==4125==    by 0x6E03E89: gettimeofday (in /lib/libc-2.12.so)
==4125==    by 0x66304E6: g_get_current_time (in /usr/lib/libglib-2.0.so.0.2400.1)
==4125==    by 0x664E5CC: g_slice_init_nomessage (in /usr/lib/libglib-2.0.so.0.2400.1)
==4125==    by 0x664ECAC: _g_slice_thread_init_nomessage (in /usr/lib/libglib-2.0.so.0.2400.1)
==4125==    by 0x665A3A8: g_thread_init_glib (in /usr/lib/libglib-2.0.so.0.2400.1)
==4125==    by 0x608DC4E: g_type_init_with_debug_flags (in /usr/lib/libgobject-2.0.so.0.2400.1)
==4125==    by 0x409631: main (in /usr/bin/gcalctool)
==4125==  Address 0xffffffffff600000 is not stack'd, malloc'd or (recently) free'd

Seem like glibc.

Last edited by Perberos (2010-05-30 19:38:49)

kmaglione · 2010-05-31 02:08:50

I don't know about the original poster, but I'm getting the same error as the above poster since the upgrade to glibc 2.12. This is a major problem for me, since I use valgrind quite extensively.

==29237== Jump to the invalid address stated on the next line
==29237==    at 0xFFFFFFFFFF600400: ???
==29237==    by 0x5E9EE5C: time (in /lib/libc-2.12.so)
==29237==    by 0x4128EE: dostat (fs.c:208)
==29237==    by 0x4132CB: fs_stat (fs.c:416)
==29237==    by 0x422A31: handlereq (request.c:272)
==29237==    by 0x4223D8: handlefcall (request.c:139)
==29237==    by 0x423A10: handle_conns (server.c:113)
==29237==    by 0x423B83: ixp_serverloop (server.c:164)
==29237==    by 0x417B2A: main (main.c:440)
==29237==  Address 0xffffffffff600400 is not stack'd, malloc'd or (recently) free'd
==29237== 
==29237== 
==29237== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==29237==  Bad permissions for mapped region at address 0xFFFFFFFFFF600400
==29237==    at 0xFFFFFFFFFF600400: ???
==29237==    by 0x5E9EE5C: time (in /lib/libc-2.12.so)
==29237==    by 0x4128EE: dostat (fs.c:208)
==29237==    by 0x4132CB: fs_stat (fs.c:416)
==29237==    by 0x422A31: handlereq (request.c:272)
==29237==    by 0x4223D8: handlefcall (request.c:139)
==29237==    by 0x423A10: handle_conns (server.c:113)
==29237==    by 0x423B83: ixp_serverloop (server.c:164)
==29237==    by 0x417B2A: main (main.c:440)

I suppose I should file a bug report.

Last edited by kmaglione (2010-05-31 02:09:17)

Allan · 2010-05-31 02:52:58

Make sure you have valgrind-3.5.0-5

kmaglione · 2010-05-31 03:23:10

I have. I've cleared my package cache and done a full system upgrade and restarted.

falconindy · 2010-05-31 03:39:22

You're looking at memory that's still being used by other applications when your traced program exits. It's mapped into your process's address space and although you might free any allocations you made in your own application, valgrind reports some false positives because the memory is still in use by other applications.

...or at least this is my understanding of what's going on. It occurs with other libraries such as readline which are used by shells.

@kmaglione: I'm seeing seg faults inside valgrind 3.5.0-5 as well on one of my applications (on its own, the app runs clean). I've been working to bisect the issue, but I'm having problems compiling anything earlier than r11027. My lack of SVN familiarity isn't helping either. In the meantime, I'm running valgrind compiled from trunk (valgrind-svn in the aur).

I had initially filed a bug report because suppressions were missing for glibc 2.12. The test case I provided Allan with brought us to Valgrind 3.5.0-5, but apparently has unearthed some other issues. I wanted to try and bisect it for him before reopening. Feh.

Allan · 2010-05-31 03:48:21

@kmaglione: Find a minimal test case, check it on valgrind svn. It it does not work from svn, file a bug upstream. If it does, file a bug here.

falconindy · 2010-05-31 04:13:07

Requested a reopen of the same bug report -- the test case I provided you shows the seg fault in valgrind 3.5.0-5 on my machine.

==5993== Memcheck, a memory error detector
==5993== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==5993== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==5993== Command: ./curltest
==5993== 
==5993== Jump to the invalid address stated on the next line
==5993==    at 0xFFFFFFFFFF600400: ???
==5993==    by 0x5108E5C: time (in /lib/libc-2.12.so)
==5993==    by 0x4E5ED5A: Curl_srand (in /usr/lib/libcurl.so.4.2.0)
==5993==    by 0x4E58C2F: curl_global_init (in /usr/lib/libcurl.so.4.2.0)
==5993==    by 0x40083C: main (in /home/haruko/devel/c/chomp/curltest)
==5993==  Address 0xffffffffff600400 is not stack'd, malloc'd or (recently) free'd
==5993== 
==5993== 
==5993== Process terminating with default action of signal 11 (SIGSEGV)
==5993==  Bad permissions for mapped region at address 0xFFFFFFFFFF600400
==5993==    at 0xFFFFFFFFFF600400: ???
==5993==    by 0x5108E5C: time (in /lib/libc-2.12.so)
==5993==    by 0x4E5ED5A: Curl_srand (in /usr/lib/libcurl.so.4.2.0)
==5993==    by 0x4E58C2F: curl_global_init (in /usr/lib/libcurl.so.4.2.0)
==5993==    by 0x40083C: main (in /home/haruko/devel/c/chomp/curltest)
==5993== 
==5993== HEAP SUMMARY:
==5993==     in use at exit: 0 bytes in 0 blocks
==5993==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==5993== 
==5993== All heap blocks were freed -- no leaks are possible
==5993== 
==5993== For counts of detected and suppressed errors, rerun with: -v
==5993== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 7 from 7)
zsh: segmentation fault  valgrind ./curltest

edit: Runs clean on svn checkouts as far back as I'm able to compile (r11027).

Last edited by falconindy (2010-05-31 04:14:12)

Allan · 2010-05-31 04:55:33

falconindy wrote:

Requested a reopen of the same bug report -- the test case I provided you shows the seg fault in valgrind 3.5.0-5 on my machine.

For what it is worth, valgrind runs that test case without issues on i686

Firing up my chroot now. Apart from the patches in ABS, there are two build fixes that need applied for older revisions (from r10978 and r10954 I think...)

kmaglione · 2010-05-31 04:58:06

The SVN version works like a charm for me.

falconindy · 2010-05-31 05:00:47

Fair enough -- I was starting to think that it was an issue of 32 v. 64. I also notice I completely neglected to mention my architecture in the initial report. Oops.

Allan · 2010-05-31 05:09:07

Looks like SVN checkouts not over ssh are blocked at work so I will look into this once I get home.

Perberos · 2010-05-31 09:43:31

[perberos@maxima ~]$ valgrind --version
valgrind-3.5.0
[perberos@maxima ~]$ valgrind --leak-check=full -v --show-reachable=yes gcalctool
==15559== Memcheck, a memory error detector
==15559== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==15559== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==15559== Command: gcalctool
==15559==
--15559-- Valgrind options:
--15559-- --leak-check=full
--15559-- -v
--15559-- --show-reachable=yes
--15559-- Contents of /proc/version:
--15559-- Linux version 2.6.33-ARCH (thomas@evey) (gcc version 4.5.0 (GCC) ) #1 SMP PREEMPT Thu May 13 11:32:37 CEST 2010
--15559-- Arch and hwcaps: AMD64, amd64-sse3-cx16
--15559-- Page sizes: currently 4096, max supported 4096
--15559-- Valgrind library directory: /usr/lib/valgrind
--15559-- Reading syms from /usr/bin/gcalctool (0x400000)
--15559-- object doesn't have a symbol table
--15559-- Reading syms from /lib/ld-2.12.so (0x4000000)
--15559-- Reading syms from /usr/lib/valgrind/memcheck-amd64-linux (0x38000000)
--15559-- object doesn't have a symbol table
--15559-- object doesn't have a dynamic symbol table
--15559-- Reading suppressions file: /usr/lib/valgrind/default.supp
--15559-- REDIR: 0x4016250 (strlen) redirected to 0x380405e7 (???)
--15559-- Reading syms from /usr/lib/valgrind/vgpreload_core-amd64-linux.so (0x4a21000)
--15559-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so (0x4c22000)
==15559== WARNING: new redirection conflicts with existing -- ignoring it
--15559-- new: 0x04016250 (strlen ) R-> 0x04c268f0 strlen
--15559-- REDIR: 0x4016070 (index) redirected to 0x4c26550 (index)
--15559-- REDIR: 0x4016220 (strcmp) redirected to 0x4c26ef0 (strcmp)
--15559-- Reading syms from /usr/lib/libgtk-x11-2.0.so.0.2000.1 (0x4e2a000)
--15559-- Reading syms from /usr/lib/libgdk-x11-2.0.so.0.2000.1 (0x5458000)
--15559-- Reading syms from /usr/lib/libatk-1.0.so.0.3009.1 (0x5706000)
--15559-- Reading syms from /usr/lib/libpango-1.0.so.0.2800.0 (0x5926000)
--15559-- Reading syms from /usr/lib/libgconf-2.so.4.1.5 (0x5b6f000)
--15559-- Reading syms from /usr/lib/libgio-2.0.so.0.2400.1 (0x5dac000)
--15559-- Reading syms from /usr/lib/libgobject-2.0.so.0.2400.1 (0x605f000)
--15559-- Reading syms from /usr/lib/libxml2.so.2.7.7 (0x62a7000)
--15559-- Reading syms from /usr/lib/libglib-2.0.so.0.2400.1 (0x65f4000)
--15559-- Reading syms from /lib/libm-2.12.so (0x68d4000)
--15559-- Reading syms from /lib/libpthread-2.12.so (0x6b56000)
--15559-- Reading syms from /lib/libc-2.12.so (0x6d73000)
--15559-- Reading syms from /usr/lib/libXext.so.6.4.0 (0x70cf000)
--15559-- Reading syms from /usr/lib/libXrender.so.1.3.0 (0x72e1000)
--15559-- Reading syms from /usr/lib/libXinerama.so.1.0.0 (0x74ea000)
--15559-- Reading syms from /usr/lib/libXi.so.6.1.0 (0x76ec000)
--15559-- Reading syms from /usr/lib/libXrandr.so.2.2.0 (0x78fa000)
--15559-- Reading syms from /usr/lib/libXcursor.so.1.0.2 (0x7b02000)
--15559-- Reading syms from /usr/lib/libgdk_pixbuf-2.0.so.0.2000.1 (0x7d0b000)
--15559-- Reading syms from /usr/lib/libpangocairo-1.0.so.0.2800.0 (0x7f2c000)
--15559-- Reading syms from /usr/lib/libX11.so.6.3.0 (0x8137000)
--15559-- Reading syms from /usr/lib/libXcomposite.so.1.0.0 (0x8470000)
--15559-- Reading syms from /usr/lib/libXdamage.so.1.1.0 (0x8672000)
--15559-- Reading syms from /usr/lib/libXfixes.so.3.1.0 (0x8874000)
--15559-- Reading syms from /usr/lib/libcairo.so.2.10800.10 (0x8a79000)
--15559-- Reading syms from /usr/lib/libpangoft2-1.0.so.0.2800.0 (0x8cf4000)
--15559-- Reading syms from /usr/lib/libfreetype.so.6.4.0 (0x8f1d000)
--15559-- Reading syms from /usr/lib/libfontconfig.so.1.4.4 (0x91b4000)
--15559-- Reading syms from /usr/lib/libgmodule-2.0.so.0.2400.1 (0x93e8000)
--15559-- Reading syms from /usr/lib/libgthread-2.0.so.0.2400.1 (0x95eb000)
--15559-- Reading syms from /lib/librt-2.12.so (0x97ef000)
--15559-- Reading syms from /usr/lib/libpng14.so.14.2.0 (0x99f7000)
--15559-- Reading syms from /usr/lib/libz.so.1.2.5 (0x9c20000)
--15559-- Reading syms from /usr/lib/libORBit-2.so.0.1.0 (0x9e38000)
--15559-- Reading syms from /usr/lib/libdbus-glib-1.so.2.1.0 (0xa0a6000)
--15559-- Reading syms from /usr/lib/libdbus-1.so.3.4.0 (0xa2c9000)
--15559-- Reading syms from /lib/libdl-2.12.so (0xa508000)
--15559-- Reading syms from /lib/libpcre.so.0.0.1 (0xa70c000)
--15559-- Reading syms from /lib/libresolv-2.12.so (0xa93c000)
--15559-- Reading syms from /usr/lib/libxcb.so.1.1.0 (0xab53000)
--15559-- Reading syms from /usr/lib/libpixman-1.so.0.18.2 (0xad6e000)
--15559-- Reading syms from /usr/lib/libxcb-render-util.so.0.0.0 (0xafcf000)
--15559-- Reading syms from /usr/lib/libxcb-render.so.0.0.0 (0xb1d2000)
--15559-- Reading syms from /usr/lib/libexpat.so.1.5.2 (0xb3da000)
--15559-- Reading syms from /usr/lib/libXau.so.6.0.0 (0xb602000)
--15559-- Reading syms from /usr/lib/libXdmcp.so.6.0.0 (0xb804000)
--15559-- REDIR: 0x6df00c0 (rindex) redirected to 0x4c26340 (rindex)
--15559-- REDIR: 0x6df1570 (memset) redirected to 0x4c27b60 (memset)
--15559-- REDIR: 0x6dee5d0 (strlen) redirected to 0x4c26890 (strlen)
--15559-- REDIR: 0x6dee7b0 (strncmp) redirected to 0x4c26d50 (strncmp)
--15559-- REDIR: 0x6de9f40 (calloc) redirected to 0x4c24600 (calloc)
--15559-- REDIR: 0x6de8dd0 (malloc) redirected to 0x4c25f40 (malloc)
--15559-- REDIR: 0xffffffffff600000 (???) redirected to 0x4a21570 (_vgnU_ifunc_wrapper)
==15559== Jump to the invalid address stated on the next line
==15559== at 0xFFFFFFFFFF600000: ???
==15559== by 0x6E03E89: gettimeofday (in /lib/libc-2.12.so)
==15559== by 0x66304E6: g_get_current_time (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x664E5CC: g_slice_init_nomessage (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x664ECAC: _g_slice_thread_init_nomessage (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x665A3A8: g_thread_init_glib (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x608DC4E: g_type_init_with_debug_flags (in /usr/lib/libgobject-2.0.so.0.2400.1)
==15559== by 0x409631: main (in /usr/bin/gcalctool)
==15559== Address 0xffffffffff600000 is not stack'd, malloc'd or (recently) free'd
==15559==
==15559==
==15559== Process terminating with default action of signal 11 (SIGSEGV)
==15559== Bad permissions for mapped region at address 0xFFFFFFFFFF600000
==15559== at 0xFFFFFFFFFF600000: ???
==15559== by 0x6E03E89: gettimeofday (in /lib/libc-2.12.so)
==15559== by 0x66304E6: g_get_current_time (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x664E5CC: g_slice_init_nomessage (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x664ECAC: _g_slice_thread_init_nomessage (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x665A3A8: g_thread_init_glib (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x608DC4E: g_type_init_with_debug_flags (in /usr/lib/libgobject-2.0.so.0.2400.1)
==15559== by 0x409631: main (in /usr/bin/gcalctool)
--15559-- REDIR: 0x6de92e0 (free) redirected to 0x4c250a0 (free)
==15559==
==15559== HEAP SUMMARY:
==15559== in use at exit: 1,448 bytes in 8 blocks
==15559== total heap usage: 8 allocs, 0 frees, 1,448 bytes allocated
==15559==
==15559== Searching for pointers to 8 not-freed blocks
==15559== Checked 733,232 bytes
==15559==
==15559== 4 bytes in 1 blocks are still reachable in loss record 1 of 8
==15559== at 0x4C25FAD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15559== by 0x66387C2: g_malloc (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x95ED0A6: g_private_new_posix_impl (in /usr/lib/libgthread-2.0.so.0.2400.1)
==15559== by 0x665A382: g_thread_init_glib (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x608DC4E: g_type_init_with_debug_flags (in /usr/lib/libgobject-2.0.so.0.2400.1)
==15559== by 0x409631: main (in /usr/bin/gcalctool)
==15559==
==15559== 40 bytes in 1 blocks are still reachable in loss record 2 of 8
==15559== at 0x4C25FAD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15559== by 0x66387C2: g_malloc (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x95ED3EE: g_mutex_new_posix_impl (in /usr/lib/libgthread-2.0.so.0.2400.1)
==15559== by 0x665A353: g_thread_init_glib (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x608DC4E: g_type_init_with_debug_flags (in /usr/lib/libgobject-2.0.so.0.2400.1)
==15559== by 0x409631: main (in /usr/bin/gcalctool)
==15559==
==15559== 40 bytes in 1 blocks are still reachable in loss record 3 of 8
==15559== at 0x4C25FAD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15559== by 0x66387C2: g_malloc (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x95ED3EE: g_mutex_new_posix_impl (in /usr/lib/libgthread-2.0.so.0.2400.1)
==15559== by 0x6639171: _g_mem_thread_init_noprivate_nomessage (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x665A369: g_thread_init_glib (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x608DC4E: g_type_init_with_debug_flags (in /usr/lib/libgobject-2.0.so.0.2400.1)
==15559== by 0x409631: main (in /usr/bin/gcalctool)
==15559==
==15559== 48 bytes in 1 blocks are still reachable in loss record 4 of 8
==15559== at 0x4C25FAD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15559== by 0x66387C2: g_malloc (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x95ED29E: g_cond_new_posix_impl (in /usr/lib/libgthread-2.0.so.0.2400.1)
==15559== by 0x665A35D: g_thread_init_glib (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x608DC4E: g_type_init_with_debug_flags (in /usr/lib/libgobject-2.0.so.0.2400.1)
==15559== by 0x409631: main (in /usr/bin/gcalctool)
==15559==
==15559== 56 bytes in 1 blocks are still reachable in loss record 5 of 8
==15559== at 0x4C24682: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15559== by 0x6638819: g_malloc0 (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x6659F3A: g_thread_self (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x665A347: g_thread_init_glib (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x608DC4E: g_type_init_with_debug_flags (in /usr/lib/libgobject-2.0.so.0.2400.1)
==15559== by 0x409631: main (in /usr/bin/gcalctool)
==15559==
==15559== 252 bytes in 1 blocks are still reachable in loss record 6 of 8
==15559== at 0x4C24682: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15559== by 0x6638819: g_malloc0 (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x664E651: g_slice_init_nomessage (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x664ECAC: _g_slice_thread_init_nomessage (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x665A3A8: g_thread_init_glib (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x608DC4E: g_type_init_with_debug_flags (in /usr/lib/libgobject-2.0.so.0.2400.1)
==15559== by 0x409631: main (in /usr/bin/gcalctool)
==15559==
==15559== 504 bytes in 1 blocks are still reachable in loss record 7 of 8
==15559== at 0x4C24682: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15559== by 0x6638819: g_malloc0 (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x664E671: g_slice_init_nomessage (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x664ECAC: _g_slice_thread_init_nomessage (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x665A3A8: g_thread_init_glib (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x608DC4E: g_type_init_with_debug_flags (in /usr/lib/libgobject-2.0.so.0.2400.1)
==15559== by 0x409631: main (in /usr/bin/gcalctool)
==15559==
==15559== 504 bytes in 1 blocks are still reachable in loss record 8 of 8
==15559== at 0x4C24682: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15559== by 0x6638819: g_malloc0 (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x664E691: g_slice_init_nomessage (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x664ECAC: _g_slice_thread_init_nomessage (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x665A3A8: g_thread_init_glib (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x608DC4E: g_type_init_with_debug_flags (in /usr/lib/libgobject-2.0.so.0.2400.1)
==15559== by 0x409631: main (in /usr/bin/gcalctool)
==15559==
==15559== LEAK SUMMARY:
==15559== definitely lost: 0 bytes in 0 blocks
==15559== indirectly lost: 0 bytes in 0 blocks
==15559== possibly lost: 0 bytes in 0 blocks
==15559== still reachable: 1,448 bytes in 8 blocks
==15559== suppressed: 0 bytes in 0 blocks
==15559==
==15559== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 7 from 7)
==15559==
==15559== 1 errors in context 1 of 1:
==15559== Jump to the invalid address stated on the next line
==15559== at 0xFFFFFFFFFF600000: ???
==15559== by 0x6E03E89: gettimeofday (in /lib/libc-2.12.so)
==15559== by 0x66304E6: g_get_current_time (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x664E5CC: g_slice_init_nomessage (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x664ECAC: _g_slice_thread_init_nomessage (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x665A3A8: g_thread_init_glib (in /usr/lib/libglib-2.0.so.0.2400.1)
==15559== by 0x608DC4E: g_type_init_with_debug_flags (in /usr/lib/libgobject-2.0.so.0.2400.1)
==15559== by 0x409631: main (in /usr/bin/gcalctool)
==15559== Address 0xffffffffff600000 is not stack'd, malloc'd or (recently) free'd
==15559==
--15559--
--15559-- used_suppression: 7 dl-hack3-cond-1
==15559==
==15559== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 7 from 7)
Segmentation fault
[perberos@maxima ~]$

Well, that look like a Valgrind Bug. Or maybe a feature.

--15559-- REDIR: 0x6de8dd0 (malloc) redirected to 0x4c25f40 (malloc)
--15559-- REDIR: 0xffffffffff600000 (???) redirected to 0x4a21570 (_vgnU_ifunc_wrapper)
==15559== Jump to the invalid address stated on the next line

rgacogne · 2010-06-01 15:28:59

Same issue here with valgrind-3.5.0-5 on x86_64.

--22960-- REDIR: 0xffffffffff600400 (???) redirected to 0x4a21570 (_vgnU_ifunc_wrapper)
==22960== Jump to the invalid address stated on the next line
==22960== at 0xFFFFFFFFFF600400: ???
==22960== by 0x5E97E5C: time (in /lib/libc-2.12.so)

Problem goes away when I rebuild using PKGBUILD but without the valgrind-3.5.0-elf-indirect-functions.patch patch. I don't know where this patch comes from, but either it contains a bug itself or it triggers one in valgrind.

Allan · 2010-06-01 21:37:20

That patch comes from upstream svn and suppress _A LOT_ of noise warnings with glibc-2.12.

rgacogne · 2010-06-01 21:54:31

After re-reading my last sentence, I find it to be a bit rude. Sorry, no offense meant, I was really wondering if it was an official patch or not.

That patch comes from upstream svn and suppress _A LOT_ of noise warnings with glibc-2.12.

Looks like they have a bug then

Last edited by rgacogne (2010-06-01 21:55:02)

Allan · 2010-06-01 22:08:25

It is probably fixed in another SVN revision... I just have to find which...

Allan · 2010-06-03 13:35:09

valgrind-3.5.0-6 should fix everything... really!

falconindy · 2010-06-03 15:05:27

Looks good on my end!

Perberos · 2010-06-03 15:15:33

Allan McRae thank you so much

Arch Linux

#1 2010-04-23 09:40:17

Valgrind and memory leaks

#2 2010-05-30 19:33:50

Re: Valgrind and memory leaks

#3 2010-05-31 02:08:50

Re: Valgrind and memory leaks

#4 2010-05-31 02:52:58

Re: Valgrind and memory leaks

#5 2010-05-31 03:23:10

Re: Valgrind and memory leaks

#6 2010-05-31 03:39:22

Re: Valgrind and memory leaks

#7 2010-05-31 03:48:21

Re: Valgrind and memory leaks

#8 2010-05-31 04:13:07

Re: Valgrind and memory leaks

#9 2010-05-31 04:55:33

Re: Valgrind and memory leaks

#10 2010-05-31 04:58:06

Re: Valgrind and memory leaks

#11 2010-05-31 05:00:47

Re: Valgrind and memory leaks

#12 2010-05-31 05:09:07

Re: Valgrind and memory leaks

#13 2010-05-31 09:43:31

Re: Valgrind and memory leaks

#14 2010-06-01 15:28:59

Re: Valgrind and memory leaks

#15 2010-06-01 21:37:20

Re: Valgrind and memory leaks

#16 2010-06-01 21:54:31

Re: Valgrind and memory leaks

#17 2010-06-01 22:08:25

Re: Valgrind and memory leaks

#18 2010-06-03 13:35:09

Re: Valgrind and memory leaks

#19 2010-06-03 15:05:27

Re: Valgrind and memory leaks

#20 2010-06-03 15:15:33

Re: Valgrind and memory leaks

Board footer