Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#116 closed bug (worksforme)

MUI 3.9 unstable (due to bubble help?!?)

Reported by: supernobby Owned by: Thore Böckelmann
Priority: normal Milestone: 3.9-2015R1
Component: muimaster.library Version: 3.9-2014R3
Severity: minor Keywords:
Cc: OS Platform: AmigaOS3
Blocked By: Blocking:
Release Notes:

Description

Summary

Hello! thanks for updating MUI. But since I installed MUI 3.9 (now 2014R3), MUI applications behave rather unstable, what I did not know from my rather stable working AMIGA 4000 with OS3.9 and MUI 3.8. So sorry for this rather unspecific ticket. But I actually do not know where to start. It crashes so often and one could get the impression, it is somehow related to the bubble help (which now inserts line breaks). But that must not be the real reason, as I have other problems too. So I also can't exclude my system. But since MUI 3.8 does well. I tend to blame MUI 3.9. I hope to find out here, as I am not sure if there are other ways to discuss this.

Steps to reproduce

A) crash in MUI settings → (Rollbalken) → Balken → Knopf → Bubble Help
A1. Open MUI settings
A2. select "Intern" Classes and go to (Rollbalken)
A3. Hover with the mouse pointer over the "Knopf" selector until bubble help appears
A4. repeat this fast several times and the system crashes / freezes somehow

Notes

Other problems are:

  • MUI Window settings page can't be created
  • Luciferin (Flash Tool for E3B USB cards) does not even start and cause system crash
  • in "Scout.os3 → About MUI → show external classes" causes system crash

But all this may relate to the same reason.
Did something change on the stack requirements, that I miss?
Also, what is Phase5.mcc, that MUI tries to load?

Unfortunately, the current nightly build or the current debug version fail to open, that might would help to further investigate.

Attachments (8)

muimaster_no_wpaa.lha (229.5 KB) - added by Thore Böckelmann 4 years ago.
muimaster.library without WritePixelArrayAlpha()
mui_116_2014-12-14.log (5.4 KB) - added by supernobby 4 years ago.
muimaster_big_buffer.lha (231.0 KB) - added by Thore Böckelmann 4 years ago.
muimaster.library with a big buffer for WritePixelArrayAlpha()
mui_116_2015-01-06.log (32.6 KB) - added by supernobby 4 years ago.
mui_116_2015-01-10.log (55.0 KB) - added by supernobby 4 years ago.
mui_116_2015-01-10.JPG (3.5 MB) - added by supernobby 4 years ago.
muimaster_no_alphablend.lha (231.0 KB) - added by Thore Böckelmann 4 years ago.
muimaster.library without alpha blending
MUI-Bubbles-help.avi (3.6 MB) - added by Mikhail Malyshev 4 years ago.
Bubble help ripping drawing…

Change History (59)

comment:1 Changed 49 years ago by supernobby

Status: pendingnew

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

I very much doubt that the bubble help should be causing anything here. But you can disable it to proof that it really makes a difference.

MUI3.9 has been used by lots of AmigaOS4 users without any problems and AmigaOS4 is much more sensitive to programming error which go by unnoticed on AmigaOS3. In general AmigaOS3 usually is very heavily patched, and most of the patches do more harm than good. It is very likely that a patch is causing the issues, not MUI. And even if I must admit that AmigaOS4 has lots of bugs fixed which still are present in AmigaOS3 MUI 3.9 is in use by lots of people by now I am using it myself on AmigaOS3/WinUAE for about 4 years now. I really doubt that there are any severe bugs in MUI 3.9 which occur so easily for you but for nobody else.

The non working Windows page had been reported in #92, but I never got any answer from the reporter. Hence the only solution for me was to close that ticket as "works for me".

Phase5.mcc is nothing that is included with MUI, neither 3.8 nor 3.9. I don't know what it is doing, but I'd say it can be deleted without any negative side effects.

MUI was always a bit more memory hungry than other GUI systems. 32K stack should be sufficient.

Finally, a bug report where you are talking about crashes is absolutely useless without any kind of crash log, Enforcer hits, whatever. So please run the usual debugging tools to catch any kind of invalid memory accesses or to shed some light on the crashes you are experiencing.
And what do you mean by "the current nightly build or the current debug version fail to open"? What fails to open? What is happening at all? You are omitting the important information.

comment:2 Changed 4 years ago by supernobby

Hi!
the bubble help issue could relate to the RTG screen. I use Picasso96 and a Cybervision64. On AGA, this problem seems not present. Also not in UAE, as far as I can say.
However, Luciferin crashes and also the issue with Scout.os3 is present.

I have MuForce and Sashimi running. But the crashes are very destructive. I see no Output, because the AMIGA resets immediately or just freezes or "random" MuForce reports. If I would have better data, I would already have provided it.

The the nighly or debug builds do not work is also now ticket 117. I have the same. MUI applications just report, that they can't open muimaster.library.

When the debug version issue is sorted out, I can then also reopen ticket 92 to help find out, why Windows settings do not work.

But generally, big thanks for still working on this!

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

Scout's "About MUI" dialog is an internal MUI class. Hence if this crashes for Scout it should crash for any other application as well. Just try the "About…" menu item of MUI prefs.

I do all development on WinUAE and have no working real classic machine any more. If things are working here but not on real hardware and nobody is able to provide more valuable information than "it crashes" then I am affraid we will have a hard time to solve this issue.

However, there are subtantial differences regarding bubble help on RTG and colormapped screens. For colormapped screens the old 8bit images will be used while for hi/true color screens new 24bit images with alpha channel will be used. But that's already all of it. The "base" to display the bubble help is the same, just the imagery is different.

Alternatively you can switch the bubble mode to rectangles instead of comic bubbles. That mode is independend of any screen depth as much as possible.

Does Luciferin require the E3B hardware to be present or can it be run without it as well? Where can I download it to check it myself?

comment:4 Changed 4 years ago by Mikhail Malyshev

This is interesting, I have a similar case with ReqAttack prefs MUI.
Under AmiKIT/UAE it seems to be working fine, on my real machine it likes to crash when you do some changes in prefs and press the preview button. Very high chance. One thing odd is imho there is something wrong with RAprefsMUI, since all tools report a negative stack for it's task, so why it works fine under UAE is a big question. Is it MUI related or a bug in the program ?

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

Replying to Michael:

This is interesting, I have a similar case with ReqAttack prefs MUI.
Under AmiKIT/UAE it seems to be working fine, on my real machine it likes to crash when you do some changes in prefs and press the preview button. Very high chance. One thing odd is imho there is something wrong with RAprefsMUI, since all tools report a negative stack for it's task, so why it works fine under UAE is a big question. Is it MUI related or a bug in the program ?

For me RAPrefsMUI tends to crash a lot as well in my WinUAE system. But all the output from Winuaeenforcer points to RAPrefsMUI itself and does not even mention MUI in the stacktrace. For me it looks like a "use after free" error. This means RAPrefsMUI is accessing memory after it has been freed. This has always been a bug, but AmigaOS3 usually is very forgiving in this respect and such accesses go by unnoticed. Additionally MUI 3.8 might have been working differently internally and MUI 3.9 might go a slightly different way now, but this still doesn't make the "use after free" thing better. Contact Jacek Piszczek and ask for an update, although I doubt very much that he will do any AmigaOS3 development. MorphOS is his only focus.

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

Any progress here? The nightly builds are working again.

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

Status: newpending

comment:8 Changed 4 years ago by supernobby

Hello!
The crashes are most likely stack related. Luciferin had 8k. Set to 16k made it start, but "About MUI → show external classes" crashes. Set 32k of stack and also this works.
Similar with Scout.os3. It had 16k stack. Changed to 32k made this work as well.
So I would say, quite some increased stack demand.

Changing bubble help from comic to simple box also makes this problem go away. As the performance is also much better I have no problem staying with this setting. But if you want to investigate the "comic hi/true color" problem, I am happy to help.

comment:9 in reply to:  8 Changed 4 years ago by Thore Böckelmann

Component: undefinedmuimaster.library
Milestone: MUI 3.9-2014R4
Priority: undecidednormal

Replying to supernobby:

So I would say, quite some increased stack demand.

Well, things change and advances GUIs take more memory/stack. It was always said that the default stack size of 8K might be too small for certain MUI applications. Now you get the bill for ignoring this warning. But it is good to hear that the solution was so simple.

Changing bubble help from comic to simple box also makes this problem go away. As the performance is also much better I have no problem staying with this setting. But if you want to investigate the "comic hi/true color" problem, I am happy to help.

I assume that you don't have AfAOS running which provides some functions which are missing in cybergraphics.library. Because of that MUI has to implement a custom version of WritePixelArrayAlpha() to provide correct alpha blending. All my tests showed that this custom implementation works correctly and does not trash memory.

I will attach a version of muimaster.library which simply does nothing in that case. The comic mode bubble help will definitely look bad, but perhaps that reduced version does not cause crashes. That would at least prove or exclude a possible bug in my custom implementation.

Changed 4 years ago by Thore Böckelmann

Attachment: muimaster_no_wpaa.lha added

muimaster.library without WritePixelArrayAlpha()

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

Please note that this version of muimaster.library is based on the current nightly builds. So it would be good to install the current nightly build instead of 2014R3 before trying it to avoid any possible issues due to recent changes.

comment:11 Changed 4 years ago by supernobby

Hi!
yes, I have no AfAOS installed. With the "muimaster.library without WritePixelArrayAlpha()" I get no graphics at all. Comic bubble help has no frame, but also no crash. So WritePixelArrayAlpha() seems to be some kind of problem.

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

Hm, even if I disable AfAOS completely everything is still working perfectly and I get no trashed memory due to the definitely now active custom WPAA().

Did you try to run tools like WipeOut or MungWall already to catch possible memory trashes?

comment:13 Changed 4 years ago by supernobby

Hi!
yes, I tried MuGuardianAngle. It reports something, but also rather random stuff and difficult to capture, because immidiate freeze / crash. Real serial line capture with other computer might help, if you want to see some examples.

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

Any valuable hint is welcome.

Changed 4 years ago by supernobby

Attachment: mui_116_2014-12-14.log added

comment:15 Changed 4 years ago by supernobby

Hello,
I added a log that I captured over serial line. It is made with the current nightly build + debug version. Seems not to produce that random crashes.
What I did was starting MUI prefs as first MUI application, clicked (Scrollbars) and hovered over the "Knob" button and away.
It is just Rear Mung-walls damaged. So probably writing over the end of allocated buffers/arrays. Maybe it helps.

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

Hard to say who is to blame here. The damage might be caused by anybody: MUI, CyberGraphics, anybody else, I don't know.

However, there are sections of the bubble image with a width of 2 pixels which could explain the allocation size of 8 (2 pixels * 32bits = 8 bytes). But then it is CyberGraphics who is causing the buffer overrun by reading too many bytes into the correctly sized buffer.

Unfortunately the log doesn not contain any information about how many bytes have been damaged.

Last edited 4 years ago by Thore Böckelmann (previous) (diff)

Changed 4 years ago by Thore Böckelmann

Attachment: muimaster_big_buffer.lha added

muimaster.library with a big buffer for WritePixelArrayAlpha()

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

Please try the attached "big buffer" version of muimaster.library.

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

In 4296:

  • mastergfx.c: changed the custom WritePixelArrayAlpha() implementation to use a full sized buffer instead of a single line buffer. This refs #116.

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

Owner: set to Thore Böckelmann
Status: newassigned

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

Any news on this issue?

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

Status: assignedpending

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

Resolution: fixed
Status: pendingclosed

Since I didn't get a reply from within 3 weeks I suppose this is fixed now. Otherwise please reopen the ticket.

comment:23 Changed 4 years ago by supernobby

Resolution: fixed
Status: closedreopened

Changed 4 years ago by supernobby

Attachment: mui_116_2015-01-06.log added

comment:24 Changed 4 years ago by supernobby

Hello!
I also tested this again with MUI-3.9-20150106r4377-os3.lha. But, no big change. MuForce/MuGuardianAngle still start to scream when I hover over the "Knop" gadget (which is by the way not editable anymore without license). I add a mui_116_2015-01-06.log which I just captured over serial line.

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

Unfortunately the log does not contain any valuable information except that fact that the real wall was damaged.

What values for PRESIZE and POSTSIZE are using for MuGuardianAngel? Using the DISPC and DUMPWALL options to let MGA output the disassembled code and damaged wall would be helpful as well.

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

Milestone: MUI 3.9-2014R4MUI 3.9-2015R1

Milestone renamed

comment:27 Changed 4 years ago by supernobby

PRESIZE and POSTSIZE have default values (32). I added DISPC and DUMPWALL and the resulting log mui_116_2015-01-10.log is also attached.
With MGA running, the bubble help for the Knop gadget after some time also appears and I can see some graphic corruption around it. I tried to photograph it, so see mui_116_2015-01-10.JPG.

Changed 4 years ago by supernobby

Attachment: mui_116_2015-01-10.log added

Changed 4 years ago by supernobby

Attachment: mui_116_2015-01-10.JPG added

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

I am really running out of ideas. Did you try the "big buffer" version of muimaster.library? Does this make any change?

If my custom WPAA implementation would be causing any memory trashing I should be able to observe this myself. But it only accesses bytes within the allocated memory. Any write access outside that region is correctly detected by WipeOut, which does the same job like MGA. So the only possible culprit is ReadPixelArray() of your cybergraphics.library. And that is beyond my control.

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

Any news here? An answer regarding the "big buffer" version is highly appreciated.

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

Status: reopenedpending

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

Resolution: worksforme
Status: pendingclosed

Since I didn't get a single answer from you within two weeks I suppose you are no longer interested in a fix for this issue. I cannot reproduce this issue myself, hence I cannot fix anything if there should be a bug in MUI. Please reopen this ticket if you have more information to share.

comment:32 Changed 4 years ago by supernobby

Sorry, I have to neglect this a bit due to other things. I think I tested the "big buffer" version with the result, that it did not crash and no MGA hits, but with similar graphic errors around the bubble as in my photos that I added here already.

But as there is a alternative for the bubble help with simple and faster boxes, it is not so important. But if you want to investigate further, please reopen and I will try to help.

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

Switching to plain rectangular boxes might fix the issue for you, but in general it should be fixed in MUI in case MUI is causing the trashing. If the trashing happens outside MUI then you have a generic problem and the trashing will happen at any time again, even for non-MUI applications.

I will provide another test version later today. It would be nice if you could try that ASAP, because the public release of MUI4 for AmigaOS3 is scheduled quite soon and I'd like to get this issue solved until then.

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

Please try the "no alphablend" version. That one will do everything like the normal version except the alpha blending. Hence the bubble help will have no bubble border. I'd like to know whether this version still causes Enforcer hits.

comment:35 Changed 4 years ago by supernobby

Resolution: worksforme
Status: closedreopened

I tried the "no alphablend" version, but it crashes before I can do the bubble help test. Seems like there are significant changes in the GUI system. The MUI settings window still opens, but if I click on "Hilfe" to change the comic help bubbles, the application will crash, like othere programs do as well, sooner or later. Is there again an increased stack demand?

Changed 4 years ago by Thore Böckelmann

Attachment: muimaster_no_alphablend.lha added

muimaster.library without alpha blending

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

Sorry, my fault. I just replaced it with a working version.

comment:37 Changed 4 years ago by supernobby

I tested the new "no alphablend" version. But unfortunately, this has the same behaviour as the original version. I really hope, my system itself is not the problem, but the alpha blending itself does not seem to be the problem.
In particular, the first comic message box still shows up. But in the left upper and lower corners, there are now only this pink lines. That pink you can also see already in my photo. So the round corners look like to have been drawn on to of the pink lines. I hope you understand what I mean (first the "problem" and then the alpha-blended drawing).

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

Resolution: worksforme
Status: reopenedclosed

This very much looks like a bug in your CyberGraphics system. The "no alphablend" version just allocates a correctly sized buffer, reads all pixels to that buffer and immediately writes the buffer back to screen. If that already causes trashed memory then MUI is definitely not guilty.

It seems you really have to switch to rectangular bubble help permanently. There is nothing that I could fix in MUI. But if really CyberGraphics is buggy here then this kind of trashing can and probably will happen with other (even non-MUI) applications as well.

comment:39 Changed 4 years ago by Mikhail Malyshev

Have to raise a question here.

Something has changed in the drawing routines of the comic bubble help ?

Comparing to older MUI 3.9 and current MUI 4.0 AmiKit 8.2 edition
I see how the help bubbles rip the screen on redraws and do redraws of the area possibly twice. Previously the bubbles disappeared nicely and smoothly without redrawing everything under them, and it was much quicker too.

comment:40 Changed 4 years ago by Mikhail Malyshev

Checked the OS4 version, same problem.
Looks like a grey square is cleared over the bubble help area before the original data is redrawn, this results in a tearing effect.
Previously (at least in 3.9) the data was recovered without the whole area being cleared.

Comments ?

comment:41 Changed 4 years ago by Mikhail Malyshev

Done a slow motion capture… It actually draws a square filled with the window background pattern (what for?!) and then restores the image that was under the bubble!

comment:42 Changed 4 years ago by Mikhail Malyshev

Comments?

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

What kind of comment do you expect, except that for me everything is working perfectly. And before you ask: MUI 3.9 and MUI 4.0 share the same code for the bubble help. If anything is wrong for you then open a new ticket, because this one is about system instability caused my trashed memory.

comment:44 Changed 4 years ago by Mikhail Malyshev

I have commented to this, since potentially the code changes that took place here have brought this effect up and it might be memory trashing related too.

The older 3.8/3.9 MUI drawed the bubbles differently, and there were no double drawing that is not required. If you keep the area under the bubble in memory,
you restore it as is. Currently it clears, then draws the area with background fill pattern, then recovers the original image. This looks crap and 'flickers' the screen. In other words the transition to/from the bubble is no longer smooth.
It might be difficult to notice on a very fast system and LCD screen. But on slower systems and high refresh rate CRT it is a nightmare.

Changed 4 years ago by Mikhail Malyshev

Attachment: MUI-Bubbles-help.avi added

Bubble help ripping drawing…

comment:45 Changed 4 years ago by Mikhail Malyshev

A quick slow motion capture video of the artefacts (overdrawing) when bubble is removed. This is from MUI 4.0. Older MUI clears it nicely, without the fill.

Also new bug, you can see the shadow effect under the bubble is uneven coloured!
Under the tick its a darked bar.

comment:46 Changed 4 years ago by Mikhail Malyshev

Resolution: worksforme
Status: closedreopened

comment:47 Changed 4 years ago by Mikhail Malyshev

Re. drawing routines, shadow problems (see video)

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

Resolution: worksforme
Status: reopenedclosed

You have been told to open a new ticket for new issues! Read the title of this ticket again. It about "system instability", not about speed nor about graphical issues. Is that really so hard to understand?

Both MUI 3.9 and MUI 4 do exactly the same to show and to hide the bubble help. Showing it just consists of opening a window plus blitting the prepared image to that window. Hiding is just consists of closing the window. If that is too slow on your machine then this is your problem, not mine. You have been told many times by now that MUI4 is targeted at fast machines. If yours is too slow then stick with MUI 3.8.

comment:49 Changed 4 years ago by Mikhail Malyshev

How was the bubble cleared in 3.8 and early 3.9 ?
There was no ripping effect (background filling polygon) as seen in slow motion capture. It's hard to see on CRT, and almost impossible to spot on LCD screens due to their slower refresh nature. I had to do a 100Hz capture to get a vivid view of what is happening. (it is as if the option with clear/without clear is applied to the bubble)
But it does irritate the eye because it worked nicely before and does not at the moment. And the other persons problems might be solved too, since as I understood the older code works for him, and the new one has glitches.

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

Milestone: MUI 3.9-2015R13.9-2015R1

Milestone renamed

Note: See TracTickets for help on using tickets.