RTSupport
Chris Hall (132) 3554 posts |
If I load a draw file containing a particular sprite into ArtWorks I get an error ‘abort on data transfer at xxxx’ where xxxx is at offset &1438 in module RTSupport (same offset in both Titanium and ARMX6). What is RTSupport? The file loads into Impression, !Draw and PhotoDesk OK |
Jeffrey Lee (213) 6048 posts |
https://www.riscosopen.org/wiki/documentation/show/RTSupport%20Module%20API%20Specification It’s quite possibly a SWI returning a duff error pointer and causing RTSupport’s Service_Error handler to explode. I should probably check in that code I have for trapping bad error pointers… |
Chris Hall (132) 3554 posts |
Many thanks for the explanation. Now all I have to do is to work out why ArtWorks doesn’t like that RO3.5 16M colour sprite… |
Jon Abbott (1421) 2651 posts |
I’m seeing ZeroPain reports from RTSupport as well and have tracked it down to “((_kernel_oserror *)(r→r [0 ]))→errnum” in module_ServiceHandler trying to read from &0 And it looks like the duff error pointer may be originating from within BASIC. EDIT: I’ve attempted to trap Service_Error at the SWI handler before it’s issued, but I’m not seeing the SWI. Could the null pointer be originating from the Kernel? EDIT2: ErrHandler in Kernel,v also tries to copy an error string from Page Zero. |
Chris Hall (132) 3554 posts |
If I load a draw file containing a particular sprite into ArtWorks I get an error ‘abort on data transfer at xxxx’ where xxxx is at offset &1438 in module RTSupport (same offset in both Titanium and ARMX6). Mea culpa. The particular Draw file included a transformed sprite where the sprite length was 16 bytes shorter than the draw object length allowed for, i.e. the sprite contained 16 bytes extra at the end. Some software would look for the next object based on the draw file object length (and therefore work) whereas other used the end of sprite (which should be the same but wasn’t here due to my own mistake). |