- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 libstdc++.so.5 has been changed to version 6. Here pasting the output of both ldd binaries.
$ ldd mybinary.so_orig_by_gcc
/usr/lib/libcwait.so (0x00111000)
libnsl.so.1 => /lib/libnsl.so.1 (0x00ef0000)
libdl.so.2 => /lib/libdl.so.2 (0x00113000)
libpthread.so.0 => /lib/tls/i686/nosegneg/libpthread.so.0 (0x00d5b000)
libstdc++.so.5 => ./libstdc++.so.5 (0x00117000)
libm.so.6 => /lib/tls/i686/nosegneg/libm.so.6 (0x003f0000)
libgcc_s.so.1 => ./libgcc_s.so.1 (0x00a82000)
libc.so.6 => /lib/tls/i686/nosegneg/libc.so.6 (0x001d0000)
/lib/ld-linux.so.2 (0x00565000)
$ ldd mybinary.so__by_ICC
/usr/lib/libcwait.so (0x00664000)
libm.so.6 => /lib/tls/i686/nosegneg/libm.so.6 (0x00111000)
libnsl.so.1 => /lib/libnsl.so.1 (0x00134000)
libdl.so.2 => /lib/libdl.so.2 (0x0068c000)
libpthread.so.0 => /lib/tls/i686/nosegneg/libpthread.so.0 (0x0014b000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x0015d000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00228000)
libc.so.6 => /lib/tls/i686/nosegneg/libc.so.6 (0x002aa000)
/lib/ld-linux.so.2 (0x00565000)
Core dump changes, still pasting stack strace
#0 0x005be6c5 in vfprintf ()
from /lib/tls/i686/nosegneg/libc.so.6
(gdb) where
#0 0x005be6c5 in vfprintf () from /lib/tls/i686/nosegneg/libc.so.6
#1 0x005da51b in vsprintf () from /lib/tls/i686/nosegneg/libc.so.6
#2 0x005c72cb in sprintf () from /lib/tls/i686/nosegneg/libc.so.6
#3 0x027b2ece in bString::bAppend () from /mybinary.so
#4 0x027b2e6d in bString::bAppend () from /mybinary.so
#5 0x02731a87 in try_end_1_179.0.83 () from /mybinary.so
#6 0x02746adb in bSWrapper::bwrite () from /mybinary.so
#7 0x027449b9 in bMWrapper::bwrite () from /mybinary.so
#8 0x027195a7 in bMChannel::bNMPinitialize () from /mybinary.so
#9 0x0271b49c in bMThread::Run () from /mybinary.so
#10 0x027bff42 in bThread::ThreadFunc () from /mybinary.so
#11 0x007db413 in start_thread () from /lib/tls/i686/nosegneg/libpthread.so.0
#12 0x006520fe in clone () from /lib/tls/i686/nosegneg/libc.so.6
$uname -a
Linux myhost 2.6.9-89.0.0.0.1.ELxenU #1 SMP Tue May 19 04:48:26 EDT 2009 i686 i686 i386 GNU/Linux
Any clue where I should investigate.
-- DONG
$ ldd mybinary.so_orig_by_gcc
/usr/lib/libcwait.so (0x00111000)
libnsl.so.1 => /lib/libnsl.so.1 (0x00ef0000)
libdl.so.2 => /lib/libdl.so.2 (0x00113000)
libpthread.so.0 => /lib/tls/i686/nosegneg/libpthread.so.0 (0x00d5b000)
libstdc++.so.5 => ./libstdc++.so.5 (0x00117000)
libm.so.6 => /lib/tls/i686/nosegneg/libm.so.6 (0x003f0000)
libgcc_s.so.1 => ./libgcc_s.so.1 (0x00a82000)
libc.so.6 => /lib/tls/i686/nosegneg/libc.so.6 (0x001d0000)
/lib/ld-linux.so.2 (0x00565000)
$ ldd mybinary.so__by_ICC
/usr/lib/libcwait.so (0x00664000)
libm.so.6 => /lib/tls/i686/nosegneg/libm.so.6 (0x00111000)
libnsl.so.1 => /lib/libnsl.so.1 (0x00134000)
libdl.so.2 => /lib/libdl.so.2 (0x0068c000)
libpthread.so.0 => /lib/tls/i686/nosegneg/libpthread.so.0 (0x0014b000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x0015d000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00228000)
libc.so.6 => /lib/tls/i686/nosegneg/libc.so.6 (0x002aa000)
/lib/ld-linux.so.2 (0x00565000)
Core dump changes, still pasting stack strace
#0 0x005be6c5 in vfprintf ()
from /lib/tls/i686/nosegneg/libc.so.6
(gdb) where
#0 0x005be6c5 in vfprintf () from /lib/tls/i686/nosegneg/libc.so.6
#1 0x005da51b in vsprintf () from /lib/tls/i686/nosegneg/libc.so.6
#2 0x005c72cb in sprintf () from /lib/tls/i686/nosegneg/libc.so.6
#3 0x027b2ece in bString::bAppend () from /mybinary.so
#4 0x027b2e6d in bString::bAppend () from /mybinary.so
#5 0x02731a87 in try_end_1_179.0.83 () from /mybinary.so
#6 0x02746adb in bSWrapper::bwrite () from /mybinary.so
#7 0x027449b9 in bMWrapper::bwrite () from /mybinary.so
#8 0x027195a7 in bMChannel::bNMPinitialize () from /mybinary.so
#9 0x0271b49c in bMThread::Run () from /mybinary.so
#10 0x027bff42 in bThread::ThreadFunc () from /mybinary.so
#11 0x007db413 in start_thread () from /lib/tls/i686/nosegneg/libpthread.so.0
#12 0x006520fe in clone () from /lib/tls/i686/nosegneg/libc.so.6
$uname -a
Linux myhost 2.6.9-89.0.0.0.1.ELxenU #1 SMP Tue May 19 04:48:26 EDT 2009 i686 i686 i386 GNU/Linux
Any clue where I should investigate.
-- DONG
Link Copied
6 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It would be nice if you share the test case. It will help us investigate the issue.
Om
Om
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
Is there any specific requirment of stack size with ICC?
What ideal stack size I should choose for creating new thread with ICC?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Following is the ldd output of the binary:
$ ldd mybinary.so
/usr/lib/libcwait.so (0x00111000)
libimf.so => not found
libm.so.6 => /lib/tls/i686/nosegneg/libm.so.6 (0x00f34000)
libnsl.so.1 => /lib/libnsl.so.1 (0x00113000)
libdl.so.2 => /lib/libdl.so.2 (0x0012a000)
libpthread.so.0 => /lib/tls/i686/nosegneg/libpthread.so.0 (0x00263000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x0012e000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x001f9000)
libcxaguard.so.5 => not found
libirc.so => not found
libc.so.6 => /lib/tls/i686/nosegneg/libc.so.6 (0x00d70000)
/lib/ld-linux.so.2 (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.
$ ldd mybinary.so
/usr/lib/libcwait.so (0x00111000)
libimf.so => not found
libm.so.6 => /lib/tls/i686/nosegneg/libm.so.6 (0x00f34000)
libnsl.so.1 => /lib/libnsl.so.1 (0x00113000)
libdl.so.2 => /lib/libdl.so.2 (0x0012a000)
libpthread.so.0 => /lib/tls/i686/nosegneg/libpthread.so.0 (0x00263000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x0012e000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x001f9000)
libcxaguard.so.5 => not found
libirc.so => not found
libc.so.6 => /lib/tls/i686/nosegneg/libc.so.6 (0x00d70000)
/lib/ld-linux.so.2 (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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 this binary without setting LD_LIBRARY_PATH, as sourceing the iccvars script would do?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Do you expect to run a shared object directly without starting it from a.out form binary?
[No]
Do you expect to run this binary without setting LD_LIBRARY_PATH, as sourceing the iccvars script would do?
[Yes]
To get the clear idea, about the dependancy, I written a simple program which prints the stacksize of a thread.
//stacksize.c
#include
#include
int main(int argc, char *argv[])
{
size_t stacksize;
pthread_attr_t attr;
pthread_attr_init(&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/libcwait.so (0x0036f000)
libpthread.so.0 => /lib/tls/i686/nosegneg/libpthread.so.0 (0x007d6000)
libm.so.6 => /lib/tls/i686/nosegneg/libm.so.6 (0x006b8000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00917000)
libc.so.6 => /lib/tls/i686/nosegneg/libc.so.6 (0x00584000)
libdl.so.2 => /lib/libdl.so.2 (0x006dd000)
/lib/ld-linux.so.2 (0x00565000)
So I haven't seen dependancy on libiomp Or libguide.
Also I have confirmed that mybinary.so 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?
[No]
Do you expect to run this binary without setting LD_LIBRARY_PATH, as sourceing the iccvars script would do?
[Yes]
To get the clear idea, about the dependancy, I written a simple program which prints the stacksize of a thread.
//stacksize.c
#include
#include
int main(int argc, char *argv[])
{
size_t stacksize;
pthread_attr_t attr;
pthread_attr_init(&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/libcwait.so (0x0036f000)
libpthread.so.0 => /lib/tls/i686/nosegneg/libpthread.so.0 (0x007d6000)
libm.so.6 => /lib/tls/i686/nosegneg/libm.so.6 (0x006b8000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00917000)
libc.so.6 => /lib/tls/i686/nosegneg/libc.so.6 (0x00584000)
libdl.so.2 => /lib/libdl.so.2 (0x006dd000)
/lib/ld-linux.so.2 (0x00565000)
So I haven't seen dependancy on libiomp Or libguide.
Also I have confirmed that mybinary.so shared object compiled by ICC doesnt have dependancy on these libs by referring "/proc/
So why the requirement of stack size increased when I changed compiler from GCC to ICC?
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page