Welcome, Guest. Please login or register.

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

Description:

0 Members and 2 Guests are viewing this topic.

Offline wawrzon

Re: We need an iBrowse replacement for 68k!!!
« Reply #314 on: January 29, 2015, 11:45:16 PM »
Quote
A slightly more useful crashlog here:

yes, would have to reactivate muforce and recall how to recover offsets and find the offending functions, wasnt very good at it, ever, alas. but lets see.

Quote
so I have no idea how you've determined that it is so slow when it doesn't even show a single page yet

i meant input in the address bar. cannot be normal like that, though, i hope.
 

Offline chris

Re: We need an iBrowse replacement for 68k!!!
« Reply #315 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 matthey

  • Hero Member
  • *****
  • Join Date: Aug 2007
  • Posts: 1294
    • Show only replies by matthey
Re: We need an iBrowse replacement for 68k!!!
« Reply #316 on: January 29, 2015, 11:56:06 PM »
Quote from: chris;782539
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.

I tried this font config in Choices and the bullet.library crashed fairly early.

Code: [Select]
Exception !!   00000003     TCB: 08AF5338     CTX: 081C0380     SSP: 082816DC
USP : 0911BED0 SR: 0004  (U0)(-)(-)  TCB: 08AF5338
Data: 097AD9E8 00000000 0000000B 00000400 00000100 022B7B1D 022B0D13 00000000
Addr: 0911BEE8 0911BF08 097AC870 08AF5338 097AD9E8 0911BF68 ABADF00D 082816DC
Stck: 0000000B 00000400 08B4F53C 0911BF68 097ADDEC 097D200A 0911BF08 00000000
Stck: 08B58390 080189F4 09005FDE 0000000B 0911BF08 097AD9E8 80000001 00550055
Stck: 80000008 000B0000 8000000E 00000000 8000000F 00000000 8000000A 00000000
----> 097D184E - "LIBS:bullet.library"  Hunk 0000 Offset 0000593E
----> 08B4F53C - "netsurf"  Hunk 0000 Offset FFFFFFFC
----> 097D200A - "LIBS:bullet.library"  Hunk 0000 Offset 000060FA
----> 08B58390 - "netsurf"  Hunk 0000 Offset 00008E50
----> 09005FDE - "netsurf"  Hunk 0000 Offset 004B6A9E
097d180e :  001c 6718                  ori.b #$18,(a4)+
097d1812 :  72ff                       moveq.l #-$1,d1
097d1814 :  b2ac 0020                  cmp.l $20(a4),d1
097d1818 :  6710                       beq.s $97d182a
097d181a :  4a6c 0024                  tst.w $24(a4)
097d181e :  670a                       beq.s $97d182a
097d1820 :  48c0                       ext.l d0
097d1822 :  0c80 0000 ffff             cmpi.l #$ffff,d0
097d1828 :  6604                       bne.s $97d182e
097d182a :  7006                       moveq.l #$6,d0
097d182c :  6058                       bra.s $97d1886
097d182e :  7e01                       moveq.l #$1,d7
097d1830 :  6014                       bra.s $97d1846
097d1832 :  202d 0004                  move.l $4(a5),d0
097d1836 :  7e01                       moveq.l #$1,d7
097d1838 :  3940 0050                  move.w d0,$50(a4)
097d183c :  6008                       bra.s $97d1846
097d183e :  7001                       moveq.l #$1,d0
097d1840 :  6044                       bra.s $97d1886
097d1842 :  7002                       moveq.l #$2,d0
097d1844 :  6040                       bra.s $97d1886
097d1846 :  41ef 0018                  lea.l $18(a7),a0
097d184a :  2c6c 1100                  movea.l $1100(a4),a6
097d184e : *4eae ffd0                  jsr -$30(a6)
097d1852 :  2a40                       movea.l d0,a5
097d1854 :  4a80                       tst.l d0
097d1856 :  6600 fc68                  bne $97d14c0
097d185a :  4a07                       tst.b d7
097d185c :  6726                       beq.s $97d1884
097d185e :  4a2c 0015                  tst.b $15(a4)
097d1862 :  6704                       beq.s $97d1868
097d1864 :  7009                       moveq.l #$9,d0
097d1866 :  601e                       bra.s $97d1886
097d1868 :  4a2c 0016                  tst.b $16(a4)
097d186c :  6704                       beq.s $97d1872
097d186e :  700a                       moveq.l #$a,d0
097d1870 :  6014                       bra.s $97d1886
097d1872 :  486c 0018                  pea.l $18(a4)
097d1876 :  6100 af3e                  bsr $97cc7b6
097d187a :  584f                       addq.w #$4,a7
097d187c :  4a40                       tst.w d0
097d187e :  6704                       beq.s $97d1884
097d1880 :  7003                       moveq.l #$3,d0
097d1882 :  0c40 7000                  cmpi.w #$7000,d0
097d1886 :  4cdf 608c                  movem.l (a7)+,d2-d3/d7/a5-a6
097d188a :  4e75                       rts
097d188c :  9efc 000c                  suba.w #$c,a7
Name: "Shell Process"  CLI: "netsurf"

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.


Quote from: chris;782589
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.

I have the debugger stopped on the first hit while I post from AWeb on the same Amiga. Images in AWeb will load but are immediate flushed despite plenty of memory (edit: my 2MB of gfx mem is <512k with P96 RTG which explains the flushing and slowness) on  and the system is slower than it should be so there must already be some kind of problem. It seems stable enough though.

The last NetSurf debug output:

Code: [Select]
(12.866687) amiga/gui.c ami_openscreen 725: Screen signal 22
(14.550011) amiga/font.c ami_font_open 381: Font cache miss: DejaVu Sans
(14.583344) amiga/os3support.c OpenOutlineFont 64: Unable to open FONTS:DejaVu Sans.otag
(14.600012) amiga/font.c ami_font_open 388: Requested font not found: DejaVu Sans
(14.633347) amiga/misc.c ami_misc_req 54: Unable to open
DejaVu Sans
(14.833350) amiga/gui.c gui_window_create 3713: Creating window object
(15.333339) amiga/gui.c gui_window_create 3978: Opening window
(15.450009) amiga/gui.c gui_window_create 3982: Window opened, adding border gadgets
(15.500009) desktop/browser.c browser_window_navigate 1895: bw 0x9660ba0, url about:welcome
(15.533344) desktop/browser.c browser_window_navigate 1994: Loading 'about:welcome'
(15.566682) amiga/gui.c ami_gui_splash_close 5254: Closing splash window

The MuForce hit:

Code: [Select]
LONG READ from FBFBFC03                        PC: 08C8352A
USP : 09240108 SR: 0010  (U0)(-)(-)  TCB: 08B40040
Data: 00000004 00000003 09281228 00000400 00000100 022FA539 022C9399 08C73284
----> 08C73284 - "NetSurf"  Hunk 0000 Offset FFFFFFFC
Addr: FBFBFBFB 08B40040 0912DE2C 08B40040 00000000 092401B0 08021A14 08280620
Stck: 00570001 0924018E 09281228 00000400 0912DE2C 08021A14 00030000 08B49A3A
Stck: 00000028 45BE29A9 00000118 00000400 00000100 022FA539 022C9399 08C73284
Stck: 00000001 08C3A9F8 0912DE2C 08B40040 00000000 09240178 08CA17E0 08020000
----> 08C8352A - "NetSurf"  Hunk 0000 Offset 000102A2
----> 0912DE2C - "NetSurf"  Hunk 0000 Offset 004BABA4
----> 08B49A3A - "C/MuGuardianAngel"  Hunk 0000 Offset 00002162
----> 08C73284 - "NetSurf"  Hunk 0000 Offset FFFFFFFC
----> 0912DE2C - "NetSurf"  Hunk 0000 Offset 004BABA4
----> 08CA17E0 - "NetSurf"  Hunk 0000 Offset 0002E558
08c834ea :  181c                       move.b (a4)+,d4
08c834ec :  206d ffd6                  movea.l -$2a(a5),a0
08c834f0 :  7004                       moveq.l #$4,d0
08c834f2 :  b0a8 000e                  cmp.l $e(a0),d0
08c834f6 :  6622                       bne.s $8c8351a
08c834f8 :  2f2d ffce                  move.l -$32(a5),-(a7)
08c834fc :  4eb9 08c9 8996             jsr $8c98996
08c83502 :  588f                       addq.l #$4,a7
08c83504 :  4a40                       tst.w d0
08c83506 :  6708                       beq.s $8c83510
08c83508 :  6100 24c4                  bsr $8c859ce
08c8350c :  6000 1808                  bra $8c84d16
08c83510 :  2b6d ffd2 ffd6             move.l -$2e(a5),-$2a(a5)
08c83516 :  6000 17ee                  bra $8c84d06
08c8351a :  41ed ffde                  lea.l -$22(a5),a0
08c8351e :  2f08                       move.l a0,-(a7)
08c83520 :  2f3c 0057 0001             move.l #$570001,-(a7)
08c83526 :  206d ffce                  movea.l -$32(a5),a0
08c8352a : *2f28 0008                  move.l $8(a0),-(a7)
08c8352e :  4eb9 0912 50d0             jsr $91250d0   ; <- this is DoMethod()
08c83534 :  4fef 000c                  lea.l $c(a7),a7
08c83538 :  2b40 fffc                  move.l d0,-$4(a5)
08c8353c :  4aad fffc                  tst.l -$4(a5)
08c83540 :  6700 17c4                  beq $8c84d06
08c83544 :  222d fffc                  move.l -$4(a5),d1
08c83548 :  0281 ffff 0000             andi.l #-$10000,d1
08c8354e :  2b41 ff70                  move.l d1,-$90(a5)
08c83552 :  0cad 0004 0000 ff70        cmpi.l #$40000,-$90(a5)
08c8355a :  6700 16e2                  beq $8c84c3e
08c8355e :  0cad 0004 0000 ff70        cmpi.l #$40000,-$90(a5)
08c83566 :  6236                       bhi.s $8c8359e
08c83568 :  0cad 0002 0000 ff70        cmpi.l #$20000,-$90(a5)
Name: "Shell Process"  CLI: "NetSurf"  Hunk 0000 Offset 000102A2

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.

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.

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.
« Last Edit: January 30, 2015, 03:02:16 AM by matthey »
 

Offline chris

Re: We need an iBrowse replacement for 68k!!!
« Reply #317 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 #318 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 #319 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 matthey

  • Hero Member
  • *****
  • Join Date: Aug 2007
  • Posts: 1294
    • Show only replies by matthey
Re: We need an iBrowse replacement for 68k!!!
« Reply #320 on: January 30, 2015, 04:09:21 PM »
Quote from: chris;782631
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).

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.

Quote from: chris;782642
I've just twigged what the cause of that is.  I'll put a fixed version up later.

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

Offline chris

Re: We need an iBrowse replacement for 68k!!!
« Reply #321 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 buzz

  • Hero Member
  • *****
  • Join Date: Mar 2002
  • Posts: 612
    • Show only replies by buzz
Re: We need an iBrowse replacement for 68k!!!
« Reply #322 on: January 30, 2015, 09:06:38 PM »
Should you check that list->lh_Head isn't null also ?

not sure if this will be of any use to you but this is from the hivelytracker source:

Code: [Select]
static struct Node *_GetHead(struct List *list)
{
  if ((!list) || (!list->lh_Head)) return NULL;
  if (list->lh_Head->ln_Succ == NULL) return NULL;
  return list->lh_Head;
}

static struct Node *_GetSucc(struct Node *node)
{
  if (node->ln_Succ->ln_Succ == NULL) return NULL;
  return node->ln_Succ;
}
« Last Edit: January 30, 2015, 09:11:35 PM by buzz »
 

Offline NovaCoder

Re: We need an iBrowse replacement for 68k!!!
« Reply #323 on: January 30, 2015, 09:59:52 PM »
Code: [Select]
struct Node *GetHead(struct List *list)
{
struct Node *res = NULL;

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

return res;
}

That's the obvious fix (checking if list->lh_Head != NULL)

Update: Duplicate post to above
« Last Edit: January 30, 2015, 10:52:44 PM by NovaCoder »
Life begins at 100 MIPS!


Nice Ports on AmiNet!
 

Offline matthey

  • Hero Member
  • *****
  • Join Date: Aug 2007
  • Posts: 1294
    • Show only replies by matthey
Re: We need an iBrowse replacement for 68k!!!
« Reply #324 on: January 30, 2015, 10:01:24 PM »
Quote from: buzz;782662
Should you check that list->lh_Head isn't null also ?

It should not be necessary unless checking for a corrupt or unitialized list (an empty list with no nodes is o.k). An AmigaOS list is initialized by setting the lh_Head field to the address of lh_Tail. Adding or removing nodes should never make this field NULL. An empty list (initialized List header but no nodes) will have the list lh_Head field set to the address of lh_Tail (list->lh_Head = &list.lh_Tail). The list header acts like a node when transversing the list in either direction.

Edit: The info above is good but the other I had was wrong. The list or list header (List structure) is not the same as the list Head (List->lh_Head->Node) which confused me. Chris's GetHead() still looks correct which extracts the Head node from a List header after checking that the pointer to the list is not NULL and that the list is not empty. The list is empty if (NULL == list->lh_Head->ln_Succ) or (list->lh_TailPred == (struct Node *)list). There is a macro called IsListEmpty() in exec/lists.h which uses the latter way to check for an empty list and could give something like the following if used.

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

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

It's more readable to me and should generate a little more optimal code than what Chris is using.
« Last Edit: February 03, 2015, 08:05:06 PM by matthey »
 

Offline chris

Re: We need an iBrowse replacement for 68k!!!
« Reply #325 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 matthey

  • Hero Member
  • *****
  • Join Date: Aug 2007
  • Posts: 1294
    • Show only replies by matthey
Re: We need an iBrowse replacement for 68k!!!
« Reply #326 on: January 31, 2015, 12:16:39 AM »
Code: [Select]
if (node->ln_Succ->ln_Succ == NULL) return NULL;
Quote from: chris;782672
This is interesting, and appears to have solved my problem.

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) or tries to process the last link in the list (either direction) which is the list header (valid data nodes have non-NULL successor and predecessor pointers).
« Last Edit: January 31, 2015, 12:35:33 AM by matthey »
 

Offline chris

Re: We need an iBrowse replacement for 68k!!!
« Reply #327 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 matthey

  • Hero Member
  • *****
  • Join Date: Aug 2007
  • Posts: 1294
    • Show only replies by matthey
Re: We need an iBrowse replacement for 68k!!!
« Reply #328 on: January 31, 2015, 01:25:51 AM »
Quote from: chris;782674
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.


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.

Quote from: chris;782674

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.


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.
« Last Edit: January 31, 2015, 01:39:53 AM by matthey »
 

Offline chris

Re: We need an iBrowse replacement for 68k!!!
« Reply #329 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