Scout (monitoring tool) crashing under WinUAE, someone can fix it?

hexaae · 04 July 2018, 11:07

(Not sure if this is the appropriate section or should go under Software forum main thread, sorry)

Hello,
just noticed that the excellent monitoring tool Scout http://aminet.net/package/util/moni/Scout_os3 has some issues with System button that randomly (click it for 50+ times and should happen at least once) triggers DEADEND (Divide by zero) crashes:

AFAICR this randomly happened also on my real A1200+B1260@66MHz, so it's a generic issue with the System section of this monitoring tool (bad CPU MHz calculation? Bad "Last Alert" routines to retrieve last GURU data?)

It seems to cause also illegal memory reads detected by WinUAEEnforcer:

Code:

Enforcer Hit! Bad program
Illegal LONG READ from: 00000100                PC: 40fbf248
Data: 00000000 40095a30 40ef0750 00000000 000080ff 40ee2a96 00000000 00000017
Addr: 00000000 40ee24cc 40ee254c 40ee254c 40eea480 40fbf248 4009700c 40002364
Stck: 00194fff aa440020 00000010 00000000 00000000 400906d8 0000005c 40c5cdfc
Stck: 40c66b6c 00004000 23c60000 400023a4 00000000 002d0003 40c12b3c 6974616c
Stck: 69616e6f 00000000 00000000 00000000 00000000 00000000 00000000 00027379
Stck: 732f776f 726b6265 6e63682e 63617461 6c6f6700 00000000 00000016 400906d8
Stck: 40373b42 400908ae 00000000 01000000 00000000 00000000 402c36e8 00000000
40fbf22c :   48e7 0006            MVMLE.L #$0006,-(A7)
40fbf230 :   2c79 40ee a53e       MOVEA.L $40eea53e [4009700c],A6
40fbf236 :   4bfa 0010            LEA.L (PC,$0010) == $40fbf248,A5
40fbf23a :   4eae fef2            JSR.L (A6, -$010e) == $40096efe
40fbf23e :   2280                 MOVE.L D0,(A1) [00000000]
40fbf240 :   2481                 MOVE.L D1,(A2) [00000000]
40fbf242 :   4cdf 6000            MVMEL.L #$6000,(A7)+
40fbf246 :   4e75                 RTS.L
40fbf248 : * 2028 0100            MOVE.L (A0, $0100) == $00000100 [00000000],D0
40fbf24c :   2228 0104            MOVE.L (A0, $0104) == $00000104 [00000000],D1
40fbf250 :   4e75                 RTS.L
40fbf252 :   48e7 0006            MVMLE.L #$0006,-(A7)
40fbf256 :   2c79 40ee a532       MOVEA.L $40eea532 [400008f4],A6
40fbf25c :   4bfa 000e            LEA.L (PC,$000e) == $40fbf26c,A5
40fbf260 :   4eae ffe2            JSR.L (A6, -$001e) == $40096fee
40fbf264 :   4cdf 6000            MVMEL.L #$6000,(A7)+
40fbf268 :   4e75                 RTS.L
Name: "Scout"

Enforcer Hit! Bad program
Illegal LONG READ from: 00000104                PC: 40fbf24c
Data: 00000000 40095a30 40ef0750 00000000 000080ff 40ee2a96 00000000 00000017
Addr: 00000000 40ee24cc 40ee254c 40ee254c 40eea480 40fbf248 4009700c 40002364
Stck: 00194fff aa440020 00000010 00000000 00000000 400906d8 0000005c 40c5cdfc
Stck: 40c66b6c 00004000 23c60000 400023a4 00000000 002d0003 40c12b3c 6974616c
Stck: 69616e6f 00000000 00000000 00000000 00000000 00000000 00000000 00027379
Stck: 732f776f 726b6265 6e63682e 63617461 6c6f6700 00000000 00000016 400906d8
Stck: 40373b42 400908ae 00000000 01000000 00000000 00000000 402c36e8 00000000
40fbf230 :   2c79 40ee a53e       MOVEA.L $40eea53e [4009700c],A6
40fbf236 :   4bfa 0010            LEA.L (PC,$0010) == $40fbf248,A5
40fbf23a :   4eae fef2            JSR.L (A6, -$010e) == $40096efe
40fbf23e :   2280                 MOVE.L D0,(A1) [00000000]
40fbf240 :   2481                 MOVE.L D1,(A2) [00000000]
40fbf242 :   4cdf 6000            MVMEL.L #$6000,(A7)+
40fbf246 :   4e75                 RTS.L
40fbf248 :   2028 0100            MOVE.L (A0, $0100) == $00000100 [00000000],D0
40fbf24c : * 2228 0104            MOVE.L (A0, $0104) == $00000104 [00000000],D1
40fbf250 :   4e75                 RTS.L
40fbf252 :   48e7 0006            MVMLE.L #$0006,-(A7)
40fbf256 :   2c79 40ee a532       MOVEA.L $40eea532 [400008f4],A6
40fbf25c :   4bfa 000e            LEA.L (PC,$000e) == $40fbf26c,A5
40fbf260 :   4eae ffe2            JSR.L (A6, -$001e) == $40096fee
40fbf264 :   4cdf 6000            MVMEL.L #$6000,(A7)+
40fbf268 :   4e75                 RTS.L
40fbf26a :   4e71                 NOP.L
Name: "Scout"

Enforcer Hit! Bad program
Illegal LONG READ from: 00000100                PC: 40fbf248
Data: 00000000 40095a30 40ef0750 00000000 000080ff 40ee2a96 00000000 00000037
Addr: 00000000 40ee24cc 40ee254c 40ee254c 40eea480 40fbf248 4009700c 40002364
Stck: 00194fff aa440020 00000010 00000000 00000000 400906d8 0000005c 40c5cdfc
Stck: 40c66b6c 00004000 23c60000 400023a4 00000000 002d0003 40c12b3c 6974616c
Stck: 69616e6f 00000000 00000000 00000000 00000000 00000000 00000000 00027379
Stck: 732f776f 726b6265 6e63682e 63617461 6c6f6700 00000000 00000016 400906d8
Stck: 40373b42 400908ae 00000000 01000000 00000000 00000000 402c36e8 00000000
40fbf22c :   48e7 0006            MVMLE.L #$0006,-(A7)
40fbf230 :   2c79 40ee a53e       MOVEA.L $40eea53e [4009700c],A6
40fbf236 :   4bfa 0010            LEA.L (PC,$0010) == $40fbf248,A5
40fbf23a :   4eae fef2            JSR.L (A6, -$010e) == $40096efe
40fbf23e :   2280                 MOVE.L D0,(A1) [00000000]
40fbf240 :   2481                 MOVE.L D1,(A2) [00000000]
40fbf242 :   4cdf 6000            MVMEL.L #$6000,(A7)+
40fbf246 :   4e75                 RTS.L
40fbf248 : * 2028 0100            MOVE.L (A0, $0100) == $00000100 [00000000],D0
40fbf24c :   2228 0104            MOVE.L (A0, $0104) == $00000104 [00000000],D1
40fbf250 :   4e75                 RTS.L
40fbf252 :   48e7 0006            MVMLE.L #$0006,-(A7)
40fbf256 :   2c79 40ee a532       MOVEA.L $40eea532 [400008f4],A6
40fbf25c :   4bfa 000e            LEA.L (PC,$000e) == $40fbf26c,A5
40fbf260 :   4eae ffe2            JSR.L (A6, -$001e) == $40096fee
40fbf264 :   4cdf 6000            MVMEL.L #$6000,(A7)+
40fbf268 :   4e75                 RTS.L
Name: "Scout"

Enforcer Hit! Bad program
Illegal LONG READ from: 00000104                PC: 40fbf24c
Data: 00000000 40095a30 40ef0750 00000000 000080ff 40ee2a96 00000000 00000037
Addr: 00000000 40ee24cc 40ee254c 40ee254c 40eea480 40fbf248 4009700c 40002364
Stck: 00194fff aa440020 00000010 00000000 00000000 400906d8 0000005c 40c5cdfc
Stck: 40c66b6c 00004000 23c60000 400023a4 00000000 002d0003 40c12b3c 6974616c
Stck: 69616e6f 00000000 00000000 00000000 00000000 00000000 00000000 00027379
Stck: 732f776f 726b6265 6e63682e 63617461 6c6f6700 00000000 00000016 400906d8
Stck: 40373b42 400908ae 00000000 01000000 00000000 00000000 402c36e8 00000000
40fbf230 :   2c79 40ee a53e       MOVEA.L $40eea53e [4009700c],A6
40fbf236 :   4bfa 0010            LEA.L (PC,$0010) == $40fbf248,A5
40fbf23a :   4eae fef2            JSR.L (A6, -$010e) == $40096efe
40fbf23e :   2280                 MOVE.L D0,(A1) [00000000]
40fbf240 :   2481                 MOVE.L D1,(A2) [00000000]
40fbf242 :   4cdf 6000            MVMEL.L #$6000,(A7)+
40fbf246 :   4e75                 RTS.L
40fbf248 :   2028 0100            MOVE.L (A0, $0100) == $00000100 [00000000],D0
40fbf24c : * 2228 0104            MOVE.L (A0, $0104) == $00000104 [00000000],D1
40fbf250 :   4e75                 RTS.L
40fbf252 :   48e7 0006            MVMLE.L #$0006,-(A7)
40fbf256 :   2c79 40ee a532       MOVEA.L $40eea532 [400008f4],A6
40fbf25c :   4bfa 000e            LEA.L (PC,$000e) == $40fbf26c,A5
40fbf260 :   4eae ffe2            JSR.L (A6, -$001e) == $40096fee
40fbf264 :   4cdf 6000            MVMEL.L #$6000,(A7)+
40fbf268 :   4e75                 RTS.L
40fbf26a :   4e71                 NOP.L
Name: "Scout"

Since I've found the project + sources are available on SourceForge https://sourceforge.net/projects/sco...s/Scout-Amiga/ I wondered if some programmer could fix these annoying issues in this otherwise excellent AmigaOS monitor, and make it more compatible also with WinUAE and very fast CPU emulation.

EDIT:
SOLUTION
http://eab.abime.net/showpost.php?p=...5&postcount=29

DamienD · 04 July 2018, 11:36

@hexaae; I've noticed that all your recent screen captures are always way to blurry to be of any use

You should try another image hosting site.

hexaae · 04 July 2018, 11:52

It's a site defect indeed: you have to click in the bottom right to open full-res image, or simply extend the window of your current browser and reload to display a magnify cursor to zoom in at full res…

I use that site because has many advantages though: accepts direct CTRL+V to paste image from Windows clipboard (!), and can organize uploaded images in your account with subdirs etc... Do you know others offering the same?

DamienD · 04 July 2018, 12:08

Quote:

Originally Posted by hexaae

It's a site defect indeed: you have to click in the bottom right to open full-res image, or simply extend the window of your current browser and reload to display a magnify cursor to zoom in at full res…

What a horrible process; I (and I'm sure others) won't bother doing this...

Quote:

Originally Posted by hexaae

I use that site because has many advantages though: accepts direct CTRL+V to paste image from Windows clipboard (!), and can organize uploaded images in your account with subdirs etc... Do you know others offering the same?

I don't know other image hosting sites that let you past directly from the clipboard but to be honest have never really looked.

Just save the image and then upload; only takes a few seconds

Anyway, sorry for the off topic Toni but I think hexaae needs to address this.

daxb · 04 July 2018, 15:09

Quote:

Originally Posted by hexaae

just noticed that the excellent monitoring tool Scout http://aminet.net/package/util/moni/Scout_os3 has some issues with System button

As far as I know Scouts System function uses identify.library for it. I'm using V37.1 what works but there was an older/newer version that crash Scout. Without the library Scout should do nothing if you click the System button. I would try different versions of the library.

PeterK · 04 July 2018, 16:09

The Enforcer hit has to occur, because the last alert number is stored at address $100. That's not a bug. But I also remember that I once had these crashes with Scout on some test systems when I tried to open the system page. It may depend on the OS version or some libraries as daxb said. Scout runs absolutly stable on my main OS 3.9 system. Btw, there is no Enforcer hit on OS 3.9 when there was no alert before.

Code:

See if the system wants a guru put up after reboot.

This works as follows:  If for some reason, a guru can't be put
up in the normal fashion, the system writes "HELP" at location
zero, writes the alert data (number and 32-bit parameter) at
location $000100, and resets.

Early in the startup code (right here), this "HELP" is checked
for.  If it is present, it is removed, and the data at location
$000100 is loaded into registers D6 and D7.  If no "HELP" is
found, register D6 is loaded with -1.  This data will later be
put at ExecBase->LastAlert, once the ExecBase structure has been
built.

hexaae · 04 July 2018, 16:27

@daxb
I'm using the same identify.library included with scout3.6 archive…

@PeterK
It is perfectly stable, except the System button. If you open the System panel sometimes randomly it will crash with DEADEND. To reproduce the crash you can also try to keep pressing the "Update" button at the bottom of the System panel for 1-2 minutes… Usually after 50+ clicks (I know it's stupid but sometimes randomly happens also the first time you click on System button

) you should face the random DEADEND guru.

For the Enforcer hit… ok but it doesn't seem to work well in Scout since it's always 00000000 <none> even after a Recoverable Alert (or it's by design ignoring Recoverable Alerts?).
LAlert (ASM source included) from Aminet http://m68k.aminet.net/package/util/moni/LAlert cause no illegal LONG reads BTW…
LAlert package contains also the "Alert" command to cause a harmless recoverable alert for testing purposes.

PeterK · 04 July 2018, 16:44

Yes, I'm also using identify.library 37.1, the same as in the Scout package.

I've tried to open and close the "System" page with <Left Amiga>X/Y or update more than 50 times and "Last Alert" too, but no crashes.

hexaae · 04 July 2018, 17:44

Thanks for testing. Will try also on a very basic WB3.1 HDF and see if it's actually a Scout bug or maybe something else in my usual WB software cfg making System>Update unstable.

hexaae · 04 July 2018, 19:08

@PeterK
Do you use MMULib package? Do you use 060/040 for your WB3.9?

hexaae · 04 July 2018, 20:02

Looks like a MMULib problem...
I've now reverted my WB3.9 env to Phase5 libraries, and renamed Thor's mmu.library:

Code:

ls LIBS:680#?.library
Directory "LIBS:" on Mercoledì 04-Lug-18
68040.library                      748 ----rwed 16-Feb-02 03:58:17
68040new.library                 86276 ----rwed 28-Giu-16 01:20:54
68040old.library                 43888 ----rwed 28-Giu-16 01:20:54
68060.library                   161988 ----rwed 28-Giu-16 01:20:53

And indeed I can't reproduce it anymore (will test it for a couple of days). BTW, I've noticed now Scout reports 60-40MHz for 68060 compared to 7-0 when I had mmulib system... mmmh..

EDIT:
Doh! Just happened again after another hundreds of "Update" button clicks! LOL
Will definitely reinstall a basic WB3.1 and WB3.9 and check if I can reproduce it in those envs...

hexaae · 05 July 2018, 09:44

Checked on a new HDF with WB3.1 first install and just Picasso96 + MUI + WinUAE with Z3 RTG. I was able to reproduce it. Never in AGA mode (i.e. no Z3 RTG) but always in Z3 RTG Picasso: after you press many times "Update" in the System window of Scout, there is a random DEADEND Divide by zero guru.

WinUAE configured for 040 + FPU internal (Fastest possible, JIT direct 8MB), CPU Z3 RAM 64MB, RTG Z3 32MB, Display > Native/RTG = full-window.

PeterK · 05 July 2018, 10:43

Quote:

Originally Posted by hexaae

@PeterK
Do you use MMULib package? Do you use 060/040 for your WB3.9?

No, I'm always using the 68020 with the 68882 with Jit (no MMU). I don't like the 040/060 CPU very much and can't see any advantage of using them on WinUAE except for testing 040/060 software versions. A 060 can't be emulated faster on the same host than a 020. The MMU could be usefull for running some of the MuTools like MuForce, but I've never tried that yet.

I have P96 installed using the uaegfx monitor driver.

And no, I didn't try to reopen the system page in Scout for 100+ times, should I do that?

Although I've already searched all my posts at EAB and A1k.org I couldn't find any old comments about these crashes with the system page in Scout that I once had on one of my test systems, too.

Did you try to run SnoopDos in the background with a log onto a floppy image or to another partition where no data can be damaged?

hexaae · 05 July 2018, 11:49

Seems to happen only in 040/060 mode + Z3 RTG P96 indeed… mmh
Some 3D games or demos require higher CPU, so I prefer a universal setup with 060.

Need more testing in the next days but I'm quite sure of the bug. Don't know if it's WinUAE emu or Scout (very likely because I have no random crashes whatsoever and WB uptimes of 6+ hours, apart with Scout "System" panel and is always the same crash: "Divide by zero" DEADEND) though…

If I use Phase5 libs instead of MMULib for 060, it happens even more rarely so the suspect is around Scout's CPU/MMU detection/emu

EDIT: I was wrong, reproduced also with 020+882 with MMUlib installed. Have to try 020 without mmu extra libs...

PeterK · 05 July 2018, 13:25

Tried more than 150 times, but no crash.
Scout(with MUI) needs more than 4400 bytes of stack, so you should have StackAttack installed to increase the stack size. I'm using 10000 bytes.

hexaae · 05 July 2018, 14:09

Yes, I use 20000

daxb · 05 July 2018, 14:21

I also hit the System button more then 50 times without any problem but maybe I've a bugfix/patch running that prevent it. A1200 040 AGA 3.1 with DOpus5 and patches running. Old muimaster.library used, not the buggy 020 version.

Toni Wilen · 05 July 2018, 14:29

Enter UAE debugger, set break point to divide by zero exception vector. (i to list vectors, f <address of divide by zero vector>. Trigger it. Type H 100 and attach the output. There is chance this output helps to find out where and why it happens.

JIT must be off.

hexaae · 05 July 2018, 19:22

Will do…
In the meanwhile I tried changing CPU, cfg, JIT on/off, switched 0x0 libraries (std CBM 68040.library, MMULib, Phase 5 060 package…), created minimal boot cfg and HDF with WB3.1 and P96 + MUI…. and current results are:

it happens only with RTG Z3 uaegfx (i.e. if I boot in AGA mode removing uaegfx monitor driver, I can't replicate the crash)
does never happen if I rename identify.library

hexaae · 05 July 2018, 19:39

I made a ready to boot test env, if someone wants to try and tell me if can replicate the GURU, pressing furiously the button Scout > System > "Update"

:
[url]-removed-(14MB)
Pass: -removed-

Env is basic WB3.1 + P96 + MUI… configured for P96 Z3 RTG uaegfx 1920x1080. Paths are all relative and should run out-of-the-box.

PROCESSOR: CPU 68020/68882fpu
CUSTOM CHIPS: AA PAL Alice (id=$0023), AA Lisa (id=$00F8)
VERS: Kickstart version 40.68, Exec version 40.10, Disk version 40.42
RAM: Node type $A, Attributes $405 (FAST), at $40000000-$43FFFFFF (64.0 meg)
Node type $A, Attributes $705 (FAST), at $C00000-$C7FFFF (0.5 meg)
Node type $A, Attributes $703 (CHIP), at $400-$1FFFFF (~2.0 meg)
BOARDS:
Board + ROM (HD?) (unidentified): Prod=2011/82($7DB/$52) (@$E90000 64K)
RAM (unidentified): Prod=2011/83($7DB/$53)
(@$40000000, size 64meg, subsize same Mem)
Board (unidentified): Prod=2011/96($7DB/$60)
(@$44000000, size 16meg, subsize same)
Board (unidentified): Prod=2011/4($7DB/$4) (@$F00000 64K)

04 July 2018, 16:09	#6
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,365	The Enforcer hit has to occur, because the last alert number is stored at address $100. That's not a bug. But I also remember that I once had these crashes with Scout on some test systems when I tried to open the system page. It may depend on the OS version or some libraries as daxb said. Scout runs absolutly stable on my main OS 3.9 system. Btw, there is no Enforcer hit on OS 3.9 when there was no alert before. Code: See if the system wants a guru put up after reboot. This works as follows: If for some reason, a guru can't be put up in the normal fashion, the system writes "HELP" at location zero, writes the alert data (number and 32-bit parameter) at location $000100, and resets. Early in the startup code (right here), this "HELP" is checked for. If it is present, it is removed, and the data at location $000100 is loaded into registers D6 and D7. If no "HELP" is found, register D6 is loaded with -1. This data will later be put at ExecBase->LastAlert, once the ExecBase structure has been built. Last edited by PeterK; 04 July 2018 at 16:25.

04 July 2018, 19:08	#10
hexaae Bug hunter Join Date: Jul 2006 Location: Italy Age: 48 Posts: 2,161	@PeterK Do you use MMULib package? Do you use 060/040 for your WB3.9? Last edited by hexaae; 04 July 2018 at 19:29.

04 July 2018, 20:02	#11
hexaae Bug hunter Join Date: Jul 2006 Location: Italy Age: 48 Posts: 2,161	Looks like a MMULib problem... I've now reverted my WB3.9 env to Phase5 libraries, and renamed Thor's mmu.library: Code: ls LIBS:680#?.library Directory "LIBS:" on Mercoledì 04-Lug-18 68040.library 748 ----rwed 16-Feb-02 03:58:17 68040new.library 86276 ----rwed 28-Giu-16 01:20:54 68040old.library 43888 ----rwed 28-Giu-16 01:20:54 68060.library 161988 ----rwed 28-Giu-16 01:20:53 And indeed I can't reproduce it anymore (will test it for a couple of days). BTW, I've noticed now Scout reports 60-40MHz for 68060 compared to 7-0 when I had mmulib system... mmmh.. EDIT: Doh! Just happened again after another hundreds of "Update" button clicks! LOL Will definitely reinstall a basic WB3.1 and WB3.9 and check if I can reproduce it in those envs...

05 July 2018, 09:44	#12
hexaae Bug hunter Join Date: Jul 2006 Location: Italy Age: 48 Posts: 2,161	Checked on a new HDF with WB3.1 first install and just Picasso96 + MUI + WinUAE with Z3 RTG. I was able to reproduce it. Never in AGA mode (i.e. no Z3 RTG) but always in Z3 RTG Picasso: after you press many times "Update" in the System window of Scout, there is a random DEADEND Divide by zero guru. WinUAE configured for 040 + FPU internal (Fastest possible, JIT direct 8MB), CPU Z3 RAM 64MB, RTG Z3 32MB, Display > Native/RTG = full-window. Last edited by hexaae; 05 July 2018 at 09:53.

05 July 2018, 11:49	#14
hexaae Bug hunter Join Date: Jul 2006 Location: Italy Age: 48 Posts: 2,161	Seems to happen only in 040/060 mode + Z3 RTG P96 indeed… mmh Some 3D games or demos require higher CPU, so I prefer a universal setup with 060. Need more testing in the next days but I'm quite sure of the bug. Don't know if it's WinUAE emu or Scout (very likely because I have no random crashes whatsoever and WB uptimes of 6+ hours, apart with Scout "System" panel and is always the same crash: "Divide by zero" DEADEND) though… If I use Phase5 libs instead of MMULib for 060, it happens even more rarely so the suspect is around Scout's CPU/MMU detection/emu EDIT: I was wrong, reproduced also with 020+882 with MMUlib installed. Have to try 020 without mmu extra libs... Last edited by hexaae; 05 July 2018 at 12:10.

04 July 2018, 11:36	#2
DamienD Banned Join Date: Aug 2005 Location: London / Sydney Age: 47 Posts: 20,420	@hexaae; I've noticed that all your recent screen captures are always way to blurry to be of any use You should try another image hosting site.

04 July 2018, 11:52	#3
hexaae Bug hunter Join Date: Jul 2006 Location: Italy Age: 48 Posts: 2,161	It's a site defect indeed: you have to click in the bottom right to open full-res image, or simply extend the window of your current browser and reload to display a magnify cursor to zoom in at full res… I use that site because has many advantages though: accepts direct CTRL+V to paste image from Windows clipboard (!), and can organize uploaded images in your account with subdirs etc... Do you know others offering the same?

04 July 2018, 16:27	#7
hexaae Bug hunter Join Date: Jul 2006 Location: Italy Age: 48 Posts: 2,161	@daxb I'm using the same identify.library included with scout3.6 archive… @PeterK It is perfectly stable, except the System button. If you open the System panel sometimes randomly it will crash with DEADEND. To reproduce the crash you can also try to keep pressing the "Update" button at the bottom of the System panel for 1-2 minutes… Usually after 50+ clicks (I know it's stupid but sometimes randomly happens also the first time you click on System button ) you should face the random DEADEND guru. For the Enforcer hit… ok but it doesn't seem to work well in Scout since it's always 00000000 <none> even after a Recoverable Alert (or it's by design ignoring Recoverable Alerts?). LAlert (ASM source included) from Aminet http://m68k.aminet.net/package/util/moni/LAlert cause no illegal LONG reads BTW… LAlert package contains also the "Alert" command to cause a harmless recoverable alert for testing purposes.

04 July 2018, 16:44	#8
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,365	Yes, I'm also using identify.library 37.1, the same as in the Scout package. I've tried to open and close the "System" page with <Left Amiga>X/Y or update more than 50 times and "Last Alert" too, but no crashes.

04 July 2018, 17:44	#9
hexaae Bug hunter Join Date: Jul 2006 Location: Italy Age: 48 Posts: 2,161	Thanks for testing. Will try also on a very basic WB3.1 HDF and see if it's actually a Scout bug or maybe something else in my usual WB software cfg making System>Update unstable.

05 July 2018, 13:25	#15
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,365	Tried more than 150 times, but no crash. Scout(with MUI) needs more than 4400 bytes of stack, so you should have StackAttack installed to increase the stack size. I'm using 10000 bytes.

05 July 2018, 14:09	#16
hexaae Bug hunter Join Date: Jul 2006 Location: Italy Age: 48 Posts: 2,161	Yes, I use 20000

05 July 2018, 14:21	#17
daxb Registered User Join Date: Oct 2009 Location: Germany Posts: 3,303	I also hit the System button more then 50 times without any problem but maybe I've a bugfix/patch running that prevent it. A1200 040 AGA 3.1 with DOpus5 and patches running. Old muimaster.library used, not the buggy 020 version.

05 July 2018, 14:29	#18
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,506	Enter UAE debugger, set break point to divide by zero exception vector. (i to list vectors, f <address of divide by zero vector>. Trigger it. Type H 100 and attach the output. There is chance this output helps to find out where and why it happens. JIT must be off.

05 July 2018, 19:22	#19
hexaae Bug hunter Join Date: Jul 2006 Location: Italy Age: 48 Posts: 2,161	Will do… In the meanwhile I tried changing CPU, cfg, JIT on/off, switched 0x0 libraries (std CBM 68040.library, MMULib, Phase 5 060 package…), created minimal boot cfg and HDF with WB3.1 and P96 + MUI…. and current results are: it happens only with RTG Z3 uaegfx (i.e. if I boot in AGA mode removing uaegfx monitor driver, I can't replicate the crash) does never happen if I rename identify.library

05 July 2018, 19:39	#20
hexaae Bug hunter Join Date: Jul 2006 Location: Italy Age: 48 Posts: 2,161	I made a ready to boot test env, if someone wants to try and tell me if can replicate the GURU, pressing furiously the button Scout > System > "Update" : [url]-removed-(14MB) Pass: -removed- Env is basic WB3.1 + P96 + MUI… configured for P96 Z3 RTG uaegfx 1920x1080. Paths are all relative and should run out-of-the-box. PROCESSOR: CPU 68020/68882fpu CUSTOM CHIPS: AA PAL Alice (id=$0023), AA Lisa (id=$00F8) VERS: Kickstart version 40.68, Exec version 40.10, Disk version 40.42 RAM: Node type $A, Attributes $405 (FAST), at $40000000-$43FFFFFF (64.0 meg) Node type $A, Attributes $705 (FAST), at $C00000-$C7FFFF (0.5 meg) Node type $A, Attributes $703 (CHIP), at $400-$1FFFFF (~2.0 meg) BOARDS: Board + ROM (HD?) (unidentified): Prod=2011/82($7DB/$52) (@$E90000 64K) RAM (unidentified): Prod=2011/83($7DB/$53) (@$40000000, size 64meg, subsize same Mem) Board (unidentified): Prod=2011/96($7DB/$60) (@$44000000, size 16meg, subsize same) Board (unidentified): Prod=2011/4($7DB/$4) (@$F00000 64K) Last edited by hexaae; 05 July 2018 at 21:35. Reason: removed file, bad idea probably

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Winuae crashing!	8bitbob	support.WinUAE	3	07 December 2015 16:53
WinUAE 2.7.0 crashing	Retrofan	support.WinUAE	20	11 December 2013 20:24
WinUAE 1.3.4 in lores - crashing	killergorilla	support.WinUAE	10	06 September 2007 19:19
Winuae crashing	RickyC	support.WinUAE	4	29 May 2007 18:01
WinUAE 1.3 crashing	Tony Landais	support.WinUAE	11	26 July 2006 12:59