Skip to content

GitLab

Commit 2fb1a8bf authored by Jeffrey Lee's avatar Jeffrey Lee
Browse files

Fix crashes when a Wimp_Poll post-filter causes the Wimp to postpone switching... 

Fix crashes when a Wimp_Poll post-filter causes the Wimp to postpone switching to a VFP-enabled task

Detail:
  s/Wimp07 - In ExitPoll, swap around the order of restoring the FP context and calling the poll post-filter so that the FP context is restored after the post-poll filter has been invoked. Previously, the VFP(+FPA) context would be restored, then the post-poll filter would be invoked. If the post-poll filter was claimed, the Wimp would then scan the pollwords again and most likely decide to switch to a different task. The appslot will then be switched over, and ExitPoll will be invoked again, attempting to restore the VFP/FPA context for that task - potentially causing a crash or other bad things because the VFP context used by the original choice of task is no longer paged in. For FPA this was never really a problem, since the context is stored in the RMA rather than being potentially stored in appspace.
  s/Wimp03 - Add some extra debug out for tracking VFP context management
Admin:
  Tested on wandboard
  Fixes issue reported on forums, where using the numpad in VFP SciCalc would cause a crash if KeyExtend was loaded:
  https://www.riscosopen.org/forum/forums/4/topics/10293


Version 5.60. Tagged as 'Wimp-5_60'
parent 74a6db0a
Hide whitespace changes
Inline Side-by-side
Showing with 65 additions and 60 deletions
VersionASM
View file @ 2fb1a8bf
......@@ -11,13 +11,13 @@
GBLS Module_HelpVersion
GBLS Module_ComponentName
GBLS Module_ComponentPath
Module_MajorVersion SETS "5.59"
Module_Version SETA 559
Module_MajorVersion SETS "5.60"
Module_Version SETA 560
Module_MinorVersion SETS ""
Module_Date SETS "24 Jul 2017"
Module_ApplicationDate SETS "24-Jul-17"
Module_Date SETS "17 Feb 2018"
Module_ApplicationDate SETS "17-Feb-18"
Module_ComponentName SETS "Wimp"
Module_ComponentPath SETS "castle/RiscOS/Sources/Desktop/Wimp"
Module_FullVersion SETS "5.59"
Module_HelpVersion SETS "5.59 (24 Jul 2017)"
Module_FullVersion SETS "5.60"
Module_HelpVersion SETS "5.60 (17 Feb 2018)"
END
VersionNum
View file @ 2fb1a8bf
/* (5.59)
/* (5.60)
*
* This file is automatically maintained by srccommit, do not edit manually.
* Last processed by srccommit version: 1.1.
*
*/
#define Module_MajorVersion_CMHG 5.59
#define Module_MajorVersion_CMHG 5.60
#define Module_MinorVersion_CMHG
#define Module_Date_CMHG 24 Jul 2017
#define Module_Date_CMHG 17 Feb 2018
#define Module_MajorVersion "5.59"
#define Module_Version 559
#define Module_MajorVersion "5.60"
#define Module_Version 560
#define Module_MinorVersion ""
#define Module_Date "24 Jul 2017"
#define Module_Date "17 Feb 2018"
#define Module_ApplicationDate "24-Jul-17"
#define Module_ApplicationDate "17-Feb-18"
#define Module_ComponentName "Wimp"
#define Module_ComponentPath "castle/RiscOS/Sources/Desktop/Wimp"
#define Module_FullVersion "5.59"
#define Module_HelpVersion "5.59 (24 Jul 2017)"
#define Module_LibraryVersionInfo "5:59"
#define Module_FullVersion "5.60"
#define Module_HelpVersion "5.60 (17 Feb 2018)"
#define Module_LibraryVersionInfo "5:60"
s/Wimp03
View file @ 2fb1a8bf
......@@ -443,6 +443,7 @@ SWIWimp_Poll
MOV R1,#VFPSupport_ChangeContext_Lazy+VFPSupport_ChangeContext_AppSpace
SWI XVFPSupport_ChangeContext
MOVVS R0,#0 ; Ignore error (probably means VFPSupport isn't loaded)
Debug fp,"VFP on Wimp_Poll entry",R0
STR R0,[R4,#task_vfpcontext]
CLRV
;
......
s/Wimp07
View file @ 2fb1a8bf
......@@ -754,6 +754,7 @@ SWIWimp_StartTask
MOV R1,#VFPSupport_ChangeContext_Lazy+VFPSupport_ChangeContext_AppSpace
SWI XVFPSupport_ChangeContext
MOVVS R0,#0 ; Ignore error (probably means VFPSupport isn't loaded)
Debug fp,"VFP on Wimp_StartTask entry",R0
STR R0,[R4,#task_vfpcontext]
Pull "R0-R1"
;
......@@ -1084,6 +1085,52 @@ returnerror
01
]
;
[ StartTaskPostFilter
LDR R14,sender
CMP R14,#-1
BLT %FT01 ; Are we starting up Wimp_StartTask?
BNE %FT02 ; Are we returning from Wimp_StartTask?
; We're returning from Wimp_StartTask and
; R0 = task handle of child (or 0). Wimps before 3.96
; would not call the post-filter in this case, but would
; call it if Wimp_StartTask returned 0 (so the filter
; would think a null event was happening.) Now, the
; Toolbox (and probably other filters) relies on the
; post filter to monitor the current task. If the postfilter
; doesn't get called here then there is no way of telling
; that this task has become active. So, we now call the filter
; with a null event, and ignore any attempt to claim it. (In
; the past the filter was able to claim the "null" event if
; Wimp_StartTask returned 0, causing instant death.
; This is the problem that hit Toolbox 1.33).
;
; Hopefully this shouldn't cause any problems, as filters
; will have had to be able to deal with the dummy "null"
; event for at least some Wimp_StartTask calls already.
Push "R0,R1"
MOV R0,#No_Reason
MOV R1,userblk
CallFilter postfilter ; call the post-poll filter (ignoring
Pull "R0,R1" ; R0 return)
B %FT01
02
|
CMP R0,#max_reason ; Valid message?
BHS %FT01 ; No then jump,maybe -> *command from Wimp_StartTask
]
Push "R1"
MOV R1,userblk
CallFilter postfilter ; call the post-poll filter
Pull "R1"
CMP R0,#-1
BEQ repollwimp ; if it claimed then just re-poll
01
Push "R0-R1"
LDR R4,[wsptr,handle]
TEQ R4,#task_unused
......@@ -1138,53 +1185,10 @@ returnerror
LDRNE R0,[R4,#task_vfpcontext]
MOVNE R1,#VFPSupport_ChangeContext_Lazy
TEQNE R0,#0 ; We should already be on the null context, so only call if user does have a context to restore
DebugIf NE,fp,"VFP on Wimp_Poll exit",R0
SWINE XVFPSupport_ChangeContext
Pull "R0-R1"
;
[ StartTaskPostFilter
LDR R14,sender
CMP R14,#-1
BLT %FT01 ; Are we starting up Wimp_StartTask?
BNE %FT02 ; Are we returning from Wimp_StartTask?
; We're returning from Wimp_StartTask and
; R0 = task handle of child (or 0). Wimps before 3.96
; would not call the post-filter in this case, but would
; call it if Wimp_StartTask returned 0 (so the filter
; would think a null event was happening.) Now, the
; Toolbox (and probably other filters) relies on the
; post filter to monitor the current task. If the postfilter
; doesn't get called here then there is no way of telling
; that this task has become active. So, we now call the filter
; with a null event, and ignore any attempt to claim it. (In
; the past the filter was able to claim the "null" event if
; Wimp_StartTask returned 0, causing instant death.
; This is the problem that hit Toolbox 1.33).
;
; Hopefully this shouldn't cause any problems, as filters
; will have had to be able to deal with the dummy "null"
; event for at least some Wimp_StartTask calls already.
Push "R0,R1"
MOV R0,#No_Reason
MOV R1,userblk
CallFilter postfilter ; call the post-poll filter (ignoring
Pull "R0,R1" ; R0 return)
B %FT01
02
|
CMP R0,#max_reason ; Valid message?
BHS %FT01 ; No then jump,maybe -> *command from Wimp_StartTask
]
Push "R1"
MOV R1,userblk
CallFilter postfilter ; call the post-poll filter
Pull "R1"
CMP R0,#-1
BEQ repollwimp ; if it claimed then just re-poll
01
[ AutoHourglass
Push "R0-R2"
LDR R1, hourglass_status
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment