|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004091||WHDLoad||[All Projects] General||public||2019-03-13 15:08||2019-03-24 12:42|
|Assigned To||Wepl||Project Info||HD-Installer for OS-Killer|
|Target Version||Fixed in Version|
|Summary||0004091: Crash when WHDLoad-Startup attempts to close down Roadshow when the network wasn't previously available|
|Description||My 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
; stop wireless connection
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 Reproduce||80MHz 68060 (with FASTATA Mk.III)|
Inside my WHDLoad.prefs as following:
Inside WHDLoad-Startup as following:
; stop Roadshow
; stop wireless connection
Then load any WHDLoad game.
|Additional Information||A 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.
Run <>NIL: C:WirelessManager prism2.device
|Tags||No tags attached.|
|KickROM||40 - Kick 3.1|
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.
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.
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.
|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|