I've been advocating for help getting this issue fixed in different forums for a while and thought I might try here. The short problem definition is that the amazing Hollywood application called Pixy crashed on the X5000, I personally have an AmigaOne XE where it runs just fine. I've asked 6 or 7 different X5000 owners and they all report the same issue, The SAM and X1000 owners have also reported no issues. There are a few other MUIRoyale based Hollywood apps that have the exact same problem so it is not just Pixy and it is easy to reproduce.
This particular problem is interesting as you have so many different tools at play it is easy for one author to pass it off as a problem outside the scope of their program.
I hope a solid Amiga dev with an X5000 is willing to take this on. The steps would be pretty simple, download the latest codesets, source code here, grab Pixy from the link above, and try it.
I am confident this person would see a DSI with a similar stack trace:
- Stack trace:
- native kernel module newlib.library.kmod+0x00034bc4
- LIBS:codesets.library:LIB_CodesetsConvertStrA()+0x178 (section 1 @ 0x85FC)
- module SYS:Storage/Hollywood/hollywood.RDNZNC/MUIRoyale.hwp at 0x7BF48F74 (section 0 @ 0x9F50)
- module SYS:Storage/Hollywood/hollywood.RDNZNC/MUIRoyale.hwp at 0x7BF5E280 (section 0 @ 0x1F25C)
- module SYS:Storage/Hollywood/hollywood.RDNZNC/MUIRoyale.hwp at 0x7BF60244 (section 0 @ 0x21220)
- module SYS:Storage/Hollywood/hollywood.RDNZNC/MUIRoyale.hwp at 0x7BF611EC (section 0 @ 0x221C8)
- module SYS:Storage/Hollywood/hollywood.RDNZNC/MUIRoyale.hwp at 0x7BF63430 (section 0 @ 0x2440C)
- module SYS:Storage/Hollywood/hollywood.RDNZNC/MUIRoyale.hwp at 0x7BF583D0 (section 0 @ 0x193AC)
- module SYS:Storage/Hollywood/hollywood.RDNZNC/MUIRoyale.hwp at 0x7BF485B4 (section 0 @ 0x9590)
- module SYS:Storage/Hollywood/hollywood.RDNZNC/MUIRoyale.hwp at 0x7BF4E9F8 (section 0 @ 0xF9D4)
- module Pixy at 0x7B776830 (section 0 @ 0x10680C)
- module Pixy at 0x7B77D838 (section 0 @ 0x10D814)
- module Pixy at 0x7B776F20 (section 0 @ 0x106EFC)
- module Pixy at 0x7B773C68 (section 0 @ 0x103C44)
- module Pixy at 0x7B775E30 (section 0 @ 0x105E0C)
- module Pixy at 0x7B775F1C (section 0 @ 0x105EF8)
- module Pixy at 0x7B773958 (section 0 @ 0x103934)
- module Pixy at 0x7B691E0C (section 0 @ 0x21DE8)
- module Pixy at 0x7B7FFE3C (section 0 @ 0x18FE18)
- module Pixy at 0x7B678C68 (section 0 @ 0x8C44)
- module Pixy at 0x7B7FA008 (section 0 @ 0x189FE4)
- module Pixy at 0x7B8B2174 (section 0 @ 0x242150)
- module Pixy at 0x7B8B4CBC (section 0 @ 0x244C98)
- 0x61727400 symbol not available
Then I think the next logical step would be to build the debug version of the codesets library with to see exactly what part of LIB_CodesetsConvertStrA is failing. Once that is known an issue could be raised on the github page to see if one of the team could address it.
Thanks for reading!
Bill "tekmage" Borsari
If I hazard a guess it would be a corrupted string. It goes from LIB_CodesetsConvertStrA() into a newlib call. Decoding the newlib call is the hardest. Would help if there was a debug build.
Are you able to compile with Clib2? That at least gives function names. At least with my stuff. Provided I give -gstabs I see both source file, line and function.
Also, can you post the GPR dump and ASM listing? That usuallly tells exactly why it crashed. Usually a bad address can be easy to spot at times.
Here is the rest of the crash log minus the machine data and libs:
The interesting thing about the problem is that only happens on the X5000. It will be exciting to see the exact issue so folks can noodle through why it's happening and why only on one platform.