Ticket #279 (Fixed)Tue Mar 22 12:49:50 UTC 2011

http://www.freelists.org/post/iyonix-support/Re…

This isn’t a fault in ‘Repeat’ per se, though as noted in the Iyonix mailing list replies it is documented that you must use the -tasks switch in this situation, and that that resolves the problem. However, that it crashes is rather ungraceful.

It can in fact also work if the applications that are being Filer_Boot’d don’t themselves contain !Boot files. Looking at the code paths within the Filer show that when there is a boot obey file present this is launched with *WIMPTASK and the Obey module becomes the current application.

This is a problem because when ‘Repeat’ launched the original Filer_Boot command it used system() which shells out of the original C program by copying up to the top of application space. But *WIMPTASK (in starting a new application) pages out the current application. When the obey file completes the non shelled part of ‘Repeat’ is jumped into – and the desktop hangs.

A far simpler test case for this (eliminating ‘Repeat’ altogether) is

#include <stdlib.h>
int main(void)
{
system(“WIMPTASK Obey $.empty_obey_file”);
return 0;
}

There’s also a subtle difference that if the test program calls the Wimp_StartTask SWI directly then it gets a polite error message back saying that’s not possible from a single tasking context. The difference with the *WIMPTASK command is it will start up a dummy task for you to run the command if called from a single tasking context.

Should be fixed by Wimp 5.39. The problem was being caused by some code in Wimp_Initialise which tries to detect if application space is in use, so that tasks which aren’t using application space can have their wimpslot set to 0KB. Although the code was checking the CAO and issuing a call to Service_Memory, it wasn’t checking for if the memory limit had been artificially restricted by OS_ChangeEnvironment (which is the mechanism which system() uses to prevent the parent program from being overwritten by the child). Usually the CAO check will catch this kind of situation, except for the case where *WimpTask is issued from a single-tasking program – in which case the Wimp uses OS_Module to re-enter itself as an application so that it can create a temporary Wimp task to spawn the child from. But the act of re-entering itself causes the CAO to be reset to the Wimp module, allowing the CAO check in Wimp_Initialise to pass and the Wimp to conclude that application space isn’t being used, resulting in the parent program (and in some cases the command string to be passed to Wimp_StartTask) being nuked.

https://www.riscosopen.org/viewer/revisions/log…