Problem calling heap callocated function compiled with debug info

[Axel]

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.

[TimP]

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 · Accepted solution]

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

[Axel]

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.