On 04/21/2013 06:56 PM, Petr Koupý wrote: > changeset 1812 should be a proper way how to release resources for orphaned > windows. There were two problems with the simple patch you proposed. First > of all, it did not work with normal window closing because the function > comp_window_close would be called twice leading to a double deallocation. > Secondly, it did not take care of the window input fibril which is most of > the time blocked within comp_window_get_event. Note that in a normal > protocol-driven window closing, input fibril is already terminated when > the output fibril deallocates the window resources (including the queue > on which the input fibril is usually blocked). > > I did not investigate the root causes of the behaviour you described in much > detail, but there were definitely some orphaned fibrils within the compositor > that would work with deallocated memory if woken up. The reason for the > locked up launcher was that after you tried to spawn a new vterm, the > compositor was unable to properly establish new connections. Therefore the > vterm was blocked within its own initialization and vlaunch was blocked on > task_wait. When I killed the half-initialized vterm in kernel console, the > launcher would unblock and continue normally.
Thanks for looking into this. I did not realize my patch was breaking the normal window close because the window would be closed twice. I was so excited about the patch working for the less usual case that I did not test the more usual case. My bad :-) On the other hand, I don't understand how there could be some leaked fibrils left after the client task is killed - the kernel will hang up all its phones which should lead to ending the other connection fibril unless it is blocked on something else. Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
