2019-03-25 20:47 CET

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0004091WHDLoad[All Projects] Generalpublic2019-03-24 12:42
ReporterPaul Head 
Assigned ToWeplProject InfoHD-Installer for OS-Killer
http://whdload.de/
 
PrioritynormalSeveritycrashReproducibilityalways
StatusassignedResolutionopen 
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)

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)

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)

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.
+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
+Issue History