search

amiga-mui / muidev

:mage_man: Magic User Interface (MUI) – Documentation+Releases
http://muidev.de
55 stars 0 forks source link

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

Closed jens-maus closed 9 years ago

jens-maus commented 9 years ago

supernobby created the issue:

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:

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

jens-maus commented 54 years ago

supernobby changed status from pending to new

jens-maus commented 9 years ago

@tboeckel commented:

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.

jens-maus commented 9 years ago

supernobby commented:

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!

jens-maus commented 9 years ago

@tboeckel commented:

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?

jens-maus commented 9 years ago

Michael commented:

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 ?

jens-maus commented 9 years ago

@tboeckel commented:

Replying to [comment:4 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.

jens-maus commented 9 years ago

@tboeckel commented:

Any progress here? The nightly builds are working again.

jens-maus commented 9 years ago

@tboeckel changed status from new to pending

jens-maus commented 9 years ago

supernobby commented:

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.

jens-maus commented 9 years ago

@tboeckel changed priority from undecided to normal

jens-maus commented 9 years ago

@tboeckel changed component from undefined to muimaster.library

jens-maus commented 9 years ago

@tboeckel commented:

Replying to [comment:8 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.

jens-maus commented 9 years ago

@tboeckel uploaded file muimaster_no_wpaa.lha (229.5 KiB):

muimaster.library without WritePixelArrayAlpha()

jens-maus commented 9 years ago

@tboeckel commented:

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.

jens-maus commented 9 years ago

supernobby commented:

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.

jens-maus commented 9 years ago

@tboeckel commented:

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?

jens-maus commented 9 years ago

supernobby commented:

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.

jens-maus commented 9 years ago

@tboeckel commented:

Any valuable hint is welcome.

jens-maus commented 9 years ago

supernobby uploaded file mui_116_2014-12-14.log (5.4 KiB):

jens-maus commented 9 years ago

supernobby commented:

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.

jens-maus commented 9 years ago

@tboeckel commented:

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.

jens-maus commented 9 years ago

@tboeckel uploaded file muimaster_big_buffer.lha (231.0 KiB):

muimaster.library with a big buffer for WritePixelArrayAlpha()

jens-maus commented 9 years ago

@tboeckel commented:

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

jens-maus commented 9 years ago

@tboeckel commented:

In amiga-mui/mui@26dba94236483aa17fe89a0c24dbc912263b41ab:

jens-maus commented 9 years ago

@tboeckel changed status from new to assigned

jens-maus commented 9 years ago

@tboeckel changed owner from * to tboeckel*

jens-maus commented 9 years ago

@tboeckel commented:

Any news on this issue?

jens-maus commented 9 years ago

@tboeckel changed status from assigned to pending

jens-maus commented 9 years ago

@tboeckel changed status from pending to closed

jens-maus commented 9 years ago

@tboeckel changed resolution from * to fixed*

jens-maus commented 9 years ago

@tboeckel commented:

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

jens-maus commented 9 years ago

supernobby changed status from closed to reopened

jens-maus commented 9 years ago

supernobby changed resolution from fixed to **

jens-maus commented 9 years ago

supernobby uploaded file mui_116_2015-01-06.log (32.6 KiB):

jens-maus commented 9 years ago

supernobby commented:

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.

jens-maus commented 9 years ago

@tboeckel commented:

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.

jens-maus commented 9 years ago

supernobby commented:

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.

jens-maus commented 9 years ago

supernobby uploaded file mui_116_2015-01-10.log (55.0 KiB):

jens-maus commented 9 years ago

supernobby uploaded file mui_116_2015-01-10.JPG (3580.6 KiB):

mui_116_2015-01-10.JPG

jens-maus commented 9 years ago

@tboeckel commented:

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.

jens-maus commented 9 years ago

@tboeckel commented:

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

jens-maus commented 9 years ago

@tboeckel changed status from reopened to pending

jens-maus commented 9 years ago

@tboeckel changed status from pending to closed

jens-maus commented 9 years ago

@tboeckel changed resolution from * to worksforme*

jens-maus commented 9 years ago

@tboeckel commented:

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.

jens-maus commented 9 years ago

supernobby commented:

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.

jens-maus commented 9 years ago

@tboeckel commented:

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.

jens-maus commented 9 years ago

@tboeckel commented:

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.

jens-maus commented 9 years ago

supernobby changed status from closed to reopened

jens-maus commented 9 years ago

supernobby changed resolution from worksforme to **