Descriptive Problem Summary:
Trying to boot Alternate Worlds in Dream Seeker or Daemon in the latest beta causes the Seeker/Daemon client to hang on loading the server in the options and messages window (Seeker) or during the not responding phase of Daemon.
Numbered Steps to Reproduce Problem:
Create a map of at least 500x500 with 5 z levels and you'll start to see the load time increase intensely. Alternate Worlds has a map size of 500x500 with 20 z levels which seems to cause Daemon to be incapable of loading it entirely in the newer versions of beta. I've tried this with a combination of theads off and map-threads off, neither of which have any impact on it from what I can tell.
Workarounds:
As far as I can tell the only work around currently is to revert back to the public build and to use a smaller map (the smaller map may simply be for the sake of decreasing the load time, BYOND has always had a problem loading larger map files).
ID:1489994
 Feb 5 2014, 12:50 pm (Edited by moderator on Feb 5 2014, 1:17 pm)
|
|||||||||||||
| |||||||||||||
|
Feb 5 2014, 1:03 pm
|
|
SpaceDragonK
 |
This isn't a beta bug i think this has happened before to me in a stable version just try using less Z and decreasing the size of the map thats the only suggestion i can give you.
|
Yeah, I've always had to wait 2-3 minutes for the server to load. But with the new update that 2-3 minutes as turned into waiting well over 3 hours for the server to load, it's still loading in dream seeker but I'm not having any success and I can't figure out why.
I've tried using a smaller map and loading it, it works fine in the public version. But using the larger map doesn't seem to work anymore either and it was working just fine a couple of days ago, just randomly started having this problem. S: | |
Out of curiosity, have you tried this on the oldest 504 beta (1225)? I ask because there is a very minor change to map handling that would increase the memory usage to improve server map handling at runtime, and that could be relevant at a map size like yours. If you can pinpoint exactly which build stopped working, that would be a huge help.
The fact that this happens without threads means it's not the same issue I was hoping, but I'd still like to look into it. Also, which beta are you currently using? I'd like to make sure the report is marked with the minor version as well. | |
I was using 504 beta (1230), but have since downgraded to the current public build on the website. However that doesn't seem to be causing any changes.
The game works fine when I swap out the map file for a blank one at 500x500 (5 z levels), though it takes a few seconds to boot up. Which is to be expected with that map size, however for some reason it no longer boots up after the usual 2-3 minutes with the old map (which I modified slightly in 1230, just in case this has some effect I am unaware of). I'll install 1225 now and see what's that like on the actual map and the test map if that would be of any use to you? Or alternatively I could send you the source files, to see if you can identify anything that I may be missing. | |
Hey, this happens to my game Dragon Universe as well, which coincidently also has 500x500x20 maps.
It just won't start in the new beta. But in the public release it is fine. | |
Tens of DU, I'd like for you to try and narrow down if this issue disappears when threads are off, or if it disappears in an earlier 504 version such as 1225. This would need to be tested on Windows though, because Linux can't do threading in 1225 and I'd like to be certain this is the same issue.
| |
I've reverted back to the current public release and I'm having problem running the map still and can't for the life of me figure out what has changed.
The game runs fine in my test map of 500x500x5, but when I try and run my world map of 500x500x20 it fails to get past the Options and Messages window. I've left it on for three hours and didn't get any further, I don't know if having saved the map in the beta version has made any difference to it but it just doesn't seem to want to work at all anymore. /: | |
DU works on my Windows PC in 503, 504.1225, and 504.1230 for me.
But not on our Linux VPS | |
Tens of DU wrote:
DU works on my Windows PC in 503, 504.1225, and 504.1230 for me. There's quite some difference in a Dedicated PC and a VPS.. | |
Maybe VPS is the wrong term but I don't know
| |
Linux (Debian Squeeze)
503.1124 - working as intended. 504.1230 w/ Threading -crashes with no recorded error at approximately one minute after start up. Seems to be about the time the map and item files are fully loaded. 504.1230 w/o Threading - working as intended. 504.1230 w/o Map Threading - working as intended. Shortly after the initial test with "map-threads off", I got this error log: *** glibc detected *** DreamDaemon: double free or corruption (out): 0xb380fe90 *** And the second occurance: *** glibc detected *** DreamDaemon: double free or corruption (!prev): 0x1a965f80 *** | |
To be clear, this was with threads on (or unspecified) and map-threads off?
The crash trace does have some useful info, in that it tells me that the issue came up while running background/sleeping procs. I'm not sure how that all ties in, but it's given me some things to look at. However it seems unrelated to this specific thread, since it's a crash happening only in threaded mode. | |
Lummox JR wrote:
To be clear, this was with threads on (or unspecified) and map-threads off? I dunno, Tens said test in 504.1320 and post results, so I did. Probably should have checked the thread. | |
I ask because the setting of map-threads is totally irrelevant if threads are off. Turning off map-threads when threads are already off will result in no change.
| |
Lummox JR wrote:
I ask because the setting of map-threads is totally irrelevant if threads are off. Turning off map-threads when threads are already off will result in no change. Oh, forgot to answer that part. The crash trace is with "map-threads off" and threads on (unspecified). | |
Okay, that fits for me. I found that I haven't been able to discover any lingering problems with map threads on vs. off, but only with threading in general on vs. off.
It would really help a lot to have the code to examine. What I've determined from your crash trace is that the crash happened at the end of a proc that was run in the background. I can't tell which proc that is, however. Do you have any info from a standard stack trace produced by DD? There ought to have been something that also said which procs had recently been run. You mentioned the map and item files. Do you have any debugging in the routines loading these files that might shed some light on where it's failing? The one constant I keep seeing in all the startup woes with threading appears to be that it happens with more complex games. (SilkWizard has a different issue, though, related to the machine it's on.) Yet it's not happening for me with games like Eternia, so there has to be more to it. | |
Lummox JR wrote:
Okay, that fits for me. I found that I haven't been able to discover any lingering problems with map threads on vs. off, but only with threading in general on vs. off. That's all the info there I'm afraid. :/ With map-threading disabled, the loading completes just fine, and takes approximately 10-15 minutes to crash, upon fully loading. | |