conditional jump or move depends on uninitialized value4 - valgrind

valgrind shows such errors..
7471== 7 errors in context 4 of 6:
==17471== Conditional jump or move depends on uninitialised value(s)
==17471== at 0x36EA6718D0: _IO_file_xsputn##GLIBC_2.2.5 (in /lib64/libc-2.12.so)
==17471== by 0x36EA64818F: vfprintf (in /lib64/libc-2.12.so)
==17471== by 0x36EA64F189: printf (in /lib64/libc-2.12.so)
==17471== by 0x4008F3: main (main.c:84)
==17471== Uninitialised value was created by a stack allocation
==17471== at 0x4004E8: ??? (in /user/gur39229/extension/assign1/bin/exe)
==17471==
==17471==
==17471== 8 errors in context 5 of 6:
==17471== Conditional jump or move depends on uninitialised value(s)
==17471== at 0x36EA647E2C: vfprintf (in /lib64/libc-2.12.so)
==17471== by 0x36EA64F189: printf (in /lib64/libc-2.12.so)
==17471== by 0x4008F3: main (main.c:84)
==17471== Uninitialised value was created by a stack allocation
==17471== at 0x4004E8: ??? (in /user/gur39229/extension/assign1/bin/exe)
==17471==
==17471==
==17471== 8 errors in context 6 of 6:
==17471== Conditional jump or move depends on uninitialised value(s)
==17471== at 0x4A07FB7: strcpy (mc_replace_strmem.c:442)
==17471== by 0x4008CC: main (main.c:83)
==17471== Uninitialised value was created by a stack allocation
==17471== at 0x4004E8: ??? (in /user/gur39229/extension/assign1/bin/exe)
my code : pls check the code all the initializations and the use of the variables after initiation. at line no. 83 it says uninitialized..y ? i dont understand .. pls help.
/*Declaration*/
42 int i = 0;
43 int a[4]={0};
44 char cstr[80];
45 memset(cstr,0,80);
46 int largest = 0;
if(largest == 3)
82 {
83 strcpy(cstr,str_concat(v[1],v[2]));
84 printf("\t%s%s\n\n",cstr,v[3]);
85
86 }
though i have initialised every variable still its showing valgrind error what to do ?

Related

Memory Leak with import_array() for numpy Python3.5

Could someone suggest a fix for this problem?
When I use import_array(), Valgrind reports memory leak of 157528 bytes.
Here is the small piece of code to replicate the problem on Ubuntu16.04 and Python3.5
#include <Python.h>
#include "numpy/arrayobject.h"
int main(int argc, char *argv[])
{
Py_Initialize();
import_array();
Py_Finalize();
return 0;
}
Here are the relevant pieces of Valgrind report.
==85642== **2,689** bytes in 2 blocks are definitely lost in loss record 1,044 of 1,100
==85642== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==85642== by 0x4ED9777: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x505C42B: PyBytes_FromStringAndSize (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x786FE34: arr_add_docstring (compiled_base.c:1415)
==85642== by 0x4EE8038: PyCFunction_Call (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x4FF41B4: PyEval_EvalFrameEx (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x4FF4638: PyEval_EvalFrameEx (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x5084CAB: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x5084D82: PyEval_EvalCodeEx (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x4FEC9CA: PyEval_EvalCode (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x4FF967C: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x4EE8038: PyCFunction_Call (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== **154,839** bytes in 81 blocks are definitely lost in loss record 1,099 of 1,100
==85642== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==85642== by 0x4ED9777: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x4EA81D8: PyUnicode_New (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x4EABFDC: _PyUnicode_FromASCII (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x4FA073C: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x4EE8038: PyCFunction_Call (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x4FF41B4: PyEval_EvalFrameEx (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x4FF4638: PyEval_EvalFrameEx (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x5084CAB: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x5084D82: PyEval_EvalCodeEx (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x4FEC9CA: PyEval_EvalCode (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x4FF967C: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== LEAK SUMMARY:
==85642== definitely lost: 157,528 bytes in 83 blocks
==85642== indirectly lost: 0 bytes in 0 blocks
==85642== possibly lost: 158,183 bytes in 89 blocks
==85642== still reachable: 1,730,311 bytes in 3,551 blocks
==85642== suppressed: 0 bytes in 0 blocks
==85642==
==85642== For counts of detected and suppressed errors, rerun with: -v
==85642== ERROR SUMMARY: 2768 errors from 123 contexts (suppressed: 0 from 0)

valgrind output points to gfortran library

I run valgrind-3.10.0 to search for memory leaks in my fortran program. I'm using gfortran-4.9.0 to compile on OS X 10.9.5. From what I can tell from the below output, the memory leak is in a gfortran library. Am I correct? If so, is there anything that I can do?
HEAP SUMMARY:
==30650== in use at exit: 25,727 bytes in 390 blocks
==30650== total heap usage: 34,130 allocs, 33,740 frees, 11,306,357 bytes allocated
==30650==
==30650== Searching for pointers to 390 not-freed blocks
==30650== Checked 9,113,592 bytes
==30650==
==30650== 72 (36 direct, 36 indirect) bytes in 1 blocks are definitely lost in loss record 52 of 84
==30650== at 0x47E1: malloc (vg_replace_malloc.c:300)
==30650== by 0x345AB0: __Balloc_D2A (in /usr/lib/system/libsystem_c.dylib)
==30650== by 0x345CF6: __i2b_D2A (in /usr/lib/system/libsystem_c.dylib)
==30650== by 0x34362E: __dtoa (in /usr/lib/system/libsystem_c.dylib)
==30650== by 0x36A8A9: __vfprintf (in /usr/lib/system/libsystem_c.dylib)
==30650== by 0x3912DA: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==30650== by 0x376F66: _vsnprintf (in /usr/lib/system/libsystem_c.dylib)
==30650== by 0x376FC5: vsnprintf_l (in /usr/lib/system/libsystem_c.dylib)
==30650== by 0x3674DC: snprintf (in /usr/lib/system/libsystem_c.dylib)
==30650== by 0xE2F6D: write_float (in /usr/local/gfortran/lib/libgfortran.3.dylib)
==30650== by 0xE53A4: _gfortrani_write_real (in /usr/local/gfortran/lib/libgfortran.3.dylib)
==30650== by 0x3FA9999999999999: ???
==30650==
==30650== LEAK SUMMARY:
==30650== definitely lost: 36 bytes in 1 blocks
==30650== indirectly lost: 36 bytes in 1 blocks
==30650== possibly lost: 0 bytes in 0 blocks
==30650== still reachable: 316 bytes in 7 blocks
==30650== suppressed: 25,339 bytes in 381 blocks
==30650== Reachable blocks (those to which a pointer was found) are not shown.
==30650== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==30650==
==30650== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 15 from 15)
--30650--
--30650-- used_suppression: 34 OSX109:6-Leak /usr/local/lib/valgrind/default.supp:797 suppressed: 13,656 bytes in 252 blocks
--30650-- used_suppression: 1 OSX109:1-Leak /usr/local/lib/valgrind/default.supp:747 suppressed: 2,064 bytes in 1 blocks
--30650-- used_suppression: 13 OSX109:7-Leak /usr/local/lib/valgrind/default.supp:808 suppressed: 7,181 bytes in 78 blocks
--30650-- used_suppression: 11 OSX109:10-Leak /usr/local/lib/valgrind/default.supp:839 suppressed: 1,669 bytes in 29 blocks
--30650-- used_suppression: 10 OSX109:9-Leak /usr/local/lib/valgrind/default.supp:829 suppressed: 609 bytes in 15 blocks
--30650-- used_suppression: 5 OSX109:5-Leak /usr/local/lib/valgrind/default.supp:787 suppressed: 144 bytes in 5 blocks
--30650-- used_suppression: 1 OSX109:3-Leak /usr/local/lib/valgrind/default.supp:765 suppressed: 16 bytes in 1 blocks
==30650==
==30650== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 15 from 15)
This could very well be a bug in the gfortran library.
Your best bet would be to reduce this to a self-contained test case and report it to the gfortran developers at fortran#gcc.gnu.org or to submit a bug report at http://www.gnu.org/bugzilla .

Valgrind not printing inline error messages, just heap and leak summaries

I'm using the command:
valgrind --tool=memcheck --leak-check=yes ./prog
When this runs with a test script, I get no inline error messages or warnings, I just get a Heap Summary and a leak summary.
Am I missing a flag or something?
==31420== HEAP SUMMARY:
==31420== in use at exit: 1,580 bytes in 10 blocks
==31420== total heap usage: 47 allocs, 37 frees, 7,132 bytes allocated
==31420==
==31420== 1,580 (1,440 direct, 140 indirect) bytes in 5 blocks are definitely lost in loss record 2 of 2
==31420== at 0x4C274A8: malloc (vg_replace_malloc.c:236)
==31420== by 0x400FD4: main (lab1.c:51)
==31420==
==31420== LEAK SUMMARY:
==31420== definitely lost: 1,440 bytes in 5 blocks
==31420== indirectly lost: 140 bytes in 5 blocks
==31420== possibly lost: 0 bytes in 0 blocks
==31420== still reachable: 0 bytes in 0 blocks
==31420== suppressed: 0 bytes in 0 blocks
==31420==
==31420== For counts of detected and suppressed errors, rerun with: -v
==31420== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
The last time I used valgrind (a few days ago) it would print out error messages as they occurred, in addition to the heap and leak summaries.
EDIT:
I tried leak-check=full, same result
The line mentioned in the heap summary (lab1.c:51) is:
temp_record = malloc(sizeof(struct server_record));
And I use this pointer pretty often in my code. That is what was so helpful about the valgrind error messages before, they would show me when I would lose my pointer to this malloc or other problems.

Limit --memcheck To Your Own Code

Lets say I am using a library that uses glibc. When I exit the program while running it through Valgrind all sorts of memory leaks are detected by Valgrind. I am 100% sure that none of the leaks are explicitly related to my few lines of code I just wrote. Is there a way to suppress leaks from other libraries, and limit the leak detection to your immediate code?
For example:
valgrind --tool=memcheck --leak-check=full --leak-resolution=high \
--log-file=vgdump ./Main
Where the executable was built from the following source:
// Include header files for application components.
#include <QtGui>
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
QWidget window;
window.resize( 320,240 );
window.setWindowTitle(
QApplication::translate( "toplevel", "Top-level Widget" ) );
window.show( );
QPushButton button(
QApplication::translate( "childwidget", "Press me"), &window );
button.move( 100, 100 );
button.show( );
int status = app.exec();
return status;
}
Has a log-file that reports the following (large portions removed):
==12803== Memcheck, a memory error detector
==12803== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==12803== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==12803== Command: ./Main
==12803== Parent PID: 12700
==12803==
==12803==
==12803== HEAP SUMMARY:
==12803== in use at exit: 937,411 bytes in 8,741 blocks
==12803== total heap usage: 38,227 allocs, 29,486 frees, 5,237,254 bytes allocated
==12803==
==12803== 1 bytes in 1 blocks are possibly lost in loss record 1 of 4,557
==12803== at 0x402577E: malloc (vg_replace_malloc.c:195)
==12803== by 0xA1DFA4: g_malloc (in /lib/libglib-2.0.so.0.2600.0)
==12803== by 0xA37F29: g_strdup (in /lib/libglib-2.0.so.0.2600.0)
==12803== by 0xB2A6FA: g_param_spec_string (in /lib/libgobject-2.0.so.0.2600.0)
==12803== by 0x41F36473: ??? (in /usr/lib/libgtk-x11-2.0.so.0.2200.0)
==12803== by 0xB3D237: g_type_class_ref (in /lib/libgobject-2.0.so.0.2600.0)
==12803== by 0xB20B38: g_object_newv (in /lib/libgobject-2.0.so.0.2600.0)
==12803== by 0xB212EF: g_object_new (in /lib/libgobject-2.0.so.0.2600.0)
==12803== by 0x41F34857: gtk_settings_get_for_screen (in /usr/lib/libgtk-x11-2.0.so.0.2200.0)
==12803== by 0x41ED0CB6: ??? (in /usr/lib/libgtk-x11-2.0.so.0.2200.0)
==12803== by 0xB377C7: g_cclosure_marshal_VOID__OBJECT (in /lib/libgobject-2.0.so.0.2600.0)
==12803== by 0xB1ABE2: g_closure_invoke (in /lib/libgobject-2.0.so.0.2600.0)
...
==12803== 53,244 bytes in 29 blocks are possibly lost in loss record 4,557 of 4,557
==12803== at 0x402577E: malloc (vg_replace_malloc.c:195)
==12803== by 0xA1DFA4: g_malloc (in /lib/libglib-2.0.so.0.2600.0)
==12803== by 0xA36050: g_slice_alloc (in /lib/libglib-2.0.so.0.2600.0)
==12803== by 0xA36315: g_slice_alloc0 (in /lib/libglib-2.0.so.0.2600.0)
==12803== by 0xB40077: g_type_create_instance (in /lib/libgobject-2.0.so.0.2600.0)
==12803== by 0xB1CE35: ??? (in /lib/libgobject-2.0.so.0.2600.0)
==12803== by 0xB205C6: g_object_newv (in /lib/libgobject-2.0.so.0.2600.0)
==12803== by 0xB212EF: g_object_new (in /lib/libgobject-2.0.so.0.2600.0)
==12803== by 0x6180FA3: ??? (in /usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so)
==12803== by 0x41F0CDDD: ??? (in /usr/lib/libgtk-x11-2.0.so.0.2200.0)
==12803== by 0x41F11C24: gtk_rc_get_style (in /usr/lib/libgtk-x11-2.0.so.0.2200.0)
==12803== by 0x4200A81F: ??? (in /usr/lib/libgtk-x11-2.0.so.0.2200.0)
==12803==
==12803== LEAK SUMMARY:
==12803== definitely lost: 2,296 bytes in 8 blocks
==12803== indirectly lost: 7,720 bytes in 382 blocks
==12803== possibly lost: 509,894 bytes in 2,908 blocks
==12803== still reachable: 417,501 bytes in 5,443 blocks
==12803== suppressed: 0 bytes in 0 blocks
==12803== Reachable blocks (those to which a pointer was found) are not shown.
==12803== To see them, rerun with: --leak-check=full --show-reachable=yes
==12803==
==12803== For counts of detected and suppressed errors, rerun with: -v
==12803== ERROR SUMMARY: 1364 errors from 1364 contexts (suppressed: 122 from 11)
To ignore Leak errors in all shared libraries under any lib directory (/lib, /lib64, /usr/lib, /usr/lib64, ...), put this in a file and pass it to valgrind with --suppressions=*FILENAME*:
{
ignore_unversioned_libs
Memcheck:Leak
...
obj:*/lib*/lib*.so
}
{
ignore_versioned_libs
Memcheck:Leak
...
obj:*/lib*/lib*.so.*
}
This will probably suffice to limit memcheck reporting to your own code only. However, beware that this will ignore errors caused by any callbacks you wrote that were invoked by the libraries. Catching errors in those callbacks could almost be done with:
{
ignore_unversioned_libs
Memcheck:Leak
obj:*/lib*/lib*.so
...
obj:*/lib*/lib*.so
}
{
ignore_versioned_libs
Memcheck:Leak
obj:*/lib*/lib*.so.*
...
obj:*/lib*/lib*.so.*
}
... but this reveals errors in calls by a library that use the Valgrind malloc. Since valgrind malloc is injected directly into the program text -- not loaded as a dynamic library -- it appears in the stack the same way as your own code does. This allows Valgrind to track the allocations, but also makes it harder to do exactly what you have asked.
FYI: I am using valgrind 3.5.
The above is an excerpt of an answer to an older, slightly different question that is asked in the body text of this question (so title is a little insufficient):
Is it possible to make valgrind ignore certain libraries?
Look up the topic of suppressions at the Valgrind web site; you want to suppress errors from the third party library.

valgrind, profiling timer expired?

I try to profile a simple c prog using valgrind:
[zsun#nel6005001 ~]$ valgrind --tool=memcheck ./fl.out
==2238== Memcheck, a memory error detector
==2238== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==2238== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==2238== Command: ./fl.out
==2238==
==2238==
==2238== HEAP SUMMARY:
==2238== in use at exit: 1,168 bytes in 1 blocks
==2238== total heap usage: 1 allocs, 0 frees, 1,168 bytes allocated
==2238==
==2238== LEAK SUMMARY:
==2238== definitely lost: 0 bytes in 0 blocks
==2238== indirectly lost: 0 bytes in 0 blocks
==2238== possibly lost: 0 bytes in 0 blocks
==2238== still reachable: 1,168 bytes in 1 blocks
==2238== suppressed: 0 bytes in 0 blocks
==2238== Rerun with --leak-check=full to see details of leaked memory
==2238==
==2238== For counts of detected and suppressed errors, rerun with: -v
==2238== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 12 from 8)
Profiling timer expired
The c code I am trying to profile is the following:
void forloop(void){
int fac=1;
int count=5;
int i,k;
for (i = 1; i <= count; i++){
for(k=1;k<=count;k++){
fac = fac * i;
}
}
}
"Profiling timer expired" shows up, what does it mean? How to solve this problem? thx!
The problem is that you are using valgrind on a program compiled with -pg. You cannot use valgrind and gprof together. The valgrind manual suggests using OProfile if you are on Linux and need to profile the actual emulation of the program under valgrind.
By the way, this isn't computing factorial.
If you're really trying to find out where the time goes, you could try stackshots. I put an infinite loop around your code and took 10 of them. Here's the code:
6: void forloop(void){
7: int fac=1;
8: int count=5;
9: int i,k;
10:
11: for (i = 1; i <= count; i++){
12: for(k=1;k<=count;k++){
13: fac = fac * i;
14: }
15: }
16: }
17:
18: int main(int argc, char* argv[])
19: {
20: int i;
21: for (;;){
22: forloop();
23: }
24: return 0;
25: }
And here are the stackshots, re-ordered with the most frequent at the top:
forloop() line 12
main() line 23
forloop() line 12 + 21 bytes
main() line 23
forloop() line 12 + 21 bytes
main() line 23
forloop() line 12 + 9 bytes
main() line 23
forloop() line 13 + 7 bytes
main() line 23
forloop() line 13 + 3 bytes
main() line 23
forloop() line 6 + 22 bytes
main() line 23
forloop() line 14
main() line 23
forloop() line 7
main() line 23
forloop() line 11 + 9 bytes
main() line 23
What does this tell you? It says that line 12 consumes about 40% of the time, and line 13 consumes about 20% of the time. It also tells you that line 23 consumes nearly 100% of the time.
That means unrolling the loop at line 12 might potentially give you a speedup factor of 100/(100-40) = 100/60 = 1.67x approximately. Of course there are other ways to speed up this code as well, such as by eliminating the inner loop, if you're really trying to compute factorial.
I'm just pointing this out because it's a bone-simple way to do profiling.
You are not going to be able to compute 10000! like that. You will need some sort of bignum implementation for computing factorials. This is because int is "usually" 4 bytes long which means that "usually" it can hold 2^32 - 1 (signed int, 2^31) - 13! is more than that. Even if you used an unsigned long ("usually" 8 bytes) you'd overflow by the time you reached 21!.
As for what it "profiling timer expired" means - it means valgrind received the signal SIGPROF: http://en.wikipedia.org/wiki/SIGPROF (probably means your program took too long).