Debugging my Console Application displays garbage (Windows 10, win32)

[PeterTheRascal]

Debugging my Console Application displays garbage (Windows 10, win32)

I call this a “question” but its may well be a “bug report”

It shows corrupted variables though some  but not all can WRITE correctly. 

• Fortran is calling  LAPLIBO, my C++ static library (which also calls Alglib C++).
• Issue occurs both calling LAPLIB, a  DLL equivalent
• I build via CMAKE

See Below, where I set buf=”” but it is showing as garbage

Failed attempts to fix include:

• Gutting debug/ release and rebuilding
• And again and again
• Loading the same VS and Fortran on another similar notebook

It would be convenient for now if did not have to

• Download the whole project
• Do a very tedious and not guaranteed downgrade  lf both VS and Fortran

I am hoping someone is both familiar with the issue and, perhaps, has  a fix

Dell M4800 and Windows 10

• Microsoft Visual Studio Community 2015
• Version 14.0.25424.00 Update 3
• Microsoft .NET Framework
• Version 4.6.01038
• Visual C++ 2015   00322-20000-00000-AA674
• Microsoft Visual C++ 2015
• Intel® Parallel Studio XE 2016 Update 1 Composer Edition for Fortran Windows*     Package ID: w_comp_lib_2016.1.146
• Intel® Parallel Studio XE 2016 Update 1 Composer Edition for Fortran Windows* Integration for Microsoft Visual Studio* 2015, Version 16.0.0058.14, Copyright © 2002-2015 Intel Corporation. All rights reserved.

Regards, Peter

[Arjen_Markus]

Judging from the screenshot I have a question and a remark:

• Did you specify two arguments when starting the debug session? You can do that from within Visual Studio
• Strings that are not set generally have rubbish as their content, they are not initialised to spaces

[PeterTheRascal]

Yes, I specified two args. Not only that the first the input file "filei"  enabled the correct files to be loaded.  But "fili" displayed garbage in the debugger. As I said, some strings displaying as garbage are garbage as they Parse into many more fields than Imexpect.

And you will have seen "buf="" being  displayed as garbage in the attached  image

[Arjen_Markus]

Okay, the problem may be in GETARG then. Is that a C++ routine? Could it be that it does not have the right interface or the calling program does not "know" the interface?

[PeterTheRascal]

Here are some images "proving" fine input "filo" is dipalyed as rubbish but "works" (not really proved!)

Peter

[Arjen_Markus]

The problem must be in GETARG then.

Could you try instead these lines to retrieve the arguments:

call get_command_argument( 1, filei )
call get_command_argument( 2, fileo )

or the other way around (I am not entirely sure in what order you specify them ;). That way you exclude the problem and you can see whether the values of character strings are shown correctly or not.

[PeterTheRascal]

Arjen

Thanks for your interest

get_command_argument is not different. The screen dump attached gived more evidience file in "fini" is loading OK

[Arjen_Markus]

This is really odd. But this is clearly a different issue than I thought. The program works fine, just the debugger is having trouble showing the right information - at least, that is my conclusion at this moment. I will have to leave this to people more knowledgeable on this subject.

[PeterTheRascal]

Did I say:

Thanks Arjen.

I look forward to "people more knowledgeable".  Morining Steve!

Note, as I said, some variables  actually are being corrupted.  I just have not managed to prove it.

[Simon_Geard]

You might get some more information by displaying the data in hex. Various bit patterns have specific meanings but you can only really see them in hex mode.

[PeterTheRascal]

I can only convert the non strings to text. Will that help?

[PeterTheRascal]

sorry, I forgot the screen dump.

[Steven_L_Intel1 · Accepted solution]

I'm going to take a guess and ask if you have optimization enabled for this configuration. If so, it would explain what you are seeing. I was working on another customer's project yesterday where there were similarly strange results in the debugger. Even though it was a Debug configuration, /O2 had been set. This will make viewing of locals in the debugger unreliable.

[PeterTheRascal]

Many thanks Steve, you were right.and I was a ?????

With some help I am converting to CMAKE as was spending more time sorting Visual Studio parameters issues than actual programming.

So I had better tweak  some CMakeLists.txt  files.  But I will still try to stick with CMAKE!

Peter

[PeterTheRascal]

I can overwite my duplicate  reply (as here), but how can I delate iit?

[Steven_L_Intel1]

Users can't delete posts. You can ask us to do so.