2024-09-08 01:15 CEST
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004091WHDLoad[All Projects] Generalpublic2019-03-13 15:082020-10-27 11:24
ReporterPaul Head 
Assigned ToWeplProject InfoHD-Installer for OS-Killer
http://whdload.de/		 
PrioritynormalSeveritycrashReproducibilityalways
StatusclosedResolutionunable to reproduce 
Product Version18.5 
Target VersionFixed in Version 
Summary0004091: Crash when WHDLoad-Startup attempts to close down Roadshow when the network wasn't previously available
DescriptionMy system (by choice) isn't connected to the internet upon boot (no Roadshow, no WirelessManager). So when I load a game and WHDLoad attempts to connect to the internet to check for the latest slave file it opens bsdsocket.library and what happens (this is my understanding at least) is that 'C:NetShutdown' in my WHDLoad-Startup is executed too soon - before bsdsocket.library has 'finished doing its stuff'. This causes an immediate freeze followed shortly by a reboot without guru.

I run a custom Multiscan screen on my led monitor and when the freeze occurs I get a distorted image for a little over a second (screen loses sync...has probably gone to PAL) and then the reboot. If I run in PAL, I just get the freeze with no distortion, and then the reboot.

If I am actually already connected to the internet, this fault doesn't occur.

A quick fix I found is to put a Wait command in the WHDLoad-Startup as such:

; stop Roadshow
C:Wait 1
C:NetShutdown

; stop wireless connection
Set WirelessManagerPID...etc
If...etc
  Break...etc
EndIf

Despite one second being far longer than what is needed, it does fix the problem. Even slowing my machine down a bit by disabling a cache or two fixes the problem without the Wait command.
Also, of course, uncommenting ;NoNetwork in the WHDLoad.prefs also fixes the problem at the expense of slave checking.
Steps To Reproduce80MHz 68060 (with FASTATA Mk.III)

Inside my WHDLoad.prefs as following:
----------
ConfigDelay=200
CoreDumpPath=T:
ExecuteStartup=Execute S:WHDLoad-Startup
NoAutoVec
NoFlushMem
;NoNetwork
NoWriteCache
QuitKey=$5d
SavePath=DH1:Software/....(long path)
----------

Inside WHDLoad-Startup as following:
----------
; stop Roadshow
C:NetShutdown

; stop wireless connection
Set WirelessManagerPID...etc
If...etc
  Break...etc
EndIf
----------

Then load any WHDLoad game.
Additional InformationA bit more info on the problem state:
It's rare that a game (any game that is) will load - but if it does get that far it will freeze and reboot after exiting (instead of doing it before hand). Or, it will seemingly load (go to PAL black screen) but all there is will be a black screen for a few seconds followed by a reboot. Buggy Boy appears to favour these last two scenarious, whereas ZoolAGA will nearly always be the instant freeze and reboot.

Also I might as well ask, shouldn't the WirelessManager command be inside WHDLoad-Cleanup somewhere above ';start Roadshow' ? Then users can choose to uncomment it if they so please.

;BEGIN WirelessManager
Run <>NIL: C:WirelessManager prism2.device
;END WirelessManager
TagsNo tags attached.
MachineA1200
CPU68060
CPUSpeed75
ChipSetAGA
GFXCardNone
ChipMem2 MB
FastMem32 MB
WorkbenchOS 3.1
KickROM40 - Kick 3.1
KickSoftNone
WHDLoad18.5
Attached Files

-Relationships
+Relationships

-Notes

note ~0006753

Wepl (manager)

2019-03-18 14:44

 Hi Paul, thanks for the report.
As I understand this is a problem in Roadshow and must be fixed there. C:NetShutdown should not crash.
The only idea would be to add the 1 second wait you are using as workaround.

Thanks for the hint with WirelessManager in WHDLoad-Cleanup. I will add this to the supplied example script.

note ~0006756

Paul Head (reporter)

2019-03-22 22:26

 You're welcome, and thanks for your reply. I suspected it could possibly Roadshow at fault, but what made me submit this issue is that it is not a normal use-case opening the bsdsocket.library and then immediately closing it, so I thought this throws the ball back in your court a little even though as you say...NetShutdown shouldn't crash regardless of how soon it is run. Would you like me to contact Olsen or are you dealing with the report?

Whilst I have your attention there is something else that may or may not be a fault. When running WHDLoad from Workbench the splash window appears and this window is active (has focus). Now, if before the game loads I quickly select another window that can take keyboard input (such as a Shell window for instance) then that window then has the active focus and the game will load. Then, when I exit the game with my QuitKey ($5d) that keypress (*) will appear in the Shell window. Should this happen when WHDLoad is invoked via Workbench? I haven't tried this yet when running WHDLoad via the Shell but it seems undesirable if it is indeed avoidable.

note ~0006757

Wepl (manager)

2019-03-24 12:42

 Yes, I would recommend to tell Olsen about the problem. Probably this could be fixed in Roadshow.

This could happen. I have changed WHDLoad and kickemu so that these check the quitkey on key up events which avoids this behavior. But many old slaves still check the quitkey on key down. In this case the keyboard may not be acknowledged when WHDLoad quits and the os still sees the key down event. No action is currently planned to change this. Slaves must be changed because WHDLoad cannot know if keyboard was reason for quit.

note ~0006758

Paul Head (reporter)

2019-03-26 14:36

 Hello, I have contacted Olsen regarding this issue.

note ~0006759

Paul Head (reporter)

2019-03-31 22:02

 Hello, Olsen has sent me a newer version of NetShutdown (v4.8) which hasn't made any difference unfortunately. I'll give him feedback on that shortly. In the mean time, there is a script error in WHDLoad-Cleanup. Here is Roadshow's actual current Network-Startup:

; $VER: Network-Startup 1.3 (22.11.2010)
FailAt 30
Run >NIL: NetLogViewer CX_POPUP=NO
AddNetInterface DEVS:NetInterfaces/~(#?.info) QUIET

Note the tilde. Without this no net interfaces are loaded! ;-)
Also the NetLogViewer should be run as this is closed down also when NetShutdown is run.

note ~0006760

Paul Head (reporter)

2019-04-01 13:34

 I had a bit of a breakthrough yesterday evening. The problem appears to be solved by removing PoolMem from my startup-sequence. I'm not 100% sure yet and so I need to spend a couple of days or more to make sure. Also, I believe I had an error code 0100 something or other (from PoolMem?) which flashed up as a red 'Recoverable Alert' for about a second before rebooting. This was instead of the freeze and reboot that would normally happen. I have SmartCrash installed now and I'm going to use Scout to get the last alert if that will help. It will probably take me a while to get this alert to show up again.

So to sum up, I got rid of the Wait command and the freeze and crash are back again. I then got rid of PoolMem from my startup-sequence and realised that it seemingly solved my issue. The unrecoverable 'Recoverable Alert' instead of the freeze and crash was new to me, I had never seen it before yesterday and after reading PoolMem docs I think it was a PoolMem error. I will try and replicate this to report an error code. I have informed Olsen the same.

note ~0006761

Wepl (manager)

2019-04-03 22:49

 Thanks for the info.
I will adapt the WHDLoad-Cleanup with the changes you mentioned.
What told Olsen about the problem? He doesn't see any problem in Roadshow?

note ~0006765

Paul Head (reporter)

2019-04-06 23:16

 Apologies, I haven't had the time or energy to get on my Amiga again this week regarding this issue. I will contact you as soon as I can in order to give you the feedback you need. I hope this will be within the next few days.
Olsen is waiting for my feedback too, so he is unable to comment at this stage.

note ~0006768

Paul Head (reporter)

2019-04-10 14:23

 After over three hours I finally got this real actual Recoverable Alert (yellow, and timed itself out naturally)

Error 0100 0013 Task 013D51C8

The game then loaded, and when I quit the game and the Workbench screen returned it froze after a second and then a second later it rebooted (no guru).

I think the only reason I managed to get this yellow alert instead of the faulty red version (which I mentioned in a previous note) was because I ran a Vista render in the background at -5 priority whilst loading the game. It was a fluke because I couldn't repeat it, but I think it slowed it down enough to not cock-up the Recoverable Alert.
Also, from tests it seems that if I run a heavy Vista render at priority 0 it eats plenty of cpu time, enough cpu time to fix the problem altogether so that the crashes do not occur - I suppose this is equivalent to the Wait command, albeit a less practical solution :-)
Also, if I use the ALLOC32 option of PoolMem this also solves the problem, again though this option loads the cpu heavily and is achieving the equivalent of the Wait command.

----------

From the PoolMem docs:

"The following Guru meditations can be thrown by PoolMem:

0x01000013 Scratch entry illegal.

Some program invalidated the internal memory scratch list of PoolMem - by
overwriting memory that has been deallocated before. An (in)famous example
is XiPaint. Run "PatchReplyMsg" and a debugger (e.g. COP) to check for
details."

----------

As a final note I tried running the PatchReplyMsg but I didn't notice any change regarding the fault issue/state (no guru still).

note ~0006831

Paul Head (reporter)

2019-05-13 11:49

 I don't know whether this helps any or pins anything down, but I can now get a 100% repeatable normal guru which times out and reboots naturally. I can get this if I run a clean 3.1 with only PoolMem running as an extra. Just to remind you, everything is fine without PoolMem.

note ~0006832

Paul Head (reporter)

2019-05-13 13:13

 I don't know how significant this is, but I've just discovered I don't get any fault at all upon the first run of a game from a COLD BOOT. Then the second run of the game and subsequent runs will always see a return of the freeze and reboot (whether I use a clean 3.1 or not).

When my usual system is running, I can use MuForce to capture this fault condition and avoid the freeze and reboot. The game actually loads and plays, but MuForce does capture one single Alert before the game starts, and it's always the same Alert. There are no 'hits' other than the single Alert. I can repeat this everytime if I keep loading the game after I have quit it. The Alert cause is PoolMem's task, with code 13 at the end so it's PoolMem as per the guru above (please see attached jpg file). Please refer to the attached MuForce photo too.

Oh, just another reminder that everything is fine with no errors if I have the 'C:Wait' just before 'C:NetShutdown' in the WHDLoad-Startup file.

I realise this is only a minor issue, and I really don't want to make a big deal of this I just thought it best that a fault be reported where I find one. I know that waiting a second is really easy to do, and I honestly can live with it! Thank you.

note ~0006835

Paul Head (reporter)

2019-05-13 14:49

 One thing I forgot to mention, with MuForce running WITHOUT PoolMem running there are no hits or anything, and everything works fine. Could it be the fault of PoolMem?

note ~0006837

Wepl (manager)

2019-05-13 16:45

Last edited: 2019-05-13 16:48

View 2 revisions

 Surely can Poolmem be the reason for the problems.
You may ask Thomas Richter about?

For better memory allocation I would recommend http://dump.platon42.de/files/TLSFMem.readme

note ~0006851

Paul Head (reporter)

2019-05-31 14:26

 I contacted Thomas a couple of weeks back and he's looking into it. I'll report back as soon as I know more. Thanks.

note ~0007056

Wepl (manager)

2019-09-17 23:18

 Any news on this?

note ~0007581

Paul Head (reporter)

2019-12-07 21:54

 Apologies for late reply...my account is linked to an e-mail address I hardly use.
I've heard nothing from anyone recently, I suppose they're all too busy writing OS3.2. :)
I did exchange a few emails with Olsen and Thomas until about July time, but they were inconclusive. Thomas swayed towards it being a WHDLoad issue and not the fault of PoolMem. Thomas was very helpful in trying to find the fault but he could not.

note ~0007583

Wepl (manager)

2019-12-10 13:32

 To summerize: there is only a problem when using PoolMem?
In this case I would assume a problem with PoolMem in conjunction with RoadShow.
PoolMem docs tell about guru '0x01000013 Scratch entry illegal' this may caused be using freed memory. This would match to your observation that Wait fixes it. PoolMem docs advise to use 'Run "PatchReplyMsg" and a debugger (e.g. COP) to check for
details.'
I don't see a relation to WHDLoad and would mark this as resolved.
I could maybe further investigate if you could provide an UAE installed image which reproduces the problem.

note ~0007588

Paul Head (reporter)

2019-12-22 01:05

 I'll have a crack at that then, I'll see if I can replicate it on WinUAE, but I'm not hopeful at all about getting it to replicate the fault. Thanks for your time in looking into this for me.
+Notes

-Issue History
Date Modified Username Field Change
2019-03-13 15:08 Paul Head New Issue
2019-03-18 14:21 Wepl Assigned To => Wepl
2019-03-18 14:21 Wepl Status new => assigned
2019-03-18 14:44 Wepl Note Added: 0006753
2019-03-22 22:26 Paul Head Note Added: 0006756
2019-03-24 12:42 Wepl Note Added: 0006757
2019-03-26 14:36 Paul Head Note Added: 0006758
2019-03-31 22:02 Paul Head Note Added: 0006759
2019-04-01 13:34 Paul Head Note Added: 0006760
2019-04-03 22:49 Wepl Note Added: 0006761
2019-04-06 23:16 Paul Head Note Added: 0006765
2019-04-10 14:23 Paul Head Note Added: 0006768
2019-05-13 11:49 Paul Head File Added: 2019-05-12 18.54.02_S.jpg
2019-05-13 11:49 Paul Head Note Added: 0006831
2019-05-13 13:13 Paul Head File Added: 2019-05-12 20.41.48_S.jpg
2019-05-13 13:13 Paul Head Note Added: 0006832
2019-05-13 14:49 Paul Head Note Added: 0006835
2019-05-13 16:45 Wepl Note Added: 0006837
2019-05-13 16:48 Wepl Note Edited: 0006837 View Revisions
2019-05-31 14:26 Paul Head Note Added: 0006851
2019-09-17 23:18 Wepl Note Added: 0007056
2019-09-17 23:18 Wepl Status assigned => feedback
2019-12-07 21:54 Paul Head Note Added: 0007581
2019-12-07 21:54 Paul Head Status feedback => assigned
2019-12-10 13:32 Wepl Note Added: 0007583
2019-12-10 13:32 Wepl Status assigned => resolved
2019-12-10 13:32 Wepl Resolution open => unable to reproduce
2019-12-22 01:05 Paul Head Note Added: 0007588
2020-10-27 11:24 Wepl Status resolved => closed
+Issue History