[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #7212 [Tor]: circuitmux assertion failure in 0.2.4.4-alpha
#7212: circuitmux assertion failure in 0.2.4.4-alpha
-----------------------+----------------------------------------------------
Reporter: nickm | Owner:
Type: defect | Status: needs_review
Priority: major | Milestone: Tor: 0.2.4.x-final
Component: Tor | Version: Tor: 0.2.4.4-alpha
Keywords: tor-relay | Parent:
Points: | Actualpoints:
-----------------------+----------------------------------------------------
Comment(by andrea):
Now, if this happens while a spliced circuit is active, it will hit one or
the other end's p_chan first, and then circuit_unlink_all_from_channel()
first calls channel_unlink_all_circuits(), then circuit_mark_for_close()
on every unmarked circuit. If that hits the spliced circuit, it then
recursively calls circuit_mark_for_close() on the spliced circuit, and
then circuit_clear_cell_queue(), and finally update_circuit_on_cmux().
Before nickm's recent fix to circuit_clear_cell_queue(), it would not be
checked whether the spliced circuit was attached to the cmux, so that
could trigger the assert if it were not attached. Is it possible for a
spliced rendezvous circuit to, by coincidence, have the same p_chan on
both ends? I think it is, and if so that could trigger the bug.
If any instances of this are observed in the future, I'd quite like to see
the p_chan as well as the n_chan, but I think nickm's change to
circuit_clear_cell_queue() fixes it.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7212#comment:25>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs