List:MySQL++« Previous MessageNext Message »
From:Chris Frey Date:February 13 2005 10:08pm
Subject:Re: mysql++1.7.28 core dumps on solaris
View as plain text  
Hi Alex,

Do exceptions in general work properly?  I looked at the backtrace, and
from my reading, the ~BadQuery() destructor is an argument to
__cxa_throw(), so I think it is not throwing from there, but from inside
select_db().  The __cxa_throw() code seems to support that:

	extern "C" void
	__cxa_throw (void *obj, std::type_info *tinfo, void (*dest) (void *))
	{
	  __cxa_exception *header = __get_exception_header_from_obj (obj);
	  header->exceptionType = tinfo;
	  header->exceptionDestructor = dest;
 
I'm guessing the alloc.h reference to the select_db line is an inline
std::string item, but I'm not sure.

It almost looks like the catch(BadQuery&) that is there is not recognized,
which leads me to believe that either exceptions are broken in general, or
maybe resetdb.cpp was compiled with a different exception setting than
the library.  (i.e. --with-exception or not)

Glad you found a workaround though, this is a strange one. :-)

- Chris

On Sat, Feb 12, 2005 at 05:30:31PM -0500, Alex Vishnev wrote:
> 
> Chris, 
> 
> Thanks for the answer. However it did not help. I checked the permission and
> everything seemed to be fine. I can use mysql and create db with the same
> user name. After I installed you patch, the program still core dumped. It
> looked like the problem is with destruction of exception object. I could be
> wrong, but at least that is what gdb points to. In any case, I modified
> resetdb to avoid try/catch conditions and everything worked fine. So that
> makes me think that something in exception catching is not working. Did
> anyone experience something like that? maybe I did something (or did not do
> something) when I recompiled mysql++. 
> 
> Sincerely,
> 
> Alex
> 
> 
> -----Original Message-----
> From: Chris Frey [mailto:cdfrey@stripped] 
> Sent: Saturday, February 12, 2005 2:58 PM
> To: plusplus@stripped
> Subject: Re: mysql++1.7.28 core dumps on solaris
> 
> I think this is a bug in the resetdb.cpp example, where it doesn't turn
> off exceptions inside the catch() handler.
> 
> Check the permissions of your login in your mysql database.  The crash
> occurs because it can't select (and probably can't create) the sample
> database, so I'm guessing it is a permission issue.
> 
> Below is a quick untested patch that should avoid the coredump, to give
> an idea where the problem is.
> 
> - Chris
> 
> diff -u resetdb.cpp resetdb.cpp
> --- resetdb.cpp 10 Dec 2004 01:00:35 -0000      1.1.1.1
> +++ resetdb.cpp 12 Feb 2005 19:58:08 -0000
> @@ -20,6 +20,12 @@
>                         con.select_db(kpcSampleDatabase);
>                 }
>                 catch (mysqlpp::BadQuery &) {
> +                       mysqlpp::Connection con(!mysqlpp::use_exceptions);
> +                       if (!connect_to_db(argc, argv, con, "")) {
> +                               cerr << "Failed to connect to sample
> database." << endl;
> +                               return 1;
> +                       }
> +
>                         // Couldn't switch to the sample database, so assume
> that it
>                         // doesn't exist and create it.  If that doesn't
> work, exit
>                         // with an error.
> c
> 
> 
> On Sat, Feb 12, 2005 at 01:34:09PM -0500, Alex Vishnev wrote:
> > Hello,
> > 
> > I am using Solaris 2.8(32bit) with MySql-Standard 4.0.23 and
> mysql++.1.7.28.
> > GCC version is 3.3.2. When I am running any of the examples application,
> I
> > get a core dump (trace below).mysql++ was recompiled from source using
> > 4.0.23 include/lib references. Compilation did not produce any errors.
> > 
> > 
> > #0  0xff09c4ac in _libc_kill () from /lib/libc.so.1
> > #1  0xff035a84 in abort () from /lib/libc.so.1
> > #2  0xff161acc in __cxxabiv1::__terminate (handler=0xff03597c <abort>) at
> > ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:47
> > #3  0xff161b04 in std::terminate () at
> > ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:57
> > #4  0xff161c74 in __cxa_throw (obj=0x2d340, tinfo=0x1af3c, dest=0x19b94
> > <mysqlpp::BadQuery::~BadQuery()>)
> >     at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:80
> > #5  0xff3288c4 in mysqlpp::Connection::select_db (this=0x0, db=0x1af3c "")
> > at /usr/local/include/c++/3.3.2/bits/stl_alloc.h:652
> > #6  0x00013b88 in main (argc=1, argv=0xffbef774) at resetdb.cpp:22
> > (gdb)
> > 
> > Sincerely,
> > 
> > Alex
> > 
> > 
> > 
> > 
Thread
mysql++1.7.28 core dumps on solarisAlex Vishnev12 Feb
  • Re: mysql++1.7.28 core dumps on solarisChris Frey12 Feb
    • RE: mysql++1.7.28 core dumps on solarisAlex Vishnev12 Feb
      • Re: mysql++1.7.28 core dumps on solarisChris Frey13 Feb
        • RE: mysql++1.7.28 core dumps on solarisAlex Vishnev14 Feb
          • Re: mysql++1.7.28 core dumps on solarisWarren Young14 Feb
    • Re: mysql++1.7.28 core dumps on solarisWarren Young14 Feb
  • Re: mysql++1.7.28 core dumps on solarisWarren Young14 Feb
    • RE: mysql++1.7.28 core dumps on solarisAlex Vishnev14 Feb
      • Re: mysql++1.7.28 core dumps on solarisWarren Young14 Feb
        • mysql++1.7.28 thread safetyAlex Vishnev14 Feb
          • Re: mysql++1.7.28 thread safetyEarl Miles14 Feb
            • Re: mysql++1.7.28 thread safetyWarren Young14 Feb
              • Re: mysql++1.7.28 thread safetyEarl Miles14 Feb
              • RE: mysql++1.7.28 thread safetyAlex Vishnev15 Feb
                • Re: mysql++1.7.28 thread safetyWarren Young16 Feb