Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Axel
Beginner
109 Views

Problem calling heap callocated function compiled with debug info

Jump to solution
Hi,

I encountered an issue with ICC 11.1 064 on ia32 on what we call SLC5, a customized Scientific Linux which is a customized RedHat Linux (yes, yikes). I believe what's relevant is:

uname -a
Linux localhost.localdomain 2.6.18-164.6.1.el5 #1 SMP Wed Nov 4 09:08:07 CET 2009 i686 i686 i386 GNU/Linux

glibc-2.5-42.el5_4.2.i686
gcc-4.1.2-46.el5_4.1.i386
libgcc-4.1.2-46.el5_4.1.i386

The code is attached. It uses mmap to allocate an executable piece of the heap and memcpys a function into it, e.g. changing the value of a local variable. That function gets then called, and when compiled with debug info (icc -g t3.cxx && ./a.out) results in a segmentation violation. The same code works on many other platforms and with all other compilers that I ever tried. It works on the exact same machine without debug info (icc t3.cxx) as well as with GCC.

Any ideas what could cause it? Please let me know if I can provide more info.

Cheers, Axel.

0 Kudos
1 Solution
Dale_S_Intel
Employee
109 Views



For me it fails at -O0 but passes at -O2. The behavior is the same with gcc and icc. '-g' doesn't affect it, except that, as Tim pointed out, -g implies -O0 for icc unless otherwise specified.

Dale

View solution in original post

3 Replies
TimP
Black Belt
109 Views
As icc would use its own version of memcpy at default, and possibly use the one you have installed in glibc when you set -O0 (implied by -g), it seems that you can't necessarily blame the addition of debug symbols. Perhaps you mean to add -O along with -g ?
Regardless of whether your OS is meant to clone glibc from an old redhat version, I doubt much attention is paid to the quality of it, particularly in the 32-bit version. I'm trying to set up a current 32-bit icc on a recent 32-bit linux to see what I get with your example.
Are you certain that you were always able to rely on a C compiler switching to C++ on account of your source file name or content? Normal procedure is to use icpc, just as you would use g++ for the gnu C++:
t3.cxx(6): remark #193: zero used for undefined preprocessing identifier "INT_MAX"
#if INT_MAX < LONG_MAX
^

t3.cxx(6): remark #193: zero used for undefined preprocessing identifier "LONG_MAX"
#if INT_MAX < LONG_MAX
^

t3.cxx(20): remark #869: parameter "narg" was never referenced
FunctionCode_t(int narg) : f_offset(0), fa_offset(0), fSize(0) {
^

t3.cxx(51): remark #1418: external function definition with no prior declaration
int inner(void*, char*, void*, int) {
^

t3.cxx(56): remark #1418: external function definition with no prior declaration
int Method_stub_with_context(StubContext_t* context,
^

t3.cxx(57): remark #869: parameter "result" was never referenced
void* result,
^

t3.cxx(59): remark #869: parameter "libp" was never referenced
void* libp,
^

t3.cxx(68): remark #1418: external function definition with no prior declaration
char* allocfunc(char* src, size_t len) {


default version:



nm t3.o|grep memcpy
U _intel_fast_memcpy

-g -O0 version:
nm t3.o|grep memcpy
U memcpy

Dale_S_Intel
Employee
110 Views



For me it fails at -O0 but passes at -O2. The behavior is the same with gcc and icc. '-g' doesn't affect it, except that, as Tim pointed out, -g implies -O0 for icc unless otherwise specified.

Dale

View solution in original post

Axel
Beginner
109 Views
Thanks for you help, Tim and Dale! Your comments allowed me to track the issue down - it's a wrong assumption in the code, obviously nothing wrong with the compilers!

Cheers, Axel.

Reply