Bypass 3rd party Application

[qnphan]

I am debugging a dynamic DLL project. I use a 3rd party application(large program)to invoke my library. Is there a way to tell PS to bypass the checking of the 3rd party application and report only issues associated with my library? TIA.

[Vladimir_T_Intel]

Quoting - qnphan

I am debugging a dynamic DLL project. I use a 3rd party application(large program)to invoke my library. Is there a way to tell PS to bypass the checking of the 3rd party application and report only issues associated with my library? TIA.

Would you please specify which exactly tool in the Parallel Studio you want to bypass the a 3-rd party application?

[qnphan]

Quoting - Vladimir Tsymbal (Intel)

Would you please specify which exactly tool in the Parallel Studio you want to bypass the a 3-rd party application?

It is the Parallel Inspector that I'd likeit to skip all resources analysis on the 3rd party application.The options to suppress certain module or file from the reporting does not serve the same purpose since it still waste lots of time on themodule unrelated to my DLL project.

[Vladimir_T_Intel]

Quoting - qnphan

It is the Parallel Inspector that I'd likeit to skip all resources analysis on the 3rd party application.The options to suppress certain module or file from the reporting does not serve the same purpose since it still waste lots of time on themodule unrelated to my DLL project.

The technology that Inspector analysis is based on implies taking into account all the memory accesses and threading API calls in the process - otherwise some diagnostics maybe lost. So the suppression mechanism is just simplifying the post processing analysis. If you concerned about analysis overhead, then you need to vary the level of analysis.

[qnphan]

Quoting - Vladimir Tsymbal (Intel)

The technology that Inspector analysis is based on implies taking into account all the memory accesses and threading API calls in the process - otherwise some diagnostics maybe lost. So the suppression mechanism is just simplifying the post processing analysis. If you concerned about analysis overhead, then you need to vary the level of analysis.

Thanks for the quick response! Sounds like there is no such provision at this point to by-pass the analysis of 3rd party Apps. I already tried different level of analysis but it still consumes way too much time!

I understadn that Inspector tool checks all memory read/write with thread info. to derive the race condition or memory access issues. I would think tracking the working threadson the3rd party Appsisnot as intense as the memory checks.Please comment on a suggestion toprovides runtime functions so instrumentation can be applied to skip only the memory read/write in non interested modulebut keep the thread info. though so data race can still be checked on the interested modules? Thanks. -phan

[Vladimir_T_Intel]

Quoting - qnphan

Thanks for the quick response! Sounds like there is no such provision at this point to by-pass the analysis of 3rd party Apps. I already tried different level of analysis but it still consumes way too much time!

I understadn that Inspector tool checks all memory read/write with thread info. to derive the race condition or memory access issues. I would think tracking the working threadson the3rd party Appsisnot as intense as the memory checks.Please comment on a suggestion toprovides runtime functions so instrumentation can be applied to skip only the memory read/write in non interested modulebut keep the thread info. though so data race can still be checked on the interested modules? Thanks. -phan

Overhead is unavoidable evil of the instrumentation technology. The payment for decreasing overhead is truncating the scope of errors detected.

Inspector does not provide any runtime functions API to skip memory checks - there is no sense in that. Data races can be detected if only memory accesses and threading API calls are tracked.