On 2/7/2012 12:09 PM, Sebastien Darveau wrote:
>
> Thread [16] 26141 (Suspended : Signal : SIGPIPE:Broken pipe)
...
> No exception are thrown, the program crashes.
It seems this first stack trace you've given doesn't actually show the
problem, then. You should be able to get a more useful stack trace from
the core files produced when the program segfaults.
Core files may be suppressed on your system. Say 'ulimit -c' in the
context of the user running the program (not admin, not a dev user, the
actual user that starts the program) to find out. It needs to say
"unlimited", or at least a very large number, for this to give useful
results.
> Interesting fact, MySQL 5.5 does not use a separated libmysqlclient_r.so library
> anymore
What is the return value of Connection::thread_aware()?
> I can see that in all cases, it happened in mysqlpp object's destructor (double
> delete?):
>
> Server 1
> ---------
> 2012-02-06 05:56:15: [ERROR] Query error: Lost connection to MySQL server during
> query
> 2012-02-06 05:56:16: [ERROR] 1: 0x2b3f35e39a67 <+47550487042663>
> (/usr/lib64/libmysqlclient.so.18)
This stack trace makes no sense.
First off, it claims to start in Query's dtor, but Query has no explicit
dtor. Query allocates no dynamic memory, and doesn't derive from
anything with a nontrivial virtual dtor, so it doesn't need one. That
means if ~Query() is involved at all, it's the compiler-generated
default dtor.
More confusing is that fact that ~Query() (being trivial) doesn't call
Query::use(), and use() doesn't say "delete this", so there's no way the
call sequence you show can happen.
I think it's most likely that something trashed your stack before you
got to this point. Running the program under valgrind has a good chance
of finding this problem.
It may instead be that whatever tool you're using to read the stack
trace at crash time isn't doing a good job. Getting the backtrace from
the core file with gdb will test this guess.
