failed startup() hangs forever

ID:120858
 
Nov 7 2011, 11:40 am
BYOND Version:493
Operating System:Windows 7 Home Premium 64-bit
Web Browser:Firefox 7.0.1
Applies to:Dream Maker
Status: Verified
A member of our crack team of bug testers has verified that this issue is reproducible, and has handed it off to the development team for investigation.
If startup() fails, because you already have a server on the supplied port, for example, it seemingly hangs forever and prevents the rest of the code from executing. If I'm not mistaken, it used to return "[IP]:0" if it failed. Not 100% sure when this started though, it may have been when the -close parameter was implemented.

Also, startup() either starts new servers in whatever visibility mode the parent is set to, or to whatever the last DD instance was (not 100% sure which). This is understandable, but I think it would be better to always start new worlds in public mode. Or possibly, take a parameter for that setting, like it does for the safety mode.
Apr 5 2012, 11:09 am
I couldn't get this to happen in my tests. If the startup fails it does in fact return [ip]:0 for me. This happened whether DS was being hosted itself or not. If the DD instance failed to start, nothing happened.

We actually do have visibility parameters for startup(), though they are undocumented (and I think it makes sense to document them).
Apr 5 2012, 11:09 am
Lummox JR changed status to 'Unverified'
Apr 5 2012, 2:00 pm (Edited on Apr 5 2012, 3:51 pm)
You have to include the -close option

world/New()
    world.OpenPort(0)
    return ..()

mob/verb/Startup_Test()
    world<<"Starting..."
    world<<startup('StartupFail.dmb',world.port,"-close")
    world<<"Started?"

EDIT: It also seems to fail in a similar manner if you include an option that doesn't exist, like "-closed"
Apr 8 2012, 12:38 pm
This has happend with both a 'ServerMonitor' I created to keep my game up AND a 'ServerMonitor' I actualy paid for, it involves a false-negetive ping.
Apr 9 2012, 12:36 pm
I can now verify this issue, but I'm afraid the solution is not readily apparent. It has to do with the way the slave server is being shutdown. The fact that this happens for unrecognized args further complicates the issue. I don't intend to let this go but I don't expect the fix to be in 494.
Apr 9 2012, 12:36 pm
Lummox JR changed status to 'Verified'