Closed bjakubski closed 10 years ago
i think it is similar problem with #9. https://github.com/shogo82148/Redis-Fast/compare/fix-issue-9-avoid-double-free this branch will also fix this issue. try it please.
double free related to #9 but ignoring signal looks related to #10 ?
Thanks for feedback!
It does appear related to other issues, but I decided to post it separatel, as I have nice, small and reproducible test case (and some details differ).
@shogo82148 this branch does indeed make "double free" go away, but main problem is that first TERM signal gets "eaten" somewhere. That in turn looks like #10 but I've never seen that without reconnect enabled. I suspect that select() being interrupted by signal is mistaken as a lost connection and reconnect code triggers in
oops, sorry, I had misunderstood the problem.
I suspect that select() being interrupted by signal is mistaken as a lost connection and reconnect code triggers in
i think so, too.
Redis::Fast always reconnect if select() returns error. but it should not reconnect with errno == EINTR
.
I will fix it.
pr #12 will fix this. try it please.
I merged #12 and released Redis::Fast 0.0.9.
We discovered that Redis::Fast in some circumstances behaves badly when receiving signal during blocking operation (e.g. brpop).
Following code works ok when it receives signal 15 during brpop:
Just adding
$SIG{TERM} = sub {}
(actual content of this sub does not matter) makes it ignore first TERM signal received and reissue brpop command (it appears it trigger reconnect code) second TERM signal crashes this program. ("double free").When there is no reconnect enabled problem does not appear, so one needs to have both reconnect and some TERM singnal handler installed to reproduce it.
Tested on 0.08 with perl 5.10.1 and 5.16 I compiled Redis::Fast with DEBUG enabled and reproduced this issue - see below