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
