Welcome, Guest. Please login or register.

Author Topic: NetSurf OS3 - testing!  (Read 30400 times)

Description:

0 Members and 3 Guests are viewing this topic.

Offline chrisTopic starter

Re: NetSurf OS3 - testing!
« Reply #29 from previous page: April 08, 2019, 06:53:53 PM »
The official builds now use AmiSSL: https://ci.netsurf-browser.org/builds/amigaos3/
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar picture is Tabitha by Eric W Schwartz
 

Offline chrisTopic starter

Re: NetSurf OS3 - testing!
« Reply #30 on: April 10, 2019, 06:29:27 PM »
There is, however, a bug in the code concerning the guigfx.library. This library seems to keep some sort of object pool which is not totally released upon exit of Netsurf. When netsurf exits, it deletes the pool. However, at least version 31.0 of guigfx detects that there are still live objects in the pool, and then - instead of running into an Alert() - runs into an ILLEGAL instruction and the code crashes. Thus, there seems to be at least one thing wrong with the objects netsurf allocates through guigfx, and it should release objects properly before releasing the pool.

I've added a missing release so hopefully this bug is gone now, thanks for finding!
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar picture is Tabitha by Eric W Schwartz
 

Offline chrisTopic starter

Re: NetSurf OS3 - testing!
« Reply #31 on: October 09, 2020, 11:46:34 AM »
Problem was codesets library, if there is a one, it needs to be lattest. I t works without it, but not with older versions.

Yeah, for some reason they added features and didn't bump the version, only the revision.
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar picture is Tabitha by Eric W Schwartz
 

Offline chrisTopic starter

Re: NetSurf OS3 - testing!
« Reply #32 on: October 09, 2020, 12:41:26 PM »
I can add a setting to disable it.  I'd be surprised if it was really that much slower, but possibly the way I'm using it isn't optimal.  I'll see if I can cache the internal structures for the charsets as it might be looking them up each time.
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar picture is Tabitha by Eric W Schwartz
 

Offline chrisTopic starter

Re: NetSurf OS3 - testing!
« Reply #33 on: October 09, 2020, 01:08:05 PM »
I haven't tested it at all, but try build 5216.
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar picture is Tabitha by Eric W Schwartz
 

Offline chrisTopic starter

Re: NetSurf OS3 - testing!
« Reply #34 on: October 10, 2020, 12:17:29 PM »
Quote
It has now a problem without codesets.library and it introduced new graphical problem.

I haven't touched the non-codesets code so that must be caused by something else.

Probably where the code is now offset differently the old bug causing it to access memory it shouldn't be is having a different effect.

This hasn't answered the question I wanted answered which was "is it any quicker now *with codesets.library*?"

Quote
Would it be possible to revert back few years old version so that new amissl would work with it?  Those versions were almost usefull, these versions.. it doesn't matter if you fix or not these problems, there is no point to use it as it loads page like amigaworld.net about 5 minits. It used to load about 15 seconds, when Olaf fixed memory fragmentation issue three? years ago.

I have no idea what caused it to go slow as I was told about this several months after it happened.  I have absolutely no chance of figuring out why now as I couldn't even at the time.

The memory model hasn't changed since then.

It's probably worth adding log_filter:level:CRITICAL to Choices because by default it is spewing out loads of Javascript-related errors which will be slowing it down.

I did switch to using AmiSSL as OpenSSL stopped working, I can't revert that change as not being able to make secure connections makes the browser useless.  There's no reason why AmiSSL should be slower than OpenSSL anyway, it's 99% the same thing.

What it needs is for somebody who can actually debug it properly to figure out what is causing the suspected buffer overflow problem and fix that.  That gets rid of the weirdness of it randomly crashing and doing odd things.  Then it's worth spending a bit of time optimising (again, by somebody who knows what they are doing).

« Last Edit: October 10, 2020, 12:24:09 PM by chris »
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar picture is Tabitha by Eric W Schwartz