3 Replies Latest reply on Aug 19, 2010 12:22 PM by chipf

    Deadlock while loading ACML 4.4.0 DLL

    Andy387

      Hi, I'm using the LAPACK routines of ACML, thanks a lot for the great library!

      On Windows 7 x64 using ACML 4.4.0 ifort32, I experience a deadlock (one core @ 100%) at the startup of my program; the stack trace points to libifcoremd.dll.

      The problem exists for both the single and the multi-threaded version of the library.

      It does not occur for the preceding 4.3.0 release.

      There is no issue on Windows XP x64, neither for version 4.4.0 nor 4.3.0.

      The deadlock can be reproduced with a minimal example program, e.g.  sgetrf_cpp_example.cpp.

      I'm using Visual Studio 2008.

      Is this a known problem? Thanks a lot!

        • Deadlock while loading ACML 4.4.0 DLL
          chipf

          We tried this and could not reproduce a problem.  The machine is a two socket Magny Cours system running Win7 64-bit.  VS 2008 is installed.  We also have the intel compilers on this system, but a command line window is started and variables set so that the intel compilers are not visible to the command line.  The window startup invokes the 32 bit Microsoft setup scripts rather than the x64 scripts.

          Both the C and C++ examples run, and both can be built using the microsoft cl compiler.  This is for the ifort32 library.

          Make sure you don't have any issues with the PATH variable pointing at the wrong acml lib directory.  The example makefile sets this for each example, but just running the executable on the command line will use whatever PATH is pointing at.

            • Deadlock while loading ACML 4.4.0 DLL
              Andy387

              Thank you very much for looking into the issue!

              The library keeps stalling on my Windows 7 x64 system, with the cause being rooted in libifcoremd.dll. I inspected the disassembly in the Visual Studio debugger and it seems to me that the infinite loop occurs while the CPU model is identified. I have a Core 2 Quad Q9650 installed, which would explain why you could not reproduce the error. The CPU identification routine seems to work properly and take the right path for my processor. However, as the last step of the identification, the extended control register XCR0 is retrieved via the xgetbv instruction. Bits 63..32 of the XCR0 are stored as result of the routine. As far as I understand, these bits are currently reserved and zero on my system. Yet the routine is repeated until the result is one of three nonzero values.

              I believe this could be due to the following issue of the Intel Compiler:

              Update 2 revised (Posted October 2009), Package IDs below

              w_cproc_p_11.1.048
              w_cprof_p_11.1.048

              DPD200139120 C, C++, Fortran - The packages were rebuilt to correct an issue where the compiler would not run on certain Windows 7* and Windows Server 2008* systems. Correctness of the generated code is not an issue.

              Or due to the same/related issue of the Intel Parallel Composer:

              Update 2 Revised (Posted October 2009)

              DPD200139120 C, C++ - Update 2 list below has more details on this issue. Note: The package was rebuilt to correct an issue where the compiler would not run on certain Windows 7* and Windows Server 2008* systems. Correctness of the generated code is not an issue.

              Update 2 (Posted September 2009)

              DPD200139120 C,C++ - Composer may hang or encounter a segmentation-fault when run on Microsoft* Windows 7* or Windows Server 2008* R2. Please refer to the following links for more details:

              [...]

              DPD200139120 C,C++ - Application hangs due to xgetbv in __intel_cpu_indicator_init() function 


              The respective websites are:

              http://software.intel.com/en-us/articles/intel-professional-edition-compilers-111-fixes-list/
              http://software.intel.com/en-us/articles/intel-parallel-composer-fixes-list/

              Is it possible that the acml 4.4.0-ifort32 was built with an Intel compiler not containing the afore-mentioned patch? The "product version" (Windows Explorer context menu) of libifcoremd.dll is listed as "11.1 (Beta)" on my system, the "File Version" is 11.1.4.4?
              If that is the case, would it be possible to release the package built with a recent Intel compiler having the latest patches?

              Thanks a lot for your efforts!