• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: _GLIBCXX_DEBUG _GLIBCXX_DEBUG_PEDANTIC nuttiness causing debug build crashes...
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: _GLIBCXX_DEBUG _GLIBCXX_DEBUG_PEDANTIC nuttiness causing debug build crashes...


  • Subject: Re: _GLIBCXX_DEBUG _GLIBCXX_DEBUG_PEDANTIC nuttiness causing debug build crashes...
  • From: Graham Reitz <email@hidden>
  • Date: Wed, 5 Dec 2007 22:14:53 -0600

When D_GLIBCXX_DEBUG is defined in the project and linking against libraries that are not compiled with D_GLIBCXX_DEBUG you get undefined behavior (and passing around stl containers). So when Xcode adds that by default (a good thing) it was causing unpredictable behavior when the debug build ran.

http://gcc.gnu.org/onlinedocs/libstdc++/debug.html#safe

thanks again for the help,
graham


On Dec 5, 2007, at 4:36 PM, Graham Reitz wrote:

Ok thanks folks. You are not going to get an argument from me. I agree completely. Although, I expect an argument from the author(s) of mysql++ .

It must be in the mysql++ code, since the code (a simple main function) only makes call into it.

The code is below for those of you that are interested. I would be interested in hearing your opinions.

The code:
int main (int argc, char * const argv[])
{
  string database_name = "db_rev_4";
  string ip_address = "X.X.X.X";
  string username = "admin";
  string password = "admin";
  string client_id = "graham";
  string client_pw = "reitz";
  string error_msg;

  cout << "Attempting to connect to the database...";

  Connection m_connection(database_name.c_str(),
                          ip_address.c_str(),
                          username.c_str(),
                          password.c_str(),
                          3306,
                          false,
                          15);

  Result client_id_result;

	try
	{

      cout << "connected to the database\n";

      Query client_id_query = m_connection.query();

      client_id_query <<
      "select client_id from clients where client_user_name ="
      << quote_only << client_id << " and client_password ="
      << quote_only << client_pw;

      cout << "Query created: " << client_id_query.preview() << endl;

      client_id_result = client_id_query.store();

      if (client_id_result)
      {
          cout << "Result received = " << client_id_result.rows()
<< endl;
          Row client_id_row;
          Row::size_type i = 0;
          client_id_row = client_id_result.at(i);
      }

      Row client_id_row;
      // The "=" versus "==" syntax is more mysqlpp bs
      if (client_id_row = client_id_result.at(0))
      {
          cout << client_id_row.at(0) << endl;
          return client_id_row.at(0);
      }
  }
  catch (exception &e)
  {
      cout << "exception occurred...";
      cout << e.what() << endl;
  }
  catch (...)
  {
      error_msg = "Unknown exception";
      cout << error_msg << endl;
  }

  m_connection.close();

  return 0;
}

On Dec 5, 2007, at 1:00 PM, Clark Cox wrote:

On Dec 5, 2007 8:29 AM, Graham Reitz <email@hidden> wrote:
Thanks Tom,

That is what goes wrong - the passed in values don't survive
validation. Either one of them is uninitialized, they are in the
wrong order or don't belong to the same container.

Why does the exact same code and libraries run fine under the release
build?

This is the whole point of these extra checks. Many people do things
with the STL that *seems* to work, but which isn't guaranteed to work
by the C++ standard. Some examples of this that I have seen in
people's code:
1) Assuming that every iterator is just a pointer or can be
constructed from one (setting an iterator to NULL is a very common
example of this).
2) assuming that it is legal to compare iterators that don't belong to
the same container
3) assuming that you can decrement an input iterator, output iterator
or forward iterator
4) assuming that you can store a copy of an input iterator to
"remember your place"
...and many others.


Out of sheer luck (or lack thereof, when you really think about it),
many of these things will seem to work in many cases or on certain
platforms. The debug settings in GCC are being helpful by pointing
these problems out in debug mode (i.e. *before* you've shipped the bad
code to your customers).


You would be well served to leave these settings as they are, and to
track down every crash that they cause.

--
Clark S. Cox III
email@hidden

_______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden

_______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
  • Follow-Ups:
    • Re: _GLIBCXX_DEBUG _GLIBCXX_DEBUG_PEDANTIC nuttiness causing debug build crashes...
      • From: Thomas Engelmeier <email@hidden>
References: 
 >_GLIBCXX_DEBUG _GLIBCXX_DEBUG_PEDANTIC nuttiness causing debug build crashes... (From: Graham Reitz <email@hidden>)
 >Re: _GLIBCXX_DEBUG _GLIBCXX_DEBUG_PEDANTIC nuttiness causing debug build crashes... (From: Thomas Engelmeier <email@hidden>)
 >Re: _GLIBCXX_DEBUG _GLIBCXX_DEBUG_PEDANTIC nuttiness causing debug build crashes... (From: Graham Reitz <email@hidden>)
 >Re: _GLIBCXX_DEBUG _GLIBCXX_DEBUG_PEDANTIC nuttiness causing debug build crashes... (From: "Clark Cox" <email@hidden>)
 >Re: _GLIBCXX_DEBUG _GLIBCXX_DEBUG_PEDANTIC nuttiness causing debug build crashes... (From: Graham Reitz <email@hidden>)

  • Prev by Date: Re: Displaying Breakpoints dialog
  • Next by Date: How to make a program look for dylibs other than /usr/local/lib?
  • Previous by thread: Re: _GLIBCXX_DEBUG _GLIBCXX_DEBUG_PEDANTIC nuttiness causing debug build crashes...
  • Next by thread: Re: _GLIBCXX_DEBUG _GLIBCXX_DEBUG_PEDANTIC nuttiness causing debug build crashes...
  • Index(es):
    • Date
    • Thread