I'm trying to convert a .exe to .dll proj. that use many other libs & a global macro defined to exit when fatal errors occurred.
do you have an idea to instead of exit, return error number?
thanks a lot.
Probably the easiest solution is to throw an exception. However, expect memory leaks. The existing code won't release memory in those fatal cases. Hence, you probably should exit anyway, but at least catching the exception would allow you to save work in progress.
Related
I am writing a c++/CUDA code with Visual Studio 2015 to generate a mex file to integrate with MATLAB.
When I run the mex file through the MATLAB console and then try to compile it again on VS I get this error:
LINK : fatal error LNK1168: cannot open filename.mexw64 for writing
Closing the MATLAB and opening the programme again solves the problem.
Does anyone know any solution which not involves closing the MATLAB?
MEX-files are DLLs (on Windows, shared objects on other systems). When first run, MATLAB links to them, but doesn't unlink unless explicitly told to (or quitting MATLAB of course).
Typing
clear mex
in MATLAB will unlink all MEX-files. See the relevant documentation.
But note that your MEX-file can call mxLock, which will cause it to be locked in memory and then it will not be cleared by clear mex. If you use this function in your MEX-file, you need to include a facility to have your MEX-file call mxUnlock. I usually add a syntax such as mymexfile --unlock: the MEX-file checks to see if it is called with one argument, and that argument is a string, and the string matches "--unlock", then it calls mxUnlock.
I am writing a new UT in my code (C++, VS10).
Apparently there is an error somewhere in the test. I see the following error in the compilation console
unknown location(0): fatal error in "Test1": breakpoint encountered
I want to debug the test to see what is wrong, but I can't, since this test failure cases the compilation to fail, and prevents me from running the code inside VS debugger.
I guess I can copy my code to the main() function, but this is problematic since the test requires many includes that are absent from that part.
Is there any other option?
Use DebugBreak inside Test1. It will crash and then you can attach the application to debugger. However, if debug information is not generated, you have to debug through assembly code.
Simple usage of DebugBreak
DebugBreak(); //Include Windows.h for it.
I used to work with the Release version of VS2010 and suddenly, when switching to the Debug version, I get a breakpoint error message and it's redirected to the file dbgrptt which exists at C:\Program Files\Microsoft Visual Studio 10.0\VC\crt\src\dbgrptt.c
The displayed error message is:
ex.exe has triggered a breakpoint
This is where is redirects after showing the error message.
_CRTIMP void _cdecl _CrtDbgBreak(
void
)
{
__debugbreak();
}
How can I get rid of it?
The debug version of the CRT detected that something went wrong. The debug version sacrifices runtime speed in order to do more expensive checking so that it can detect such situations. They are typically caused by a bug in your code. In other words, you an error that happened not to manifest in the release build - so far.
How do you get rid of it? Fix the error. Run your program under the debugger, and when you reach the error, check the call stack. Go up the call stack until you find out what happened. Chances are, you are doing something like using a dangling reference/pointer, or an invalidated iterator, or you access something out of bounds.
From Microsoft Docs:
Assertion statements compile only if _DEBUG is defined. Otherwise, the
compiler treats assertions as null statements. Therefore, assertion
statements impose no overhead or performance cost in your final
Release program, and allow you to avoid using #ifdef directives.
I am attempting to compile a qt project using the following sequence of commands
> qmake -project
> qmake
> make
In the make process I keep getting the following error popping up.
{standard input}: Assembler messages:
{standard input}:21385: Fatal error: can't close Transfer.o: Input/output error make: *** [Transfer.o] Error 1
The same error is coming up for multiple classes, Originally I thought it was qt related because it first appeared in when the compiler tried to make a moc file. But now it seems to be popping up in other classes in my project.
I don't really know where to look for problems because I don't understand the error, Could anybody point me in the right direction? I'm happy to post code as needed.
I think this is related to some part of the code that assembler is not able to decode it.
eMbedded Visual C++ 3 project, that is building for PocketPC 2000. On the ARM build, the linker throws the following error:
fatal error LNK1223: invalid or corrupt file: file contains invalid pdata contributions
On SH3, the project compiles, links, and works. The project also works when built for ARM on Visual C++ 2005, but I need to test builds specifically from eVC3.
Any ideas, please? What's a pdata contribution and how do I affect (or disable) those? It's something to do with exception handling; I've tried disabling SEH by specifying /EHsc, to no effect.
Very weird. I tried commenting out everything in the file. The error went away when I commented out a function that was extern "C" void __declspec(naked) with no body (body #ifdef'fed away). I have similar functions in the project, but they did not throw any errors like this. Maybe a compiler bug...
No idea from me, but the Google-mind dredged up this thread which might give you a clue how to fix/workaround the problem... maybe:
http://www.pocketpcjunkies.com/Uwe/Forum.aspx/wince-pb/7477/Link-error-during-DEBUG-build
After looking at the error more closely, I finally figured out that this is
a side-effect of my hijacking of SC_SetDaylightTime() in the kernel with my
own version. Apparently, something that I'm doing in my code there is
causing the compiler to generate pdata entries that are wrong in some way.
A strategically-placed #ifndef worked around it.