Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
19 user(s) are online (11 user(s) are browsing Forums)

Members: 0
Guests: 19

more...

Support us!

Headlines

 
  Register To Post  

(1) 2 »
Strange crash with ARexx and RexxReqTools on Amiga OS4
Just popping in
Just popping in


See User information
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):
/*
$VER: impsend.rexx 1.0
 */
addlib('rexxreqtools.library',0,-30,0)

string rtgetstring('Hello' ,'Test''Title''Okay|Okay & Send|Cancel')

say string
exit


IMPwttr.rexx (calling impsend):
/*
$VER: IMPwttr.rexx 1.0
*/

call pragma('w','NULL')
call impsend.rexx()


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
call pragma('w','NULL')

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

Go to top
Re: Strange crash with ARexx and RexxReqTools on Amiga OS4
Just can't stay away
Just can't stay away


See User information
@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

Go to top
Re: Strange crash with ARexx and RexxReqTools on Amiga OS4
Just popping in
Just popping in


See User information
@nbache

Yes, this makes a difference.

CALL PRAGMA('w')

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


Edited by FlynnTheAvatar on 2024/11/30 17:53:04
Reason: Added information
Go to top
Re: Strange crash with ARexx and RexxReqTools on Amiga OS4
Just can't stay away
Just can't stay away


See User information
@FlynnTheAvatar

Quote:
Update:
No, it is not.
Calling PRAGMA('W') without second parameters is (re-)enabling DOS requesters.
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

Go to top
Re: Strange crash with ARexx and RexxReqTools on Amiga OS4
Just popping in
Just popping in


See User information
@FlynnTheAvatar

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

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.

Go to top
Re: Strange crash with ARexx and RexxReqTools on Amiga OS4
Just popping in
Just popping in


See User information
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

Go to top
Re: Strange crash with ARexx and RexxReqTools on Amiga OS4
Just can't stay away
Just can't stay away


See User information
@FlynnTheAvatar
Quote:
Is there is way to extract the exact location of the failing code in the 68k library from the GrimReaper?
Should be in the stack trace and disassembly of GrimReaper, it supports emulated m68k code as well.

Go to top
Re: Strange crash with ARexx and RexxReqTools on Amiga OS4
Just popping in
Just popping in


See User information
@joerg:

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

And this seems to be the issue:

68k disassembly:
 
650df776206b0062             movea.l           0x62(a3),a0
 650df77a
4a88                 tst.l             a0
 650df77c
671a                 beq.b             0x650df798
*650df77e24680056             movea.l           0x56(a0),a2
 650df782
4a8a                 tst.l             a2


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

Arexx fault or ReqTools?

Go to top
Re: Strange crash with ARexx and RexxReqTools on Amiga OS4
Just can't stay away
Just can't stay away


See User information
@FlynnTheAvatar
Quote:
Arexx fault or ReqTools?
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.


Edited by joerg on 2024/12/1 16:14:55
Go to top
Re: Strange crash with ARexx and RexxReqTools on Amiga OS4
Just popping in
Just popping in


See User information
@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.

Go to top
Re: Strange crash with ARexx and RexxReqTools on Amiga OS4
Just popping in
Just popping in


See User information
Okay, this is C code:

if (!glob->prwin || !glob->prwin->UserPort
         
|| (glob->prwin->UserPort->mp_SigTask != ThisProcess()))


I tried to rewrite it as
if ((ULONGglob->prwin <= || !glob->prwin->UserPort
         
|| (glob->prwin->UserPort->mp_SigTask != ThisProcess()))


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?

Go to top
Re: Strange crash with ARexx and RexxReqTools on Amiga OS4
Not too shy to talk
Not too shy to talk


See User information
@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.


Edited by Hypex on 2024/12/3 12:27:41
Go to top
Re: Strange crash with ARexx and RexxReqTools on Amiga OS4
Not too shy to talk
Not too shy to talk


See User information
@joerg

Quote:
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.


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.

Go to top
Re: Strange crash with ARexx and RexxReqTools on Amiga OS4
Just popping in
Just popping in


See User information
@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.

Go to top
Re: Strange crash with ARexx and RexxReqTools on Amiga OS4
Just can't stay away
Just can't stay away


See User information
@FlynnTheAvatar
Quote:
I tried to rewrite it as
if ((ULONGglob->prwin <= || !glob->prwin->UserPort
         
|| (glob->prwin->UserPort->mp_SigTask != ThisProcess()))
An unsigned integer (ULONG, uint32, etc.) can't be < 0, only signed integers (LONG, int32, etc.) can.
Try
if ((LONGglob->prwin <= || !glob->prwin->UserPort
         
|| (glob->prwin->UserPort->mp_SigTask != ThisProcess()))

Go to top
Re: Strange crash with ARexx and RexxReqTools on Amiga OS4
Just popping in
Just popping in


See User information
Duh, rookie mistake. Now it works. Thank you, joerg.

Go to top
Re: Strange crash with ARexx and RexxReqTools on Amiga OS4
Not too shy to talk
Not too shy to talk


See User information
@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

Go to top
Re: Strange crash with ARexx and RexxReqTools on Amiga OS4
Just popping in
Just popping in


See User information
@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.

Go to top
Re: Strange crash with ARexx and RexxReqTools on Amiga OS4
Not too shy to talk
Not too shy to talk


See User information
@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

Go to top
Re: Strange crash with ARexx and RexxReqTools on Amiga OS4
Just popping in
Just popping in


See User information
@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.

Go to top

  Register To Post
(1) 2 »

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2024 The XOOPS Project