Fix a segfault related to async statements #60
Conversation
| @@ -684,6 +684,8 @@ void dbd_db_destroy (SV * dbh, imp_dbh_t * imp_dbh) | |||
| if (imp_dbh->async_sth->result) { | |||
| TRACE_PQCLEAR; | |||
| PQclear(imp_dbh->async_sth->result); | |||
| if (imp_dbh->last_result == imp_dbh->async_sth->result) | |||
There was a problem hiding this comment.
Actually this first change does nothing to alleviate segfaults for me, but looks safer to me to do this...
|
Hi, I just ran into the same double free issue in an application that uses async extensively and can confirm that the above patch fixes that. I don't have a small test-case but at least I can show the code: https://github.com/a6502/jobcenter/blob/master/bin/maestro This uses Mojo::Pg (subclassed for better connection pooling). Is there anything I can do to help solve this issue? |
|
Yeah, my app also uses Mojo::Pg. I considered that maybe Mojo::Pg was misusing DBD::Pg somehow, but after digging through the dbdpg code I settled on the flaw being here. What do you think @turnstep ? |
|
Maybe a duplicate of #37? |
|
Looks very similar, but I didn't think it was the exact same bug because I bisected this crash to a commit made later than that bug was filed (b312efb). |
|
Merge conflict. Needs rebasing? |
Actually this PR should be abandoned because the issue was fixed with the 3.10.1 release. |
Hi friends,
After upgrading to DBD::Pg 3.10.0, my async app now dies on "Segmentation fault" or "double free or corruption". The exact place it dies is inconsistent, but capturing various backtraces reveals it's always in
PQclear. So it seems clear we're attempting to free a result more than once. Here's a sample backtrace:I bisected to b312efb (made prior to 3.9.0).
I took a stab at fixing the problem and came to this solution. This does alleviate the segfaults for me, though I'd need someone more familiar with this code to verify it's the right solution.
Although it crashes consistently in my complex app, I haven't yet succeeded in even reproducing the crash in a test file. :-(