Opened 4 weeks ago

Last modified 30 hours ago

#387 new bug

Video memory trouble with R2

Reported by: K-L Owned by:
Priority: undecided Milestone: future release
Component: undefined Version: 5.0-2018R2
Severity: minor Keywords:
Cc: Hubert Maier OS Platform: AmigaOS4
Blocked By: Blocking:
Release Notes:

Description

Summary

MUI 5-2018-R2 seems to eat a lot of video memory without freeing it.

Steps to reproduce

  1. Launch a monitor to check video memory consumption (to be done with R1 and then R2 to see differences)
  1. Launch any MUI application and check video memory consumption

Expected results

A huge amount of video memory will be used while using an MUI Application (Odyssey for example).

Actual results

More than 50% of video memory (I have 256MB here) will be used and not be freed when quitting all MUI applications.

Regression

It is a regression from R1.

Notes

Attachments (3)

putty.lha (375.5 KB) - added by Hubert Maier 3 weeks ago.
Crashlog_Odyssey_2018-08-04_17-17-20.txt (37.9 KB) - added by Hubert Maier 12 days ago.
Crashlog_Odyssey_2018-08-04_17-22-09.txt (37.6 KB) - added by Hubert Maier 12 days ago.

Download all attachments as: .zip

Change History (44)

comment:1 Changed 4 weeks ago by jPV

This sounds very similar to what my friend (who makes betatest for my OS4 programs) reported, but he told that MUI programs consume system memory (RAM) too, not just video memory. The memory isn't freed when quitting the applications.

If he boots the machine without MUI applications running, memory isn't consumed. But if he launches MUI program(s), memory is being consumed continuously until it's all gone. For example, while just using AmIRC, all memory (512MB) was gone after 11 hours. Just running the MUI settings program alone will also consume memory in the similar way.

This kind of behaviour was already seen with 5.0-2017R4, but it's worse with 5.0-2018R2 now.

Last edited 4 weeks ago by jPV (previous) (diff)

comment:2 Changed 3 weeks ago by Thore Böckelmann

Keep in mind that MUI does cache images. That means that images are loaded once only and will be reused when restarting the program or even when other programs use the same image. When the program that caused the loading of an image is terminated the images will stay in memory and of course will consume memory until they are flushed.

Flushing the image cache will happen when system memory is low and Exec invokes the usual low memory handlers. This can also be enforced by running the supplied FlushImagespace program.

@K-L
What kind of video memory monitor are you referring to?

@jPV
If free video memory is constantly decreasing there must be something that MUI's debugging framework is able to expose by doing excessive output.

comment:3 Changed 3 weeks ago by Thore Böckelmann

I have had MUI prefs of 2018R2 running for almost 8 hours now on my WinUAE/AmigaOS4 setup and have absolutely no problems. According to the Workbench title bar free video memory has decreased from 1K (yes, 1024 bytes) down to 0K as soon as MUI prefs has started. But that's it. Normal memory figures have not changed at all.

comment:4 Changed 3 weeks ago by K-L

Well, I'll make some new tests with screen grabs. Thanks for having tested.

comment:5 Changed 3 weeks ago by Hubert Maier

I can confirm this behaviour.

Especially Odyssey is eating away video ram very fast (Workbench title bar is showing envvar %mgum - Memory Graphics Used Megabytes) and is neither freeing it after the program's quit nor while Odyssey is running.

Can easily be reproduced on sites which features lots of pictures, e.g. http://uberhumor.com/
…you can actually see the video memory getting filled up.

Just scroll down the site, let the pictures load and move on to the next page and so on.

I'm filling up at leat 1 to 2 Megabytes per new site.

comment:6 Changed 3 weeks ago by Hubert Maier

More tests needed, but it seems as if the nightly build
https://muidev.de/download/MUI%205.0%20-%20Nightly%20Builds/MUI-5.0-20180724r6309-os4.lha
fixed the behaviour for me.

Changed 3 weeks ago by Hubert Maier

Attachment: putty.lha added

comment:7 Changed 3 weeks ago by Hubert Maier

Nope, behaviour still there

comment:8 in reply to:  5 Changed 3 weeks ago by Thore Böckelmann

Replying to Hubert Maier:

Can easily be reproduced on sites which features lots of pictures, e.g. http://uberhumor.com/
…you can actually see the video memory getting filled up.

Wait! This is beyond MUI's control. If Odyssey eats up tons of memory when loading web pages then MUI cannot do anything against this. These images are under control of Odyssey only and MUI does not know about them.

comment:9 Changed 3 weeks ago by K-L

But, how can you explain that there was not this behaviour with 2018R1 and it now happens with 2018R2 with the exact same version of Odyssey ?

comment:10 Changed 3 weeks ago by Thore Böckelmann

I have created some nightly build versions of previous commits dated around the release of 2018R1. Please check these as well:
commit 6244
commit 6244 debug version
commit 6248
commit 6248 debug version
commit 6251
commit 6251 debug version

Changed 12 days ago by Hubert Maier

Changed 12 days ago by Hubert Maier

comment:11 Changed 12 days ago by Hubert Maier

All three of the provided debug versions produce a reproducable crash on start

comment:12 in reply to:  11 Changed 12 days ago by Thore Böckelmann

Replying to Hubert Maier:

All three of the provided debug versions produce a reproducable crash on start

Did you install the debug version of muimaster.library on top of the corresponding "normal" archive contents? As usual you should not mix files of different releases, unless told explicitly.

comment:13 Changed 11 days ago by Hubert Maier

It seems i'm not getting alterted when there is a new comment :-(

…and, yes, i did, as i don't have a debug release installed, it's the latest release from the download page.

And it worked with the very first debug muimaster.library you sent out, so i thought it will do now too

comment:14 Changed 11 days ago by Thore Böckelmann

Cc: Hubert Maier added

comment:15 in reply to:  13 Changed 10 days ago by Thore Böckelmann

Replying to Hubert Maier:

It seems i'm not getting alterted when there is a new comment :-(

I added you as CC, so you should get notified now.

…and, yes, i did, as i don't have a debug release installed, it's the latest release from the download page.

And it worked with the very first debug muimaster.library you sent out, so i thought it will do now too

I just tried all 3 archives on my virtual AmigaOS4 setup and none of them causes a crash.

Let me repeat again: do not mix files from different releases. If you want to test the debug version of the r6244 release from the download page, then first install all files from the "normal" r6244 archive and then copy the debug version of muimaster.library from the debug r6244 archive on top. After that you can either call MUI:FlushMUI to remove all possibly remaining stuff from a previous release from memory or just reboot the system to be absolutely sure that no previous stuff is used. Then start your debugging session.

If the special builds should be broken in any way this would mean that all the nightly builds would be broken as well, as these archives have been built from scratch in exactly the same way as the normal nightly builds and release builds.

comment:16 Changed 10 days ago by Hubert Maier

I added you as CC, so you should get notified now.

Yes, thank you

I didn't know that, sorry.
The files you linked to only hold the muimaster.library, so i thought it would be sufficient to copy that to my installed MUI temporarily.

I have to ask how i'm supposed to get that special build/files?
There is nothing on the downloads page and following your r6244 link takes me to the release info only.

comment:17 in reply to:  16 Changed 10 days ago by Thore Böckelmann

Replying to Hubert Maier:

The files you linked to only hold the muimaster.library, so i thought it would be sufficient to copy that to my installed MUI temporarily.

I have to ask how i'm supposed to get that special build/files?
There is nothing on the downloads page and following your r6244 link takes me to the release info only.

??? I downloaded the archives from the given links myself using Odyssey. But it should not matter which link you are using. The 6 archives can be found on the download page between the 2018R1 and 2017R4 archives as well.

comment:18 Changed 10 days ago by Hubert Maier

Yep, my bad, i never checked the "normal" links, sorry about that.

After testing build r6244 for a pretty long time and stressing it, i can savely say that this revision doesn't suffer from the OP problems.

I'll move on to the next revision shortly

comment:19 Changed 10 days ago by Hubert Maier

r6248 doesn't show the behaviour aswell

comment:20 Changed 10 days ago by Hubert Maier

…and r6251 neither have that problem too

comment:21 in reply to:  20 Changed 10 days ago by Thore Böckelmann

Replying to Hubert Maier:

…and r6251 neither have that problem too

Hm, that is interesting. According to #379 r6251 is exactly the first revision which causes issues. And now you tell me that there are no issues with that revision.

Either #379 and this ticket are about different faults or we are turning in circles here.

I will provide more interim builds until we find the guilty revision. Please test each build exactly like you tested the other three build.

comment:23 Changed 10 days ago by Thore Böckelmann

r6306 exactly matches 2018R2. Hence the issue must have crept in somewhere between r6251 and r6306.

comment:24 Changed 9 days ago by Hubert Maier

Progress :-)

r6261 is fine

r6278 is the first version displaying the behaviour

btw, i found another way to easily test and fill up my gfx ram (slowly)
Just load in new sites one after the other, i.e. i'm going through my bookmarks from top to bottom and all five or so sites my gfx ram gets filled by another % and exactly these filled up % never get freed on quit.

Looking at the additions inbetween those revisions it now can only be r6262, r6264 or r6265, right?
All the others are either translation updates, one utf-8 fix that only affects greek (r6270?) or a package merge (r6263) for the release build?

Last edited 9 days ago by Hubert Maier (previous) (diff)

comment:25 Changed 9 days ago by Thore Böckelmann

Some more archives to test:
commit 6262
commit 6262 debug version
commit 6264
commit 6264 debug version
commit 6265
commit 6265 debug version
commit 6272
commit 6272 debug version

All the other commits between 6261 and 6278 are irrelevant as they cover changes to the catalog translations only. And from my point of view the only possibly guilty commit is r6272, because this one covers the highlighting of the selected list columns. However, I still fail to see why that change should cause any harm. But if that revision turns out to cause the memory eating effect then please try to set the list highlighting effect to "off" (MUI prefs → Lists → Brightening).

comment:26 Changed 9 days ago by Hubert Maier

r6265 is fine

r6272 is the culprit

Though turning "Brightening" off doesn't help, it's still eating away gfx mem and refuse to give it back after quit.

PS: What is that "Brightening" supposed to do?
I can set the sliders to 100% on each side and nothing happens

Last edited 9 days ago by Hubert Maier (previous) (diff)

comment:27 in reply to:  26 Changed 9 days ago by Thore Böckelmann

Replying to Hubert Maier:

r6272 is the culprit

Hmpf. I feared that… No idea yet.

PS: What is that "Brightening" supposed to do?
I can set the sliders to 100% on each side and nothing happens

Lists with sortable columns will highlight the currently sorted column. The List2 demo demonstrates this.

comment:28 Changed 9 days ago by Hubert Maier

No problem, take your time

comment:29 Changed 9 days ago by Thore Böckelmann

A slightly modified version with brightening code disabled. This is essentially the only modification compared to previous commits.

commit 6272 without brightening
commit 6272 debug version without brightening

comment:30 Changed 9 days ago by Hubert Maier

I have bad news, this release still has the issue in place.

Why am i the only one testing here, btw, where is K-L??? :-)

comment:31 Changed 9 days ago by Thore Böckelmann

comment:32 Changed 9 days ago by Hubert Maier

Yep, r6271 is fine

comment:33 Changed 9 days ago by K-L

Hi,

I'm following your results by mail :-)

I'm on holidays so I did not test the debug buids but as far as I can see, you managed to track the culprit.

comment:34 Changed 9 days ago by Hubert Maier

@K-L

Pfft, i at least expect a bag of sand from the beach you are slowly tanning… ;-)

…and maybe a shell for Thore :-D

comment:35 Changed 3 days ago by Thore Böckelmann

Another test build of r6272 with some more code disabled:

commit 6272
commit 6272 debug version

comment:36 Changed 2 days ago by Hubert Maier

This still has the problem in place, i'm afraid

comment:37 Changed 2 days ago by Thore Böckelmann

Well, then there is nothing else I can do. The List class of the last test build has all the fancy stuff disabled and is in no way different from r6271 (except the missing brightening stuff). And the column brightening stuff is the all that r6272 is about. All other changes are either locale stuff or MUI prefs. If r6271 works but r6272 - modified or unmodified - does not, then I am completely out of ideas what might be causing this issue. And since I am not able to reproduce it myself I cannot provide a solution at the moment.

comment:38 Changed 43 hours ago by Hubert Maier

Maybe if someone else could cross-check (K-L?), there is always a slim chance i mixed something up while testing.

Right now i still have the last (6272 from comment #35 in place and it's displaying said behaviour.

Thank you so far for providing the test builds.

Do i understand it correctly that everything else was stripped except the column brightening stuff?
If that is the one still in the place, shouldn't that be the culprit then?
Maybe i misread though

comment:39 Changed 34 hours ago by Thore Böckelmann

All row and column brightening effects have been disabled, because this is essentially is what r6272 is all about. Before the column brightening was hard coded to +20%, with r6272 it became user configurable. That's all.

Have you tried resetting all MUI settings to defaults already? Perhaps that makes a change.

I am still wondering what kind of "monitor to check video memory consumption" K-L is referring to. Is the WB title bar sufficient? If yes, then I cannot do anything about that, because WinUAE/PPC emulates a Picasso4 with 4MB video RAM only and that is almost completely eaten up by the Workbench screen already. There are 7K left initially and these decrease to 0K as soon as any further window is opened.

comment:40 Changed 30 hours ago by Hubert Maier

All MUI settings set to default - no change.

I don't know what K-L is using.
I'm using two things to chek/display my gfx mem
1) env var text display in the WB titlebar (Total/Used)
2) The GFXMem docky which graphically displays the used mem in either % or MB

Both show the same gain in used mem when opening sites (no need to let them load completely, just surf to different sites) and the same amount of non-freed mem after i close the program.

I have yet to find another MUI based program that displays the same behaviour, so i might be guessing that Odyssey is doing something "special" which breaks.

Could you enhance your virtual video mem somehow?
I wonder what happens when your systems asks for more video mem? Maybe it silently gets added in the background, or your "normal" memory is decreasing is that case?

comment:41 Changed 30 hours ago by K-L

I'm using : http://os4depot.net/index.php?function=showfile&file=utility/workbench/titlebarclock.lha (and GFXDock from the zTools package available on AmiStore).

Note: See TracTickets for help on using tickets.