Microsoft Visual Studio* Output Window radio button - What is for?

[Salvatore_Li_Mandri]

Hello,

I have an application that sends mesages (hints) about program execution to a console style window.
Application when run via VS2005 debug environment reports messages fine in this dedicated window.

As you would expect, Inspector XE when has the Radio button set in the Option\\Intel Inspector XE 2011 Properties set to Separate Console (last of the 3 - Default), Window does the same thing (fine).
For clarity the messages still appear fine when they go to the sameseparate window.

Switchradio button to "Collection Log Window" (Top Radio button of the 3)

All my threads are up an running by over 30 minutes
This application uses 15 threads:10 waiting for events of different kind to arrive before they begin any work
The others, are sleeping on timely fashion (5 to 100 nSec) interval. No big deal.
The summary comfirm the threads were created.
I confirmed their readiness via someevent logger messages.

The application isbasically idleing waiting for a command to arrive via a port before starts any work.
CPU usage is 11% top (utilized)

How is possible that the Inspector XE thread that writes to the Application Window has no chance to write a single message there after 30 minutes?

I calculated the number of messages that should have been appearing - 42 lines of text with the longest line65 characters long.

Tried a simpler single program, using a couple of threads (Main application thread + 1 Single thread)
Both threads send some messages, but a different rate.
For this programit takes about 10 minutes before I see the first group of messages which appear to update at ramdom rate. (Strange)

Nothing else is going on that I can tell.
CPU usage is 9% top (utilized)

Q1: What is going on with the Inspector XE ability of reporting messages to the application window?
Is there a way to have it more responsive at the cost of more time for the inspection?
I obviously will be running the test overnight...

One possibility could be to give the user abutton so hecan raise the priority of the thread that drives the show, or run the defaulty priority as shipped. (Wish)

Not knowing what else to do and understanding fully the logging capability of the tool, since I need to log messages operation for inspection after the run, I tried to use the Middle Radio button selection: marked "Microsoft Visual Studio* Output Window" radio button

StartInspector XE with thethesimple "Hello World" been displayed forever at 1 second interval.
I see no output in any Visual Studio Window Pane inside Microsoft.
I tought that after 10 minutes or so, something would be showing up, somewhere
No such luck.

Warning: If you try this mode of operation you will not be able to quit, without crashing the IDE (or so appears)
Probably, it is because since V7 update, it is required to confirm the desire of quitting the run via the keyboard input once "Hit any key to continue..." appears

Sincethere is no window in focus containing the message, my keyboard entry is lost.
If you click the Close button while the program still runs, instead of Stop followed by Close, you do more damage. The IDE appear to lock-up with all the Run arrows been disabled. My program is obviously still running).

So, I must be doing something wrong with the tool.

Q2: What is then this display message option for?
Where the "Hello World" messages went to?

--------------

I believe I answered this question on my own...

I reviewed thedocumentation about the XE inspector demonstration chapters and I came across the statement that basically says that when using the "Microsoft Visual Studio* output window" the user generated messages will appear there.

Wrong. They do not. (Does this mean that this feature is broken?)

Has anybody seen this operate?
I use the lastest update 7 insive VS2005

The MS Output Combo box lists only the following:

Intel Inspector XE 2011 Messages
Intel Parallel Debugger Extension

I might need to click on something that is not listed
---------------

Thanks to anyone that can tell me what is going on with my 2 questions (now 1).

Sal

[Peter_W_Intel]

Yes. I can repeat this issue after installing Update 7 and worked on Visual Studio 2005.

It seems that Output-Inspector XE 2011 message (enabled MS Visual Studio* output window) & Application Output(enabled Collection Log window) truncated some message (part 3 in this example)


The workaround is to use standalone application to avoid this. Application Output(enabled Collection Log window) works fine


We will investigate this problem, hope to fix it in future releases. Sorry.

Regards, Peter

[Salvatore_Li_Mandri]

Hi Peter,

Thanks for taking the time to reply to my question.

You made the statement "... and worked on Visual Studio 2005".
Were you then able to see any messages in the MS Visual Studio pane?
Looks like you got only a fraction of the first (I hardly can read the screen shot).

I have no messages at all in my PC with that selection.

Whatwas the setting of the combobox above the area where the messages whould have appeared VS2005 Output Pane? - Just to be use I know what setting I should have used...

I assume the correct choice should have been "Intel Inspector XE 2011: Messages"
I can really tell, because some of the screen image details were lost.
Can you please confirm? - Thanks

A final question, then.

If I redirect all the messages to the "Application Output" pane, "Collector Radio button" then, will the reporting ability of the tool improve if I run my Inspector XE run stand alone, outside the Visual Studio environment?

I am asking this, because I have a kernel crash that happens while this tool runs and nothing I have done has brought any light on that may be happening.

If I could see "all" the the program internally generated messages, I might have a chance to obtain a clue.

Thanks for your help
Sal

[Peter_W_Intel]

Hi Sal,

If you can't see screen shots in my previous post, please see attached docx.

I doubt that the problem was due to out-of-memory resource, since it never always happens - I can repeat this on my old machine, Xeon with Windows Server 2003. Visual Studio* consumes many resource...I guess.

You may enlarge your Vitual Memory for system then restart the system to have a retry.

Also you can use command line as a temp workaround, since you can open result file from standalone GUI.

Example:

C:\zwang1\iStep2011\Demos\memoryLeak\Debug>inspxe-cl -collect mi1 -- Banner.exe
Used suppression file(s): []
1. Banner Program has started execution.

2. Banner Program output from thread pool..

b d eee
aaa b ccc d e e
a a bbb c ddd eee
a a a b b c d d e
aaaaa bbb ccc ddd eee

3. Banner Program has completed execution. Please press enter.

1 new problem(s) found
1 Memory leak problem(s) detected

Regards, Peter
By the way, please report the crash from standalone application if you meet.

[Salvatore_Li_Mandri]

HI Peter,

Please take a look to:

"C/C++ TRACE messages - Can they be seen during an Inspector XE run ?"

thread.

Sergey, sugesteted a solution that appear to be appropriate to make appear program generated messages I have been saying are no longer visible with this radio button selection.

It would be interesting to know if its solution addresses the messages drop-out issue you were confirming existed when you ran that Intel testing program you used.

What I find somewhat confusing is that the change he sugested should have applied to TRACE messages not regular messages produced, say via a printf() function...

You might be able to add more to these 2 iopen threads, now related

----------
An update:

I discovered that the above hint works fine for small programs in VS2005, not for large programs or programs that output many messages.

It works great, if the application you are having trouble with and you want to monitor messages to help your-self in debugging while running in Inspector XE 2011 mode, is migrated to the VS2010 environment.

You must be using the Collector Radio selection, because as in VS2005 it does not work either.

Best regards
Sal

[SergeyKostrov]

Hi,

When a TRACE function doesn't display some text or truncates textit could be related to a ANSI-to-MBCS character conversions and Ihad a couple of similarproblems.

Does your project configured as UNICODE or ANSI?

In another words, does it use 'Use Unicode Character Set' or 'Use Multi-Byte Character Set'?

Best regards,
Sergey

[Salvatore_Li_Mandri]

Sergey,

Hello again.

Thanks again for the additional input.
No, my program uses neither. Plain character set, since the program is for a limited market.

Sorry, I had collected bad informations

What I discovered is however, accidentally, is that I have trouble also re-directing messages to the Output Window pane of code generated for the VS2010 studio.

Best regards,
Sal

[SergeyKostrov]

Hi Sal,

Could you create a very simple test case that reproduces the problem?

Just C orC++ source filecould beenough.

I have three MS Visual Studios ( 2005, 2008 and 2010 ) on my computerand I could verify your test application.

Best regards,
Sergey

[SergeyKostrov]

Your First question was as follows:

...
How is possible that the Inspector XE thread that writes to the Application Window has no chance to write a single message there after 30 minutes?
...

As I suspected in my first post there is a possibility that a call toTRACE inside of the Inspector XE threadcouldn't process your MBCS strings and that is why it didn't display what you've expected to see.

There is a possibility that some kind of memory corruption in your applicationhappened ( I can't it confirm it )andtheapplicationwas inunpredictable state.

Best regards,
Sergey

[SergeyKostrov]

>>...

>>9. By some reason, at the moment not explained, _tcscpy_s releases memory of the
>> input buffer szBuff!

>> Note: Is that by Microsoft's design? I don't know and MSDN doesn't say anything.
>>...

Hi Sal, I'm currently investigating what could be wrong and'm enclosing a couple of screenshoots:

[SergeyKostrov]

Hi Sal,

Here areresults of my quick investigation regarding a problem with '_tcscpy_s' CRT-function. Try that piece of codeand will seein the Debugger what is wrong.

...
TCHAR szSrcText[32] = _T("Hello, world"); // A length is 12 characters
TCHAR szDstText1[32] = { 0x0 };
TCHAR szDstText2[32] = { 0x0 };

int iSrcTextLen = _tcslen( szSrcText );

_tcscpy( szDstText1, szSrcText ); // Does it release szSrcText? No
_tcscpy_s( szDstText2, sizeof( TCHAR ) * 12, szSrcText );// Does it release szSrcText? No
//_tcscpy_s( szDstText2, iSrcTextLen, szSrcText ); // ASSERT - "Buffer is too small"
_tcscpy_s( szDstText2, sizeof( TCHAR ) * iSrcTextLen, szSrcText );// Does it release szSrcText? No
_tcscpy_s( szDstText2, sizeof( szDstText2 ), szSrcText );// Does it release szSrcText? No,
// itcorrupts szDstText1!
...

[Salvatore_Li_Mandri]

Hi Sergey,

I want to thank you personally for all the work you put into it.

I never wanted for the issue to escalate the way it did, though it pointed to an additional issue currrently under your investigation.

I was certain that the simply project you are using had the "Character Set" project option set to "Not Set", as my original application that contain the real issue I am trying to work out. I was wrong.

I guess I lost track of which project I was comparing and I end-up zipping up the project that appeared to run fine in the default VS 25005 IDE environment with the wrong character set (it would run fine either way)

With that said, while the general issues about messages and TRACE messages not appearing where intended remains, or the execution issues of one method selection versus another remain too, you have explained why the thread is not named "Sal" in the timeline

In the revised program you created you changed the name of the definition to describe the thread name.
If I use your name, and I scale back the project as I said, the name still appears.

This means that all those functions you changed are scaled back to use the basic functions as the program I initially sent you automatically by the Compiler.

If you look at the headers, they automatically replace the name of the function _tXXXXX to something else to match themost basic function callfor the "character set" not set.

Another example the macro _T is translated to null, etc...

Finally, all this means that as Peter Wang said there are still some issues to be investigated (using their benchmark programs) at Intel and the TRACE MFC message (It is still alive), are not supported by this INspector version. It is not clear if it was intentional or just by design and if will be corrected in future.

Again,
Thanks

Sal

[SergeyKostrov]

Hi Sal,

>>..."Character Set" project option set to "Not Set"...

You're right, I forgot to mention it.

To be honest, I even don't remember at least one my project where a "Character Set" was set to "Not Set". Usually it was for MBCS or UNICODE.

So, I'm glad to hear that it helped to find an another problem. Good Luckwith investigation!

Best regards,
Sergey

PS: A problem with _txxxxx_s functions was an Absolute Surprise for me :)