MySQL Forums
Forum List  »  Connector/C++

Segmentation fault when inserting a large string
Posted by: Martin O'Neal
Date: April 17, 2016 11:13AM

I have a repeatable segmentation fault when using prepared statements with large chunks of data bound to a mediumblob data type. I’ve searched the outstanding bugs, but can’t find anything relevant, and just wanted to sanity check what I’m doing, before I go ahead and create a new bug.

My code is well established and has been working in a variety of iterations for years, but I noticed recently that one subroutine that loads files into a database was failing on a new example, which was larger than prior files.

The code is fully unit tested, and larger read and writes are working as expected within the tests.

When I looked at the failing section, the parameter had been bound to a std::string using setString, rather than a stream and setBlob. In all cases, the segmentation fault was triggered when execute was issued.

Off the back of this, I added additional tests and the results I found were:

setString fails at ~250k with a segmentation fault
getString, setBlob and getBlob all work fine, and appear only limited by max_allowed_packet

I’m a bit of an anal coder, and the compiler generates no warnings, plus a valgrind run with a smaller file generates no errors at all.

With a large file, the segmentation fault is generated, and valgrind reports (heavily abridged):
Conditional jump or move depends on uninitialised value(s)
Uninitialised value was created by a stack allocation
sql::mysql::MySQL_Prepared_Statement::execute() (in /usr/lib/

Which looks like the library code has tried to allocate the string on the stack, failed, but has not checked the return before using it.

Code versions:

Options: ReplyQuote

Written By
Segmentation fault when inserting a large string
April 17, 2016 11:13AM

Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.