@Deniil715

Hey, calm down There are several people here admitting that this problem might indeed be a simple OWB bug.

The problem with all the "memmeters" is, that they actually cant work properly. Thats why I requested to use memstat, to see the paging activties of the system after OWB terminated.

And, as I said already, too, there is a certain possibility of a pager bug, that is preventing freed memory to be scored as really free memory again.

I said POSSIBILITY, to make this absolutely clear!

I dont say that this particular bug actually exists!

@Deniil715

If it is just specific sites as you suggest, this relatively good news.
There is always the option to try other browsers.

@all

I would like to test some of these problem sites on different browsers.
Could you all please list some here for me to test.

Thanks

_________________
If your nose runs and your feet smell, you're upside down.

@All

This memory leak issue is doing my head in, cause every time I see this thread bumped to the top of the list I keep thinking Kas1e has posted more updates of OWB - MUI. Are we just about done on this memory leak issue?

I just want OWB - MUI, I could really care less whether or not OWB - Reaction has a memory leak, with each revision it seems more features get taken out of it.

Keep going Kas1e, Fab and Denill you guys ROCK!

_________________
Amiga A1200T - TF1260 - R9200 - Indivision AGA MK3
Amiga A500 - PiStorm EMU68
Pegasos 2 G4 - AmigaOS 4.1 FE / MorphOS 3.16

@Tomppeli

There is a very obvious difference when OWB has used 200MB but didn't leak and when it did leak. If it didn't leak (which is the normal case on most web sites) most is returned as free and can be reused. If it did leak, if I start OWB again it will be very shortly until it swapps because it cannot reuse its old memory.

I find it typically leaks on pages where you need to login, like web shops, if you surf around a bit or just leave it there for an hour on a few sites. I guessing JS is to blaim.

Quote:

Isn't all memory allocations resource tracked so if any app leaks memory then when you close that app all memory, which that app allocated, is freed (or marked as unused at least) ? Also if app leaks memory it means it allocates memory but doesn't use it ever (or uses it only once and then forgets it or something like that). So such unused but allocated memory should be eventually paged out when system runs out of free memory and doesn't harm anybody.

AmigaOS does not have resource tracking like this. And it is a real pain when you code and crash and code and crash and the memory just drops. Only items allocated with AllocSysObject and the Trackable flag set will be tracked, not normal memory. That is because you are allowed in AmigaOS to give away a pointer to someone else then exit.

If it remains unused it may be swapped out, unless if it was allocated with SHARED or PUBLIC as far as I understood. Most memory is allocated as SHARED today I guess. I think newlib/malloc uses SHARED but I'm not sure.

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Fairdinkem

Quote:

This memory leak issue is doing my head in, cause every time I see this thread bumped to the top of the list I keep thinking Kas1e has posted more updates of OWB - MUI. Are we just about done on this memory leak issue? I just want OWB - MUI, I could really care less whether or not OWB - Reaction has a memory leak, with each revision it seems more features get taken out of it.

Good point
I've been sick for a week so not much progress. Now I'm at work... Let's see if we can make something happen this rest of the week.

OWB-MUI already works quite well I've heard. Haven't tested it heavily myself. Seem quite a bit faster than OWB-RA too, layout and scroll-wise. There are some input issues, like typing anything than Latin1, favicons don't show in history list, no download progress, ugly tab buttons and stuff like that.

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Deniil715

What you say is quite right, and I'm not claiming that OWB has no memory leaks. I'm merely saying that there is no way that I the user, or you the programmer, can tell how much memory is used or "lost", never to be returned. The only numbers you can get from the system are not "gospel".

Doesn't it strike anyone as odd that OWB should use 200 MB to build a few pages? How many pages are we talking about? Most busy pages that I've seen have been a megabyte or so at most.

_________________
cheers
tony

Hyperion Support Forum: http://forum.hyperion-entertainment.biz/index.php

@tonyw

I have seen myself that OWB uses a few meg per page usually.
But in the case of wundeground for example, it uses up about 100 meg almost instantly.

I certainly did find that strange.

_________________
If your nose runs and your feet smell, you're upside down.

@TiredofLife


I notice the same thing but 200MB.
All plus extra returned on exiting OWB,


Quote:

TiredofLife wrote: @tonyw I have seen myself that OWB uses a few meg per page usually. But in the case of wundeground for example, it uses up about 100 meg almost instantly. I certainly did find that strange.

_________________
Sam460ex : Radeon Rx550 Single slot Video Card : SIL3112 SATA card

@whose

Quote:

whose wrote: @Tomas Maybe you (and others) should try C:memstat then (and prep yourself with some patience, important!) to see, how "deep" the pager goes into this game. It is quite possible that OWB eats up all your memory, then the pager kicks in, and your system needs some time to resemble the memory lists after OWB is closed. Maybe some seconds, maybe a minute, or even more. As I said, there is saying that there are some bugs in the paging system. Quite possible that this is one of them. Nonetheless an OWB bug is possible, too. Btw., I say this because I have real hard problems to track down memory leaks with OS4.x, using "simple" application software but no debugging tools, so it is a bit strange for me to read about memory leaks here

I have sadly used it for days after losing quite a bit memory with it getting worse over time instead of better.
So i know for sure that it sometimes dosent free the memory even after closed.

I am pretty sure someone in another thread mentioned that this bug was present in other OSes using a different browser using same engine and he/she afair claimed it vanished with new version.
I also know i did not have this issue at least to this extent with earlier versions of OWB. I think the problem started with either 3.28 or 3.29.

@Deniil715

Quote:

I've been sick for a week so not much progress. Now I'm at work... Let's see if we can make something happen this rest of the week.

That's great, keep it up Daniel !

_________________
BACK FOR THE FUTURE

http://www.betatesting.it/backforthefuture

Sam440ep Flex 800 Mhz 1 GB Ram + AmigaOS 4.1 Update 6
AmigaOne XE G3 800 Mhz - 640 MB Ram - Radeon 9200 SE + AmigaOS 4.1 Update 6

@all
Please motivate Deniil more to works on mui-owb :)

For now in general there is just need to fix "fast links" part and "bookmark" window managments, and after that we will have only "bugs" which need to fix and some cosmetic stuff.

But you all can be sure its all really hard, and hardest in compare as we all expect (its not just rewrite mui4 to mui3, there is many other little problems).

Today we setup with Slash our private SVN, and also Slash almost finish Process.mcc, so all works is going, but without Deniil its all a bit slower.

Also those random crashes and freezes annoy pretty much, so there is works to do. I fix everyday something myself (easy bugs, with help of some other developers), but well.. Deniil are need it badly :)

Related to screenshots, i think last ones which will need to show, its screens with woring "fast links" , and after that visually nothing should changes heavy, just internal changes to fix the bugs.

We dedicated to not release buggy version, just to avoid any problems and annoyng talks about what is buggy and what is wrong and so on. First beta should be "almost ready" stuff.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

Hmm..
Why is OWB 3.31 still in upload queue on os4depot?? Wasnt it released like a week or more ago?

@Tomas

Because its samo79 upload the archive , while Joerg just not do it , by his classic strange reassons :) And while old archive looks like was passworded (or maybe just uplaoded by another person), its just in upload query, and need ask os4depot admin to approve it manually.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@Fairdinkem

Btw, to clear the stuff: mui-owb will not solve all the problems, which have WebKit itself. All those "memory leeks" which we have with reaction-owb, very-very possible to have and with mui-owb. Just because "engine" uses the same. And when engine its buggy - owb (does not matter reaction one, or mui one) will be buggy on some sites with all those leaks and so on.

Its mostly problem not of joerg, its problem of webkit which he use in reaction-owb for now (which are quite old).

But even in new webkit's bugs still have place. As fab say, there is some JavaScript bug was introduced lately. And that is not because of good/bad reaction/mui interface.

I mean - some bugs can be just the same on both browsers.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@kas1e

i hate to repeat myself but if anyone managed to compile os3 version it might become possible to track down the cause of even seemingly random crashes thanks to muforce and sashimi (if they are mam allocation related). sadly i cant do that even if i d like very much.

@kas1e

Quote:

kas1e wrote: @Tomas Because its samo79 upload the archive , while Joerg just not do it , by his classic strange reassons :) And while old archive looks like was passworded (or maybe just uplaoded by another person), its just in upload query, and need ask os4depot admin to approve it manually.

Ah that explains it.

@wawa

For now would be just good to have a working and usable OS4 binary release, i don't think we need plus extra huge job to add into the current list, of course if other 68k devs would like to help in meantime entering in development now would be cool, but for now we have only Daniel, Roman and Slash on this and for what i've understand the OS4 release it's not done yet and have many problems to solve

@Denill

Keep you time Daniel, there is no hurry at all, having you on this even in a single day per week would be just fine, also when a first beta will be out we can think about setting up a bounty to motivate more you and others ppls

Thanks a lot for all things you already did, mutch mutch apprecied !

_________________
BACK FOR THE FUTURE

http://www.betatesting.it/backforthefuture

Sam440ep Flex 800 Mhz 1 GB Ram + AmigaOS 4.1 Update 6
AmigaOne XE G3 800 Mhz - 640 MB Ram - Radeon 9200 SE + AmigaOS 4.1 Update 6

@wawa
Quote:

i hate to repeat myself but if anyone managed to compile os3 version it might become possible to track down the cause of even seemingly random crashes thanks to muforce and sashimi (if they are mam allocation related). sadly i cant do that even if i d like very much.

The real problem with port to 68k and AROS, that there will be too much new bugs (not only crashes) related to. It will be problems with compilers/linkers, with ported libs and whatever else. If someone will brave enough to try to compile 68k or aros version - i will help with all what i know. Fab also say that he doesn't mind if it will ported to os3 or to aros.

But should to say, that our current mui3.9 (on aos4) have already inside fixes for some bugs, which are not fixed at all in the mui3.8 on 68k , so mui-owb just will be buggy just by default already, and need someone who will deal with bugs of mui3.8 / zune. We even use already some mui3 features, which are implemented only in 3.9 (not big deal of course, but someone again should rewrite those deps too)

Even with that "wrappers" for mui4/mui3, reality is worse : the real problems not only mui4/mui3 rewrite , but any little bug / mistake can cause a problems. To make port to os3, imho need to fix Zune normally, and then backport it to os3.

Can say for now, that this all not trivial 100%. Even if Fab say that all the hard parts we already done, there is tons of other little problems related to bugs / not-done-features / anythink else.

Also add to it, that its not you write the code from scratch , its you trying to understand code done by other one. Even if Fab trying to explain all the stuff, its anyway done by him, and only he know all the stuff of his code (which are big).

There need someone really motivated, really skilled and so on, to make a port to os3/aros. Just because its all mean fix zune , and that hell of work as well.

ps. and not latest moment, its all need time, which today almost noone from amiga-devs have looks like. I really "annoy" deniil and slash to work. They of course have other thinks to do, and other interests. Even if someone will start to works on 68k/aros port , i know already how all will be: it will be just few days to understand how hard all of this, then, maybe "two more weeks" , and then, he will just give up. I am almost on 99% sure about that.

The only solution for os3/aros i see : if we will found someone really "Annoy-energetic" kind person who just will heavy annoy to imporve zune, and heavy annoy fab , me , anyone else with anything, just to make port.

At this point, some even can think that better write new browser from scratch :)

Last edited by kas1e on 16-Feb-2011 at 06:41 PM.
Last edited by kas1e on 16-Feb-2011 at 06:39 PM.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@wawa

Realted to muforce+sashimi, well .. its the same crappy small little toolz, which we already have on aos4. Sometimes crashes so heavy, and so random, and so strange, that all those karashimi will just not helps at all. Even with GR (which should to say help a lot), its still sometime very annoy to found bugs.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@kas1e
you are right, im aware of that its not just a recompile.
in case of possible 68k i would propose the route to aros and then eventually to 68k aros. debug tools should work there by the time.
i expect os4 has some debug tools avaliable lot least built in like gr, but from other threads (reaction owb) i get an impression it is impossible to determine in realtime the factual memory handling under os4 which leads to random crashes or leaks that cannot be eliminated in course of years.