Welcome, Guest. Please login or register.

Author Topic: We need an iBrowse replacement for 68k!!!  (Read 76296 times)

Description:

0 Members and 2 Guests are viewing this topic.

Offline chris

Re: We need an iBrowse replacement for 68k!!!
« Reply #44 on: January 28, 2015, 11:46:34 PM »
Quote from: matthey;782524
It looks like the freeze is from intuition.library OffMenu()

Ah!  That would make sense as the window doesn't have any menus attached at the moment.

Should be fixed now along with the ASLFR_InitialDrawer hit, thanks.
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar picture is Tabitha by Eric W Schwartz
 

Offline chris

Re: We need an iBrowse replacement for 68k!!!
« Reply #45 on: January 28, 2015, 11:47:22 PM »
Quote from: wawrzon;782505
are the changes so far commited to the source available from netsurf site? i would like to try to setup build environment for 68k target once again.

Yes, I'm commiting everything direct to trunk as I see no reason not to.
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar picture is Tabitha by Eric W Schwartz
 

Offline chris

Re: We need an iBrowse replacement for 68k!!!
« Reply #46 on: January 29, 2015, 12:29:37 AM »
Quote from: wawrzon;782534
i have checked out the current netsurf source out of git repository, but i lack makefile.config for amiga-m68k target. also there is actually only amiga fronend source, is this supposed to work for both targets together? so, like in when i compile the source for ppc i get os4 binaries and when i compile for m68k i get amiga binaries? if so, i have an aros68k gcc4.6.4 installed in my opt dir. this backend produces elf files, but i can elf2hunk them, otherwise the aros binaries should run on amiga if they are not linked against static or dynamic aros libs.

It's all the same makefile.
"make TARGET=amigaos3" wil give you the OS3/68k build
"make TARGET=amiga" will give you the OS4/PPC build

AFAIK they differ only in the name of the cross-compiler and a few different compiler flags.

Quote
so.. crosscompiling it on debian im currently caught with libutf8proc dependency. ive compiled it and put in usr/lib without success...

Try doing a "make install" on it.  NetSurf's buildsystem is set up to look for libraries in certain places, and especially if you're cross compiling those places might not be where you expect.
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar picture is Tabitha by Eric W Schwartz
 

Offline chris

Re: We need an iBrowse replacement for 68k!!!
« Reply #47 on: January 29, 2015, 12:41:29 AM »
Quote from: matthey;782524
Do I win a new build of NetSurf?

Yes :)

It's still freezing for me so unless I haven't removed the On/OffMenu properly (I've #defined them out of existance) then there's something new to find.

I've fixed all the font code so it should now be reading fonts and printing to the window exactly the same as on OS4 (ie. full UTF-8 support).  You'll probably find you need to set some different fonts in the Choices file, as the defaults are set to fonts which come with OS4, so something like this should work on a basic OS3 install: (they must be outline fonts)

Code: [Select]
font_sans:CGTriumvirate
font_serif:CGTimes
font_mono:LetterGothic
font_cursive:CGTimes
font_fantasy:CGTimes

Choices is usually PROGDIR:Users/default/Choices (the "default" may differ if you have the USER env-var set).  You may need to create it.
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar picture is Tabitha by Eric W Schwartz
 

Offline chris

Re: We need an iBrowse replacement for 68k!!!
« Reply #48 on: January 29, 2015, 08:30:28 AM »
Quote from: matthey;782540
O.k. I have something else I need to work on so I probably won't be able to test until tomorrow. Did you place a new build at the same location as the others?


Yes, same place.
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar picture is Tabitha by Eric W Schwartz
 

Offline chris

Re: We need an iBrowse replacement for 68k!!!
« Reply #49 on: January 29, 2015, 10:12:57 AM »
Quote from: wawrzon;782541
have removed any reference to the cross compiler but neither simple "make" nor "make install" seems to work around this problem. must consult google or netsurf forums about how to build current netsurf on debian. this problem has not existed with 2.0 i have compiled before.


It will auto-detect whether you need a cross-compiler or not.

Build instructions are here although it's aimed at non-cross-compiled builds so you need to do add HOST=m68k-unknown-amigaos or TARGET=amigaos3 to the make lines:
http://wiki.netsurf-browser.org/Documentation/GettingCoding

The core library buildsystem stuff was added since v2 I think, so that might be what is tripping you up.
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar picture is Tabitha by Eric W Schwartz
 

Offline chris

Re: We need an iBrowse replacement for 68k!!!
« Reply #50 on: January 29, 2015, 07:40:01 PM »
Quote from: chris;782555
Yes, same place.

I've just updated it again.  This time the menus should work (so OnMenu/OffMenu is back in place) and I've enabled the auto on/off scrollbars.  It doesn't appear to be freezing any more, but it crashes far too much for me to tell whether it works!

Somehow, though, I managed to click on a link to NetSurf's homepage, so I'm pretty sure the display of webpages isn't working.
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar picture is Tabitha by Eric W Schwartz
 

Offline chris

Re: We need an iBrowse replacement for 68k!!!
« Reply #51 on: January 29, 2015, 11:37:23 PM »
Quote from: wawrzon;782602
decompressed the lha (3) with apparently newer rar on win8 ok. on kick 3.9++ im getting software failure on start, need to check when exactly.

I know about this one, it happens randomly though, so I suppose it must be an uninitialised variable somewhere.  A slightly more useful crashlog here:
Code: [Select]
Crash log for task "NetSurf_OS3"
Generated by GrimReaper 53.19
Crash occured in module  at address 0x6D433FDC
Type of crash: DSI (Data Storage Interrupt) exception
Alert number: 0x80000003

Register dump:
GPR (General Purpose Registers):
   0: FFFFFFFC 531104D0 00000000 00000001 00000001 DFD05269 58B6D9A0 DFD0526D
   8: 531104D2 6D434128 58B6D978 6D434128 00000004 6D4340F0 6D434128 6D434128
  16: 5C2D1000 5A370000 519586AE 6D4340F4 00000000 51E04F86 531105F4 00000400
  24: 00000100 FFD50001 FFD60001 51951004 51E0BC04 565781E0 531104EC 5C25A540


FPR (Floating Point Registers, NaN = Not a Number):
   0:              nan                0                0                0
   4:                0                0                0                0
   8:                0      1.67772e+07            1e+61            1e-59
  12:              nan    -1.67052e+307                0                0
  16:                0                0                0                0
  20:                0     4.34638e-311                0                0
  24:            1e+61            1e-59              0.5       4.5036e+15
  28:              nan            65536      1.67772e+07                0

FPSCR (Floating Point Status and Control Register): 0x00000001


SPRs (Special Purpose Registers):
           Machine State (msr) : 0x0002F030
                Condition (cr) : 0x535ECD80
      Instruction Pointer (ip) : 0x6D433FDC
       Xtended Exception (xer) : 0x014193D0
                   Count (ctr) : 0x535ED0F8
                     Link (lr) : 0x0002000E
            DSI Status (dsisr) : 0x587A8994
            Data Address (dar) : 0x535ED0F8



680x0 emulated registers:
DATA: 58B6D978 000090D0 FB955688 5C3125D6 00000100 FFD50001 FFD60001 51951004
ADDR: 533E87C4 58B6D968 00000000 00003720 00000010 531104CC 5311050C 531104B0
FPU0:                0                0                0                0
FPU4:                0                0                0                0



Symbol info:
Instruction pointer 0x6D433FDC belongs to module "" (HUNK/Kickstart)

Stack trace:
    0x6D433FDC symbol not available
    0x6D434128 symbol not available
    native kernel module SmartFilesystem+0x00016b38
    native kernel module SmartFilesystem+0x0001163c
    native kernel module SmartFilesystem+0x00016b38
    native kernel module SmartFilesystem+0x0001163c
    native kernel module SmartFilesystem+0x00019eb4
    native kernel module SmartFilesystem+0x00018954
    native kernel module SmartFilesystem+0x00018ba8
    native kernel module SmartFilesystem+0x00018c48
    native kernel module SmartFilesystem+0x0001a424
    native kernel module SmartFilesystem+0x0001d06c
    native kernel module SmartFilesystem+0x0000a4d4
    native kernel module kernel+0x009c56f4

68k Stack trace:
    51e04f84 (68k IP) - "NetSurf_OS3" Hunk 0000 Offset 004b3f84 (SegList: 14654401)
    519585bc - "NetSurf_OS3" Hunk 0000 Offset 000075bc (SegList: 14654401)
    00000001 - "SYS:System/GrimReaper" Hunk 0000 Offset 00000000 (SegList: 1595e53d)
    51958b14 - "NetSurf_OS3" Hunk 0000 Offset 00007b14 (SegList: 14654401)
    00000001 - "SYS:System/GrimReaper" Hunk 0000 Offset 00000000 (SegList: 1595e53d)
    6ff61508 - "LIBS:datatypes.library" Hunk 0005 Offset 00009508 (SegList: 1708a015)
    5195612e - "NetSurf_OS3" Hunk 0000 Offset 0000512e (SegList: 14654401)
    519560f8 - "NetSurf_OS3" Hunk 0000 Offset 000050f8 (SegList: 14654401)
    00000001 - "SYS:System/GrimReaper" Hunk 0000 Offset 00000000 (SegList: 1595e53d)
    5195460e - "NetSurf_OS3" Hunk 0000 Offset 0000360e (SegList: 14654401)
    519545fa - "NetSurf_OS3" Hunk 0000 Offset 000035fa (SegList: 14654401)
    51969f1a - "NetSurf_OS3" Hunk 0000 Offset 00018f1a (SegList: 14654401)
    00000001 - "SYS:System/GrimReaper" Hunk 0000 Offset 00000000 (SegList: 1595e53d)
    01dbdcc2 - "Kickstart/kernel" Hunk 0001 Offset 0015dcc2

68k disassembly:
 51e04f7c: 0010200d             ori.b             #0xd,(a0)
 51e04f80: 4cdf7c00             movem.l           (sp)+,a2-a6
*51e04f84: 4e75                 rts              
 51e04f86: 2f0e                 move.l            a6,-(sp)
 51e04f88: 4ab9533e87d0         tst.l             0x533e87d0.l

System information:

CPU
 Model: AMCC PPC440EP V1.3
 CPU speed: 599 MHz
 FSB speed: 133 MHz
 Extensions:  

Machine
 Machine name: Sam440EP
 Memory: 524288 KB
 Extensions: bus.pci

Expansion buses
 PCI/AGP
  00:00.0 Vendor 0x1014 Device 0x027F
  00:0A.0 Vendor 0x12D8 Device 0x8150
  00:0C.0 Vendor 0x1002 Device 0x4C66
   Range 0: A8000000 - B0000000 (PREF.MEM)
   Range 1: 00001000 - 00001100 (IO)
   Range 2: B0000000 - B0010000 (MEM)
  00:0E.0 Vendor 0x1095 Device 0x3114
   Range 0: 00001100 - 00001108 (IO)
   Range 1: 00001108 - 00001110 (IO)
   Range 2: 00001110 - 00001118 (IO)
   Range 3: 00001118 - 00001120 (IO)
   Range 4: 00001120 - 00001130 (IO)
  01:04.0 Vendor 0x1013 Device 0x6005
   Range 0: A0000000 - A0001000 (MEM)
   Range 1: A0010000 - A0020000 (MEM)
  01:05.0 Vendor 0x1131 Device 0x1561
   Range 0: A0020000 - A0021000 (MEM)
  01:05.1 Vendor 0x1131 Device 0x1561
   Range 0: A0021000 - A0022000 (MEM)
  01:05.2 Vendor 0x1131 Device 0x1562
   Range 0: A0022000 - A0022100 (MEM)
  01:06.0 Vendor 0x1260 Device 0x3873
   Range 0: A0023000 - A0024000 (PREF.MEM)

Doesn't mean much to me (although the mention of "datatypes.library" might suggest it's in the DataTypes reader, which is somewhere around the point it is crashing) as I still can't look up the offsets, but maybe Matthey can offer some insight?

Quote
edited the fonts settings in netsurf/users/admin/choices, which have been created (probably after first start since it contained default screenmode) which had no effect on the crash, so no need to fiddle with it too much i guess. ive been able to get through to gui two times, which worked so far that i could edit the path in address bar, felt though deadly slow in comparison with netsurf68k (sdl) or even aros owb on the same host.

Stability first, then speed.  I can't even figure out how fast it is until I can get it to a state where it works as a browser, so I have no idea how you've determined that it is so slow when it doesn't even show a single page yet.

Quote
note that the files in question do not seem to get created, like Resource.map as well as resources/themes/default/netsurf.png, even though the dir has all the other pngs, an netsurf.info is present.

If you run it with -v you'll see it is just scanning directories for files, it doesn't create anything outside of "users", there's just a pretty hefty search path to ensure the correct language or theme files are loaded even though it doesn't know whether the file is language or theme specific, or even if it's the correct filename.  It's a bit convoluted (I wrote it), and it still surprises me sometimes when it picks up a new file from the correct place.
« Last Edit: January 29, 2015, 11:46:07 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
 

Offline chris

Re: We need an iBrowse replacement for 68k!!!
« Reply #52 on: January 29, 2015, 11:50:10 PM »
Quote from: wawrzon;782610
i meant input in the address bar. cannot be normal like that, though, i hope.

If that's slow it's probably caused by all the other bugs.  It's unlikely to stay like that, it's a standard ReAction string gadget.
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar picture is Tabitha by Eric W Schwartz
 

Offline chris

Re: We need an iBrowse replacement for 68k!!!
« Reply #53 on: January 30, 2015, 12:31:48 AM »
Quote from: matthey;782612
I tried this font config in Choices and the bullet.library crashed fairly early.

I didn't try to bebug this further as I was able to get further without Choices. I can take a look if you want though.

That might be important.

Quote
I don't see many symbols beside the call to DoMethod() so the function doing the DoMethod() call is probably a "static" function. The problem is a bad pointer argument being passed to DoMethod(). The base pointer above is A0=FBFBFBFB and on my current run is A0=A7A7A7A7. This is probably an unitialized pointer from MuGuardianAngel munging of memory. I may know after I step a bit but I'll post this in case it crashes.

I'll leave you to it and pick this up again tomorrow, as it's late here.  I've just uploaded another new build with minor changes, but it has the fonts set to the old CG fonts by default, so if you still get the bullet.library crashes I think they will need investigating.
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar picture is Tabitha by Eric W Schwartz
 

Offline chris

Re: We need an iBrowse replacement for 68k!!!
« Reply #54 on: January 30, 2015, 09:54:24 AM »
Quote from: matthey;782612
Edit: I believe this hit is from ami_handle_msg() in /amiga/gui.c. I can see calls to ami_401login_event() and ami_try_quit() probably before the DoMethod() call and a call to ami_gui_get_space_box() right after. What is generating the call to DoMethod() I can't tell from the source. DoMethod() is a GCC or NetSurf function with what looks like 3 stack based arguments and *not* an AmigaOS library call.


DoMethod is an amiga.lib function.  I think what you're referring to must be the RA_HandleInput() call (which is a macro - and actually calls DoMethod) around here in the source (there's a ami_gui_trap_mouse before the ami_gui_get_space_box though, unless you're only seeing functions that are being called).

I'm not sure why this would be called with a NULL pointer as there are only two arguments, and one of those is a pointer to a variable on the stack, so somehow we're getting a NULL window object there.  If that's the case it's easily fixed anyway.

Quote

Edit2: I believe the next 2 hits from this same build come from ami_mime_entry_locate in /amiga/filetype.c. This would be a bit after the GetHead(ami_mime_list). There is another unitialized pointer in a list or structure.


Most likely caused by me not checking for NULL here.
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar picture is Tabitha by Eric W Schwartz
 

Offline chris

Re: We need an iBrowse replacement for 68k!!!
« Reply #55 on: January 30, 2015, 03:32:51 PM »
Quote from: matthey;782612
I tried this font config in Choices and the bullet.library crashed fairly early.


I've just twigged what the cause of that is.  I'll put a fixed version up later.
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar picture is Tabitha by Eric W Schwartz
 

Offline chris

Re: We need an iBrowse replacement for 68k!!!
« Reply #56 on: January 30, 2015, 08:01:32 PM »
Quote from: matthey;782645
The DoMethod() that I describe is called with a BSR and *not* JSR (xxx,A6) so it is *not* an AmigaOS call with a library base in A6. The DoMethod() function calls some AmigaOS functions though. There is a good chance the code that gives the DoMethod() is from RA_HandleInput() and may be from amiga.lib. It looked too big to me to be a stub.

I don't think DoMethod is a stub - it's a real function.  It was moved to Intuition in OS4 and renamed IDOMethod, but on OS3 it's in the libamiga static link library.

Quote
The freeze was from a bullet.library SetInfoA() call if you want verification ;).

Yes, confident I've fixed that, thanks.

I've uploaded another new version.  Changes are:
bullet access is fixed
font scanner enabled
possible but sceptical that the other two hits were fixed

The font scanner appears to be working but freezes at the end, I suspect it's another NULL pointer access.  Actually I'm suspecting I've done something wrong with my list access loops, which are defined like this:

Code: [Select]
node = GetHead(list);
do {
nnode = GetSucc(node);
// more code here
} while((node = nnode));

This works fine on OS4, but when built for OS3 I think it's not stopping properly :)

GetSucc(node) is defined as node ? node->ln_Succ : NULL
It was just node->ln_Succ but I put some extra armour around it.  It doesn't seem to have helped though.

GetHead is:
Code: [Select]
struct Node *GetHead(struct List *list)
{
struct Node *res = NULL;

if ((NULL != list) && (NULL != list->lh_Head->ln_Succ))
{
res = list->lh_Head;
}
return res;
}

Can anybody spot anything obviously wrong?

Other than that, see if the previous two hits were fixed.  You can trick it into skipping the font scan by creating a file in your user directory called FontGlyphCache, containing:
0x0000 "CGTimes"

(hmm, I seem to have broken font scanning on OS4 too - not entirely sure how that has happened)
edit: fixed the OS4 crash, sadly that's not what is causing the freeze on OS3 though.  Re-compiled and re-uploaded.
« Last Edit: January 30, 2015, 08:58:11 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
 

Offline chris

Re: We need an iBrowse replacement for 68k!!!
« Reply #57 on: January 30, 2015, 11:32:31 PM »
Quote from: buzz;782662
 if (node->ln_Succ->ln_Succ == NULL) return NULL;


This is interesting, and appears to have solved my problem.

Sadly it hasn't magically cured everything else, but certainly the font scanner has stopped freezing.

New build uploaded.
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar picture is Tabitha by Eric W Schwartz
 

Offline chris

Re: We need an iBrowse replacement for 68k!!!
« Reply #58 on: January 31, 2015, 12:24:23 AM »
Quote from: matthey;782673
Perhaps the code above will not get the last node in a list? I suspect that some of the list handling code doesn't handle exec empty lists correctly. An empty exec list looks like there is one more node in it when it is empty but it is actually pointing back to the list header.

I think it stops the list header being used as a node, whereas without it the list header ends up being parsed and we get problems.

All my lists are checked with Is(Min)ListEmpty before proceeding even to the GetHead.

I'm still getting the crash around RA_HandleInput.  Curiously it sometimes gets past that and tells me a WMHI_ACTIVE message (262144 - which I think is WMHI_ACTIVE anyway) is received.  WMHI_ACTIVE doesn't do much at all.
« Last Edit: January 31, 2015, 12:27:34 AM by chris »
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar picture is Tabitha by Eric W Schwartz
 

Offline chris

Re: We need an iBrowse replacement for 68k!!!
« Reply #59 from previous page: January 31, 2015, 11:45:33 AM »
Quote from: matthey;782676
Processing the exec list header as a node is basically what I was trying to say and it's a common problem with exec lists. Do the list nodes have many data (non-link) pointers? If so, would it be easy to define data (like padding) and clear the memory below the List or MinList header structures? Then if the list header was used like a node for a pointer, it would usually generate a MuForce/Enforcer hit to address 0 which we should be able to catch.

OK, well I'm pretty sure Buzz's code is OK as it's in use elsewhere, but I've added some padding to the list structure in the function which usually allocates the memory for my lists, so if it is still reading the list header anywhere we'll see it.

Quote
The RA_HandleInput problem is tough because there is a lot of abstraction in this area. This is where it would be nice to have line debug and know the source lines. I can normally pretty well compare the C source to assembler but not here.

I added some more debugging to try and track this down, and it seems to be consistently crashing after RA_HandleInput now, so I'm thinking I've fixed this.  You'll see how the function is called on the debug now, which might help.

Could you have a look at the new build and see what you get?  Thanks for your help!

edit: fixed build as an earlier fix got reverted accidentally
« Last Edit: January 31, 2015, 12:07:57 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