I am facing some strange behaviour appearing only on some notebook.
I am developing in c++ using msvc 2012 and the qt framework.
I will try to sum up the problem and i am hoping that someone has any idea what the problem could be or what i could try to find out..
Generally it's the following problem:
void myclass::foo()
{
const double value1 = 100.0;
double value2;
value2 = some_function_returning_double();
if(value1 > value2)
{
//__ do something
}
}
The problem is that the condition fails as the local variable gets overwritten.
If I do some debug output i can see that variable value1 is not 100.0 anymore but some random value .. so that the comparison randomly fails ..
One thing i figured out is that everything just works fine if i don't use local variables. If i set up value1 and value2 as member variables of my class everything works without problems, but that can't be the solution.
Now the strange thing is that this error does only occur on some notebook (some mobile i5 cpu).
On my machine (i5) and on many other notebooks (even other mobile i5) everything just works fine.
I know that you won't be able to solve my problem with this little information i can offer here, but maybe some of you has any hint what the problem could be and what i could try to solve this.
Many thanks in advance.
In visual studio 2012, add a data breakpoint (debug->new breakpoint->new data breakpoint) on the address of the variable that gets overwritten.
First, break at the start of the function.
Then set the data breakpoint: just type &value1 in the "New breakpoint` the input box.
Then it should break just after the value has been modified, and you should see the culprit.
Data breakpoints are a very powerful tool, that helped me found nasty bugs very quickly.
Related
See below for the following code, and below that, the error that follows.
std::string source = "C:\\Users\\cambarchian\\Documents\\tested";
std::string destination = "C:\\Users\\cambarchian\\Documents\\tester";
std::filesystem::path sourcepath = source;
std::filesystem::path destpath = destination;
std::filesystem::copy_options::update_existing;
std::filesystem::copy(sourcepath, destpath);
terminate called after throwing an instance of 'std::filesystem::__cxx11::filesystem_error'
what(): filesystem error: cannot copy: File exists [C:\Users\cambarchian\Documents\tested] [C:\Users\cambarchian\Documents\tester]
Tried to use filesystem::copy, along with trying different paths. No luck with anything. Not too much I can write here as the problem is listed above, could be a simple formatting issue. That being said, it worked on my home computer using visual studio 2022, however using VS Code with gcc 11.2 gives me this issue.
Using:
filesystem::copy_file(oldPath, newPath, filesystem::copy_options::overwrite_existing);
The overloads of std::filesystem::copy are documented. You're using the first overload, but want the second:
void copy(from, to) which is equivalent to [overload 2, below] using copy_options::none
void copy(from, to, options)
Writing the statement std::filesystem::copy_options::update_existing; before calling copy doesn't achieve anything at all, whereas passing the option to the correct overload like
std::filesystem::copy(sourcepath, destpath,
std::filesystem::copy_options::update_existing);
should do what you want.
... it worked on my home computer using visual studio 2022 ...
you don't say whether the destination file existed in that case, which is the first thing you should check.
I put the copy_options within the copy function but it didn't work so I started moving it around, I probably should have mentioned that.
Randomly permuting your code isn't a good way of generating clean examples for others to help with.
In the rare event that hacking away at something does fix it, I strongly recommend pausing to figure out why. When you've hacked away at something and it still doesn't work, by all means leave comments to remind yourself what you tried, but the code itself should still be in a good state.
Still doesn't work when I write std::filesystem::copy(sourcepath, destpath, std::filesystem::copy_options::recursive)
Well, that's a different option, isn't it? Were you randomly permuting which copy_options you selected as well?
Trying recursive and update_existing yields the same issue.
The documentation says
The behavior is undefined if there is more than one option in any of the copy_options option group present in options (even in the copy_file group).
so you shouldn't be setting both anyway. There's no benefit to recursively copying a single file, but there may be a benefit to updating or overwriting one. If the destination already exists. Which, according to your error, it does.
Since you do have an error explicitly saying "File exists", you should certainly look at the "options controlling copy_file() when the file already exists" section of the table here.
Visual Studio 2022 fixed the problem
Hi I have a big problem: We created a program in C++/Qt 4.8.4 /Qt Creator 2.8.1 years ago that while executing runs another executable (written and compiled in FORTRAN). Everything worked well.
We recompiled our Fortran-Code with the new version of Visual studio and now suddenly it doesn`t work any more. I looked into my C++-Code and found the position where the program crashes:
std::string Executable = ApplicationName.toStdString();
bool RunOK= system((Executable+" > "+"X.out2").c_str());
QString ExeName = (Executable+" > "+"X.out2").c_str();
QString tf = QString::number(qweee);
if(system((Executable+" > "+"X.out2").c_str()))
{
msg.showMessage("msg.showMessage("An XXX error occured during calculation......((Executable+ > +X.out2).c_str(): "+ExeName +"......(system((Executable+ > +X.out2).c_str()): "+ QString::number(RunOK));
if(QFile(OutputFiles[0]).exists())
QFile(OutputFiles[0]).remove();
}
Somehow system((Executable+" > "+"X.out2").c_str()) gets to be true which didn`t happen before.
This seems to happen either in the c_str-command or in the system()-command.
We had some missing dll-issues before. Is this another dll-problem and if so which?
Can anybody help us on this?
Thank you
The return value of system is an integer, not a boolean. Its value is only defined for one very special case, system(nullptr). That's not the case here. So whether you get a zero or non-zero result depends on your particular C++ implementation, which has indeed changed. ("New visual studio version"). You can't rely on non-zero means error
c_str() is not a suspect at all.
I have a C++ program which works well when I compile with no additional options. However, whenever I use cmake -DCMAKE_BUILD_TYPE=Release there is a very specific part of the code which stops working.
Concretely, I have an interface for a Boost Fibonacci Heap. I am calling this function:
narrow_band_.push(myObject);
And this function does the following:
inline void myHeap::push (myStruct & c) {
handles_[c.getIndex()] = heap_.push(c);
}
where heap_ is:
boost::heap::fibonacci_heap<myStruct, boost::heap::compare<compare_func>> heap_;
For some reason the heap_size is not being modified, therefore the rest of the code does not work because the next step is to extract the minimum from the heap and it is always empty.
In Debug mode it works ok. Thank you for your help.
EDIT - Additional info
I have also found this problem: I have a set of code which do simple math operations. In Release mode the results are incorrect. If I just do cout of a couple of variables to check their values, the result changes, which is still incorrect but quite strange.
I solved the problem. It was funny but in this case it was not initialization/timing issues common in the Release mode. It was that the return statement was missing in a couple of functions. In debug mode the output was perfect but in the release mode that failed. I had warnings deactivated, that is why I did not see it before.
I run the following with Code::Blocks
#include <iostream>
using namespace std;
int main()
{
cout << "Hello, world !!!!!!!";
return 0;
}
Now, there were some questions last night about how I knew my return value. I don't know if it's my version or not, but after the program runs on my version it says "Process returned v (0xv) execution time..." and etc where "v" is the returned value.
Now, here is what I'm asking, and this is as clear as I can make it.
When I run this, it returns value 1993075819 instead of 0. Also, the program doesn't run, all it does is show me the returned value.
Two things worthy of note:
AVG pops up everytime I try and do this, and reports it as a trojan
If I run the code without
cout << "Hello, world!!!!";
It returns 0 like it should and AVG does not pop up
How can I fix this?
(Code::Blocks 12.11)
The problem is not with your code, but with a false positive produced by AVG. The return code 1993075819 is because AVG intercepts the program and does not let it run.
You can report the false positive to AVG. Virus vendors are actually very good at fixing false positives reported by users. When I used to work at a company that produced lots of false positives (security related code that did funky things that triggered false positives), the turn-around was usually about a week.
In the mean time, if you use different compiler switches (e.g. optimized compile if it is not currently optimized or vice versa) there's a decent chance that the code you generate will not trigger the false positive.
You can also add your compiled program to the AVG safe list:
http://www.ehow.com/how_8192066_add-exceptions-avg.html
Disable AVG or configure it not to complain about your executable. For some reason the heuristics are misinterpreting some bit pattern in your executable as if it was a trojan and killing it before it starts. The result code that you get is from the intercepted program call (i.e. the antivirus) not from your program that is not even running.
I am attempting to use the gdb/mi debugger in the Eclipse CDT version 6.02. While I am debugging I can step through the program with ease up until I reach the following snippet of a block of code.
ENUM_START_TYPE My_Class::some_function( const char * c, const char * e)
{
ENUM_START_TYPE result = GENERIC_ENUM_VALUE;
if ( c[0] == '<' )
{
result = do_something()
}
...
MORE CODE
...
return result;
}
When the debugger reaches this line.
if ( c[0] == '<' )
It starts exploring sections of code that it can not find until it opens a tab containing the /projectname/.metadata and simply declares:
"Resource '/project_name/.metadata' does not exist.
At which point the debugger terminates the program with no reason as to why.
All I wish to do is step over this line of code because it really is as trivial as comparing characters.
My question is: Why is this happening? Is it something to do with the debugger, or does it have something to do with my code, or what. Additionally, what is the .metadata and why can't the file be located and opened when it clearly exists (I can locate and open the .metafile without a problem).
Other info that may be pertinent: The files are located on a clearcase snapshot view, but are not checked into source control. I don't think that would cause an error like this, but clear case has caused so many random errors for me that I thought it would be worth mentioning.
Thanks in advance
As I am not aware of any side-effect a snapshot view might have in the process.
A dynamic view could consider part of the directories as "non-selected" (and then non-readable).
You have also the issue of symlink to dynamic view set on drive.
But a snapshot view is nothing more than a working tree on the hard drive.
To rule out any "ClearCase interference", you could try and debug your project entirely copied outside of any view of any sort (based on the content of your current snapshot view), and see if the problem persists.