mirror of https://github.com/grpc/grpc.git
tc_on_alarm() and on_writable() race, resulting in the following: ``` D1219 08:59:33.425951347 86323 tcp_client_posix.cc:143] CLIENT_CONNECT: ipv4:127.0.0.1:27465: on_writable: error="No Error" D1219 08:59:33.426032150 86342 tcp_client_posix.cc:104] CLIENT_CONNECT: ipv4:127.0.0.1:27465: on_alarm: error="No Error" // At this point, note that the callbacks are running on different threads. D1219 08:59:33.426063521 86323 tcp_client_posix.cc:218] XXX on_writable ac->addr_str 0x603000008dd0 before unlock. # refs 2->1. Done 0 // on_writable() unrefs while still holding the lock. Because refs > 0, it marks its "done" as false and unlocks. D1219 08:59:33.426125130 86342 tcp_client_posix.cc:113] XXX tc_on_alarm ac->addr_str 0x603000008dd0 before unlock. # refs 1->0. Done 1 // right after on_writable() unlocks, tc_on_alarm() acquires the lock and unrefs, this time getting to zero and marking its "done" as true. // It then proceeds to destroy "ac", and, in particular for this failure, "ac->addr_str". D1219 08:59:33.426139370 86323 tcp_client_posix.cc:234] XXX on_writable about to read from ac->addr_str 0x603000008dd0. Done 0, error=OS Error // When on_writable() tries to read ac->addr_str to assemble its error details, it causes a use-after-free. ``` The problem is the lock isn't held long enough by on_writable(). Alternatively, a copy of ac->addr_str could be made in on_writable() while still holding the lock, but that seems more fragile. It doesn't seem that holding the lock longer would be a performance issue, given we are in a failure scenario.pull/13494/head
parent
1bedfa3963
commit
5f31f01a8c
1 changed files with 1 additions and 1 deletions
Loading…
Reference in new issue