Unexpected change of value of data transfer variable Topic is solved

If you are using the main C++ distribution of wxWidgets, Feel free to ask any question related to wxWidgets development here. This means questions regarding to C++ and wxWidgets, not compile problems.
User avatar
eranon
Can't get richer than this
Can't get richer than this
Posts: 867
Joined: Sun May 13, 2012 11:42 pm
Location: France
Contact:

Re: Unexpected change of value of data transfer variable

Post by eranon »

raananb wrote:Edit: on a second thought, doing this will produce a different object, and the result may not apply anymore. As I already mentioned, the Debug version did not have this problem.
Don't know specifically about Visual Studio, but like I told you in a previous post (posting.php?mode=quote&f=1&p=179563#pr179546), chance you can mix the generation of debug info and any optimization option. The debug info being generated in a separated file this will not change your generated binaries which will be without any debug info inside (debug info being beside in another file).

Using Clang on Mac (again, I can't say nothing about Visual Studio, the last one I used was Visual Studio 6.0:), the process is this one (observed through Xcode -- the official Mac way --, even if I use another IDE) :
1) Using the option "-g" for the compiler, it generates the debug infos in the object files
2) Objects are linked to produce the executable
3) I ask explicitely to extract the debug infos to a .dSym file
4) I strip out the debug info into the executable.

So the behavior of my final executable sould be the same as the one w/o generation of debug info. It is exactely the same as the one it would be without generation of debug infos and even after debug info have been removed in the final binaries, the dSym file is still able to tell what address matches what function/location in code. Since I provide the matching binary image and dSym file (same UUID), a debugger or tool to symbolicate a crash report understanding the format of the dSym (eg. DWARF) file will be able to do its job.

So, I don't know about MSVC, but I'm surprised you say it doesn't behave the same.
[Ind. dev. - wxWidgets 3.0/3.1 under "Win 7 64-bit, TDM64-GCC" + "OS X 10.9, LLVM Clang"]
raananb
Super wx Problem Solver
Super wx Problem Solver
Posts: 488
Joined: Fri Oct 27, 2006 4:35 pm
Location: Paris, France
Contact:

Re: Unexpected change of value of data transfer variable

Post by raananb »

I reproduced the issue on a different Windows 10 computer, so it is not a hardware problem.

I then generated the application on OSX (with DialogBlocks, using an identical code except for a few unimportant places), and the application behaves properly, as programmed.

My conclusion is that the code generated in the Release version is at fault. Since I am working with Visual Studion Express 2013, it makes no sense to raise the issue with MS. I will try to install Visual Studio Community 2017 on my computer and get it to work, which is not as straitforward as it may seem. Getting all the bits and pieces to work together is a game of trial and terror.

Thanks for trying ot help.
User avatar
eranon
Can't get richer than this
Can't get richer than this
Posts: 867
Joined: Sun May 13, 2012 11:42 pm
Location: France
Contact:

Re: Unexpected change of value of data transfer variable

Post by eranon »

Well, so you dropped the idea of debugging step by step into the depths of the wx code and the "==" operator of wxString as suggested by doublemax?

However, it could effectively be a compiler issue too. If you produce a small sample code that reproduces the issue on your side, I could try to compile it in my dev station (mine is Windows 7 64-bit + MinGW64 (aka. GCC) ; I have VS 2008 Express too, but just for building the wx samples, not fluent with its specific settings) and see if the comparison fails here too.
[Ind. dev. - wxWidgets 3.0/3.1 under "Win 7 64-bit, TDM64-GCC" + "OS X 10.9, LLVM Clang"]
ONEEYEMAN
Part Of The Furniture
Part Of The Furniture
Posts: 7459
Joined: Sat Apr 16, 2005 7:22 am
Location: USA, Ukraine

Re: Unexpected change of value of data transfer variable

Post by ONEEYEMAN »

Hi,
Installing the next MSVC version should be a straightforward deal.
Then open the appropriate wxWidgets/build/wx_msw<n>.sln file and compile.
Then open you project, change the library path to point to the newly compiled libraries and recompile.

It may very well be either version (2013) or the edition (community).

Do you have an access to the Professional Edition of 2013?

Thank you.
PB
Part Of The Furniture
Part Of The Furniture
Posts: 4193
Joined: Sun Jan 03, 2010 5:45 pm

Re: Unexpected change of value of data transfer variable

Post by PB »

While compiler bugs do exist, it is still much more likely that the issue is in the user code. But if you believe that compiler optimizations are to blame, did you try to turn them off (/Od) or change them (e.g. /O1 vs /O2) in the project settings (C++/Optmization) to see if it changes anything?
raananb
Super wx Problem Solver
Super wx Problem Solver
Posts: 488
Joined: Fri Oct 27, 2006 4:35 pm
Location: Paris, France
Contact:

Re: Unexpected change of value of data transfer variable

Post by raananb »

With no optimization (/Od) the execution is as programmed.

With optimization (/O1, /O2 and /Ox) the problem shows up: the test in the following sequence is executed as if newConsultaiton value is "Yes" event though the message boxes display "No" twice in a row.

Code: Select all

  wxMessageBox(newConsultation);
  wxMessageBox(newConsultation);

  if (newConsultation == "Yes")
Thanks for helping pinpoint the optimizer as the culprit.

I guess the issue can be closed.
PB
Part Of The Furniture
Part Of The Furniture
Posts: 4193
Joined: Sun Jan 03, 2010 5:45 pm

Re: Unexpected change of value of data transfer variable

Post by PB »

You could try to reshuffle the code a bit. E.g., in the code you posted before, you pasted the string as "wxString", you could try changing it to "const wxString &". You can also try turning the optimization off only for that source file but I would rather try a new compiler, if possible...

I believe it is still possible that there is an issue in your code somewhere, that manifests only when the code is compiled in a certain way...
raananb
Super wx Problem Solver
Super wx Problem Solver
Posts: 488
Joined: Fri Oct 27, 2006 4:35 pm
Location: Paris, France
Contact:

Re: Unexpected change of value of data transfer variable

Post by raananb »

A change of code was made a while ago, removing the problem as it appeared. The discussion continued with the original code, to try and pinpoint where and what was behind.

The code as such is pretty straightforward, which was one of the reasons of the strangeness of the problem.

Another compiler was tried on OSX, and the problem was not reproduced. I am now investigating the installation of Visual Studio Community 2017 on my Windows 10 Computer.
raananb
Super wx Problem Solver
Super wx Problem Solver
Posts: 488
Joined: Fri Oct 27, 2006 4:35 pm
Location: Paris, France
Contact:

Re: Unexpected change of value of data transfer variable

Post by raananb »

I tested with Visual Studio Community 2015 (which insatlls as Microsoft Visual Studio 14.0) - same problem.

I then tested with Visual Studio Community 2017 (which installes as Microsoft Visual Studio/2017) the problem is not present anymore.

My guess os that VS2017 has a new Compiler/optimizer, while VS2015 is using the same components as VS2013.
User avatar
eranon
Can't get richer than this
Can't get richer than this
Posts: 867
Joined: Sun May 13, 2012 11:42 pm
Location: France
Contact:

Re: Unexpected change of value of data transfer variable

Post by eranon »

raananb wrote:My guess os that VS2017 has a new Compiler/optimizer, while VS2015 is using the same components as VS2013.
Right! Sounds like MSVC's code optimizer changed in 2016 ;)
https://blogs.msdn.microsoft.com/vcblog ... optimizer/
[Ind. dev. - wxWidgets 3.0/3.1 under "Win 7 64-bit, TDM64-GCC" + "OS X 10.9, LLVM Clang"]
Post Reply