Yes, this definitely seems to be where the SIGSEGV is being generated from. The o pointer
will have already been deleted by the auto_ptr in DBDriver::set_option when
Connection::set_option attempts to use it.
--Kevin
-----Original Message-----
From: Kevin Regan [mailto:k.regan@stripped]
Sent: Friday, June 12, 2009 3:56 PM
To: Jonathan Wakely
Cc: plusplus@stripped
Subject: RE: Why dynamic allocation for Option objects?
I was taking another look at this issue (please see the code below to following along with
my issue). If the DBDriver::set_option returns non-empty error string, wouldn't it have
deleted the objected contained in o that Connection::set_option will call typeid(*o) on?
My application is currently crashing in set_option call and I'm trying to track down what
might be going on.
--Kevin
bool
Connection::set_option(Option* o)
{
error_message_ = driver_->set_option(o);
if (error_message_.empty()) {
return true;
}
else {
if (throw_exceptions()) {
throw BadOption(error_message_, typeid(*o));
}
return false;
}
}
std::string
DBDriver::set_option(Option* o)
{
std::ostringstream os;
std::auto_ptr<Option> cleanup(o);
switch (o->set(this)) {
case Option::err_NONE:
applied_options_.push_back(o);
cleanup.release();
break;
case Option::err_api_limit:
os << "Option not supported by database driver v" <<
client_version();
throw BadOption(os.str(), typeid(*o)); // mandatory throw!
case Option::err_api_reject:
os << "Database driver failed to set option";
break;
case Option::err_connected:
os << "Option can only be set before connection is established";
break;
}
return os.str();
}
-----Original Message-----
From: jonathan.wakely@stripped [mailto:jonathan.wakely@stripped] On Behalf Of Jonathan
Wakely
Sent: Thursday, June 11, 2009 1:43 AM
To: Kevin Regan
Cc: plusplus@stripped
Subject: Re: Why dynamic allocation for Option objects?
2009/6/11 Kevin Regan:
>
> Let's take as an example, the function in question:
>
> std::string
> DBDriver::set_option(Option* o)
> {
> std::ostringstream os;
> std::auto_ptr<Option> cleanup(o);
>
> Now, let's imagine that the constructor for std::ostringstream can throw an exception
> (maybe it allocates a working buffer). In that event, the memory for the option will
> not be reclaimed when a std::bad_alloc exception is thrown.
The ostringtream default constructor shouldn't throw, but it wouldn't
hurt to swap those two lines so that the pointer is guarded
immediately.
I detest raw pointers to dynamically allocated memory, and would
advise using an auto_ptr in the interface, so it is explicit that
ownership is being transferred and that the address of a static or
local variable should not be passed in.
std::string
DBDriver::set_option(std::auto_ptr<Option> o);
The existing function could then be changed to simply forward to that
one, and ideally deprecated.
Jonathan
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsub=1

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.