List:MySQL++« Previous MessageNext Message »
From:Warren Young Date:February 9 2012 10:40pm
Subject:Re: Segmentation Fault after upgrading to MySQL 5.5
View as plain text  
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.
Thread
Segmentation Fault after upgrading to MySQL 5.5Sebastien Darveau6 Feb
  • RE: Segmentation Fault after upgrading to MySQL 5.5Sebastien Darveau7 Feb
    • RE: Segmentation Fault after upgrading to MySQL 5.5Dino Korah7 Feb
      • RE: Segmentation Fault after upgrading to MySQL 5.5Sebastien Darveau7 Feb
    • Re: Segmentation Fault after upgrading to MySQL 5.5Warren Young9 Feb