Reputation: 21
I'm writing a simple application to correct a certain byte in a binary blob that's stored in a database. I use OTL to connect my C++ program to the database. Reading the data and manipulation works fine, but when I want to write it back to the database, the program dies.
The code:
try
{
std::string updateQuery = "UPDATE tbtptemplates "
" SET tptemplate=:tp<BLOB> "
"WHERE afisid=:aid<INT>";
otl_long_string blob(&stp(), theSizeOfBlob);
blob.set_len(theSizeOfBlob);
otl_stream str(1, updateQuery.c_str(), theDbConnection);
str.set_lob_stream_mode(true);
str.set_commit(0);
otl_lob_stream lob;
lob.set_len(theSizeOfBlob);
str << lob;
str << theCurrentAfisId;
lob << blob;
lob.close();
}
catch (const otl_exception &oe)
{
std::cerr << oe.msg;
throw std::runtime_error("could not write to database");
}
I spied at Sourceforge for an example.
I create an otl_long_string that takes the data. Then I create an otl_stream and bring together the SQL statement and the database connection. I use an otl_lob_stream to provide the binary data to the otl_stream. Streaming of the blob data to the otl_stream works fine. But when I hand over the id to the stream, the process dies.
This is the killer instruction:
str << theCurrentAfisId;
it is a simple int-variable that I hand over. The effect is very funny: the process doesn't die completely, only the call stack below the current method is gone. This is the call stack before the statement:
Thread #1 [fix_stp] 10307 [core: 7] (Suspended : Breakpoint)
Drm::TPFixer::DatabaseConnector::writeDB() at DatabaseConnector.cpp:224 0x40b565
Drm::TPFixer::DatabaseConnector::fixImpressiontype() at DatabaseConnector.cpp:139 0x40b516
Drm::TPFixer::SuperTemplateManager::fixImpressiontype() at SuperTemplateManager.cpp:67 0x4074e3
main() at main.cpp:51 0x40477b
and this is the complete stack in the very moment after the instruction:
Thread #1 [fix_stp] 10307 [core: 7] (Running : Step)
Drm::TPFixer::DatabaseConnector::writeDB() at DatabaseConnector.cpp:240 0x40b6b2
I tried to debug the otl. It seems that the otl finds that it's got all required parameters and starts to run. In that moment it crashes.
The environment that I use:
- OTL 4.0
- CentOS Linux, kernel 3.10.0-327.22.2.el7.x86_64
- gcc-Version 4.8.5
- Oracle 11g
Does anybody have an idea?
Upvotes: 1
Views: 376