- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 | | |
__________________________________________________________________________________________
- Intel Thread Checker 3.1 command line instrumentation driver (26185)
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page