Forums

jean-michel.rouet@philips.com originally wrote:

Has anybody experienced succesful instrumentation and error detection with openmp code? OpenMP is quite a standard practice in nowadays programming. I would expect that devpartner error detection supports such code.

First I've ever heard of the thing, but I've had my nose down deep in BoundsChecker for quite a while, so I may have missed some things going on in the outside world. There are a lot of OpenXX libraries out there...

On a large VisualStudio 2008 project I'm involved in, my code crashes when ran under ErrorDection, unless the number of OMP threads is set to 1. Also, even in the latter case, a lot of false positives are reported.

Well, we'd be glad to accept a test case, as stability of the product (don't crash, don't cause crashes) is our #1 priority here.

As for the false positives, that does not surprise me. That's our #2 priority...

Last I modified the instrumentation in regards to openmp was in support of the Analysis tools. One thing that can also help us to determine where the issues may lie is to run the instrumented application not under Error Detection and let us know if the problems still occur. If they do it is an instrumentation issue. If not fingers point more towards the Boundschecker side of things.


Also then a test case and where abouts the problems lie in the sample is greatly appreciated too.

Thanks

Some may wonder at the distinction between "Instrumentation" and "BoundsChecker". The one would appear to be part of the other. Here in the office, though, "Instrumentation" is a part of the overall product that applies equally to Error Detection (BoundsChecker), Coverage Analysis (TrueCoverage) and Performance Analysis (TrueTime). There is no shared code between BoundsChecker and Instrumentation, and they are run independently of each other. When BoundsChecker encounters a program that has been built with instrumentation, it finds itself with more opportunities to observe what the program being tested is doing, with new function calls generated by the instrumented code and intercepted and acted upon by BoundsChecker.

For the most part, Mark gets down in the weeds of Instrumentation, and I burrow around in the guts of BoundsChecker.

Thanks everybody for your replies.

I will investigate more whether running the instrumented code outside of BC is still an issue.
I was not able to produce a simple test case, so the issue may be more complicated than I thought. It can also well be that an idiot programming error of mine causes all the troubles, but BC does not see it correctly.

However, I can provide you will another test case that crashes (Internal Compiler Error) Visual studio during the instrumentation. If instrumentation is off, the code compiles correctly.
I'm using visual studio 2008 SP1 (9.0.30729.1 SP) on windows-7 x64 machine.

#include

void main()
{
try {/* do something */ }
catch(...) { }

#pragma omp parallel for
for(int x =0; x
}



Compiling...
DevpartnerTest.cpp
c:\data\rouet\src\ipus_source\action\devpartnertest\devpartnertest.cpp(5) : fatal error C1001: An internal error has occurred in the compiler.
(compiler file 'f:\dd\vctools\compiler\utc\src\p2\main.c[0x5E3672CD:0x00000014]', line 182)
To work around this problem, try simplifying or changing the program near the locations listed above.
Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more information
Instrumenting .\DevpartnerTest.cpp


Hope this helps.

Thanks,

I'll look at that in between my reboot cycles of testing on Win 8....

One last Q on that though. Which version of the product are you using? Help About in Visual Studio or Boundschecker (Error Detection) should show the full version & build number.

I'm using the following version:

Microsoft Visual Studio 2008
Version 9.0.30729.1 SP
Microsoft .NET Framework
Version 3.5 SP1
Installed Edition: Professional
Microsoft Visual C++ 2008 91605-270-4250197-60958

Micro Focus DevPartner Studio 10.6.292.0

jean-michel.rouet@philips.com originally wrote:

I will investigate more whether running the instrumented code outside of BC is still an issue.
I was not able to produce a simple test case, so the issue may be more complicated than I thought. It can also well be that an idiot programming error of mine causes all the troubles, but BC does not see it correctly.

on my first issue (not the internal compiler error during instrumentation), I did more testing.
I could not reproduce small testcase, but observed weird behaviors deep in my code, in calls like


const int chunkSize = __max(int(zSize/8),1);
printf("size: %d %d\n", omp_get_thread_num(), chunkSize);
#pragma omp parallel for schedule(dynamic,chunkSize)
for(int z = 0; z
{
printf("size: %d %d\n", omp_get_thread_num(), chunkSize);



where the chunSize variable is unexpectedly corrupted during a _numega_finalcheck() call.
The ouput of the above snippet is something like:


size: 0 1
User Error 1001: chunk-size in loop schedule must be positive
size: 0 -33686019


Note that the "User Error" comes from openmp, which sees a negative (corrupted) chunkSize value.
And when I run this code outside of BC, the output is normal.

I wish this report helps.
Regards
Jean-Michel.

Good news / bad news....

Using the following code in a new win32 console app with last nights build of 10.6 I was unable to replicate the instrumentation issue. Also on a Win 7 X64 ultimate machine. I will trya a few other thinsg to see if I can make it have an error.

#include

void main()
{
try {/* do something */ }
catch(...) { }

#pragma omp parallel for
for(int x =0; x
}

mlevis originally wrote:

Good news / bad news....

Using the following code in a new win32 console app with last nights build of 10.6 I was unable to replicate the instrumentation issue. Also on a Win 7 X64 ultimate machine. I will trya a few other thinsg to see if I can make it have an error.

Hi,
I would say it's a pretty good news! Is there a big difference between the last nights build of 10.6 and the official 10.6.292 build (the one I use)?
Can you at least reproduce the compilation bug on a 10.6.292? If not, I may have other issues on my build environment, exonarating Devpartner's tools at the same time!

Regards,
JM