Thread Checker: Unknown in callstack

[anid5]

Thread Checker is reporting multiple write->read, and write->write data race items. It reports the callstack of one of the two access points. For the other access it reports a callstack of size 3, each item being "Unknown". Is there something that I can do to cause Thread Checker to report the callstack of the other access?

Thank you for your time.

[Vladimir_T_Intel]

Quoting - anid5

Thread Checker is reporting multiple write->read, and write->write data race items. It reports the callstack of one of the two access points. For the other access it reports a callstack of size 3, each item being "Unknown". Is there something that I can do to cause Thread Checker to report the callstack of the other access?

Thank you for your time.

Most probably, there are callson path wheresystem modules or moduleswhich have no .pdb files with debug information are involved. In this case Thread Checker marks those calls as 'Unknown'.
If you feel that I missed the point, please provide the screen shots and explain in more details.
Thanks.

[anid5]

The application has a pdb file. The application depends on several libraries which have pdb files. Some of those are static libraries and others are dynamic. Do I need do anything in ThreadChecker to somehow reference those pdb files?

Thank you.

[Vladimir_T_Intel]

Quoting - anid5

The application has a pdb file. The application depends on several libraries which have pdb files. Some of those are static libraries and others are dynamic. Do I need do anything in ThreadChecker to somehow reference those pdb files?

Thank you.

Actually Thread Chaker does not need to explicitly point out path to pdb files if you didn't move them after recompiling the project.

Just make sure you set the folloing options in the project properties:

C/C++ -> Debug Information Format -> /Zi

Linker -> Debugging -> Generate debug info -> /DEBUG

Linker -> Advanced -> Fixed Base address -> /FIXED:NO

Better results in symbols resolution canbe achieved by disabling compiler optimization:

C/C++ ->Optimization -> Optimization -> /Od

[anid5]

We usually build the third party libraries using each library's native or recommended build system.Then we move the.lib, .dll,and pdb files to a lib subdirectory (and the.h files to an include subdirectory)that are referenced when we build the application. The application build system currently uses makefiles.

I've tried moving the .pdb files to the directory that contains the application executable. I've also tried moving some of the pdb files to the location of their corresponding .dll. Moving the pdb files to the dll location resulted ThreadChecker reporting different error messages. I didn't see as many of the "unknown" error messages, but the callstacks that were reported didn'tseem entirely correct.

I'm considering rebuilding all the 3rd party libraries and applicationusing Z7 instead of Zi.

[Vladimir_T_Intel]

Quoting - anid5

We usually build the third party libraries using each library's native or recommended build system.Then we move the.lib, .dll,and pdb files to a lib subdirectory (and the.h files to an include subdirectory)that are referenced when we build the application. The application build system currently uses makefiles.

I've tried moving the .pdb files to the directory that contains the application executable. I've also tried moving some of the pdb files to the location of their corresponding .dll. Moving the pdb files to the dll location resulted ThreadChecker reporting different error messages. I didn't see as many of the "unknown" error messages, but the callstacks that were reported didn'tseem entirely correct.

I'm considering rebuilding all the 3rd party libraries and applicationusing Z7 instead of Zi.

OK. This sounds more clear. If some third party libraries are being built apart, Thread Checker's symbol resolver might not find the right paths. Usually, it's enough to assosiate those paths to dlls and pdbs. Go to Menu -> Configure -> Options -> Directories -> File Assosiation. Find the list of binary files of your project on each file type (Binary/Symbol) and assosiate the files with right paths. This might not result the similar behaviour to when moving dlls/pdbs, as I'm not sure if symbol resolver is used during collectiom. But give it a try.

If this doesn't help much, the reason is most probably compiler opimization options. You didn't mention whether you switched them off.

I don see any benefit in recompiling with Z7 instead of Zi or ZI.

[anid5]

It seems that my attempts to associate .dll and .pdb files did not work. There are currently no items listed in the "Binary and Symbol Files" list. After referencing .dll and .pdb files and clicking "OK" in the "New File Association" dialog, there are no items in the "Binary and Symbol Files" list.

The application's code was compiled with /Od. But not all of the 3rd party libraries were compiled with /Od.

[Vladimir_T_Intel]

Hmm.. here are my thoughts.

Make sure you have at least one module of interest selected for your activity. Usually it's .exe file. You can check it at Activity Properties -> Advanced Activity Configuration Dialog -> Application/Module Profiles field -> [Your application] -> Configure -> Modules of Interest. This module should also appear in the File Association dialog (Context: Your Project; File Type: Symbol). If not, assosiate it with appropriate symbol file name manually. Try the collection again.

Note the module names of the "Unknown" functions in the stack. Check the level of instrumentation for those modules in the instrumentation table: Activity Properties -> Advanced Activity Configuration Dialog -> Data Collectors -> Intel Thread Checker -> Configure button -> Configure Chread Checker Dialog -> Instrumentation Tab. If the current level of instrumentation for the noted module is "Module imports", it means that thre is no debug info found for it. "Debug" column in the table can confirm that. In this case having the Unknowns in the stack is unavoidable.

If you see "Module imports" level of instrumentation for some dll, but you are sure that pdb-file is present, check the dll with Static Analizer: Menu -> File -> Open Static Module Viewer -> Choose the dll in the Open dialog. If you see all the functions of the dll in the list, it means that Thread Cheker couldn't find the path to the pdb file. If no functions listed (exept export ones), then it's something wrong with symbol information in the pdb.

Look through the output window messages after collection. There should be meaningful messages there regarding inability to instrument some ddls.

[avodovnik]

Quoting - Vladimir Tsymbal (Intel)

Hmm.. here are my thoughts.

Make sure you have at least one module of interest selected for your activity. Usually it's .exe file. You can check it at Activity Properties -> Advanced Activity Configuration Dialog -> Application/Module Profiles field -> [Your application] -> Configure -> Modules of Interest. This module should also appear in the File Association dialog (Context: Your Project; File Type: Symbol). If not, assosiate it with appropriate symbol file name manually. Try the collection again.

Note the module names of the "Unknown" functions in the stack. Check the level of instrumentation for those modules in the instrumentation table: Activity Properties -> Advanced Activity Configuration Dialog -> Data Collectors -> Intel Thread Checker -> Configure button -> Configure Chread Checker Dialog -> Instrumentation Tab. If the current level of instrumentation for the noted module is "Module imports", it means that thre is no debug info found for it. "Debug" column in the table can confirm that. In this case having the Unknowns in the stack is unavoidable.

If you see "Module imports" level of instrumentation for some dll, but you are sure that pdb-file is present, check the dll with Static Analizer: Menu -> File -> Open Static Module Viewer -> Choose the dll in the Open dialog. If you see all the functions of the dll in the list, it means that Thread Cheker couldn't find the path to the pdb file. If no functions listed (exept export ones), then it's something wrong with symbol information in the pdb.

Look through the output window messages after collection. There should be meaningful messages there regarding inability to instrument some ddls.

Hi!

I'm having this same problem. When I load the exe file of my mixed mode DLL (VS 2008 SP1) with the Static Analyzer it shows all the functions. When I try and run an activity using the Threads checker I only get "UNKNOWN" everywhere. I've tried all the things you said above to no avail. Any suggestion?

Regards,

Ane

[Vladimir_T_Intel]

Quoting - avodovnik

Hi!

I'm having this same problem. When I load the exe file of my mixed mode DLL (VS 2008 SP1) with the Static Analyzer it shows all the functions. When I try and run an activity using the Threads checker I only get "UNKNOWN" everywhere. I've tried all the things you said above to no avail. Any suggestion?

Regards,

Ane

Hi Ane,

Could you confirm it - do you keep all thePDB filesinthe same directory as DLLs located in?

And if by mixed mode DLL you mean that some of DLLs are stripped out (no debug info), the stack will be UNKNOWN right after a call to such DLL.

[avodovnik]

Quoting - Vladimir Tsymbal (Intel)

Hi Ane,

Could you confirm it - do you keep all thePDB filesinthe same directory as DLLs located in?

And if by mixed mode DLL you mean that some of DLLs are stripped out (no debug info), the stack will be UNKNOWN right after a call to such DLL.

Hi Vladimir,

let me ilustrate the project a little bit: I have a mixed mode EXE (by mixed mode I mean that some files are built with /clr support) with no specially linked DLLs. In this EXE I have a few threads that happen to run into a data race condition. When built, the PDBs are next to the EXE yes, and also, like I wrote, if I open it using the static module opener, I can see all the functions.

Regards,

Ane

[Vladimir_T_Intel]

Quoting - avodovnik

Hi Vladimir,

let me ilustrate the project a little bit: I have a mixed mode EXE (by mixed mode I mean that some files are built with /clr support) with no specially linked DLLs. In this EXE I have a few threads that happen to run into a data race condition. When built, the PDBs are next to the EXE yes, and also, like I wrote, if I open it using the static module opener, I can see all the functions.

Regards,

Ane

Oh, I see now. Of course we use 'mixed' term when some .net part is incorporated. I just confused itwith the previous app description.

Thead Checker doesn't support .NET, which is unfortunate. This might affected the stacks reconstruction.Whereas, VTune static analyser is tolerant towards clr calls.

[avodovnik]

Quoting - Vladimir Tsymbal (Intel)

Quoting - avodovnik

Hi Vladimir,

let me ilustrate the project a little bit: I have a mixed mode EXE (by mixed mode I mean that some files are built with /clr support) with no specially linked DLLs. In this EXE I have a few threads that happen to run into a data race condition. When built, the PDBs are next to the EXE yes, and also, like I wrote, if I open it using the static module opener, I can see all the functions.

Regards,

Ane

Oh, I see now. Of course we use 'mixed' term when some .net part is incorporated. I just confused itwith the previous app description.

Thead Checker doesn't support .NET, which is unfortunate. This might affected the stacks reconstruction.Whereas, VTune static analyser is tolerant towards clr calls.

Oh, that is a dissapointment :- But ok, I'm 99,9% sure the problematic area is in the native part, so I'll just take it out, and build a new project around it and try and instrument that one. Hope it will do the trick.

Do you happen to know if there are any plans to add support, or if there is a beta available?

Regards,

Ane

[Vladimir_T_Intel]

Quoting - avodovnik

Do you happen to know if there are any plans to add support, or if there is a beta available?

Regards,

Ane

Yes, we have plans to support .NET in our products that will come after Intel Parallel Studio (that one does not support .NET as well). Just stay tuned.