Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#319 closed bug (fixed)

Bug with current nightly MUI with afaos running

Reported by: anonymous Owned by: Thore Böckelmann
Priority: normal Milestone: 5.0-2017R1
Component: build environment Version: 5.0-nightly build
Severity: minor Keywords:
Cc: Tomek, Jens Maus OS Platform: AmigaOS3
Blocked By: Blocking:
Release Notes:

Description

Summary

With current MUI5 I have found 2 bugs. They only appear when afaos is running.
First is in scout as in the picture https://drive.google.com/open
Second in MiamiDX when I click on "socks options" I have reboot.

Steps to reproduce

1.Run scout then click on "libraries" button to show some text corruption.
2.Run MiamiDX then click on "socks" → reboot

Expected results

All works before, no text corruption in scour or rebbot with MiamiDX.

Actual results

Text corruption in scout, reboot with MiamiDx socks

Regression

previous version works

Notes

Attachments (2)

bug_in_mui.png (380.1 KB) - added by Thore Böckelmann 2 years ago.
Screenshot showing issues
MUI-5.0-20170106r5636-os3.lha (3.4 MB) - added by Thore Böckelmann 2 years ago.
build with old inlines for graphics.library

Change History (21)

comment:1 Changed 2 years ago by Thore Böckelmann

First of all, please refrain from using external file hosters. The files are going to vanish at some point in time and are no longer available for reference.

I think the issues are caused by Jens' recent switch to a new m68k cross compiler. We really need to check out what exactly is causing the observed bugs.

Finally, if you are referring to a previous version you should state the exact version, i.e. SVN revision, build date, etc. Simply talking about the previous version is going to end up us checking the wrong version as soon as there are further builds. Nobody will be able to tell which version exactly you are referring to.

Changed 2 years ago by Thore Böckelmann

Attachment: bug_in_mui.png added

Screenshot showing issues

comment:2 Changed 2 years ago by Thore Böckelmann

Oh, I almost forgot. Although it is possible to report bugs anonymously it would be much better if you create yourself an account here and log in before you create new tickets or comment on existing ones.

It is really important for us to know about possible bugs, but without the possibility to ask you further questions about the bugs fixing might become quite hard or even impossible.

comment:3 Changed 2 years ago by Tomek

Even with current MUI-5.0-20161217r5593-os3.lha the bug is still present.

comment:4 Changed 2 years ago by Thore Böckelmann

Cc: Tomek added

I really don't know how to reproduce these two issues myself.

I have AfAOS running for a very long time by now but never experienced any graphical corruption in NList by it until now.

I even tried MiamiDx myself but there are no freezes. Is there anything special to set up there to cause the freeze? I just did a basic installation including the MUI GUI toolkit. Since I use WinUAE I just deactivated WinUAE's internal bsdsocket.library emulation to be able to run MiamiDx at all. But because of this I have no network boards/connections. But to sum it up: the SOCKS page works like all other pages in MiamiDx.

comment:5 Changed 2 years ago by Tomek

It is nothing related to bsdsocket.library for sure. I have also crash with simplecat when I try to import locale. If you wish I could compres hdf image and send you to email including my winuae config and custom rom. Maybe you found something whats cause that strange behavior. So how about that ?

comment:6 in reply to:  5 Changed 2 years ago by Thore Böckelmann

Replying to Tomek:

It is nothing related to bsdsocket.library for sure. I have also crash with simplecat when I try to import locale. If you wish I could compres hdf image and send you to email including my winuae config and custom rom. Maybe you found something whats cause that strange behavior. So how about that ?

Just go ahead.

I just tried SimpleCat myself and imported a .cd and a .ct file without any problems. And SimpleCat does not use NList, so that class is out of scope here.

comment:7 Changed 2 years ago by Tomek

I send you email with link to me google drive. There is also description and steps to reproduce the bug.

comment:8 Changed 2 years ago by Thore Böckelmann

Ok, it took me some time to get that configuration running, but here are the first things I noticed:

  • the system is SLOW. Is that because it emulates a Blizzard1260 plus Picasso4?
  • NList definitely screws up its title, but this is no bug of NList. Even MUI's background selection is not able to show all possible backgrounds correctly. Most important the simple patterns are all screwed up, except one. This explains why NList's title is screwed up, because no background is really drawn before the title text is drawn. But I have absolutely no idea why such a basic feature of graphics.library is not working anymore with AfAOS. Have you asked Bernd Roesch about this already? Could this be related to your patched custom ROM? I am using a plain OS3.1 ROM and let SetPatch do all the dirty work.

comment:9 Changed 2 years ago by Tomek

No I didnt speak with Bernd because he abandoned this project. I tested with original kick 3.1 with Amiga ROM Update from boingbag 2 . Still the same like with custom kickstart rom.

comment:10 Changed 2 years ago by Tomek

Not picasso IV but "UAE ZorroIII" board. I have intel i7 cpu so not so slow for me.

comment:11 Changed 2 years ago by Thore Böckelmann

Component: undefinedbuild environment
Owner: set to Thore Böckelmann
Priority: undecidednormal
Status: newassigned

After some investigation I found that this is an issue with our cross compiler. We recently switched to a different build to be able to build AmiSSL correctly for AmigaOS3. While AmiSSL works perfectly MUI and YAM produce graphical garbage since then. I do my own private builds with the previous compiler version and with that one everything is ok, no graphical glitches or whatsoever.

Please give us some time to sort our this compiler issue.

comment:12 Changed 2 years ago by Thore Böckelmann

Cc: Jens Maus added

I did some extensive tests regarding code generation with the old and the new cross compiler suite. I noticed that with the new cross compiler suite certain calls of functions of graphics.library do get their parameters passed in a slightly different fashion than with the old suite.

This difference is caused by the updated inline header files of the new suite. Although these updated inlines define the function parameters in exactly the same way as the corresponding function prototypes this causes i.e. a UBYTE value to be moved to the appropriate 68k register by a move.b (8 bits) instruction. The old inlines however use LONG/ULONG types for certain parameter even if the function prototype uses BYTE/UBYTE. This lets the compiler emit a move.l (32 bits) instruction instead. The difference might be small, but the effect might cause arbitrary havoc.

Let me explain why. Although the functions do take an 8 bit parameter only it might be possible that graphics.library does access the full 32 bits of a register containing the parameter value, or at least 16 bits. Setting up the parameter registers with full 32 bits ensures that not just the 8 bits according to the documentation are initialized but even the possibly unused upper 24 bits. Doing a simple 8 bit setup might be faster, but it will leave the upper 24 bits in and undefined state. And this is what is causing all the trouble when these additional bits with undefined contents are considered being zero.

I have built a new release with the old inline file for graphics.library. Please try this one and report back whether it fixes the text corruption or not. I cannot guarantee the the SOCKS page of MiamiDx will be positively affected, but I hope that at least all graphic related glitches will be fixed.

Changed 2 years ago by Thore Böckelmann

build with old inlines for graphics.library

comment:13 Changed 2 years ago by Tomek

Yeehaw! Yes this one works. All issues has been resolved. Thanks.

comment:14 Changed 2 years ago by Thore Böckelmann

Resolution: fixed
Status: assignedclosed

In 5637:

  • include/inline/graphics.h: added the GCC inline header file from the previous tool chain. This one uses correct 32bit parameter types for certain functions. This closes #319 and refs #325.

comment:15 Changed 2 years ago by Thore Böckelmann

Milestone: future release5.0-2017R1

comment:16 Changed 2 years ago by Thore Böckelmann

Please continue to check whether the next few nightly builds work as intended, too.

comment:17 Changed 2 years ago by Thore Böckelmann

In 5639:

  • include/inline/graphics.h: removed the local copy again, because the tool chain of our build system now consists of a properly fixed version. This refs #319 and refs #325.

comment:18 Changed 2 years ago by Thore Böckelmann

Can anybody please confirm whether the current nightly builds are working or not?

comment:19 Changed 2 years ago by Tomek

Current "MUI-5.0-20170110r5641-os3.lha" works as expected. Thank you very much.

Note: See TracTickets for help on using tickets.