Menu
▾
▴
#266 Audit needed: Tk_MaintainGeometry reenters interp
Just discovered that Tk_MaintainGeometry can reenter the interpreter. Code path: Tk_MaintainGeometry -> Tk_MoveResizeWindow -> TkDoConfigureNotify, which calls Tk_HandleEvent directly instead of adding it to the event queue. Tk_HandleEvent in turn fires binding scripts, so anything at all can happen.
Need to audit all calls to Ttk_PlaceSlave to make sure this is safe (neither Tk_MaintainGeometry nor Tk_MoveResizeWindow are called from anywhere else in Tile).
Logged In: YES
user_id=68433
Originator: YES
Tk_UnmapWindow() also calls Tk_HandleEvent() directly. Need to audit Ttk_UnmapSlave calls as well.
From a quick check, it looks like Ttk_PlaceSlave calls are safe against most (but not all) mischief: labelframe and notebook widget only map one slave at a time and call Ttk_PlaceSlave in (near-) tail position. The panedwindow PlacePanes routine (by fortuitous accident) tests the slave index against Ttk_NumberSlaves() each pass through the loop, so it's immune from the slave array changing in the middle of the loop (it won't do the right thing, but at least it won't step out of bounds).
However, if a slave destroys its master in a <Configure>, <Map>, or <Unmap> binding, it can lead to a write to freed memory (RecomputeLayout writes to mgr->flags after calling the PlaceSlaves hook), and, for ttk::panedwindow, even worse.
Proposed changes: in RecomputeLayout (manager.c), clear the MGR_RELAYOUT_REQUIRED flag _before_ calling the PlaceSlaves hook. This way the Ttk_PlaceSlave calls in the notebook and labelframe widgets will be in tail position, and will also allow geometry propagation to be rescheduled if a slave binding does something that requires one.
Can't think of a good way to handle slaves of a panedwindow destroying their master in a configure binding (other than to say "Don't Do That.")