Intel® C++ Compiler
Support and discussions for creating C++ code that runs on platforms based on Intel® processors.
7646 Discussions

Intel compiled binary results into core dump on linux system

On linux32 system previously binary(.so) was compiled by gcc 332 and it was working fine. Then I changed compiler to use Intel(ICC 9.1.046patched) keeping rest of the compiler option same. This new binary resulting into core dump. Core dump shows that, program is crashing near about some mutex locking function. In the program file logger is also implemeted. This crash changes when I change into logger buffer size.( It seems to be irrelevant for me). When I used ldd on both binaries found that dependency on has been changed to version 6. Here pasting the output of both ldd binaries.

$ ldd mybinary.so_orig_by_gcc
/usr/lib/ (0x00111000) => /lib/ (0x00ef0000) => /lib/ (0x00113000) => /lib/tls/i686/nosegneg/ (0x00d5b000) => ./ (0x00117000) => /lib/tls/i686/nosegneg/ (0x003f0000) => ./ (0x00a82000) => /lib/tls/i686/nosegneg/ (0x001d0000)
/lib/ (0x00565000)

$ ldd mybinary.so__by_ICC
/usr/lib/ (0x00664000) => /lib/tls/i686/nosegneg/ (0x00111000) => /lib/ (0x00134000) => /lib/ (0x0068c000) => /lib/tls/i686/nosegneg/ (0x0014b000) => /usr/lib/ (0x0015d000) => /lib/ (0x00228000) => /lib/tls/i686/nosegneg/ (0x002aa000)
/lib/ (0x00565000)

Core dump changes, still pasting stack strace
#0 0x005be6c5 in vfprintf ()
from /lib/tls/i686/nosegneg/
(gdb) where
#0 0x005be6c5 in vfprintf () from /lib/tls/i686/nosegneg/
#1 0x005da51b in vsprintf () from /lib/tls/i686/nosegneg/
#2 0x005c72cb in sprintf () from /lib/tls/i686/nosegneg/
#3 0x027b2ece in bString::bAppend () from /
#4 0x027b2e6d in bString::bAppend () from /
#5 0x02731a87 in try_end_1_179.0.83 () from /
#6 0x02746adb in bSWrapper::bwrite () from /
#7 0x027449b9 in bMWrapper::bwrite () from /
#8 0x027195a7 in bMChannel::bNMPinitialize () from /
#9 0x0271b49c in bMThread::Run () from /
#10 0x027bff42 in bThread::ThreadFunc () from /
#11 0x007db413 in start_thread () from /lib/tls/i686/nosegneg/
#12 0x006520fe in clone () from /lib/tls/i686/nosegneg/

$uname -a
Linux myhost 2.6.9- #1 SMP Tue May 19 04:48:26 EDT 2009 i686 i686 i386 GNU/Linux

Any clue where I should investigate.

0 Kudos
6 Replies
It would be nice if you share the test case. It will help us investigate the issue.

Crash issue has been resolved. In the program we were creating one new thread which was responsible for socket read/write operation. I was in doubt, when SIGSEGV was resulted when call to function was made. Execution was not going inside that called function. The thread was created using 32k stack size, I increased it to 64k. This stack size works well when program compiled with gcc 332.

Is there any specific requirment of stack size with ICC?
What ideal stack size I should choose for creating new thread with ICC?
Black Belt
There's no such thing as an ideal stack size. Intel libiomp5 (for several years, the successor to libguide provided with your compiler) sets a default thread stack size of 2MB (4MB for 64-bit mode).
gcc 3.3.2 was released over 8 years ago. There can't be many people still using it. Current linux distros support gcc 4.4 or newer.
Following is the ldd output of the binary:
$ ldd
/usr/lib/ (0x00111000) => not found => /lib/tls/i686/nosegneg/ (0x00f34000) => /lib/ (0x00113000) => /lib/ (0x0012a000) => /lib/tls/i686/nosegneg/ (0x00263000) => /usr/lib/ (0x0012e000) => /lib/ (0x001f9000) => not found => not found => /lib/tls/i686/nosegneg/ (0x00d70000)
/lib/ (0x00565000)

I have not seen dependancy on libiomp5 or libguide libs. Here libpthread is the threading lib are using.

Is above stack size statistics applicable to pthread lib as well? Please correct me.
Black Belt
Do you expect to run a shared object directly without starting it from a.out form binary?
Do you expect to run this binary without setting LD_LIBRARY_PATH, as sourceing the iccvars script would do?
Do you expect to run a shared object directly without starting it from a.out form binary?
Do you expect to run this binary without setting LD_LIBRARY_PATH, as sourceing the iccvars script would do?

To get the clear idea, about the dependancy, I written a simple program which prints the stacksize of a thread.



int main(int argc, char *argv[])
size_t stacksize;
pthread_attr_t attr;
pthread_attr_getstacksize (&attr, &stacksize);
printf("Default stack size = %dn", stacksize);

when I compiled this program using gcc(gcc version 3.4.6 20060404) like:
$ gcc stacksize.c -lpthread
$ ./a.out
Default stack size = 10485760

When I compiled the same program using icc(without sourcing iccvars) like:
$ /usr/local/packages/icc_remote/9.1.046patched/bin/icc stacksize.c -lpthread
$ ./a.out
Default stack size = 10485760

gives the same output.
Note that I didnt set "LD_LIBRARY_PATH".
And when I excuted ldd on a.out compiled by ICC it give output as:
$ ldd a.out
/usr/lib/ (0x0036f000) => /lib/tls/i686/nosegneg/ (0x007d6000) => /lib/tls/i686/nosegneg/ (0x006b8000) => /lib/ (0x00917000) => /lib/tls/i686/nosegneg/ (0x00584000) => /lib/ (0x006dd000)
/lib/ (0x00565000)

So I haven't seen dependancy on libiomp Or libguide.

Also I have confirmed that shared object compiled by ICC doesnt have dependancy on these libs by referring "/proc//maps" file which has list of SO's loaded into a process.
So why the requirement of stack size increased when I changed compiler from GCC to ICC?