Strange crash with ARexx and RexxReqTools on Amiga OS4

Hi,

I get a strange DSI when calling a rexx script that calls another rexx script that uses RexxReqTools.

Minimal testcase:

IMPsend.rexx (opening requester):


IMPwttr.rexx (calling impsend):


Calling IMPSend.rexx directly does not cause any issue.

GrimReaper:
Guru Meditiation: 8000 0003
Task: 0x646fcaa0 ('ARexx')
verursachte einen Fehler des Typs DSI (Data Storage Interrup)
an Adresse 0x01824ae0
'Rote Zone' des Stacks wude nicht beschädigt
Stackpointer ist innerhalb der Grenze

It crashes somewhere in the reqtools.library.

If I remove the line

it no longer crashes.

Anybody has any idea why the pragma call is causing issues?

Versions:
68k:
rexxreqtools.library 37.95 (16.08.1994)
68k with PPC glue code:
reqtools.library 39.3 (15.11.2001)


Thank you,
Flynn

@FlynnTheAvatar

Have you tried removing the null second argument to PRAGMA? It is optional when using option W.

Might be interesting to see if it makes a difference.

Best regards,

Niels

@nbache

Yes, this makes a difference.


does not crash.

Is this really the same as PRAGMA('W','N') or PRAGMA('W','NULL')?

Update:
No, it is not.
Calling PRAGMA('W') without second parameters is (re-)enabling DOS requesters.

Thanks,
Flynn

@FlynnTheAvatar

Quote:Oh, you wanted to suppress requesters? Right, in that case, it looks like you do need PRAGMA('W', 'N'). I read the following in ARexxGuide.guide, which is usually quite accurate (but of course it could be wrong):

Window [{'N'| 'W'}] Controls the display of system requesters
(like 'Please insert volume...'). If the 'N'
or 'Null' option is used, the requesters won't
appear at all. The 'W' or 'Workbench' option is
the default. It causes the requesters to be
displayed on the Workbench screen and can also
be called by using PRAGMA('W') without a second
option.

So if that crashes, I'm not sure what is happening.


Best regards,

Niels

@FlynnTheAvatar

Quote:
PRAGMA('W','N') would appear to set the pr_WindowPtr field in the Process struct for ARexx to -1, which is how you tell DOS to not put up any requesters for your program. pr_WindowPtr normally points to a window whose screen DOS should open its requesters on, or is NULL if it should use the Workbench screen.

It looks like something in either reqtools.library or rexxreqtools.library doesn't check for a pr_WindowPtr of -1 and attempts to use it as the address of a window, which of course causes a crash. Perhaps reqtools is trying to open the requester on the same screen that DOS would use, and doesn't check for the special "don't open any requesters" value.

The strange thing is that the requester opens if I ignore the DSI. Also, calling impsend.rexx directly from the shell works regardless if CALL PRAGMA('W', 'N') is used or not in impsend.rexx.

Is there is way to extract the exact location of the failing code in the 68k library from the GrimReaper? So far I could not compile reqtools.library 39.3 (AROS backport). But I could use IRA to disassemble the library to see it does, but without the location of the failing code it does not help me much.

Thanks,
Flynn

@FlynnTheAvatar
Quote:Should be in the stack trace and disassembly of GrimReaper, it supports emulated m68k code as well.

@joerg:

Thank you, found the 68k disassembly in GrimReaper's report.

And this seems to be the issue:



The code tests if a0 is properly set. But Arexx sets the WindowPtr to -1 instead of 0.

Arexx fault or ReqTools?

@FlynnTheAvatar
Quote:If it's checking struct Process pr_WindowPtr it's ReqTools fault.
Possible values for pr_WindowPtr, check for example https://wiki.amigaos.net/wiki/AmigaDOS_Data_Structures :
1. A pointer to a window. The requester is opened on the same screen on which this window is.
2. NULL: The requester is opened on the default public screen (usually Workbench).
3. -1/~0/0xFFFFFFFF: DOS requesters are disabled. If I understand the m68k assembly code from GrimReaper correctly, I never did any m68k asm programming and might be wrong, the code fails to check for that case and tries to access 0xFFFFFFFF+0x56=0x55 which causes the invalid data access (zero page) DSI.

If I'm right the DAR (on most PPC CPUs, on 405/44x/46x CPUs it has a different name) of the crash should be 0x00000055.

@joerg

Yes, read the Assembler code correctly. Thank you very much for the detailed explaination. I patched the library with a hex editor and changed the beq.s to a ble.s (less or equals). This seems to fix the crash.

Still trying to identify the corresponding C code to do a proper fix and create a pull request in the AROS repo.

Okay, this is C code:



I tried to rewrite it as


but the generated assembler code still uses a simple null check (tst.l a0, beq.s) ignoring the less than 0 condition.

Any ideas how to force GCC 3.3 to check for -1?

@FlynnTheAvatar

It looks like you got the call stack you needed. For 68K it's recommended to disable Petunia (from Kicklayout) or blacklist the app in Compatibility Prefs. They really haven't sorted this out. You can't disable JIT emulator without modding your Kicklayout. And blacklisted apps don't have inheritance so child processes still have JIT.

Disabling JIT is recommended as in a lot of cases you don't see the actual code but the the ends of the JIT cache or something.

@joerg

Quote:

That looks right but you cannot trust the DAR. Anything Reaper spews out about a DAR is corrupt for ten years or more. IIRC it's correct on the serial log.

@Hypex

Thank you for your input. I already blacklisted the reqtools.library so I got the correct piece of code in the stack trace.

And it is a coding issue, as the code does not check if the WindowPtr is -1, it only checks for null.

The remaining issue is that I cannot convince the C compiler (gcc 3.3 classic) to generate the correct assembler code. I do not run the code, I disassemble the generated object file with IRA to check the assembler code.

@FlynnTheAvatar
Quote:An unsigned integer (ULONG, uint32, etc.) can't be < 0, only signed integers (LONG, int32, etc.) can.
Try

Duh, rookie mistake. Now it works. Thank you, joerg.

@FlynnTheAvatar

Hi,

I was just wondering...

It looked like you were just creating a simple string requester.
Were you trying to do more then that?

Were just that, why not simply use the c:requeststring and avoid
the pitfalls of relying on a 3rd party library?

Curious,

PJS

@pjs

No, I am not trying anything ;)

Some very talented AREXX coder from the German IMP3 chat created very nice scripts to automatically insert text from webservice (weather information) to system information and away messages.

I just investigated why sometimes the scripts crash on Amiga OS4 and at least for one other 3.2.2 user.

And it is a bit more than displaying one string. And it should also work on 3.x.

@FlynnTheAvatar

ah, OK. Trying to make an ARexx script that will work in both
OS4 and OS3? An interesting challenge...

I just don't recall if there was anything like the OS4
requestchoice/requeststring/requestfile commands in the end
on OS3. Maybe they backported them in OS3.2 ??

If they were available, that would simplify things - to just
use a simple command line command to do what you want on both
systems.

Otherwise, you could check the system version at you script
start and then use whatever method best suited the system your
script was running on.

Well, good luck with your hacking!

PJS

@FlynnTheAvatar

Checking for a value less than zero will reject any address where the MSb is set, and not just -1. Strictly speaking, only the value -1 is reserved; other values with the MSb set might be legitimate addresses.

In practice, I think OS4 reserves addresses in the upper 2 GB range for uses other than general purpose RAM, so pr_WindowPtr will never actually point there. Still, while checking for a value less than zero is fine for a patch to an existing binary, if you're modifying the source why not do it right and only reject NULL and -1? That way you're not depending on something that might change some day.