MySQL C++ Connector: SIGABRT Connecting to Database - c++

I am having a hard time getting past this bug. Recently, changed from VM of Ubuntu 14.04 to making Ubuntu 15.10 my host OS. Now I am having a myriad of issues with this project; this one being the most recent. I am getting a SIGABRT signal when executing the code that calls this function DB_Interface::DB_Interface(int Preset). When this function is called from an executable, the error arises in the second try{}catch{} block. So I don't think it something specific to SetSchema.
I have tried reinstalling all the mysql libraries and tools(HERE). I have checked accessing the server from the command prompt with the same credentials with no problem. So I am leaning to incompatibility of the C++ connector with something... The million dollar question. So my question is how to resolve this issue. More info below:
System Info:
Ubuntu 15.10
MySQL: Ver 14.14 Distrib 5.6.27
Code Excerpt:
DB_Interface::DB_Interface(int Preset) {
try{
driver = sql::mysql::get_mysql_driver_instance();
flags[0] = 0;
}
catch(...)
{
flags[0] = 1;
printf("DB_Interface: Flag 0 has been set.");
throw Except;
}
try{
con = driver->connect("localhost:3306", "CANS_OPERATION", "SMOOTH_OPERATOR");
flags[1] = 0;
}
catch(...)
{
flags[1] = 1;
printf("DB_Interface: Flag 1 has been set.");
throw Except;
}
try{
con->setSchema("CANS_SQL"); //SIGABRT occurs in executing this line.
std::string Query = "UNLOCK TABLES";
sql::Statement *stmt;
stmt = con->createStatement();
stmt->execute(Query);
flags[4] = 0;
}
catch(sql::SQLException &e)
{
flags[4] = 1;
printf("DB_Interface: Flag 4 has been set");
throw Except;
}
EDIT 1
The following has also been attempted with no success.
sudo apt-get install cpp:i386 gcc:i386 g++-5:i386 gcc-5:i386 g++:i386 libboost-dev:i386 binutils:i386
Followed by a reinstall of libmysqlcppconn-dev.

For anyone that may have the same issue, this has been resolved. When I moved to Ubuntu 15.10, I used the same schema model as I did in my last setup. After testing on a completely separate schema for a test project, I noticed no issues. This gave me the hunch that recreating my schema in this version of MySQL and Ubuntu may alleviate some issues. Surprise, surprise it did. After that I recreated the user "CANS_OPERATION". My excerpt above then worked. To get the MATLAB wrapper to work with it as well, I changed from the recommended g++-4.7 compiler for mex functions to the most recent release. Hope this finds someone well.

Related

How can I deal with dll and lib files for connecting MariaDB to C++ Application?

I am trying to work on the project which is to connect MariaDB with C++ application.
I referred to the URL: https://mariadb.com/docs/clients/connector-cpp/#installing-mariadb-connector-c-via-msi-windows.
This URL is quite a good source to connect MariaDB with C++. However, it doesn't describe how to deal with the lib file and dll file.
When I installed the MariaDB connector/C++ via MSI, it gave me several files: conncpp.hpp, mariadbcpp.dll, mariadbcpp.lib, etc.
I tried to include mariadb/conncpp.hpp by setting the path C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29910\include and I did same with the lib file.
Also, I went to the properties and set the linkers for the lib file.
Here is the code that I am planning to execute:
// Includes
#include <iostream>
#include <mariadb/conncpp.hpp>
// Main Process
int main(int argc, char** argv)
{
try
{
// Instantiate Driver
sql::Driver* driver = sql::mariadb::get_driver_instance();
// Configure Connection
// The URL or TCP connection string format is
// ``jdbc:mariadb://host:port/database``.
sql::SQLString url("jdbc:mariadb://192.0.2.1:3306/test");
// Use a properties map for the user name and password
sql::Properties properties({
{"user", "db_user"},
{"password", "db_user_password"}
});
// Establish Connection
// Use a smart pointer for extra safety
std::unique_ptr<sql::Connection> conn(driver->connect(url, properties));
// Use Connection
// ...
// Close Connection
conn->close();
}
// Catch Exceptions
catch (sql::SQLException& e)
{
std::cerr << "Error Connecting to MariaDB Platform: "
<< e.what() << std::endl;
// Exit (Failed)
return 1;
}
// Exit (Success)
return 0;
}
But whenever I compile and execute the code, it says Unhandled exception(0x00007FF918058D25(mariadbcpp.dll), MariaDB_Connection.exe): 0xC0000005:Access violation reading location 0xFFFFFFFFFFFFFFFF at the line of
std::unique_ptr<sql::Connection> conn(driver->connect(url, properties));.
Could you tell me how to solve this problem?
You've hit the deficiency in the C++ connector API. Or call it a bug. It's Windows specific. Debug and release versions of STL objects may have different layout.
Switching build to release configuration should help. But some issues are still possible depending on VS version used. As a workaround you could also try to use other connect method, i.e.
std::unique_ptr<sql::Connection> conn(driver->connect(url, "db_user", "db_user_password"));
since it doesn't rely on Properties map, that causes the issue here.

XCODE produces Segmentation fault as opposed to Exception

I have a very basic C++ program :-
#include <iostream>
#include <stdexcept>
int main(int argc, const char * argv[])
{
std::cout <<"Welcome .. "<<std::endl;
try {
throw std::runtime_error(std::string("Crazy exception"));
}
catch(std::exception& e) {
std::cerr << "error: " << e.what() << "\n";
exit(0);
} return 0;
}
Whenver I run this program, instead of an exception I see a Segmentation fault: 11
On the debugger, I see EXC_BAD_ACCESS(code=EXC_I386_GPFLT) at the throw statement.
I have exceptions enabled on XCODE. Has anyone ever seen this kind of basic error ?
This is really killing me, should I re-install XCODE ? If yes, what's the way for clean install or something
Re-installed XCODE directly from APP STORE. Same issue !! Next is what ? Re-install the whole OSX i believe. Can someone give some clue what "can" be tried before I lounge into a brainless reformatting of the machine ?
Yes, I have executed this program on my mac and it compiled successfully using every type of runtime error in <stdexcept>. Which version of Xcode are you running? is it installed from the Apple store or some other website?
If you have installed it from Apple store please update Xcode version to Xcode 8.3.3 and run the code again.
In case you are using it from some other website, then there is a chance that it has a bug. I have also encountered a similar problem before.
There is a simple way to uninstall Xcode from your Mac. Drag Xcode from Finder in Applications and throw it in the Trash and Empty the Trash.
Re installed MAC OSX ! And it fixed the issue.
Surprisingly there can be some OS corruption which may cause this.
Hopefully this would help someone else in future

OCCI app crashes when running in debug mode in Visual Studio 2005

I'm attempting to get a development environment up and running for developing applications with Oracle C++ Call Interface (OCCI) in Visual Studio 2005.
My system specs are:
OS: Windows 7, 64-bit
Oracle: 11g release 11.2.0.2, 32-bit
Instant Client: BasicLite and SDK version 11.2.0.4 32-bit
Visual Studio 2005 Professional Edition version 8.0 with 32-bit tools enabled
I've followed this guide by Mark Williams and I got the example running but only in release mode. When I switch to debug mode the app will build, but when I run it I get the following error:
Problem signature:
Problem Event Name: APPCRASH
Application Name: OCCITest.exe
Application Version: 0.0.0.0
Application Timestamp: 53f5dfdd
Fault Module Name: KERNELBASE.dll
Fault Module Version: 6.1.7601.18229
The small example program that triggers this error is:
#include "employees.h"
using namespace std;
using namespace oracle::occi;
int main (void)
{
Employees *pEmployees = new Employees();
delete pEmployees;
return 0;
}
Employees::Employees()
{
user = "hr";
passwd = "hr";
db = "localhost:1521/service_name";
env = Environment::createEnvironment(Environment::DEFAULT);
try
{
con = env->createConnection(user, passwd, db);
}
catch (SQLException& ex)
{
cout << ex.getMessage();
exit(EXIT_FAILURE);
}
}
Employees::~Employees()
{
env->terminateConnection (con);
Environment::terminateEnvironment (env);
}
If I remove all calls to OCCI functionality the application doesn’t crash. That is, this program runs error-free:
#include "employees.h"
using namespace std;
using namespace oracle::occi;
int main (void)
{
Employees *pEmployees = new Employees();
delete pEmployees;
return 0;
}
Employees::Employees()
{
user = "hr";
passwd = "hr";
db = "localhost:1521/service_name";
cout<<"Look at me, I'm running"<<endl;
}
Employees::~Employees()
{}
In the guide Mark mentions that when running in debug mode, the linker should use the library file oraocci11d.lib. However, this file is not included in the Instant Client SDK version 11.2.0.4, so I’m using the input file oraocci11.lib for both the release and debug version.
I'm running out of ideas about how to proceed in solving this problem, and I would greatly appreciate any and all help.
If the Oracle DLL receives and/or passes objects such as std::string or any other object that either:
Manipulates the heap in any way, or
The objects could have differing internals between app and DLL,
then you have no choice but to use the correct library to link with. Otherwise you wind up with binary or heap incompatible objects being passed, which leads to what you're seeing now.
See here: http://docs.oracle.com/cd/E11882_01/appdev.112/e10764/install.htm#CBHGBBJI
The link above mentions both the debug import library and debug version of the DLL. Also this is stated at the link:
Applications that link to MSVCRTD.DLL, a debug version of Microsoft C-Runtime, /MDd compiler flag, should link with these specific OCCI libraries: oraocci11d.lib and oraocci11d.dll.
Since it took me quite some time to get the debug environment working I figured I'd answer my own question now that I did.
I got a variety of errors throughout the ordeal, but the error that I got most stuck on was an error saying:
'The application was unable to start correctly (0xc0150002).
Click OK to close the application.'
Also, I used http://www.dependencywalker.com which repeatedly told me that either oraocci11d.dll or a the following list of dll's could not be found.
API-MS-WIN-APPMODEL-RUNTIME-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
API-MS-WIN-SHCORE-SCALING-L1-1-1.DLL
DCOMP.DLL
IESHIMS.DLL
However, what was really missing was for the executable to be able to find oci.dll. I'm just mentioning the errors in case someone else runs into these.
Here is what was needed to make it work:
First of all, the Instant Client does not contain the oraocci11d.lib or oraocci11d.dll, so it is necessary to install the full Oracle Client.
Next, the following must be added to the PATH:
C:\Program Files\Oracle\11.2.0\OCI\lib\MSVC\vc8
C:\Program Files\Oracle\11.2.0\BIN
In Visual Studio, select Tools -> Options, unfold 'Projects and Solutions' and select VC++ Directories. In 'Show directories for' under:
Include Files add C:\Program Files\Oracle\11.2.0\OCI\include
Library files add C:\Program Files\Oracle\11.2.0\OCI\lib\MSVC\vc8
In the property page for your project under Configuration Properties -> Linker select Input and under Additional Dependencies add oraocci11d.lib (or oraocci11.lib for release mode). Then select debug/release mode in the Configuration Manager
I have a related problem in that I am successfully using oraocci12d.dll/msvcr100d.dll, but this in turn is using oci.dll/msvcr100.dll. ie, oci.dll is not using the debug version of msvcr100.
My program seems to run okay, but any memory leak reporting disappears on exit.

C++ MySQL Connector in Xcode 5

I have a problem using MySQL Connector for C++ in Xcode 5.
When I use the sql::Driver->connect I get EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
What I have:
64bit Boost libs (working)
64bit Mysqlconnector (dylib) + header files (which are in Xcode)
libmysqlcppconn.7.dylib and libmysqlclient.18.dylib are copied to the binaries directory for being loaded (if I don't have them there, it tells me it cannot find the images.)
Compiled with 64bit Intel
What I do:
try
{
sql::Driver *driver = get_driver_instance();
driver->connect(DBHOST, DBUSER, DBPASSWORD);
m_databaseConnection = driver->connect(DBHOST, DBUSER, DBPASSWORD);
m_databaseConnection->setAutoCommit(true);
m_databaseConnection->setSchema(DBDATABASE);
return true;
}
catch (...)
{
return false;
}
I've set a breakpoint above driver->connect and recognized that driver is set, so get_driver_instance() seems to work.
When calling its connect method, driver becomes NULL and the program crashes with bad access.
How can I solve this?

Visual Studio 2013 crashes when compiling Sqlite C++ library

I'm having an absolute nightmare of a time trying to get the Sqlite C++ library to compile in Visual Studio 2013 Ultimate (Compiles fine in VS2012).
Basically regardless of whether I try to perform a clean or a rebuild VS will claim to successfully finish but will subsequently freeze and become unresponsive, never to recover.
Here is the output
and here is the actual VS project.
Anyone care to give it a crack and see if they are running into the same problem or provide any suggestions?
Tim Heuer gives step by step instructions ON THIS LINK. The batch files are hardcoded for TCL 8.5, you'll save yourself some time if you don't download the latest (8.6)
EDITED - I successfully compiled SQLite with Tim's steps (I just reinstalled Windows 8.1 / VS 2013). Note: the only issue I encountered was taking the steps to literally, be sure to change into the newly created SQLite directory before running the fossil command.
FYI for WinRT, be sure to use the correct path, if you just specify the filename you will get an access denied error (which will surface as a "cannot open database" error).
using namespace Windows::Storage;
using namespace std;
void SqliteWrapper::RunTest(void)
{
sqlite3 *db;
int rc;
auto path = ApplicationData::Current->LocalFolder->Path+"\\MyDatabase.db";
string dataPath(path->Begin(), path->End());
rc = sqlite3_open(dataPath.c_str(), &db);
if( rc ){
fprintf(stderr, "Can't open database: %s\n", sqlite3_errmsg(db));
sqlite3_close(db);
}
sqlite3_close(db);
}