My application uses MS Access mdb files because of legacy reasons. It connects to the database using ADO with the following connection string:
Provider=Microsoft.Jet.OLEDB.4.0;Persist Security Info=False;Data Source=Dummy.mdb
Recently I started porting my application to 64 bit. Because of that Jet OLEDB provider is not available on 64 bit systems I used ACE OLEDB provider with the following connection string:
Provider=Microsoft.ACE.OLEDB.12.0;Persist Security Info=False;Data Source=Dummy.mdb
The application also uses MS XML DOM to work with XML files. Sometimes the 64 bit version crashes with access violation exception in SysFreeString which is called from one of the MS XML wrapper methods. The 32 bit version does not have these problems. I distilled the problem into the tester applicaiton.
#define _WIN32_WINNT 0x0501
#include <stdio.h>
#include <windows.h>
#include <process.h>
#include <conio.h>
#include <ObjBase.h>
#import <msxml6.dll>
#import <msado15.dll> rename("EOF", "EndOfFile")
using namespace ADODB;
bool s_bRepeat = true;
unsigned __stdcall XmlThreadFunc(void*)
{
CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);
MSXML2::IXMLDOMDocumentPtr l_pXMLDom;
l_pXMLDom.CreateInstance(__uuidof(DOMDocument), NULL, CLSCTX_INPROC_SERVER);
l_pXMLDom->async = VARIANT_FALSE;
MSXML2::IXMLDOMElementPtr l_pRoot = l_pXMLDom->createElement("root");
l_pXMLDom->appendChild(l_pRoot);
unsigned int l_nCnt = 0;
while (s_bRepeat)
{
if (0 == l_nCnt++ % 1000)
{
printf(".");
}
l_pRoot->setAttribute("test", "Test1");
Sleep(0);
}
CoUninitialize();
_endthreadex(0);
return 0;
}
unsigned __stdcall DbThreadFunc(void*)
{
CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);
_ConnectionPtr l_pConnection;
l_pConnection.CreateInstance(__uuidof(Connection));
#ifdef _WIN64
LPCSTR l_cszConnectStr = "Provider=Microsoft.ACE.OLEDB.12.0;Persist Security Info=False;Data Source=Dummy.mdb";
#else
LPCSTR l_cszConnectStr = "Provider=Microsoft.Jet.OLEDB.4.0;Persist Security Info=False;Data Source=Dummy.mdb";
#endif
while (s_bRepeat)
{
l_pConnection->Open(l_cszConnectStr, "", "", adConnectUnspecified);
Sleep(1000);
printf("(");
l_pConnection->Close();
printf(")");
}
CoUninitialize();
_endthreadex(0);
return 0;
}
int main()
{
HANDLE l_hXmlThread = reinterpret_cast<HANDLE>(_beginthreadex(NULL, 0, &XmlThreadFunc, NULL, 0, NULL));
HANDLE l_hDbThread = reinterpret_cast<HANDLE>(_beginthreadex(NULL, 0, &DbThreadFunc, NULL, 0, NULL));
_getch();
s_bRepeat = false;
HANDLE l_Handles[2] = { l_hXmlThread, l_hDbThread };
WaitForMultipleObjects(2, l_Handles, TRUE, INFINITE);
CloseHandle(l_hXmlThread);
CloseHandle(l_hDbThread);
return 0;
}
The crash call stack is the following:
OLEAUT32!SysFreeString
TestCrash64Lean!_bstr_t::Data_t::_Free
TestCrash64Lean!_bstr_t::Data_t::~Data_t
TestCrash64Lean!_bstr_t::Data_t::`scalar deleting destructor'
TestCrash64Lean!_bstr_t::Data_t::Release
TestCrash64Lean!_bstr_t::_Free
TestCrash64Lean!_bstr_t::~_bstr_t
TestCrash64Lean!MSXML2::IXMLDOMElement::setAttribute
TestCrash64Lean!XmlThreadFunc
MSVCR80D!_callthreadstartex
MSVCR80D!_threadstartex
kernel32!BaseThreadInitThunk
ntdll!RtlUserThreadStart
At the crash the DB thread is always in the following state:
MSVCR90!memset
mso!Ordinal4118
mso!Ordinal7994
mso!MsoUninitOffice
ACECORE
ACECORE
ACEOLEDB!DllGetClassObject
ACEOLEDB!DllGetClassObject
ACEOLEDB!DllGetClassObject
ACEOLEDB!DllGetClassObject
oledb32!CAcm::FinalRelease
oledb32!ATL::CComPolyObject<CDCM>::~CComPolyObject<CDCM>
oledb32!ATL::CComPolyObject<CDCM>::Release
oledb32!CDCMCreator::DestroyResource
comsvcs!CHolder::SafeDispenserDriver::DestroyResource
comsvcs!CHolder::ProcessDestroyList
comsvcs!CHolder::FreeResource
oledb32!CDCMCreator::ReleaseResource
oledb32!CDPO::ReturnDCMToPool
oledb32!CDPO::FinalRelease
oledb32!ATL::CComPolyObject<CDPO>::`scalar deleting destructor'
oledb32!ATL::CComPolyObject<CDPO>::Release
msado15!CConnection::_Close
msado15!CConnection::Close
TestCrash64Lean!ADODB::Connection15::Close
TestCrash64Lean!DbThreadFunc
MSVCR80D!_callthreadstartex
MSVCR80D!_threadstartex
kernel32!BaseThreadInitThunk
ntdll!RtlUserThreadStart
I found that as a workaround if I keep one open connection to some empty database file, I can open and close connections to actual database files and the application does not crash. Anyway I would rather understand the actual cause of the crash. I would appreciate any suggestions.
My configuration is the following:
Microsoft Visual Studio 2005 Version 8.0.50727.4039 (QFE.050727-4000)
Windows Server 2008 R2 Standard 64 bit
Processor: Intel(R) Xeon(R) E5645 # 2.40GHz
Memory: 16.0 GB
It looks like this is a problem of ACE OLEDB provider from Microsoft Access Database Engine 2010 Redistributable. Switching to the provider from Microsoft Access 2013 Runtime resolved the problem.
Related
I am very new to Oracle and trying to write a hello world program to connect to the Oracle ODBC through C++ code so that I can get the connection opened and then execute my store procedure. I am using Visual Studio 2017 editor on Windows 10. This is what I am trying to achieve
#include <Windows.h>
#include <sql.h>
#include <sqlext.h>
#include <sqltypes.h>
int main() {
SQLHANDLE g_sqlEnvHandle;
SQLHANDLE g_sqlConnHandle;
SQLRETURN rc;
/* Allocate the Environment Handle */
rc = SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &g_sqlEnvHandle);
/* Set the ODBC version environment attribute */
rc = SQLSetEnvAttr(g_sqlEnvHandle, SQL_ATTR_ODBC_VERSION, (SQLPOINTER)SQL_OV_ODBC3, 0);
/* Allocate connection handle */
rc = SQLAllocHandle(SQL_HANDLE_DBC, g_sqlEnvHandle, &g_sqlConnHandle);
/* Connect to ODBC driver */
char sConnString_in[2000] = "DRIVER={Oracle in OraDB19Home1};SERVER=localhost;UID=system;PWD=abc;DATABASE=mydataBase";
rc = SQLDriverConnect(g_sqlConnHandle, NULL, (SQLCHAR*)sConnString_in, (SQLSMALLINT)lstrlen((char *)sConnString_in), sConnOut, 200, &cbConnStrOut, SQL_DRIVER_NOPROMPT);
}
On debugging the code, I am always getting -1 from SQLDriverConnect. Any help would be appreciated.
Thank.
Is it possible to side-step _NSGetExecutablePath on Ubuntu Linux in place of a non-Apple specific approach?
I am trying to compile the following code on Ubuntu: https://github.com/Bohdan-Khomtchouk/HeatmapGenerator/blob/master/HeatmapGenerator2_Macintosh_OSX.cxx
As per this prior question that I asked: fatal error: mach-o/dyld.h: No such file or directory, I decided to comment out line 52 and am wondering if there is a general cross-platform (non-Apple specific) way that I can rewrite the code block of line 567 (the _NSGetExecutablePath block) in a manner that is non-Apple specific.
Alen Stojanov's answer to Programmatically retrieving the absolute path of an OS X command-line app and also How do you determine the full path of the currently running executable in go? gave me some ideas on where to start but I want to make certain that I am on the right track here before I go about doing this.
Is there a way to modify _NSGetExecutablePath to be compatible with Ubuntu Linux?
Currently, I am experiencing the following compiler error:
HeatmapGenerator_Macintosh_OSX.cxx:568:13: error: use of undeclared identifier
'_NSGetExecutablePath'
if (_NSGetExecutablePath(path, &size) == 0)
Basic idea how to do it in a way that should be portable across POSIX systems:
#define _XOPEN_SOURCE 500
#include <stdio.h>
#include <limits.h>
#include <stdlib.h>
static char *path;
const char *appPath(void)
{
return path;
}
static void cleanup()
{
free(path);
}
int main(int argc, char **argv)
{
path = realpath(argv[0], 0);
if (!path)
{
perror("realpath");
return 1;
}
atexit(&cleanup);
printf("App path: %s\n", appPath());
return 0;
}
You can define an own module for it, just pass it argv[0] and export the appPath() function from a header.
edit: replaced exported variable by accessor method
We are migrating our project from Qt 4.8 to 5.4. We use multiple contexts in multiple thread. We use GLEW MX for this purpose (We make the context we desire current then call glewInit() on a local instance of GLEWContextStruct).
I'm trying to change QGLWidget and QGLContext to QOpenGLWidget and QOpenGLContext but I ended up not being able to initialize glew anymore.
GLEW doesn't return an error but glGetError() does.
I did install Qt 5.4 64 with OpenGL version.
Here is the code reduced to a minimum :
#include <QtWidgets/QApplication>
#define GLEW_MX
#define GLEW_STATIC
#include <GL/glew.h>
#include <qopenglcontext.h>
#include <qwindow.h>
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
bool errQt;
int errGlew;
GLenum errorGL;
QSurfaceFormat requestedFormat;
requestedFormat.setVersion(3, 3);
requestedFormat.setProfile(QSurfaceFormat::OpenGLContextProfile::CoreProfile);
//Creates the QGLWidget using the current context:
QWindow window;
window.setSurfaceType(QSurface::OpenGLSurface);
window.setFormat(requestedFormat);
window.create();
//Create context
QOpenGLContext context;
context.setFormat(requestedFormat);
errQt = context.create(); //true
//Bind context
context.makeCurrent(&window);
//Glew context creation
GLEWContext* pCtx = new GLEWContext; //All forwards undefined
//Release context
context.doneCurrent();
return 1;
}
Any suggestion ? Is GLEW alright with Qt5.4 ?
EDIT 1 :
It appears the problem is not Qt related. The GLEWContext created doesn't have any function forward defined (all function pointers are undefined). The code has been updated to help the reviewer not lose focus.
I use glewInit() with Qt 5.4 in my project, but I'm using QWindow as my base class, not QOpenGLWidget.
In my ctor I do this:
QRiftWindow::QRiftWindow() {
setSurfaceType(QSurface::OpenGLSurface);
QSurfaceFormat format;
format.setDepthBufferSize(16);
format.setStencilBufferSize(8);
format.setVersion(4, 3);
format.setProfile(QSurfaceFormat::OpenGLContextProfile::CoreProfile);
setFormat(format);
m_context = new QOpenGLContext;
m_context->setFormat(format);
m_context->create();
...
I execute my OpenGL work on a separate thread. Once the thread has started I call an setup method on my class
m_context->makeCurrent(this);
glewExperimental = true;
glewInit();
glGetError();
I've previously done this exact same setup with OpenGL 3.3 and had no issues.
You should actually get a warning about that:
#warning qopenglfunctions.h is not compatible with GLEW, GLEW defines will be undefined
#warning To use GLEW with Qt, do not include or after glew.h
Your "qopenglcontext.h" includes . To answer your question, you can use Qt + GLEW, but u can't easily mix up Qt-opengl with GLEW.
I hooked native api ZwCreateFile, and wdk doc says windows use ZwCreateFile to create or open a directory. I can detect the operation of opening testdir, but i failed to stop the open directory operation.
My code of my own FakeZwCreateFile like this：
NTSTATUS FakeZwOpenFile(
OUT PHANDLE FileHandle,
IN ACCESS_MASK DesiredAccess,
IN POBJECT_ATTRIBUTES ObjectAttributes,
OUT PIO_STATUS_BLOCK IoStatusBlock,
IN ULONG ShareAccess,
IN ULONG OpenOptions
)
{
NTSTATUS rtStatus = STATUS_SUCCESS;
UNICODE_STRING test = RTL_CONSTANT_STRING(L"\\??\\c:\\testdir");
if (!RtlCompareUnicodeString(ObjectAttributes->ObjectName, &test, TRUE))
{
DbgPrint("%wZ\n", &test);
FileHandle = NULL;
IoStatusBlock->Status = rtStatus = STATUS_ACCESS_DENIED;
goto exit;
}
Orig:
OrigZwOpenFile = (NTOPENFILE)oldServiceAddr[SYSTEM_INDEX(ZwOpenFile)];
rtStatus = OrigZwOpenFile(
FileHandle,
DesiredAccess,
ObjectAttributes,
IoStatusBlock,
ShareAccess,
OpenOptions
);
exit:
return rtStatus;
}
Why i failed to stop opening the c:\testdir directory?? And what shoud i do to intercept the operations of creating new folders????
In this case is better to use File System Filter Drivers instead of SSDT hooking, Because FS Filter Drivers work correctly in 64Bit version of windows but SSDT only can use in 32Bit (If you can bypass windows Patch Guard then you can use SSDT hook in 32Bit) !
My library was working fine in Visual Studio 2010 but now whenever I run it compiled in 2012, I get these memory errors:
First-chance exception at 0x76884B32 in Example.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0101F3A0.
First-chance exception at 0x76884B32 in Example.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0101F3A0.
Unhandled exception at at 0x76884B32 in Example.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0101F3A0.
First-chance exception at 0x76FF3541 (ntdll.dll) in Example.exe: 0xC0000005: Access violation reading location 0xFEFEFF02.
According to the call stack, the errors are coming up everytime return wstring(cMD5.hexdigest()); is called from the following code:
wstring GetMachineHash() {
BYTE szHash[48];
LPBYTE pIdentifierHash;
ZeroMemory(szHash, 48);
MachineNameIdentifier cNameId;
pIdentifierHash = cNameId.GetIdentifierHash();
memcpy(szHash, pIdentifierHash, 16);
NetworkAdapterIdentifier cNetAdaptId;
pIdentifierHash = cNetAdaptId.GetIdentifierHash();
memcpy(szHash+16, pIdentifierHash, 16);
VolumeInfoIdentifier cVolInfo;
pIdentifierHash = cVolInfo.GetIdentifierHash();
memcpy(szHash+32, pIdentifierHash, 16);
MD5 cMD5(szHash, 48);
return wstring(cMD5.hexdigest());
}
If your wondering what MD5 class I'm using, its the one port by Frank Thilo but its modified to return LPBYTE instead of std::string like so:
// return 16 byte md5 hash
LPBYTE MD5::hash() const {
if (!finalized)
return 0;
return (LPBYTE)digest;
}
// return hex representation of digest as string
LPTSTR MD5::hexdigest() const
{
if (!finalized)
return NULL;
LPTSTR szBuf = new TCHAR[33];
ZeroMemory(szBuf, 33);
for (int i=0; i<16; i++)
_stprintf_s(szBuf+i*2, 33, _T("%02X"), digest[i]);
szBuf[32]=0;
return szBuf;
}
After doing some research here on SO, it says these errors are because of a possible memory leak somewhere else in my program. But I have looked and everything seems to be freed correctly. Any ideas? I was wondering if this also might have something to do with calling a DLL library from an EXE through LoadLibrary() and GetProcAddress()?
(I should also note that the Platform Toolset is set to Visual Studio 2012 - Windows XP (v110_xp))