I have one big problem with using STL, C++ and Visual Studio. When i use some std or stl functions (in debug compilation) a have some errors some like this "Incorrect format specifier".
but my code are too large for "hand searching" for this error. Maybe one know how to get some help with finding error, some like __FILE__ & __LINE__ for assert? Because code of program too large.
Or try & catch my last hope?...
with respect Alex
Since you have the source code for the STL, what I would do is set a breakpoint at the point where the "Incorrect format specifier" string is located. Do a grep (eg find in files) for that string, set a breakpoint at each one, run your program and hope for death. :)
You talk about try/catch, so I assume it's throwing an exception. If you run your app within the debugger, doesn't it break your program at the point where the uncaught exception is thrown?
EDIT: If you could alternately compile on Linux/g++ it would leave behind a core with a backtrace in that case.
Maybe you could do status msgs on the console so that you get an idea where the error happens. You can search in this part more detailed with the same technique. Do this as often as you need.
After that you can debug you program and set breakpoints in the 'problem area' and step through it.
EDIT: If you are able to compile the program on linux, you can simply install and run valgrind memcheck. It should print out all errors with line number.
The attached screenshot makes it clear that you hit a runtime assertion, and even offers the option to go directly to the dbugger. This will take you to the faulty callstack.
This message is the default mode of _CrtDbgReport. With _CrtSetReportHook2, you can run your own code before the error is printed. You might create a minidump, for instance.
Related
I have a c++ program and I want to display the line number of where the program crashes in the console ! I'm using VS2010! is that even possible? I use opencv , and opencv does it !
any idea?
I had a same issue, there was a code and I wasn't able to debug it (it had to run without stopping). I put below code before every suspecting line:
cout << __LINE__ << endl;
After that, when it crashed, I could trap the problem.
But a standard way is using a debugger and put conditional breakpoints. (I'm not sure it helps you)
I'd suggest using a debugger with reasonable haltpoints and check if those haltpoints are reached. I prefer this one over console debug messages as it doesn't pollute your code.
Sometimes you cannot use a debugger, e.g. when you cannot reproduce the crash locally. In this case you need to put try/catch on top-level to catch and report all exceptions (on Windows make sure you also catch structured exceptions) and to subscribe to signals to catch and report SEGFAULTs etc.
Then you can log stack trace (not portable and requires debug symbols) or create a mini-dump (not portable).
I'm working on the development of a software in C++ on Visual Studio 2010. As this software should be run on servers where human interaction is not available, I really really need to get rid of this "program.exe has stopped working" window that pops up in the release version in case of errors. I just want the program to terminate (maybe also give an error message, but not necessarily) and not have it remain blocked waiting for someone to click the "Close the program" button. I have to mention that I have 64 bit Windows 7 Professional on my machine.
I have read about several things, such as:
the _set_abort_behavior function. This solves the case when abort() is called, but that is not the case for errors like "vector subscript out of range".
I know I could be solving some of these errors by doing exception handling, but not all errors are exceptions, therefore this would not solve my entire problem.
I've also read something about the Dr. Watson debugger, which is supposed to terminate the application silently, but I have the impression that this debugger is not available for Windows 7. Plus I don't know if this debugger would solve my problem in the release mode...
I don't find that disabling Error Reporting on my entire machine is an elegant option, although I read that this could also be an alternative (not really one that I want to take).
How can I do this in Visual Studio? Are there any settings I could use?
Is there maybe a way to turn all errors in exceptions in Visual Studio, so that I can solve the problem with the exception handling mechanism? (please be tolerant if this was a stupid question)
I'm looking forward to your proposals. Many thanks for your time!
Best regards,
Cornelia
You can use
SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX);
MSDN documentation for SetErrorMode
You can also refer here
Hope this will solve your problem...
A good way is to add your own unhandled exception filter (see SetUnhandledExceptionFilter() docs) and then write a log and a mini dump so that you can do whatever error handling you need to (eg close devices/handles) and you also have a crash dump that you can analyse later. Useful information in this answer: https://stackoverflow.com/a/1547251/188414
Sometimes this error occurs only because you have not added a & sign before the value you have used in scanf
Try the following which solved my problem
From
scanf("%d",code);
To
scanf("%d",&code);
I am working on this problem for two days and this is driving me mad as I am still quite new to C++. This violation access problem may be quite easy to you and may be answered thousands of times. But my lack of C++ knowledge make me even unable to identify the same problem ever answered.
OK here is my problem:
1. The major code is in a DLL. I am using Visual Studio 2008
2. This DLL called 3 external libraries: boost, tinyXML and SRILM (a NLP toolkit).
3. The error says: Unhandled exception at 0x5f4f068f (TextNormalizerAPI.dll) in tester.exe: 0xC0000005: Access violation reading location 0x00000000. , occurred only in Debug mode. And the error line was caused by an initialization of a boost::regex object (patUsername = regex("^\\W*#[A-Za-z]");) in my code, but the actual position was deeply inside the boost library, as shown in below figure:
**in most cases, I am not supposed to change the source code of Boost lib, isn't it? **
4. This error occurred only in Debug version, not in Release version.
5. I replace the whole solution with a old but fault-free version which worked properly in Debug mode. Yet immediately after I generating a Release version of this solution, error occurred in Debug mode!
UPDATE:
6. Thank you guys! I just tried something and found out that even a simple define a regex object in the first line of the entry of DLL will incurred this error! Any ideas?
7. yet initialize a regex object in the first line in the main() of the caller of this dll will not incur this problem.
Hope this description will help you recall something and give me some hint.
I want to ask:
what's the usual strategy to narrow down and spot the problem? thank you!
Looking at your code, you may want to verify that your m_position values are valid ... I'm seeing a escape_type_class_jump label in your code, so the goto or whatever mechanism you're using to jump to that label (I can't tell from the screen-shot) may be bypassing whatever checks are being done to verify that your position increments are still valid.
It looks to me like "this" (i.e., the basic_regex_parser) is NULL, and it's trying to call a method on a NULL object, which obviously doesn't work well. If "this" is indeed NULL (you can tell by looking in the "Locals" tab, then I would go up the call stack to the "basic_regex_implementation" level and see what's going on there -- where is this NULL value coming from? In general, looking at different levels of the call stack, and at the variables' values in those levels, will be helpful.
I have compiled a c++ code to MEX-file, but on calling this MEX-file, it crashes.
It gives the following error message in MATLAB:
Segmentation violation detected
I tried using try-catch in C++ file to print the message in the catch block
like,
try {
//my code;
}
catch(std::exception &e)
{
mexPrintf(e.what());
mexEvalString("drawnow;");
return;
}
but the print message does not work and the code still crashes.
On looking at Google, most of the time it points to some form of message given by MathWorks: http://www.mathworks.de/matlabcentral/newsreader/view_thread/25900
which instructs to set a environment variable "MATLAB_MEM_MGR=debug",
but it does not explain how to use it? Can anyone please explain it?
First off, try/catch will not catch a segmentation violation. It only catches C++ exceptions, not signals like sigsegv.
Second, to "use" MATLAB_MEM_MGR:
Set the environment variable MATLAB_MEM_MGR to "debug" in an OS shell (like a Command prompt on Windows or a terminal on Unix),
Run MATLAB from that same shell,
Run your MEX-function normally from that MATLAB.
As Q3.5 of the FAQ says, if the MEX-function corrupts memory by (for example) writing past the end of a MATLAB-allocated block of memory, MATLAB will report the corruption when the block of memory is freed.
You may instead want to try running your MEX-function under a debugger. This tech note has several links describing how to do so on various platforms.
EDIT: previous link is dead, here is the latest doc page.
Remove mexEvalString("drawnow;"). It took me 5 hours to figure out this.
I am debugging an Iphone program with the simulator in xCode and I have one last issue to resolve but I need help resolving it for the following reason: when it happens the program goes into debugging mode but no errors appear (no BAD ACCESS appears) and it does not show where the code fails. Putting some variables as global helps me to see their values to start pin pointing where the bug is but before I go into this fully I would like to know what techniques/tools you guys use to debug these situations.
If it helps Im debugging the following: I merged some code into the SpeakHere demo. The code was added in the C++ modules of the program (AQRecorder.h and .mm). I seem to have pinpointed the problem code in a function I wrote.
My favourite is always to add debugging code and log it to a file. This allows me so report any and all information I need to resolve the issue if the debugger is not working properly.
I normally control the debugging code by use of a flag which I can manipulate at run time or by the command line.
If the error is (and it probably is) a memory management issue, printing log entries is really not going to help.
I would reccomend learning how to use Instruments, and use its tools to track down the memory leak when it occurs rather than waiting until the application crashes later on.