I have a 64 bits C++ server application running on windows 7 and when it does a select on the database and calls next() on the result set the process simply dies, no exceptions, no dumps and no debug info after ResultSet->next(). Writes on the database works with no problems and both reads and writes works on the 32 bit version
I'm using the 11.2 version of the win64 oracle libraries that came with instant client and SDK
EDIT: it's the simplest of codes
const std::string sql("select * from schedule_import");
std::auto_ptr<IRecordSet> query = m_conn->Open(sql);
while(query->Next()) // dies
{
const std::string key(query->GetField("bean_key"));
//...
IRecordSet is just an interface for common functions of DB drivers like next, getField and it's implemented in here
bool OracleRecordSet::Next()
{
return m_pResultSet->next() != NULL; //crashes here
}
where m_pResultSet is a oracle::occi::ResultSet*
I'm not familiared with Oracle API, but question is if m_pResultSet is not NULL (in case of segmentation fault) and if there is no exception (in case of abort(), raise() stack).
BR!
After a lot of trys my problem is solved.
I was linking my debug program to oraocci11.lib because I didn't have the debug version and I thought it didn't matter much. After a bit of search I've found the debug version of the library, oraocci11d.lib, with the corresponding dll and the crash is gone
Related
I'm trying to debug a segmentation fault using mdb in solaris (as this is the only available option for me). The following is the core dump
`threading model: multi-threaded
status: process terminated by SIGSEGV (Segmentation Fault)
C++ symbol demangling enabled
librax.so void RajHistory_Backend::addMessage+0x58()
librax.sovoid RajErrorSink::output+0xe0()
librax.so void RajErrorSink_bg::DoWrite+9()
librax.so int RajErrorSink_Backend::run+0x128()
libmtcpp.so void*startThread+0x1e()
libc.so.1 _thr_setup+0x5b()
libc.so.1 _lwp_start()`
Code snippet
//
std::deque<char*> _queue;
//
void RajHistory_Backend::addMessage(char *msg)
{
_mutex.lock();
_queue.push_front(msg);
while ( _queue.size()-1 > _size )
{
char *b = _queue.back();
_queue.pop_back();
delete [] b;
}
_mutex.unlock();
}
I'm actually struggling to find the crash reason as I'm new to mdb . I did some debugging using this link
When I tried to print the variables in this method
> history_size/d
libenv.so`history_size:
libenv.so`history_size: 20
>msg/C
libc.so.1`msg:
libc.so.1`msg: H
>msg/s
libc.so.1`msg:
libc.so.1`msg: HGHcöHc°HÐÃUHåLeàLmèIüLuðH]ØAõL}øHì0
öIÖ|u5M
ötA>`
Does this mean the received message, char* msg is invalid?
How do I get the exact line in addMessage() method which caused the problem? Any hints on this how I can debug in mdb?
When mdb prints msg as libc.so.1`msg it’s indicating it found a value in libc, not in your code. Similarly, it’s showing libenv.so`history_size so found a similarly named entry in libenv. mdb won’t know the names of arguments to your functions.
You’ll have a much easier time if you build your binaries with debugging info (-g flag to the compiler) and use the source level debugger for your compiler (gdb if you're using gcc, dbx if you're using the Sun Studio or Solaris Studio compilers).
I have written a 'filemon' utility which basically logs file being opened during a period of time. Now I have exact these two functions in my 'filemon' utility:
set<wstring> wstrSet;
// callback - get notified by callback filter driver on any file open operation
void CbFltOpenFileN(
CallbackFilter* Sender,
LPWSTR FileName,
ACCESS_MASK DesiredAccess,
WORD FileAttributes,
WORD ShareMode,
DWORD CreateOptions,
WORD CreateDisposition )
{
// don't log for directories
if (FileAttributes & FILE_ATTRIBUTE_DIRECTORY) {
return;
}
wstring wstr = FileName;
wstr.append(L"\n");
//wstrSet.insert(wstr); // as soon as I un-comment this line I start getting BSOD in multiple execution of this utility
}
// Read all paths stored in the set and write them into the log file
void WritePathsToLog() {
typedef set<wstring>::const_iterator CI;
printf("\nNo. of files touched ===> %d\n\n", wstrSet.size());
for (CI iter = wstrSet.begin(); iter != wstrSet.end(); iter++) {
fputws((*iter).c_str(), logFile);
}
}
Basically what this code does is that 'filemon' utility interacts with callback filter driver and whenever file is touched by any process the driver reports the respective filename to the 'filemon' utility via CbFltOpenFileN function.
Now the issue is that this 'filemon' utility runs fine on win7 x64 machine 4GB machine but as soon as I uncomment the last line in the CbFltOpenFileN function i.e. start inserting the reported filename in the set then I start getting BSOD mostly with BugCheck 0xCC and sometimes with BugCheck 0x50 which basically indicates that "system is trying to access already freed memory"
P.S. on win7 x64 with 8GB RAM I am not seeing any issue at all irrespective of whether last line in the CbFltOpenFileN function is commented or not.
Currently, 'wstrSet' is using default allocator so do I need to use a specific allocator while declaring set wstrSet; if yes can someone tell me how & why?
Let me share some more information here:
I am using VS2010
My utility is a 32 bit application targeted for x86 platform
The fileystem filter driver I am using is callabck filter driver provided by Eldos corp.
Now I am tetsing this utility using a simulator which generates lots of files and then starts the 'filemon' utility, then it touches all those files and at the end stops the 'filemon' utility. This simulator repeates this process 25 times.
Now for case where last line is commented I get empty log file created 25 times as I don't insert anything in set but 'filemon' utility also doesn't causes any BSOD
But for case where last line is NOT commented I get log file created each time with path enteries as now I am inserting paths in the set but then during first few iteration, say 2nd or 3rd or 6th, itself 'filemon' utility hits this BSOD scenario.
It's hard for me to repro this issue in debug mode as my simulator take cares of the start/stop of 'filemon' utility and i need to run it multiple time to repro the issue.
Hope this added info helps!!!
Thanks and Regards,
Sachin
If you CbFltOpenFileN is a callback function, does this means it has asynchron calls? in that case, you might want to protect the global variable (wstrSet) with a mutex...
I want to program a daemon-manager that takes care that all daemons are running, like so (simplified pseudocode):
void watchMe(filename)
{
while (true)
{
system(filename); //freezes as long as filename runs
//oh, filename must be crashed. Nevermind, will be restarted
}
}
int main()
{
_beginThread(watchMe, "foo.exe");
_beginThread(watchMe, "bar.exe");
}
This part is already working - but now I am facing the problem that when an observed application - say foo.exe - crashes, the corresponding system-call freezes until I confirm this beautiful message box:
This makes the daemon useless.
What I think might be a solution is to make the main() of the observed programs (which I control) "uncrashable" so they are shutting down gracefully without showing this ugly message box.
Like so:
try
{
char *p = NULL;
*p = 123; //nice null pointer exception
}
catch (...)
{
cout << "Caught Exception. Terminating gracefully" << endl;
return 0;
}
But this doesn't work as it still produces this error message:
("Untreated exception ... Write access violation ...")
I've tried SetUnhandledExceptionFilter and all other stuff, but without effect.
Any help would be highly appreciated.
Greets
This seems more like a SEH exception than a C++ exception, and needs to be handled differently, try the following code:
__try
{
char *p = NULL;
*p = 123; //nice null pointer exception
}
__except(GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION ?
EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH)
{
cout << "Caught Exception. Terminating gracefully" << endl;
return 0;
}
But thats a remedy and not a cure, you might have better luck running the processes within a sandbox.
You can change the /EHsc to /EHa flag in your compiler command line (Properties/ C/C++ / Code Generation/ Enable C++ exceptions).
See this for a similar question on SO.
You can run the watched process a-synchronously, and use kernel objects to communicate with it. For instance, you can:
Create a named event.
Start the target process.
Wait on the created event
In the target process, when the crash is encountered, open the named event, and set it.
This way, your monitor will continue to run as soon as the crash is encountered in the watched process, even if the watched process has not ended yet.
BTW, you might be able to control the appearance of the first error message using drwtsn32 (or whatever is used in Win7), and I'm not sure, but the second error message might only appear in debug builds. Building in release mode might make it easier for you, though the most important thing, IMHO, is solving the cause of the crashes in the first place - which will be easier in debug builds.
I did this a long time ago (in the 90s, on NT4). I don't expect the principles to have changed.
The basic approach is once you have started the process to inject a DLL that duplicates the functionality of UnhandledExceptionFilter() from KERNEL32.DLL. Rummaging around my old code, I see that I patched GetProcAddress, LoadLibraryA, LoadLibraryW, LoadLibraryExA, LoadLibraryExW and UnhandledExceptionFilter.
The hooking of the LoadLibrary* functions dealt with making sure the patching was present for all modules. The revised GetProcAddress had provide addresses of the patched versions of the functions rather than the KERNEL32.DLL versions.
And, of course, the UnhandledExceptionFilter() replacement does what you want. For example, start a just in time debugger to take a process dump (core dumps are implemented in user mode on NT and successors) and then kill the process.
My implementation had the patched functions implemented with __declspec(naked), and dealt with all the registered by hand because the compiler can destroy the contents of some registers that callers from assembly might not expect to be destroyed.
Of course there was a bunch more detail, but that is the essential outline.
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 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;