- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
After update to mkl 10.2, the application crashed in pardiso, which was working well under 10.1.
When set MKL_NUM_THREADS=1 the application works also.
My system is Intel Core2 Quad CPU Q9400, CentOS release 5.3 (Final)
[power@localhost se2]$ gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.4.0/configure --prefix=/opt --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++ --with-mpfr=/usr/local
Thread model: posix
gcc version 4.4.0 (GCC)
The output information is as following
*** glibc detected *** ./app: free(): invalid next size (normal): 0x00002aaaac05bbd0 ***
======= Backtrace: =========
/lib64/libc.so.6[0x324da71ce2]
/lib64/libc.so.6(cfree+0x8c)[0x324da7590c]
./app(mkl_serv_mkl_free+0x1d)[0x528681]
./app[0x683dff]
./app(mkl_pds_lp64_sfinit_pardiso+0xf7)[0x550f73]
./app(mkl_pds_lp64_reorder1_pardiso+0xa42)[0x552816]
./app(mkl_pds_lp64_do_all_pardiso_fc+0x780e)[0x51eed2]
./app(mkl_pds_lp64_pardiso_c+0x305f)[0x4f5be7]
./app(mkl_pds_lp64_pardiso+0x44f)[0x4e2c8f]
./app(pardiso+0x2e)[0x4e283a]
/home/power/lib/libsparse_solve.so.1(_ZN13CSparseSolve213factorizationEPiS0_Pdi+0x1b3)[0x2b255b5626ef]
/home/power/lib/libsparse_solve.so.1(_ZN13CSparseSolve213factorizationER12CSparseStorei+0x40)[0x2b255b562534]
./app(_ZN15CSEFastDecouple5factQERSt3mapIiS0_IidSt4lessIiESaISt4pairIKidEEES2_SaIS3_IS4_S7_EEER12CSparseStore+0x1a1)[0x48d67f]
./app[0x49a6a5]
/opt/lib64/libgomp.so.1[0x2b255b9b0172]
/lib64/libpthread.so.0[0x324e606367]
/lib64/libc.so.6(clone+0x6d)[0x324dad2f7d]
After update to mkl 10.2, the application crashed in pardiso, which was working well under 10.1.
When set MKL_NUM_THREADS=1 the application works also.
My system is Intel Core2 Quad CPU Q9400, CentOS release 5.3 (Final)
[power@localhost se2]$ gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.4.0/configure --prefix=/opt --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++ --with-mpfr=/usr/local
Thread model: posix
gcc version 4.4.0 (GCC)
The output information is as following
*** glibc detected *** ./app: free(): invalid next size (normal): 0x00002aaaac05bbd0 ***
======= Backtrace: =========
/lib64/libc.so.6[0x324da71ce2]
/lib64/libc.so.6(cfree+0x8c)[0x324da7590c]
./app(mkl_serv_mkl_free+0x1d)[0x528681]
./app[0x683dff]
./app(mkl_pds_lp64_sfinit_pardiso+0xf7)[0x550f73]
./app(mkl_pds_lp64_reorder1_pardiso+0xa42)[0x552816]
./app(mkl_pds_lp64_do_all_pardiso_fc+0x780e)[0x51eed2]
./app(mkl_pds_lp64_pardiso_c+0x305f)[0x4f5be7]
./app(mkl_pds_lp64_pardiso+0x44f)[0x4e2c8f]
./app(pardiso+0x2e)[0x4e283a]
/home/power/lib/libsparse_solve.so.1(_ZN13CSparseSolve213factorizationEPiS0_Pdi+0x1b3)[0x2b255b5626ef]
/home/power/lib/libsparse_solve.so.1(_ZN13CSparseSolve213factorizationER12CSparseStorei+0x40)[0x2b255b562534]
./app(_ZN15CSEFastDecouple5factQERSt3mapIiS0_IidSt4lessIiESaISt4pairIKidEEES2_SaIS3_IS4_S7_EEER12CSparseStore+0x1a1)[0x48d67f]
./app[0x49a6a5]
/opt/lib64/libgomp.so.1[0x2b255b9b0172]
/lib64/libpthread.so.0[0x324e606367]
/lib64/libc.so.6(clone+0x6d)[0x324dad2f7d]
Link Copied
5 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is an unknown problem for us, how can we reproduce the problem?
What's your linking line? Can you get the test case? ( you can use the private thread for that).
I have to remind you that CentOS doesn't support officially by MKL but nevertheless it should works ..
--Gennady
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Gennady Fedorov (Intel)
Thank you for your information.
When I checked the linking line, I found a little diffrent with the example. After erase the -lgomp, It works::)
When I checked the linking line, I found a little diffrent with the example. After erase the -lgomp, It works::)
This is an unknown problem for us, how can we reproduce the problem?
What's your linking line? Can you get the test case? ( you can use the private thread for that).
I have to remind you that CentOS doesn't support officially by MKL but nevertheless it should works ..
--Gennady
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello minifat,
Can you please send us a reproducible test case?
--Gennady
Can you please send us a reproducible test case?
--Gennady
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I came across the same problem when linking C code into the Fortran/BLAS interface (also using Centos, but with newer MKL code -- original post is now 1 year old). Gennady -- I can probably forward a reproducible test code if desired.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Please sendyour test case, it will be very useful for reproducing this problem. Anyway, did you check your link line? This KB article may be helpful.
Best regards,
Artem
Please sendyour test case, it will be very useful for reproducing this problem. Anyway, did you check your link line? This KB article may be helpful.
Best regards,
Artem
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