Community
cancel
Showing results for 
Search instead for 
Did you mean: 
FDSUser
Beginner
69 Views

Problem with Intel Thread Checker

Jump to solution

All,

I have the following problem (using Intel Fortran 11.069, Intel C++ 11.069 and Intel Thread Checker 3.1 on Ubuntu 8.04 LTS):

The code I compile is a mixed Fortran-C code, one C-File with some subroutines, all other code is Fortran. The compilation flags I use are

  • ifort -c -g -tcheck -openmp -O0 -L/opt/intel/itt/tcheck/bin/32 -static
  • icc -c -g -tcheck -openmp -Dpp_noappend -O0 -no-multibyte-chars -L/opt/intel/itt/tcheck/bin/32 -static

Linking is done by using:

  • ifort -g -tcheck -openmp -O0 -L/opt/intel/itt/tcheck/bin/32 -static -o

Compilation of the code is no problem, no error occurs. I tried compiling with the -static flag and without the -static flag, no problem or error occurs.

After the successful compilation and linking, I start the Intel Thread Checker with the command:

  • tcheck_cl -f txt -w 90 ./fds5_intel_openmp 1-Gitter.fds

where fds_5_intel_openmp is my successfully compiled executable and 1-Gitter.fds is the file, which the executable needs for starting a calculation.

Then the following errors occur:

  • using an executable compiled and linked with -static flag Intel Thread Checker prints the following result:
    • [cpp]Intel Thread Checker 3.1 command line instrumentation driver (26185)
      Copyright (c) 2007 Intel Corporation. All rights reserved.
      Building project
      Instrumenting
      20% fds5_intel_openmp ( All Functions ):...................
      20% fds5_intel_openmp ( API Imports ):...........
      .

      Running: /FDS_OpenMP/fds5_intel_openmp 1-Gitter.fds


      Application finished

      __________________________________________________________________________________________
      |ID |Short |Severity |Count|Context[Bes|Descripti|1st |2nd |
      | |Description |Name | |t] |on |Access[Best] |Access[Best] |
      __________________________________________________________________________________________

      [/cpp]
  • using an executable without the -static flag, I got:
    • Intel Thread Checker 3.1 command line instrumentation driver (26185)
      Copyright (c) 2007 Intel Corporation. All rights reserved.
      Building project
      Instrumenting
      14% fds5_intel_openmp ( All Functions ):.........................................................
      .

      Running: /FDS_OpenMP/fds5_intel_openmp 1-Gitter.fds

      forrtl: severe (174): SIGSEGV, segmentation fault occurred
      Image PC Routine Line Source
      fds5_intel_openmp 0909627E Unknown Unknown Unknown
      fds5_intel_openmp 08C1CBBE Unknown Unknown Unknown
      fds5_intel_openmp 08C19232 Unknown Unknown Unknown
      libc.so.6 B7C39450 Unknown Unknown Unknown
      fds5_intel_openmp 08C18FC9 Unknown Unknown Unknown

      Application finished

      __________________________________________________________________________________________
      |ID|Short |Severity|Cou|Context[B|Description |1st Acces|2nd Acces|
      | |Description|Name |nt |est] | |s[Best] |s[Best] |
      __________________________________________________________________________________________
      |1 |Thread |Informat|1 |Whole |Thread termination at |"main.f90|"main.f90|
      | |termination|ion | |Program 1|"main.f90":1 - includes stack |":1 |":1 |
      | | | | | |allocation of 8 MB and use of | | |
      | | | | | |180,715 KB | | |
      __________________________________________________________________________________________

The problem now is, that in the first run, where no error message occur, the program does nothing, normally a screen output like

Fire Dynamics Simulator

Compilation Date : Mo, 27 Okt 2008
Version : 5.2.3 Serial
SVN Revision No. : 2558

Job TITLE : Mehrgitterversuch2-1Gitter
Job ID string : 1-Gitter

Time Step: 1, Simulation Time: 0.09 s
Time Step: 2, Simulation Time: 0.18 s
Time Step: 3, Simulation Time: 0.27 s
Time Step: 4, Simulation Time: 0.37 s
Time Step: 5, Simulation Time: 0.46 s
Time Step: 6, Simulation Time: 0.55 s
Time Step: 7, Simulation Time: 0.64 s
Time Step: 8, Simulation Time: 0.73 s
Time Step: 9, Simulation Time: 0.82 s
Time Step: 10, Simulation Time: 0.91 s
Time Step: 20, Simulation Time: 1.50 s
Time Step: 22, Simulation Time: 1.57 s
STOP: FDS completed successfully

should be printed on screen, checking the output files calculated by the program has no effect, because they are not calculated.

If I compile the source code without the Thread Checker flags, by using

  • ifort -c -O0 -axP -ip -static -vec_report0 -openmp

no problem occurs and the code is running fine.

The code has more than 50.000 lines, so is this the problem??? Or is it a Thread Checker Problem, or did I use wrong compiler flags

It would be great, if anybody could help me. The program is OpenSource, so I can answer more questions or post a link to the source-files if they are needed.

0 Kudos
1 Solution
TimP
Black Belt
69 Views

Build with -tcheck and no other unnecessary options, and no special libraries, like MKL or IPP. Run the executable normally (no tcheck_cl yet). Run tcheck_cl threadchecker.thr. This is the only likely way to work with medium to large applications. tcheck has some serious bugs, (for example, it doesn't work with OpenMP default(none)) and no current maintenance. The priority seems to be on the Windows Parallel Studio. I, for one, would like to see the non-interactive no-gui linux version brought back to life.

View solution in original post

3 Replies
TimP
Black Belt
70 Views

Build with -tcheck and no other unnecessary options, and no special libraries, like MKL or IPP. Run the executable normally (no tcheck_cl yet). Run tcheck_cl threadchecker.thr. This is the only likely way to work with medium to large applications. tcheck has some serious bugs, (for example, it doesn't work with OpenMP default(none)) and no current maintenance. The priority seems to be on the Windows Parallel Studio. I, for one, would like to see the non-interactive no-gui linux version brought back to life.

View solution in original post

FDSUser
Beginner
69 Views
Quoting - tim18

Build with -tcheck and no other unnecessary options, and no special libraries, like MKL or IPP. Run the executable normally (no tcheck_cl yet). Run tcheck_cl threadchecker.thr. This is the only likely way to work with medium to large applications. tcheck has some serious bugs, (for example, it doesn't work with OpenMP default(none)) and no current maintenance. The priority seems to be on the Windows Parallel Studio. I, for one, would like to see the non-interactive no-gui linux version brought back to life.

Thanks for your answer, I have tried different possibilities of compiling. The program itself is running successfully (compiled with -g -tcheck) without using the Thread-Checker directly and the threadchecker.thr file is build. If I want to view the threadchecker.thr file, I got the same message as written before:

__________________________________________________________________________________________
|ID|Short |Severity|Cou|Context[B|Description |1st Acces|2nd Acces|
| |Description|Name |nt |est] | |s[Best] |s[Best] |
__________________________________________________________________________________________
|1 |Thread |Informat|1 |Whole |Thread termination at |"main.f90|"main.f90|
| |termination|ion | |Program 1|"main.f90":1 - includes stack |":1 |":1 |
| | | | | |allocation of 8 MB and use of | | |
| | | | | |180,715 KB | | |
__________________________________________________________________________________________

I also have used different stack limits, no success. I have also programmed a race condition to see if any changes can be seen, but this has also no success.

TimP
Black Belt
69 Views
Quoting - FDSUser

Thanks for your answer, I have tried different possibilities of compiling. The program itself is running successfully (compiled with -g -tcheck) without using the Thread-Checker directly and the threadchecker.thr file is build. If I want to view the threadchecker.thr file, I got the same message as written before:

__________________________________________________________________________________________
|ID|Short |Severity|Cou|Context[B|Description |1st Acces|2nd Acces|
| |Description|Name |nt |est] | |s[Best] |s[Best] |
__________________________________________________________________________________________
|1 |Thread |Informat|1 |Whole |Thread termination at |"main.f90|"main.f90|
| |termination|ion | |Program 1|"main.f90":1 - includes stack |":1 |":1 |
| | | | | |allocation of 8 MB and use of | | |
| | | | | |180,715 KB | | |
__________________________________________________________________________________________

I also have used different stack limits, no success. I have also programmed a race condition to see if any changes can be seen, but this has also no success.

That looks like a normal tcheck result, where no problems are diagnosed. If you get similar results with sufficient variety of test cases, you can say it's clean as far as tcheck is concerned.

Reply