wimp_event, menus and the search dialog
jmb202 at ecs.soton.ac.uk
Mon Mar 26 01:16:48 BST 2007
So, I've just spent 5 hours trying to work out why there are 3 crashes on
the tracker relating to the search/selection code. In the process, I've
come to the following conclusions:
1) wimp_event never calls the registered window close routine if cancel is
clicked. This results in a memory leak in 401login.c if nothing else -
the session struct doesn't get freed.
2) dialogs opened as submenus never have their window close routine called
when either the menu is closed completely or a different branch is
selected by the user.
3) closing persistent dialogs doesn't result in window close routines
4) there's a hideous amount of collusion between the dialog, menu and
search code over the search dialog
5) calling ro_gui_search_end() can lead to crashes in some circumstances.
To elaborate on #5:
Calling ro_gui_search_end() causes all the matched search terms to be
destroyed. In the process, all selections relating to the search are
destroyed. In the process of selection destruction, the selections are
cleared, which causes an attempt to redraw the content. So far, so good.
Now, consider this situation:
You've just attempted to open a new window. NS crashes.
Why is this?
1) The Wimp's reused the handle for a previously existing browser window
2a) When you closed that previous window, the search dialog was still open
(and, because of #3, above, the search state was never invalidated)
2b) When you closed that previous window, the selection state was still
valid because, when you closed the search window, it didn't get
cleaned up (because of #1, above)
3) You've not used search since (so that previous state still exists).
4) As you've closed a window with the reused handle before, the content in
that window has been expunged from the cache (or, if you're lucky, it's
still in there)
5) Once the new window's content has fetched, NS checks if the new window
has the same handle as that of current_search_window. It does, so
ro_gui_search_end() gets called. This then calls selection_clear() with
the redraw flag set to true. Once it's invalidated the selection state,
selection_clear() then calls selection_redraw() which traverses the box
tree of the _previous window's content_ (and, in one case, miraculously
fails to crash - quite how, I've no idea) and then calls
browser_window_redraw_rect() with the rectangle to redraw. This then
munges the rectangle into a content_msg and calls content_broadcast()
which, finally, causes NS to SEGV (even though the new window now has a
current_content which is in a state where redraw is possible)
[I suspect #2, above, is the reason why NS sometimes crashes when F4 is
pressed - the state's not cleaned up properly, so the same thing
Fixing this one is currently beyond me - there's just too many things
interacting with each other in the UI code that I've no idea what impact
any change I make will have on any other part of the system. Therefore,
someone else is going to have to fix this one.
More information about the netsurf-dev