Ticket #214 (Fixed)Tue Jul 21 15:14:47 UTC 2009

TextGadgets post-filter's handling of Toolbox_ObjectDeleted is dangerously broken.

Reported by:	Christopher Bazley (288)	Severity:	Critical
Part:	RISC OS: Module	Release:
Milestone:		Status	Fixed

Details by Christopher Bazley (288):

The first time that a Scrollbar, ScrollList or TextArea gadget is created for a client task, the TextGadgets module uses Toolbox_RegisterPostFilter to register SWI TextGadgets_Filter to be called before delivering events of type Toolbox_ObjectDeleted for Toolbox objects of Window class. Unfortunately, the code for handling Toolbox_ObjectDeleted events is horribly broken.

It searches the internal arrays of gadgets of each type for any which have a parent object ID which matches the Window that was just deleted. Upon finding such a TextArea or Scrollbar, it copies all the pointers above downwards, but does so in a very stupid and dangerous way ([n] := [2n], [n + 1] := [2n + 1], [n + 2] := [2n + 2], etc.) In fact, this corrupts the array contents from the orphaned gadget upwards:

// Found one! int j; for (j = i; text_area_list[j] != NULL; j++) { // Copy down following gadgets text_area_list[j] = text_area_list[j+i]; }

After having corrupted the contents of the array of pointers, the memory block containing it is expanded to a silly size instead of being shrunk, because the wrong type specifier is used with the ‘sizeof’ operator:

new_list = realloc(text_area_list, sizeof(PrivateTextArea) * (remaining + 1));

(The actual type of ‘text_area_list’ is ‘PrivateTextArea **’ and not ‘PrivateTextArea *’.)

I believe that SWI TextGadgets_Filter is never called for Toolbox_ObjectDeleted events because Toolbox module’s post-filter dispatcher is unable to determine the class of an object referenced in a Toolbox event if that object ID is no longer valid (as in this case). Therefore it uses 0 as the class ID, which mismatches the class ID specified in the TextGadgets module’s array of event interests.