iBrowse versions later than 2.5.5 always crash

[StompinSteve]

Hello everybody,

First of all aMiga Christmas to you all
Long post. Sorry in advance but I want to be detailed in my problem description

I'm having a whale of a bad time with iBrowse. Version 2.5.5 runs relatively stable* but any of the later versions all crash with "Program failed error #80000037" as soon as a webpage (anything) loads.
Or, in the case of the aminet website (which is the only website that loads after pressing "enter" in the URL bar). Aminet always crashes in iBrowse v2.5.6 and later with that error when I click on the "Search" button (I don't even need to type anything in the search-field).

I don't use HTTPS at al. The few sites I visit like Aminet i visit with HTTP only. So AmiSSL issues should not be a concern. iBrowse 2.5.5 runs fine with AmiSSL 4.10, 4.12 and 5.6 and especially the latter should be incompatible. But as I don't use HTTPS anyway, it seems to be irrelevant.

The machine I use iBrowse on is an A1200 with Blizzard 1240 @ 40Mhz. The machine runs incredibly stable (I actively cool the Blizzard).

I run stock/original Kickstart 3.1 and WB 3.1 (i'm old-school and refuse to use 3.1.4 and later)

I use the latest versions of the Plipbox firmware and RoadShow Distro. The TCP-Stack is super stable. I can AmiFTP all day long and up- and down-load stuff to various FTP Servers and never have a crash.

I'm a speed/tuning freak and to squeeze the last ounce of performance of her, I make heavy use of Blizkick, MMU Libs and the 68040.library from the MMUlibs distro (I get the highest CPU and HDD performance with this combo).
Sometimes I pushed it too far with these libs and blizzes and tools causing me to have more crashes than the Italian Government.
In the end, I reached a stable state and the system is/was very stable while being tuned to the max.

* Don't get me wrong, iBrowse 2.5.5 also crashes often, but not on simple Websites like Aminet or WDHload or "http://grandis.nu/eabsearch" or Google (in HTTP mode). Those sites run fine and I can download half the planet without iBrowse 2.5.5 crashing. I hit the 30 minute demo-limit which is the only reason I have to stop the iBrowser application.

I run iBrowse from a separate, dedicated HDD partition. It happened several times that the Filesystem of that partition got corrupted after an iBrowse crash/guru. I therefore point the Cache folder to RAM:WebCache (I create that folder in user-startup). Since moving the cache to the RAM Drive, I never had the filesystem on that partition go bananas again so I highly recommend that trick.

What have I tried so far:
So I thought "why do iBrowse 2.5.6, 2.5.7a and 2.5.8" always crash on this machine then, while 2.5.5 is happy.
I then went to massively simplify my Setup:
- Stopped using BlizKick
- Stopped using MMUlibs
- Replaced 68040.library from the MMUlibs Distro with the one from Commodore
- Replaced 68040.library from the MMUlibs Distro with the one from Phase5 (which has a filesize almost twice as large as the CMD and MMUlibs versions)
- Tried several versions of SetPatch
- Re-Installed MUI 3.8
- Went back to an almost stock system
- Between every attempt, totally cleaned the system of everything installed by a specific version (I let the installers create logfiles so I know what was installed and where).
- I completely removed AmiSSL and did a clean install each time I switched between iBrowse versions, always making sure that the AmiSSL version present was the correct companion version of when a specific version of iBrowse was released (like 4.10 / 4.12 with iBrowse 2.5.5 and AmiSSL 5.6 with iBrowse 2.5.7a and 2.5.8, always making sure nothing got left behind, causing possible issues with later version etc. etc. you get my drift.
- Used SnoopDOS to find out what iBrowse and AmiSSL are loading, see if anything failed (it does not, all versions behave normally, nothing is missing or in the wrong folders etc.)

I searched the Internet as to what error #80000037 means. It does not show up on sites like this: https://wiki.amigaos.net/wiki/Unders..._error_numbers
When I google that error code, I only get a few sites and all are about iBrowse crashes but those people never get a usable answer or fix.

Long story short: Versions 2.5.6 , 2.5.7a and 2.5.8 are still totally 100% unusable on this machine. They all start but crash directly when I enter a URL and press Enter. Or in the case of the Aminet website, the frontpage loads but crashes when I click on the search button. Version 2.5.5 has no problems with AmiNet at all. Stable as a rock.

I would like to support the iBrowse folks by purchasing a license from them but I can't get it over my heart as long as the browser is so incredibly easy to crash (even 2.5.5).
Maybe I should stop trying on my system. Maybe iBrowse versions 2.5.6 and later are simply not compatible with Kickstart and Workbench 3.1 despite the iBrowse website saying they should be.

[AMIGASYSTEM]

I tested IBrowse2.5.8 on OS 3.1 with a CPU 030 and everything works smoothly, on Aminet you can enter and browse without problems.

You probably have some conflict on your OS, check all libraries used by iBrowser.

To see the libraries used by iBrowser use Multiview, but you must have installed exe.datatypes

[mfilos]

I had never had problems with iBrowse ever in any environment I tried it (3.1, 3.5, 3.9, 3.2.1).
I always used it with WarpDT datatypes though (that I bought ages ago).

[Futaura]

Not sure where to start with this, but IBrowse definitely should still be compatible with KS/WB3.0+. There have been no other similar reports since 2.5.6 was released and perhaps you should read through the 2.5.6 history log to see if any other changes made in 2.5.6 jump out at you. Given your description, I checked all the changes and nothing would appear to affect this.

Did you check all the MUI classes too? IIRC, IBrowse 2.5.6 came with updated 2.5.6 NList classes, so maybe try downgrading to the ones supplied with 2.5.5.

What crashes? "IBrowse" or "IBrowseNetwork"?

I think you need to do some narrowing down... I would suggest trying to disable as much as you can in the networking area of IBrowse. For example:

- Disabled image loading and javascript via the preferences menu
- Disable the disk cache completely
- Turn the image decoders to external
- Turn off data compression
- Turn off persistent connections

Perhaps one of these will have an effect and may help trace the issue.

At least you have a MMU and are already using the MMULibs. Are you familiar with MuForce? You should tried running that, with stack trace enabled, along with Sashimi, to catch the crash. This should tell you exactly what component the crashed code is in, although that might not necessarily be the source of the problem.

You also said "iBrowse 2.5.5 also crashes often", but no other 68k users are reporting any crash issues (which haven't already been fixed as of 2.5.8), which leads me to suspect something else on your system is causing the issue.

(Oh, and please do not register IBrowse until you are happy with it. Sometimes people have had similar issues and have registered IBrowse thinking it will magically fix things, but if it crashes in demo mode, it will most likely still crash when registered too).

[StompinSteve]

Hi Folks,

I found a solution: instead of installing the 68040/FPU version (which I always did until now), I installed the "68020-030" Version (without FPU) and viola, 2.5.8 runs stable as a rock. Performance is good. HTTPS (google for example) also works (and I thought AmiSSL requires a FPU but i guess i'm wrong).

So it must be something with the FPU. As long as I don't use the 68040 FPU version, it's all good. Just spend about 20 minutes browsing my butt off without a single crash. iBrowse 2.5.5 always crashed when using the advanced search on AmiNet (just enter a keyword, click "Search" and bang, there goes iBrowse with that #80000037 error again). With 2.5.8 "non FPU", it works perfectly. Fast and stable.

Briefly thinking "is my FPU a donkey?" is quickly replied to by myself with "No can't be because Vista Pro for example runs like a champ, rendering for hours and hours". I even have a license of Matthias Henze's "HSMathLibs 040".

Then I thought "maybe a combo of the 68040.library I use (Phase 5's v46.5 at the moment) and SetPatch v43.7 but I tried several version-combo's without any effect (crashed are the same). Not using the 040 FPU version of iBrowse is the only thing that works for me right now (and it's certainly good enough, don't know hat the 040 FPU version brings in terms of tangible benefits.

_____________________________________

Concerning the PSU I use: it's the PSU that came with the CheckMate A1500 Case. It has plenty of oompf and the system is perfectly stable otherwise.
Concerning HDD corruption: that happened several times when the cache location was still point to somewhere on DH3:iBrowse while something was being written and iBrowse went tits-up. It could always repair it with Quarterback Tools. Now that I have pointed the cache to RAM:WebCache (I create that Drawer in user-startup), DH3: was spared a partly written file when iBrowse crashed.
RAM is good.

[StompinSteve]

Originally Posted by Boing-Ball

Concerning CPU. You are using a 40mhz 040? Or a 25mhz overclocked?

Dunno. Whatever Phase 5 put on the board. Is there any way to check via software? The board is inside a CheckMate 1500 case and it's impossible to remove the Blizzard as it's 3mm from the case-sidepanel. Need to lift the motherboard a bit to have enough room to pull out the Blizzard but for that, I need to remove the PSU first...

System is virus free. I boot VirusZ III from the GoTek to scan the HDD.

[Futaura]

AmiSSL won't touch the FPU, nor will IBrowse's image decoder codecs IIRC, so that leaves only javascript.library that is compiled for 68040+FPU. But, Aminet doesn't use JavaScript.

As I mentioned earlier, I think the only way you can get to the bottom of it is by using MuForce to catch the crash. I'm thinking it may not actually be related to FPU instructions at all, but something 68040 specific in the image decoders that your system doesn't like for whatever reason.

[StompinSteve]

Did some further testing:
- Left AmiSSL 5.6 as it is.
- Deleted iBrowse incl. the files it installs in MUI:libs/mui
- Installed iBrowse 040FPU to DH3:iBrowse
- Copied the files it installs in MUI:libs/mui and marked them as the 040FPU version
- Started iBrowse, opened http://aminet.net/search (this is the "simple" search)
- Clicked on the "Search" button to the right of the edit box without typing anything in, just clicked the button -> crash #80000037
- Rebooted
- Renamed the "DH3:iBrowse" Drawer to "DH3:iBrowse-258-40FPU"
- Ran the iBrowse 258 installer again, choosing the 020/030 NoFPU version this time.
- Copied the MUI:libs/mui files from the 040FPU version into MUI:libs/mui
- During this, I noticed that those files are identical to the 020/030 noFPU version so won't bother with swapping those out in the future.
- Now running the 020/030 noFPU version
- iBrowse is perfectly stable no matter what I browsed to. HTTP and HTTPS works fine.
- I cloned the iBrowse folder to DH3:iBrowse-258-2030noFPU
- I can now swap between both variants very easily.

I noticed that the iBrowse main executable is the same in both 020/30 noFPU and 040FPU versions. The only differences I could find at a glance in the entire directory-tree are the Javascript.library and the ".codec" files.

I'm leaning towards leaving things as they are. In other words, stick with the 020/30 noFPU version as it works like a charm.
I you are curious to what is causing the crash when clicking on the "search" button in Aminet for example, you'll have to guide me through whatever it is you want me to do. "MuForce with stack trace enabled, along with Sashimi" is out of my comfort-zone.

Sidenote1: This is the "tuning" i'm using to squeeze the last bit of performance out of this hardware. From my Startup-sequence:
_______________________________________
C:SetPatch QUIET

IF EXISTS C:BlizKick
C:BlizKick * EXTRESBUF=10000 MODULE Libs:mathieeesingbas.library Libs:mathffp.library BBlank romfixes NoClick QUIET
EndIF

;BEGIN MMUtools
SYS:System/MMUTools/MuFastRom On Protect
SYS:System/MMUTools/MuFastZero On MOVESSP=FASTSSP
____________________________________________
The 68040.library I use is Phase 5's v46.5 and SetPatch = v43.7
Those math libraries in the BlizKick command are from Matthias Henze's "HSMathLibs 040" package.

If if don't use BlizKick and MMUlibs at all (so just "setpatch"), the iBrowse (crash)behaviour is fully identical. In other words, their usage, or not, has no influence on the issue at hand.
As only the Javascript library and codecs are different between both variants, the issue must be in one of those. When clicking on the "search" button in Aminet simple search, is that a Javascript thing going on? If so, it kind of makes sense to look for the problem in the Javascript.library of the 040FPU version as it seems to not like my system :-)


Sidenote2: I just received my licence-key thanks.

[gdonner]

FWIW (re: HSMathLibs) - CS-Lab, in their latest Quickstart Guide (as of firmware v1.400) no longer recommend using HSMathLibs due to issues on some of the latest AmigaOS versions:

Math libraries
It is recommended to use standard math libraries provided with AmigaOS.
Previously recommended HSMathLibs are reported to have some issues on latest AmigaOS versions.

Exactly what those issues are, I don't know, but I thought it's worth mentioning. My understanding is that it's unlikely that Matthias Henze, the HSMathLibs author, will be updating them due to health issues.

[StompinSteve]

Originally Posted by gdonner

FWIW (re: HSMathLibs) - CS-Lab, in their latest Quickstart Guide (as of firmware v1.400) no longer recommend using HSMathLibs due to issues on some of the latest AmigaOS versions:

Yeah I already found out I can't load his Math Libraries in 3.1.4 anymore. I have not been successful so far.
I think the comments in my Startup-Sequence speak for them selves

; $VER: Startup-Sequence_HardDrive 45.4 (28.5.2018)
; Startup-Sequence for hard drive systems, Amiga 1200, AmigaOS v3.1.4 ROM

C:Version intuition.library version 45 >NIL:
If Warn
   Echo ""
   Echo Cold boot detected.
   
   ; *** MuMove4K with PrepareEmul A1200 no longer needed in 3.1.4 ***
   Echo Running MuMove4K
   SYS:System/MMUTools/MuMove4K NoReboot
   
   Echo Loading module intuition.library v45 from AmigaOS v3.1.4
   Echo Rebooting...
   C:wait 2
   C:LoadModule LIBS:intuition.library
   
   ; Experimental as it looks like OS 3.1.4 breaks loading the Matthias Henze optimized Math Libraries
   ;C:LoadModule LIBS:intuition.library LIBS:mathieeesingbas.library LIBS:mathffp.library

EndIf

C:SetPatch QUIET
C:CPU CHECKINSTALL


; *** AmigaOS 3.1 Legacy. Disabled BlizKick for now
; *** These BlizKick commands no longer seem to work with AmigaOS 3.1.4
; *** Version of BlizKick command with full optimized Math Libraries by Matthias Henze
;C:BlizKick * EXTRESBUF=10000 MODULE Libs:mathieeesingbas.library Libs:mathffp.library BBlank romfixes NoClick QUIET
; *** Version of BlizKick command without the optimized math libraries replacement (FixMath404 fixes the basic bugs)
;C:BlizKick * Module romfixes FixMath404 BBlank NoClick QUIET
; *** Version of BlizKick with just BorderBlanker and NoClick. This still works in 3.1.4 but trigger a reboot. Solved by using AntiClick and BlackBorder.
;C:BlizKick * Module BBlank noclick QUIET

; *** CPU FastROM no longer works in 3.1.4 , Replaced with MuFastRom ***
SYS:System/MMUTools/MuFastRom On Protect

; *** Put both Exec and Expansion in FastRAM ***
; *** FastExec requires MuMove4K to have been run, prior to its setup. ****
SYS:System/MMUTools/MuFastZero On MOVESSP=FASTSSP FASTEXEC


C:Version >NIL:
C:AddBuffers >NIL: DF0: 15
FailAt 21

c:anticlick

c:blackborder

Steve: I left the rest out as it's not relevant.

[Jope]

Blizkick itself still works, but anything related to the extresbuffer doesn't, unless you patch blizkick to understand the new exec.library. So you can still load a ROM to your CPU card's remap area with it, but the modules mostly won't work.

[indigolemon]

Originally Posted by StompinSteve

Yeah I already found out I can't load his Math Libraries in 3.1.4 anymore. I have not been successful so far.

You can do it, but you need to specify DOWNGRADE as an option for LoadModule, as the HSMathLibs version numbers are now lower than those shipped with the OS.

That said, the newer OS libraries are much improved, so I didn't see any difference in real world use with HSMathLibs with 3.1.4 or 3.2(.1)