ifstream object declared inside a function not working on release mode - c++

I am working on my first app that i´m actually going to give to someone else to use it, so i am trying to do the hole deploy process (on Qt), and create an installer after.
The problem is that a have a specific point in my code (i already discovered where), that it runs fine on Debug mode, but on Release i have no ideia what happens (it symply not run the specific function).
The problem is (just a simple example about the) that, if a declare an ifstream object in the main function, the release .exe runs just fine. When i put that object on a function, it doesnt work! I dont know what to do.
#include <iostream>
#include <reader.h>
#include <string>
#include <map>
#include <mrp.h>
#include <file_manager.h>
#include <string>
#include <facade_mrp.h>
#include <fstream>
#include <vector>
using namespace std;
void test()
{
fstream f;
f.open("C:\\Users\\user\\Documents\\Alexandre\\C++\\MRP\\build-MRP-Desktop_Qt_5_0_2_MinGW_32bit-Release\\Demandas.txt",ifstream::in);
f.close();
}
int main(int argc, char* argv[])
{
test();
return 0;
}

Please clarify what you mean by: "does not work". Does the program crash? Or just does it not read the contents of the file?
To troubleshoot a problem with std::ifstream, it's usually convenient to have a look at .good(), .fail() and .eof() member functions. Find out more about them in the docs.
If the problem presents in Release configuration, but not in Debug, there are usually few common culprits you should look into:
Release builds usually have -O2 or -O3 optimization levels enabled, while Debug builds don't.
Release builds are usually stored in a different file system path than Debug builds (check relative paths).
Hope this helps!

Related

Can't find entry point (_ZSt28__throw_bad_array_new_lengthv) in DLL (filepath)

The error
The exact error is the title of the question.
It happens when I use vectorName.push_back() function.
I recreated it with just this simple code:
#include <iostream>
#include <vector>
using namespace std;
int main() {
vector <int> vec = {};
vec.push_back(2);
return 0;
}
Compiler and setup information
Im using msys2, and
I set it up using this guide
I have no idea if this is relevant or not, but I used tdm-gcc before this.
Research
A fix is almost nowhere to be found, or i just didn't look hard enough. I have found some posts about the _ZSt28__throw_bad_array_new_lengthv, but not with entry point. And because I didn't find anything about this exact issue, I didn't try anything.

I'm just starting c++, and I'm having a lot of trouble with VSCode [duplicate]

This question already has answers here:
How do I set up Visual Studio Code to compile C++ code?
(14 answers)
How does one set up the Visual Studio Code compiler/debugger to GCC?
(7 answers)
Closed 1 year ago.
So, I created a new project, here is my code:
#include <iostream>
using namespace std;
int main()
{
return 0;
}
For whatever reason, #include has an error, and the lightbulb won't give me any solutions. I have the code runner and c++ extensions installed.
I'm getting errors left and right for no reason including:
A red line under #include
Running the code doesn't work and says "'g++' is not recognized as an internal or external command,operable program or batch file.
" which doesn't even exist.
And so much more.
It depends on how you start off learning C++. At the very least your starter sandbox code should look like this:
#include <iostream>
int main()
{
return 0;
}
and you should have no problems.
When it comes to introducing input/output operators, the use of using namespace std; is a polarizing one.
Method 1:
#include <iostream>
using namespace std;
int main()
{
return 0;
}
Some people don't want you using it at all because ... what if you decide to create something called "namespace" yourself? In fact, this school of thought is very fearful of global things for reasons that escape me. Then you would have to take it out and rely on the traditional method ...
Method 2: eschewing namespace and using std::. You would have to use std::cout for printing text output to the prompt and std::cin for prompting input from the user.
Also, it looks like you are encountering multiple problems, so try attacking them one at a time. I haven't worked with g++ in a long time, so it sounds like you should first do some research on how to compile and run code with g++.

Defining a vector breaks program - MinGW

I have been coding for quite a few years now, but have only just recently started getting into C++.
I have already made quite a few programs in it, but have recently started running into some odd behaviour. The cases are simple enough that I expect this to be an error with my environment, and not the language itself, but I have run into a dead end.
Consider this simple program:
#include <iostream>
using namespace std;
int main() {
cout << "Test" << endl;
return 0;
}
If I compile that and run it, I get, as expected, "Test", in my console.
Now, if I add a vector to it:
#include <iostream>
#include <vector>
using namespace std;
int main() {
cout << "Test" << endl;
vector<double> whatever;
return 0;
}
For some reason, I do not get any output from that.
I have tried initalizing the vector as an empty vector aswell as with predefined values.
I tried adding a for loop running from 0 to 2^32 to see if the program failed entirely, or if it is just the output. This is where things got even weirder.
At first, I placed the loop before defining the vector; that caused the cout to suddenly work again (i.e. "Test" was printed in the console), aswell as stalling the program as expected. I then moved the for loop to after the vector definition, and then it broke entirely; I received no output, and the program exited almost instantly without error.
The issues persist when I remove the using namespace std; and prefix my cout and vector with std::
I use the g++ v6.3 compiler from MinGW. I am running Windows 10.
I am aware that this problem is probably extremely hard to reproduce, but I'll try my luck here before throwing my computer out the window.
Thanks in advance.
Edit: I fixed the issue by using Cygwin instead of MinGW. I will leave the question open in case someone has encountered a similar issue and has a fix that doesn't involve abandoning MinGW
I am running Linux and ran the code, and it ran successfully.
So this must be a compiler issue.
Maybe try using a different compiler like Cygwin / Microsoft Windows SDK.

Segmentation error with caffe

I am using caffe on Windows, and am getting segmentation errors which I cannot pinpoint. It happens when the program exits, and WinDbg said scalar deleting destructor, no idea where the memory was allocated. My complete code (currently a dummy code trying to narrow it down, but it happens only sometimes):
#include <string>
#include <vector>
#include "boost/algorithm/string.hpp"
#include "google/protobuf/text_format.h"
#include <stdio.h>
#include <opencv2/core/core.hpp>
#include <opencv2/highgui/highgui.hpp>
#include <opencv2/imgproc/imgproc.hpp>
#include "caffe/blob.hpp"
#include "caffe/common.hpp"
#include "caffe/net.hpp"
#include "caffe/proto/caffe.pb.h"
#include "caffe/util/db.hpp"
#include "caffe/util/format.hpp"
#include "caffe/util/io.hpp"
using caffe::Blob;
using caffe::Caffe;
using caffe::Datum;
using caffe::Net;
using std::string;
namespace db = caffe::db;
int main(int argc, char** argv) {
// Initialize logging with program call. First thing that needs to be done
::google::InitGoogleLogging(argv[0]);
cv::Mat mean_;
// Set Caffe to run in CPU only mode
Caffe::set_mode(caffe::Caffe::CPU);
std::vector<std::string> labels_;
/*std::shared_ptr<Net<float>> caffe_test_net;*/
Net<float>* caffe_test_net;
caffe_test_net = new Net<float>("D:\\Development\\caffe-windows\\models\\bvlc_reference_caffenet\\deploy.prototxt", caffe::Phase::TEST);
caffe_test_net->CopyTrainedLayersFrom("D:\\Development\\caffe-windows\\models\\bvlc_reference_caffenet\\bvlc_reference_caffenet.caffemodel");
delete caffe_test_net;
return 1;
}
I have tested with caffe_net in a unique or shared_ptr, but that made no difference at all. I am at a loss on how to find the issue at hand.
"Happens sometimes" is a pretty common thing with undefined behavior, which is what you're really encountering. A segmentation fault is one of a theoretically infinite number of things that the computer might do - the behavior is literally undefined. In other words, as they say on USENET: "It is legal for the compiler to make demons fly out of your nose." It may work, it might do something strange, or it might throw some major error like a segfault.
There are tools dedicated specifically to tracking down segmentation faults and other memory errors. On Linux, that's generally Valgrind, while on Windows, you'd use Dr. Memory. So long as you compiled with the debugging symbols included (-g), when you run the executable through Dr. Memory, it should give you a stack trace for the segmentation fault.
As soon as you get the stack trace, check the top of it to see which destructor the code is whining about, or in the very least, what line of code in main.cpp is calling the function(s) responsible for the undefined behavior.
Also, depending on your compiler, you may be encountering a known bug in VC.
You can find more general information about segmentation faults, common causes, and how to debug them on this answer.

Program crashing on exit

Whenever I exit my program it gives me this exception "0xC0000022: A process has requested access to an object, but has not been granted those access rights."
It breaks right at the end of a function called _lock_file in _file.c.
After trying to narrow down what the cause of the problem is I found out that it does not crash if I remove all fclose() function calls in my program then cleaning and rebuilding my program. Even if the function itself is never called it will still crash. Obviously this solution is not ideal.
When I tried to use fstream instead it produced a similar crash at the start of the program.
It's also worth mentioning that my program uses SDL.
Edit: Someone requested a minimal example and this is what I cam up with.
main.cpp
#include <stdlib.h>
#include <SDL.h>
/*...*/
#pragma comment(lib, "SDL.lib")
#pragma comment(lib, "SDLmain.lib")
/*...*/
int main( int argc, char **argv)
{
if(false)
fclose(NULL);
return 0;
}
draw.cpp
/*...*/
If I run this it will crash on exit just like I mentioned above. And yes the draw.cpp is completely commented out, but if I remove it from the project the program will run fine. All other files were removed from the project.
Edit2: In response to karlphillip I decided to double check if it is actually running and it seems that it is actually crashing at the start with this example.
Also it is a Win32 project.
Having a crash on exit usually means that the heap is corrupted during program execution. Try using a memory checker to find where. Try using _CrtDumpMemoryLeaks()
Are you using the same runtime library (Debug DLL, Debug, Release DLL, Release, etc.) for your main program as was used to build the SDL library? That can often (but not always) cause odd problems, and would be my first port of call when getting this sort of odd behaviour at runtime.
(If you get an LNK4098 warning when building, this is what it is trying to tell you, and you really need to fix it properly; the "solution" the text of the warning suggests is anything but.)
Another option is memory corruption. Consider running a debug build, and calling the following on startup:
_CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG)|_CRTDBG_CHECK_ALWAYS_DF);
This activates more thorough heap checking. (You might have to go and make a cup of tea when your program runs with this switched on, if it allocates lots of stuff while it's running.) If then "crashes" in one of the memory allocation functions -- it's actually an assert, you can't always tell though -- then at some point between that call, and the previous call to a memory management function, something has overwritten some memory it should not have. And you can take it from there, to find out what.
-Edit: "_CRTDBG_REPORT_FLAG_DF", was probably intended to be "_CRTDBG_REPORT_FLAG".
Crashing on exit can also be caused by static variables destructing and accessing objects that have already been cleaned up.
Check you static objects and ensure their destructors are not causing the crash.
How do you know your application is being executed in the first place? Add a debug right after main() is called:
#include <stdlib.h>
#include <SDL.h>
/*...*/
#pragma comment(lib, "SDL.lib")
#pragma comment(lib, "SDLmain.lib")
/*...*/
int main( int argc, char **argv)
{
printf("dbg1\n");
if(false)
fclose(NULL);
printf("dbg2\n");
return 0;
}
What kind of project are you creating? Console, Win32 or something else?
I find this post very interesting.