I have a program that makes heavy use of QSharedPointer. When I execute my program it runs fine, but when I debug it with GDB it starts throwing errors. "Invalid Address specified to RtlFreeHeap" is thrown in the following code:
QSharedPointer<PersistentList> p =
PersistentList::createEx(wrap("abc")).dynamicCast<PersistentList>();
QSharedPointer<IPersistentCollection> c = p->empty(); // Error thrown after this line
QSharedPointer<IPersistentCollection> ASeq::empty()
{
return QSharedPointer<EmptyList>(new EmptyList());
}
If I disable the p->empty() line the program runs just fine. Any ideas?
The problem is likely elsewhere in your code. Run it under Valgrind and see if you're touching any memory that's not yours, or using uninitialized data, etc.
Related
I have CLion installed with presumably default configuration. I think something is wrong with it, because I can't see exceptions. For example, this code:
int main(){ throw 5; }
Prints only Process finished with exit code 0
Why doesn't it print the exception?
Why does it print 0 instead of 1?
For comparison:
int main(){try { throw 5; } catch(int x) { std::cout << x << '\n'; }}
This prints 5, so it looks like code is correctly run and the exception is correctly thrown. It's just hidden by CLion somehow.
Edit: This is not a duplicate of "not seeing any console output". I made extremely clear in my question that I was indeed seeing console output for prints. My issue concerns exceptions specifically, not console output generally.
In your first piece of code you have not caught the exception, so it is handled by the default handler. You therefore have no control over the return code from the executable. Operation is as expected.
If you would like CLion to display the exception you can configure it to do so. Note that this will only apply when CLion is debugging your executable, outside of CLion your executable will continue to behave as you have already seen.
Go to run then view breakpoints.
Go to exception breakpoints and when any is thrown.
To display the stack trace when the exception is thrown check stack trace
If you would like your program to stop for your intervention, check enabled and when thrown.
Make sure to use Run/Debug and not Run/Run to launch your program.
In my C++ project, I encounter a very strange issue. It crashes with exit code 11 when I remove a certain log statement (cout).
This answer points to a source that explains exit code 11 (actually EAGAIN) with the following statement:
The system lacked the necessary resources to create another thread, or
the system-imposed limit on the total number of threads in a process
PTHREAD_THREADS_MAX would be exceeded.
But I am pretty sure don't create any additional threads in my code (at least not explicitly). So why does the error occur and why does it go away when I use the log statement?
For reference, I will post the code but it's of course completely out of context and basically the only relevant line is the one with the log statement.
PayloadRegionMapper(string mappingTechniqueName, string configPath = "")
: payload(PAYLOAD), config(Config(configPath)) {
cout << "construct PayloadRegionMapper" << endl; // if commented out, my program crashes....
frames = generateFrames();
setMappingTechnique(mappingTechniqueName);
}
Run the program using a debugger and then backtrace once the crash happens.
Using the bt and frame command you can get an idea about the behaviour of the program during the crashing situation.
gdb <executable>
.....<crash happened>
bt
<It will give you the stack frame >
frame <frame number>
Then look for the values and memory area there.
I have a Visual C++ 9 Win32 application that uses a third-party library. When a function from that library is called with a certain set of parameters the program crashes with "exception code 0xC000000D".
I tried to attach Visual Studio debugger - no exceptions are thrown (neither C++ nor structured like access violations) and terminate() is not called either. Still the program just ends silently.
How does it happen that the program just ends abnormally but without stopping in the debugger? How can I localize the problem?
That's STATUS_INVALID_PARAMETER, use WinDbg to track down who threw it (i.e. attach WinDbg, sxe eh then g.
Other answers and comments to the question helped a lot. Here's what I did.
I notices that if I run the program under Visual Studio debugger it just ends silently, but if I run it without debugger it crashes with a message box (usual Windows message box saying that I lost my unsaved data and everyone is sooo sorry).
So I started the program wihtout debugger, let it crash and then - while the message box was still there - attached the debugger and hit "Break". Here's the call stack:
ntdll.dll!_KiFastSystemCallRet#0()
ntdll.dll!_ZwWaitForMultipleObjects#20() + 0xc bytes
kernel32.dll!_WaitForMultipleObjectsEx#20() - 0x48 bytes
kernel32.dll!_WaitForMultipleObjects#16() + 0x18 bytes
faultrep.dll!StartDWException() + 0x5df bytes
faultrep.dll!ReportFault() + 0x533 bytes
kernel32.dll!_UnhandledExceptionFilter#4() + 0x55c bytes
//SomeThirdPartyLibraryFunctionAddress
//SomeThirdPartyLibraryFunctionAddress
//SomeThirdPartyLibraryFunctionAddress
//SomeThirdPartyLibraryFunctionAddress
//OurCodeInvokingThirdPartyLibraryCode
so obviously that's some problem inside the trird-party library. According to MSDN, UnhandledExceptionFilter() is called in fatal situations and clearly the call is done because of some problem in the library code. So we'll try to work the problem out with the library vendor first.
If you don't have source and debugging information for your 3rd party library, you will not be able to step into it with the debugger. As I see it, your choices are;
Put together a simple test case illustrating the crash and send it onto the library developer
Wrap that library function in your own code that checks for illegal parameters and throw an exception / return an error code when they are passed by your own application
Rewrite the parts of the library that do not work or use an alternative
Very difficult to fix code that is provided as object only
Edit You might also be able to exit more gracefully using __try __finally around your main message loop, something like
int CMyApp::Run()
{
__try
{
int i = CWinApp::Run();
m_Exitok = MAGIC_EXIT_NO;
return i;
}
__finally
{
if (m_Exitok != MAGIC_EXIT_NO)
FaultHandler();
}
}
I am now trying to use this Application Verifier debugging tool, but i am stuck, first of all: it breaks the program at a line that is simple variable set line (s = 1; for example)
Secondly, now when i run this program under debugger, my program seems to have changed its behaviour: i am drawing image, and now one of the colors has changed o_O, all those parts of the image that i dont draw on, has changed the color to #CDCDCD when it should be #000000, and i already set the default color to zero, still it becomes to #CDCDCD.
How do i make any sense to this?
Here is the output AV gave me:
VERIFIER STOP 00000002: pid 0x8C0: Access violation exception.
14873000 : Invalid address causing the exception
004E422C : Code address executing the invalid access
0012EB08 : Exception record
0012EB24 : Context record
AVRF: Noncontinuable verifier stop 00000002 encountered. Terminating process ...
The program '[2240] test.exe: Native' has exited with code -1073741823 (0xc0000001).
Typically when breakpoints are hit like this (via AV or an unhandled exception, etc.) inside a debugger, there is a green arrow pointing to a line of code. That arrow is pointing to the next statement to execute when the thread returns from the current function. Perhaps this green arrow is pointing to the line where you wrote "s = 1", but really the offending code is the line above it. Now I can't see your code so I can't exactly know for sure and I don't have enough rep to post a comment - but this is something that is easy to check the next time the breakpoint is hit.
I am willing to bet that s is NOT a "simple" variable. I'm much more likely to believe it's something like this:
class Foo;
int s;
void Bar() {
s = 1;
}
};
Sure, it looks like a simple s=1 statement, but in reality it is a this->s=1 statement. And if this is an invalid pointer, this->s isn't a proper variable either.
I am working on a migration project, here we are migrating large set of C++ libraries from Mainframe to Solaris. We have complted migration sucessfully, but while running the application, some places it crashes with 'signal SEGV (no mapping at the fault address)'.
Since the application supports on windows also, we checked with purify on windows. There are no memory leaks in the application and it works fine on windows.
Can any one suggests, what could be the other reasons which may create this type of errors. Any tools for tracing this type of errors?
It's not necessarily a memory leak. It could be that a piece of memory is referenced after it is free'ed.
My friend once came to me with a piece of code that runs fine on Windows but gives segv on Linux. It turned out that sometimes the memory is still valid after you free'ed it on Windows (probably for a short period of time) but immediately triggered segv on Linux.
The line below looks wrong to me
m_BindMap[sLabel] = b; // crashes at this line at when map size
I assume you are trying to add a number to the end of the string. Try this instead
stringstream ss;
ss << ":BIND" << ns;
string sLabel = ss.str();
Are you using g++? If so, recompile with the "-g" flag. Run the program in gdb. When it crashes type "bt" (for backtrace) and that should tell you where your problem is.
I am using CC compiler on solaris and dbx debugger. I know the call stack where it is crashing. But it is abromal crash.
map<string,CDBBindParam,less<string> >m_BindMap;
CNumString ns(CNumStringTraits(0,2,'0'));
ns = m_BindMap.size();
string sLabel = ":BIND"+ns;
CDBBindParam b(sLabel,val);
**m_BindMap[sLabel] = b;** // crashes at this line at when map size is more than 2
return sLabel;