Hi,

It seems there was a recent update to wiki.amigaos.net (AmigaOS4 Documentation Wiki). A lot of pages work, but there are a number of Tutorial pages that throw an internal error:

https://wiki.amigaos.net/wiki/The_Hacking_Way:_Part_1_-_First_Steps
https://wiki.amigaos.net/wiki/The_Right_Tool_for_the_Job_(Shared_Objects)
https://wiki.amigaos.net/wiki/How_to_Build_Stubs_for_68k_Libraries
https://wiki.amigaos.net/wiki/AmiWest_Lesson_1
...

and perhaps a lot of others.

How can I report these broken to the correct person to get the Wiki fixed?

Thanks,
Josef

@amigakit

Thank you!

Version 54.22 no longer has issues with getting its own version string. This also fixes the "not found" issue in Updater.

There should be a newer version of copy:



Does 54.14 work for your use case?

@skynet

It looks that Version 54.21 has sometimes issues getting its own version string:



This seems to be only an issue with the latest version 54.21.

@msteed:

That is a very good point, thank you very much!

I changed the check to the following:

@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.

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

@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.

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?

@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.

@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?

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

@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

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

Hi,

The Amigakit AK-ILBM 54.15 datatype fails to load some ILBM files that are displayed fine with other ILBM datatypes (stock OS4 ILBM 53.1 or OS3 ILBM 53.3). The files also can be loaded into PersonalPaint without any issues.

MCE (https://os4depot.net/share/game/utility/mce.lha) contains three such files:
Images/games/neuromancer.iff
Images/games/nitro.iff
Images/games/rorke.iff

Thanks,
Josef

@amigakit

Thank you for your fast response. Yes, version 54.21 indeed fixes the issue for me.

And I sent you a PM regarding the Amiga.org issue.

Thanks again for your help!

Hi,

Yes, amiga.org might be a better place for the bug report, but I do not get the validations emails from there.

So, my issue is that the latest AmigaKit version no longer sets the local variables for Workbench and Kickstart correctly:



It works correctly with Version 53.7 (Hyperion) and Version 54.15 (AmigaKit):


X5000/20
AmigaOS4.1 FE 2
Enhancer 2.2
Radeon RX 550
8 GB RAM
German locale

Hi @Boabster,

The issue is that if OS 4 crashes, it most likely also kills the USB stack. This means that it does not matters if you have a wired or wireless keyboard; because the stack is dead, no input will be processed.

@elfpipe

If you are using RadeonHD gfx card, you need to downgrade your RadeonHD driver to 3.7. With version 5.x the driver lost its ability to do a warm reboot.

Best regards,
Flynn

@Maijestro

The log file is in ffbuild/config.log.

That is not a standard location, normally it should be in the same directory where you ran configure.