|
From: joel k. <jo...@we...> - 2010-10-11 21:45:02
|
Hi, I debug an application with `valgrind -v -v ./ags`. I get the output below. The second issue about uninitialised value(s) is bad, that's clear to me. But I don't know what the message about survivors mean. Could someone tell me if it's bad, please? --3506-- memcheck GC: 4096 nodes, 4077 survivors ( 99.5%) --3506-- memcheck GC: increase table size to 8192 ... ==3506== Conditional jump or move depends on uninitialised value(s) ==3506== at 0x773D053: g_param_value_validate (in /usr/lib/libgobject-2.0.so.0.2400.2) ==3506== by 0x773B92A: g_object_newv (in /usr/lib/libgobject-2.0.so.0.2400.2) ==3506== by 0x773C14C: g_object_new_valist (in /usr/lib/libgobject-2.0.so.0.2400.2) ==3506== by 0x773C390: g_object_new (in /usr/lib/libgobject-2.0.so.0.2400.2) ==3506== by 0x43072A: ags_copy_pattern_audio_new (ags_copy_pattern_audio.c:81) ==3506== by 0x452717: ags_drum_init (ags_drum.c:171) ==3506== by 0x7756867: g_type_create_instance (in /usr/lib/libgobject-2.0.so.0.2400.2) ==3506== by 0x773A6DB: ??? (in /usr/lib/libgobject-2.0.so.0.2400.2) ==3506== by 0x773BB69: g_object_newv (in /usr/lib/libgobject-2.0.so.0.2400.2) ==3506== by 0x773C3AB: g_object_new (in /usr/lib/libgobject-2.0.so.0.2400.2) ==3506== by 0x4544EE: ags_drum_new (ags_drum.c:734) ==3506== by 0x445CC4: ags_menu_bar_add_drum_callback (ags_menu_bar_callbacks.c:213) ... --3506-- memcheck GC: 8192 nodes, 7944 survivors ( 96.9%) --3506-- memcheck GC: increase table size to 16384 |
|
From: Julian S. <js...@ac...> - 2010-10-11 21:54:16
|
On Monday, October 11, 2010, joel krähemann wrote: > Hi, I debug an application with `valgrind -v -v ./ags`. I get the output > below. The second issue about uninitialised value(s) is bad, that's > clear to me. But I don't know what the message about survivors mean. > Could someone tell me if it's bad, please? > > > --3506-- memcheck GC: 4096 nodes, 4077 survivors ( 99.5%) > --3506-- memcheck GC: increase table size to 8192 No, it is not bad. Ignore it. Both lines are related to internal implementation details of Memcheck. Really we should not show them to the user with -v, only with --stats=yes. J |
|
From: John R. <jr...@bi...> - 2010-10-11 22:02:20
|
> --3506-- memcheck GC: 4096 nodes, 4077 survivors ( 99.5%) > --3506-- memcheck GC: increase table size to 8192 It is an implementation detail that is internal to memcheck. The GC portion of leak tracking has a table. The table became full and was re-allocated to be twice as large so that tracking could continue. There is no cause for alarm. Execution will have a slight pause while the table is re-allocated. There is nothing for the user to do, except to decrease the number of "-v" arguments on the command line. -- |