We need an iBrowse replacement for 68k!!!

[matthey]

Detecting hits with Enforcer, MuForce, GuardianAngel and any similar tool is matter of good luck. MuForce only detects illegal memory accesses to unused address space. GuardianAngel detects illegal memory accesses to unused memory but if your memory is heavily used by other applications it detects nothing.

So less is more, more or less? The most common hits are to the zero page which are not luck. A hit from using munged memory is also not luck if the munging number is chosen carefully like 0xABADF00D (the most significant bit is 1). This address is >2GB (or negative if using a two's complement signed number) which is highly unusual to be in use as regular memory on an Amiga anyway. Sure, there is some luck to picking up a random hit due to lack of memory protection but I believe this is a small minority of hits. The ABADF00D hit in NetSurf was detected 4 out of 4 times I tried to catch it by the way.

[matthey]

Hmm, try now.

It still has the hit in the same location and then becomes unresponsive.

[matthey]

edit: actually I can prove whether it needs AreaInfo - can you try starting it up with direct_render:1 and see if it still crashes?

It works with direct_render:1 in Choices!

[matthey]

A-ha!  Right, remove that and try the new version.

It's still not working without direct_render:1 in Choices.

Edit: I just verified that the new version has a hit in the same place.

[matthey]

I've been following along daily but had no time to actually look at it myself.

This can't seriously be how you intend to debug the whole application. It's just not viable.

This needs to be built with source level debugging one way or another.

It's not viable in the long run but it is the quickest method to get NetSurf up and partially usable. Even if Chris had a better compiler and debugger, his hardware may not be adequate and that takes time to sort out or upgrade.

My suggestion is still to get it building with VBCC so that you can use a source level debugger such as the one in SAS/C.

It couldn't take longer than debugging like this and the final result will be more reliable.

Vbcc has a clear advantage for debugging because BDebug (Barfly package) and CPR (SAS/C) are good debuggers which can be used. Vbcc is not a drop in replacement for GCC though. It is missing some C99 support like inttypes.h which NetSurf is using. I have created and tested an experimental inttypes.h and updated stdint.h which is currently being evaluated by Frank and Volker:

http://www.heywheel.com/matthey/Amiga/new_c_headers.lha

I may have already posted a link to some fixes for the C99 math libs:

http://eab.abime.net/showthread.php?t=74692

Vbcc has pretty good C99 support (requires -c99 switch) but it doesn't have all the GCC posix and unix bloat by default. Rather than libnix or the nasty ixemul, Frank's posix.lib is usually used if this functionality is needed. The includes are a bit tricky sometimes but the posix.lib is Amiga friendly and has worked well for me the couple of times I have used it for small projects. It is actively maintained as is vbcc.

http://aminet.net/dev/c/vbcc_PosixLib.lha http://aminet.net/package/dev/c/vbcc_PosixLib

It has some bsdsocket.library functions of which the following is written in the readme,

"Since 2.0 it also includes the most important TCP/IP network functions, which are implemented through bsdsocket.library (only opened when really needed!). The main advantages in combining bsdsocket with PosixLib is the possibility to use a common set of file- and socket-descriptors as well as clean header files which don't conflict with vbcc's standard headers."

I wonder if it would work offline unlike clib? It is probably worth checking out if most of the functions needed in NetSurf are available.

There would be some work involved in compiling also, Vbcc is strict by default about C standards where GCC by default is too sloppy and forgiving. Vbcc will often warn about questionable code that usually should be fixed. Vbcc may not be a quick and easy way to get better Amiga debugging but the support is good .

@Chris
Is a new version of NetSurf available to test without RectFill?

[matthey]

The most recent one I uploaded had that removed (well, replaced with EraseRect).  I'm looking at the archive now, NetSurf executable size is 5906380 dated 13-02-2015 18:38.

That is the executable I'm using. Let me do some more debugging and I'll try to see what is going on.

Edit: Let me walk through the debugging process for people who want to learn a little about debugging. I set the stack up in the shell and changed to the NetSurf directory. I then entered:

>BDebug NetSurf -v

In the little BDebug window I selected "Crashed" (same as Catch Crashed Task in the Menu) and selected "Special->Catch Enforcer Hits" in the menu (this works with MuForce also). This will cause BDebug to stop at the problem if we don't make it to where we want to debug. I now select "Info Tools->Open Symbol Window" in the menu. I scroll down in this new window until I get to _ami_plot_clear_bbox (function names have an underscore in front of them). I then double click on this symbol and I will be asked if I want to "Jump to location?" which I select "Ok" opening a code window with the start of the function at the top. With this window active I select in the menu "Specials->Set/Clear Breakpoint" and the top line of the function and window will turn white where the break point is set. I now select in the menu "Step/Trace->Run Task" which causes the program to begin execution until a breakpoint, hit or crash occurs. I didn't have any hits up to the breakpoint and it looks like the first use of the function is where I need it to be judging by the NetSurf debug output. I now step down to "MOVE.L _GfxBase,A6" using the menu "Step/Trace->Trace over Calls" or right Amiga 't'. This skips over any functions calls to get to the "JSR EraseRect(A6)" graphics.library call we want to examine. It may be necessary to select in the menu "Configuration->Guess Lib Call" to see the "EraseRect" instead of an offset (Symbols and Show Lib Call above Guess Lib Call in the menu should already be toggled on by default).  Now I trace with right Amiga 't' until the "JSR EraseRect(A6)" is white right before branching into the library. I now look at the status window which shows the register values. The interesting values for EraseRect() from the AmigaOS 3.9 NDK are:

A1=093bb2b4 (rp)
D0=00000008 (xmin)
D1=00000034 (ymin)
D2=00000318 (xmax)
D3=0000024b (ymax)

Note that these values are in hexadecimal even though they are not marked with '$' or "0x".

Everything looks ok so far as (xmax >= xmin), (ymax >= ymin) and the rp address looks valid. Perhaps the rp is corrupt or non-ititialized correctly? I will now step into the graphics.library EraseRect() to see what is wrong and try to verify what I saw before with the hit inside but this is more advanced debugging and beyond what most programmers would do. If line debug source info was available in the NetSurf executable, we could select in the menu "Windows->Open SourceWindow" and we could have watched each line of source executed starting at the top of ami_plot_clear_bbox() but not when we branch into the AmigaOS. I'll go ahead and post what I have so far.

Edit2: I'm going in. I have the line "JSR EraseRect(A6)" highlighted in white and instead of right Amiga 't' to trace over this routine I use right Amiga 's' which traces along the Program Counter (PC) route one instruction after the next. We have an absolute jmp in the library function table and then we are in the graphics.library EraseRect(). The code first checks if rp==NULL and then saves some registers to the stack with MOVEM. The rp->Layer is then moved to A5 in preparation for a "JSR LockLayerRom(A6)" which is where the hit occurs. It looks like there may be an ObtainSemaphore() of the Layer_info->SignalSemaphore and then the AddTail() of the Layer_info->gs_Head list is corrupt and causes the hit before going to sleep with Wait(). The Layer_info is all !! Private !! data so it is unlikely that NetSurf directly messed up the list. I believe the rp->Layer or the whole RastPort is corrupt or not initialized properly.

[matthey]

Seems unlikely, however I've just discovered some code I stuck in for OS3 only which may well be causing the problem, so I've taken that out and uploaded a new version.

It's working again .

[matthey]

Is the graphical corruption still present?

The welcome page looks good but amiga.org still has gfx corruption.

[matthey]

Wawrzon : Patience! To get something work is 1/5 of job usually. Most of time is optimizing and speeding things up. Good news is that it will be useable with 16mb ram.

Just because 16MB of ram was enough on an older version of NetSurf for a different CPU and OS doesn't mean that it will be enough on the Amiga. I would expect that 32MB would be enough though.

I still get emulator error tested with 040, 32mb ram & plain AGA.

Your tag says that your '040 and '060 Amiga only have AmigaOS 3.1. NetSurf uses Reaction for it's GUI which was added to AmigaOS 3.5. It may be possible that the newest ClassAct on Aminet could be installed and make it work but there are some enhancements since then. As far as the gurus, you were getting an F-line "emulator" trap which usually comes from a lack of FPU. You might check your 68040.library installation and make sure you are using SetPatch in your S:Startup-Seqence because this error should be very uncommon with a full 68040 and a proper 68040.library installation. It looks like the program counter (PC) was getting lost on your 68060 Amiga which can cause it to generate a different guru type each time. It's hard to say why this was happening but I had this happen when the tags were being corrupted by Chris's compiler which is fixed now. You could try installing ClassAct if you only have AmigaOS 3.1:

http://aminet.net/dev/gui/classact33.lha

Do *not* install classact if you have AmigaOS 3.5+! Go online with your internet before trying to start NetSurf.

[matthey]

I have OS3.9 and I don't have any problems with other software wich requires fpu. Need to test with other 68040\060 libraries.

Good, but you might consider changing your tag line:

Code: [Select]

A1200 Micronic tower, KS3.1, Blizzard 060 66mhz,GVP Spectrum, Delfina Lite and Micronic Scandy, 160Gb hd, 66mb ram, DVD-burner and WLAN.
A1200 desktop, KS3.1, Apollo 040 40mhz, 34mb ram, Ide Fix Express with 160Gb HD and WLAN

I'm using ThoR's MuLib processor libraries but it may not be easy to change yours. As I recall, the Blizzard 68060.library is in flash memory and some of the Apollo accelerators need the Apollo specific CPU library. I wouldn't be too worried about the P5 68060.library if you have a fairly recent flash version in your accelerator but sometimes the Apollo CPU libraries were a bit dodgy.

060 did gave diffrent error, thoug I didn't tested it yesterday.

I read your old posts before commenting. You might try the 68060 setup again as a bug in the compiler which caused similar problems to what you described may be gone.

@Chris
It looks like the pesky requestor that pops up asking to insert PROGDIR in any drive is from ami_arexx_execute("PROGDIR:Rexx/Startup.nsrx") in amiga/arexx.c. It occurs shortly after ami_gui_splash_close(). The function call and string look ok but maybe the arexx_obj doesn't handle PROGDIR: correctly? What do you think is wrong here?

I did some tests of TCP/IP program memory usage when online and iconified:

Genesis using Reaction 973kB (I hacked away 17kB of fluff in the GUI library but my buffer may be larger than default)
Miami with ClassAct GUI 1209kB
Miami with MUI GUI 1211kB

I don't have MiamiDx to check memory use but I would imagine it is more than Miami with MUI. It's probable that switching to Genesis from AmigaOS 3.9 would save 1/4 MB of memory not counting the savings from sharing Reaction objects with NetSurf which could also be significant. Genesis is faster and uses less memory. An option which would save even more memory would be to use Roadshow which has no GUI. Olaf claims that the minimum memory requirement would be around 360kB but lets say 400kB with a reasonable buffer size and a few settings activated, Now you would be saving over 3/4 MB of memory and Roadshow is also faster than Miami/MiamiDx. That is a big difference. I expect that being able to optimize NetSurf with a better compiler could save 1/2 MB and closing the splash window right before opening the NetSurf screen and window instead of right after could save a little while reducing fragmentation. I'm sure there are other NetSurf options which could save memory like changing the font handling. I use and configured AWeb and Ibrowse to use the bitmap fonts from here:

http://www.amiga.org.ru/websurf/

Do you think these would work? Maybe you could get permission to include the fonts with NetSurf?

[matthey]

OK tested, now both of my machines gives : Check Instruction Error

I installed mmulibs 68040.library, so there must have been something wrong with 68040.library.

Maybe. A check instruction error is usually an indication that the Program Counter (PC) got lost. If the PC ends up inside NetSurf then it should be consistent what guru number is given (for that version of NetSurf only) but if the PC is outside of NetSurf memory then any guru number could be given as this memory changes each time a program is executed.

Though checkFPU found it as like it does with mmulibs's 68040.library

Netsurf crash immediately after makedir users/user/iconcach

I would have you use MuForce to record any hits but it wouldn't do us much good without usable source debugging info and GCCFindHit or similar working.

[matthey]

I guess it doesn't handle PROGDIR: correctly, as you say.  The "fix" would be to add the following to the config file:
arexx_dir:/Rexx

If that cures it I might be able to expand PROGDIR:Rexx by default.

In Choices, I added:

Code: [Select]


arexx_dir:/Rexx


The annoying requestor has disappeared .

[matthey]

I've uploaded a new one with the PROGDIR: problem fixed.
I've added a couple of lines of debug which might confirm whether utri's crash is in ami_mime_init or not.

New version is working ok here.

confirm progdir issue gone, browser works without further modifications, aome wrong colors (endian issue) setting 16bit pc mode on my voodoo3, but i think these are minor things to take care later. attach screenshot of aorg, alas i cannot effectively post here from my amiga since netsurf is too slow.

I'm not so sure of an endian problem. I'm using 16 bit "pc" here also.

btw, command find text causes priviledge violation and consequently crashes the system.

Same here. It's in intuition.library. I'll look into it.

There are several places (menu items or gadgets) that cause hits or crashes which I have not debugged. I don't know which areas Chris has worked on and are ready to debug.

[matthey]

OK, I've put an experimental bitmap fonts supported version up.  It's pretty horrid but is definitely faster even on OS4 when using outline fonts through it.  It doesn't make any attempt to display anything in the correct character set, you'll just get raw UTF-8 stuck on the screen.

To enable, set the following in Choices:
use_diskfont:1
font_sans:helvetica
font_serif:times
font_mono:topaz
font_cursive:garnet
font_fantasy:emerald

Feel free to use different fonts!

It's working and there is spacing in the text now which looks better but ami_font_bm_open() must be called several thousand times, often many times for the same font and size in a row. This makes it slow with netsurf -v to display all the output but maybe it will be alright without -v.

I've been trying to track down the menu "Browser->Find text" bug which is caused by a NULL pointer which is then put on the stack and used by an RTS deep inside intuition.library. What ever happened to simple hits in the executable? I guess this is what happens when back porting to an OS which is missing the new APIs and support.

Edit: I have one lead pointing to the "Browser->Find text" bug being in amiga/menu.c ami_menu_item_browser_find(), It would be the GetAttr() call that has the hit and then guru in intuition.library. The NULL pointer may be at an offset of 8 from a structure (maybe a private struct). I would have to catch before the GetAttr() call if you need more info on arguments passed.

Scrolling the display window with the keyboard works but not the proportional gadgets which give NetSurf debugging messages like:

Code: [Select]

amiga/gui.c ami_scroller_hook 5168: IDCMP hook unhandled event: 0

This might be good to fix. The NetSurf program size keeps dropping as you add new features which is good. You may eventually have enough memory on your AmigaOS 3 system to run it yourself if you keep it up .

[matthey]

OK, I think that's a 68k registers thing.  I've probably fixed it.  I'll hold off uploading new builds for the minute until I merge the bitmap fonts stuff across.

Hook problem? Fixing the registers in all hooks could make a lot of things work .

[matthey]

Yes... just done it (might* have missed some, but we'll find out)

Uploaded a new version from my bitmap fonts branch (as I don't want to merge this yet).

* Actually I know I've missed some, but nothing important for now.

Bingo!!! Most menu items and gadgets work now! It is faster than ever also. Awesome!!!