Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.

Error: uninitialised values

Pieter_Vancraeyveld
2,389 Views
Compiling the following code
[cpp]#include 

int main()
{
char x[2];
std::strcpy(x,"x");
std::strlen(x);

return 0;
}[/cpp]
with the intel compiler (11.1 20091130) gives the following error when ran through valgrind:
[shell]==11904== Conditional jump or move depends on uninitialised value(s)
==11904== at 0x400B19: __intel_new_proc_init.H (in /tmp/a.out)
==11904== by 0x400978: main (in /tmp/a.out)
==11904==
==11904== Conditional jump or move depends on uninitialised value(s)
==11904== at 0x400B3E: __intel_new_proc_init.H (in /tmp/a.out)
==11904== by 0x400978: main (in /tmp/a.out)

[/shell]
Compiling with gcc (4.4.1) produces no errors.
0 Kudos
1 Solution
Brandon_H_Intel
Employee
2,389 Views
I compile with -O2. Compiling the source with -O0 makes the valgrind error go away. I use no other flags.

As for valgrind, I use all the defaults. Running 'valgrind --track-origins=yes ./a.out' gives the following output:
[shell]==25737== Conditional jump or move depends on uninitialised value(s)
==25737== at 0x400B19: __intel_new_proc_init.H (in /tmp/a.out)
==25737== by 0x400978: main (in /tmp/a.out)
==25737== Uninitialised value was created by a stack allocation
==25737== at 0x4002DBA: dl_main (rtld.c:1640)
==25737==
==25737== Conditional jump or move depends on uninitialised value(s)
==25737== at 0x400B3E: __intel_new_proc_init.H (in /tmp/a.out)
==25737== by 0x400978: main (in /tmp/a.out)
==25737== Uninitialised value was created by a stack allocation
==25737== at 0x4002DBA: dl_main (rtld.c:1640)
[/shell]
For completeness, I use valgrind version 3.5.0 and icc for intel64

From http://valgrind.org/docs/manual/dist.news.html:

* KNOWN LIMITATIONS:

- Memcheck is unusable with the Intel compiler suite version 11.1, when it generates code for SSE2-and-above capable targets. This is because of icc's use of highly optimised inlined strlen implementations. It causes Memcheck to report huge numbers of false errors even in simple programs. Helgrind and DRD may also have problems.

I recommend seeking a resolution on the valgrind end of things.

View solution in original post

0 Kudos
10 Replies
Mark_S_Intel1
Employee
2,389 Views
I could not reproduce the problem with icc 11.1 build 20091130 (both IA32 and Intel64) and Valgrind version 2.2. Could you please provide the icc andthe valgrind options you used to get the error.

Thanks,
--mark

0 Kudos
Pieter_Vancraeyveld
2,389 Views
I compile with -O2. Compiling the source with -O0 makes the valgrind error go away. I use no other flags.

As for valgrind, I use all the defaults. Running 'valgrind --track-origins=yes ./a.out' gives the following output:
[shell]==25737== Conditional jump or move depends on uninitialised value(s)
==25737== at 0x400B19: __intel_new_proc_init.H (in /tmp/a.out)
==25737== by 0x400978: main (in /tmp/a.out)
==25737== Uninitialised value was created by a stack allocation
==25737== at 0x4002DBA: dl_main (rtld.c:1640)
==25737==
==25737== Conditional jump or move depends on uninitialised value(s)
==25737== at 0x400B3E: __intel_new_proc_init.H (in /tmp/a.out)
==25737== by 0x400978: main (in /tmp/a.out)
==25737== Uninitialised value was created by a stack allocation
==25737== at 0x4002DBA: dl_main (rtld.c:1640)
[/shell]
For completeness, I use valgrind version 3.5.0 and icc for intel64
0 Kudos
Brandon_H_Intel
Employee
2,390 Views
I compile with -O2. Compiling the source with -O0 makes the valgrind error go away. I use no other flags.

As for valgrind, I use all the defaults. Running 'valgrind --track-origins=yes ./a.out' gives the following output:
[shell]==25737== Conditional jump or move depends on uninitialised value(s)
==25737== at 0x400B19: __intel_new_proc_init.H (in /tmp/a.out)
==25737== by 0x400978: main (in /tmp/a.out)
==25737== Uninitialised value was created by a stack allocation
==25737== at 0x4002DBA: dl_main (rtld.c:1640)
==25737==
==25737== Conditional jump or move depends on uninitialised value(s)
==25737== at 0x400B3E: __intel_new_proc_init.H (in /tmp/a.out)
==25737== by 0x400978: main (in /tmp/a.out)
==25737== Uninitialised value was created by a stack allocation
==25737== at 0x4002DBA: dl_main (rtld.c:1640)
[/shell]
For completeness, I use valgrind version 3.5.0 and icc for intel64

From http://valgrind.org/docs/manual/dist.news.html:

* KNOWN LIMITATIONS:

- Memcheck is unusable with the Intel compiler suite version 11.1, when it generates code for SSE2-and-above capable targets. This is because of icc's use of highly optimised inlined strlen implementations. It causes Memcheck to report huge numbers of false errors even in simple programs. Helgrind and DRD may also have problems.

I recommend seeking a resolution on the valgrind end of things.
0 Kudos
Evren_Yurtesen
Beginner
2,389 Views
Yes, but why does it still do the same if the program is compiled with "-no-vec -march=pentium" flags? Pentium processor has no SSE2 capability as far as I know...

If icc is still using the optimized implementations, is there a way to disable them?
0 Kudos
Brandon_H_Intel
Employee
2,389 Views
"pentium" is not a supported value for -march. The driver should complain about this, but I have confirmed at least that adding that option has no effect on anything. Try adding -mia32 instead.
0 Kudos
Evren_Yurtesen
Beginner
2,389 Views
I thought I saw the 'pentium' value in intel compiler reference documentaton but I couldnt find it now. Maybe you are right, it doesnt support -march=pentium. In either case, -march=pentium does not generate any error/warning messages. Also -mia32 is not helping the issue (perhaps since I am on a 64bit Linux installation?). I tested this with C code...

#include

int main() {
printf("hello, world\n");
return 0;
}


$ icc -Wall -march=pentium test.c
$ valgrind ./a.out
==5833== Memcheck, a memory error detector
==5833== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==5833== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==5833== Command: ./a.out
==5833==
==5833== Conditional jump or move depends on uninitialised value(s)
==5833== at 0x400A49: __intel_new_proc_init.H (in /export/home/aton2/eyurtese/a.out)
==5833== by 0x4008A8: main (in /export/home/aton2/eyurtese/a.out)
==5833==
==5833== Conditional jump or move depends on uninitialised value(s)
==5833== at 0x400A6E: __intel_new_proc_init.H (in /export/home/aton2/eyurtese/a.out)
==5833== by 0x4008A8: main (in /export/home/aton2/eyurtese/a.out)
==5833==
hello, world
==5833==
==5833== HEAP SUMMARY:
==5833== in use at exit: 0 bytes in 0 blocks
==5833== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==5833==
==5833== All heap blocks were freed -- no leaks are possible
==5833==
==5833== For counts of detected and suppressed errors, rerun with: -v
==5833== Use --track-origins=yes to see where uninitialised values come from
==5833== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 6 from 6)

$ icc -Wall -mia32 test.c
$ valgrind ./a.out
==5862== Memcheck, a memory error detector
==5862== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==5862== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==5862== Command: ./a.out
==5862==
==5862== Conditional jump or move depends on uninitialised value(s)
==5862== at 0x400A49: __intel_new_proc_init.H (in /export/home/aton2/eyurtese/a.out)
==5862== by 0x4008A8: main (in /export/home/aton2/eyurtese/a.out)
==5862==
==5862== Conditional jump or move depends on uninitialised value(s)
==5862== at 0x400A6E: __intel_new_proc_init.H (in /export/home/aton2/eyurtese/a.out)
==5862== by 0x4008A8: main (in /export/home/aton2/eyurtese/a.out)
==5862==
hello, world
==5862==
==5862== HEAP SUMMARY:
==5862== in use at exit: 0 bytes in 0 blocks
==5862== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==5862==
==5862== All heap blocks were freed -- no leaks are possible
==5862==
==5862== For counts of detected and suppressed errors, rerun with: -v
==5862== Use --track-origins=yes to see where uninitialised values come from
==5862== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 6 from 6)
$ file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
$

The actual problem I am having is that I have a program written in fortran/c and it works on large 2D arrays. It was working fine with GCC, and if I am not mistaken there are some people who use it by compiling with PGI compiler. But, when I compile the program with icc 11.1 it creates segmentation faults when I increase the problem size. couldnt figure out the reason and it was happening even when options like no-vec, O0 etc. were used to compile the program. I decided to use valgrind to track down the problem but that was not successful (which lead me to find this thread).

So is it possible to turn down the optimizations of intel compiler so the binaries can be valgrind compatible?
0 Kudos
TimP
Honored Contributor III
2,389 Views
Compilers for x86_64 expect a minimum SSE2 platform, and the first Intel x86_64 platform was SSE3. So there is no explicit non-SSE2 option for 64-bit compilation in any compiler.
I see you discussing unexpected segfaults, but no mention of whether you took the standard steps for resolving it, starting with increasing your stack sizes or checking for stack overflow. I believe default stack setting is larger for PGI than for Intel compilers.
0 Kudos
Evren_Yurtesen
Beginner
2,389 Views
Sorry, I am new to intel compilers, thus the lack of information... is there any documentation pointing out how to proceed on debugging this sort of problems?

Anyway, thanks for the excellent hint. It appears that the solution to my problem was explained already at:
http://software.intel.com/en-us/articles/intel-fortran-compiler-increased-stack-usage-of-80-or-higher-compilers-causes-segmentation-fault/
Increased the stack using the 'limit' from shell and the program works...

I have few questions...

* How can I find exactly what is overflowing the stack? any pointers?
* The occurance of the problem is a little bit unpredictable... is there a way to avoid this altogether? Any performance impact for using -heap-arrays option?
* Is there any useful documentation which you think might be helpful for me to have a look at?

Thanks a lot, and sorry for hijacking the thread...
Evren
0 Kudos
TimP
Honored Contributor III
2,389 Views
The author of that piece made an excellent effort to cover the first important points.
You could set debug options, while fixing your desired level of optimization, and find out where you run off stack. As you hint, it's likely to be when you perform a dynamic allocation or in a library function which may perform implicit allocation. This includes entering a function which has local auto arrays. So, if you die when entering a function, you might check whether it defines unnecessarily large arrays, or even take the precaution of allocating the big ones explicitly (on heap) with error recovery.
-heap-arrays may be only a Fortran option, and is not necessarily safe when using -openmp or -parallel. It's common for compilers to have such an option to switch from stack to heap at a specified allocation chunk size, with the idea that extra time taken to make heap allocation is negligible for large enough allocations.
0 Kudos
jimdempseyatthecove
Honored Contributor III
2,389 Views
When you compile with debugging enabled and with run-time checks enabled what happens?
(enable check uninitialized variables, check array and string bounds, check for null pointers, actual arguments using temporary)

Since this is a mixed language (Fortran/c) you may have interface problems. In particular wrong sized pointers and/or argument calling convention errors.

If the above yields nothing then revert to inserting trace diagnostics into your program
HINT use the Fortran PreProcessor and define a macro to expand/no-expand trace with file and line numbering. Write and flush trace to log file for post mortem of crash.
Also, in trace routine, declare a local scalar, e.g. integer(8) and store into the scalar the LOC of that variable. include into the trace log the value in the variable (this will indirectly report the stack usage). Something will show up, it usually does.

Jim Dempsey
0 Kudos
Reply