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
> >
> >
> >
> >
