Debug Mode: SetSwimState Failure
#1
I can't log onto my debug server. On my client I get stuck at "Downloading Terrain." In the console I get a bunch of SetSwimState errors, followed by things like

BioGenCache: 61425 hits, 25 misses, saved 99.96 %
BioGenCache: Avg cache chain length: 4.76

Till I get a deadlocked error.

Anyone know what's going on?
Reply
Thanks given by:
#2
The BoiGenCache thing is just chunks generating, you can safely ignore that. Try increasing the deadlock boundary, it might be an issue if you're on a really slow machine.
Reply
Thanks given by:
#3
(02-21-2014, 02:43 AM)bearbin Wrote: The BoiGenCache thing is just chunks generating, you can safely ignore that. Try increasing the deadlock boundary, it might be an issue if you're on a really slow machine.

I don't think that's it...What happens is that I get a bunch of "SetSwimState Failure" errors, which I didn't used to, and then it spends up to five minutes messing around with the chunks. Then again, I am on a laptop. On the otherhand, the release version works fine.

Also, I've gotten other messages, like this:

[0b20|13:31:30] Assertion failed: !"GetBlock(x, y, z) out of bounds!", file C:\U
sers\Narroo\Documents\Git Bash Projects\MCServer\Git_MCServer\src\Chunk.cpp, lin
e 2386

EDIT: I finally, after a few tries, did get into the server. I though the Gen Stuff was being caused by the setSwimstate thing. Nevermind~~~
Reply
Thanks given by:
#4
Comment out the ENABLE_LEAK_FINDER defines in main.cpp and Server.cpp for faster debug speeds.
Reply
Thanks given by:
#5
The assertion is an important discovery - it means that a release mode binary will silently err there, with who knows what results - could be anything from nothing through a wrong written file to crashing completely. Whenever you get such an assertion, you should press Retry to drop into the debugger, and investigate the assert. Usually there is a comment next to it describing why the assert is there. Posting the assert together with the stacktrace (the Call stack window lets you copy its contents) could be useful, too, if you have just no idea on how to fix that. Usually the callstack is more important that the actual assert line, since the assert line is in some common code part, while the real cause is higher up the function call chain.

As for the poor performance, I have decided to disable the leak finder in the canon source. We haven't had any memory leaks for over a year now and when we do, the linux guys can find them with valgrind. VS2013 makes the leak finder really slow, next to unusable.

The SetSwimState failures are an issue of their own, I want the person who added the log to fix them!
Reply
Thanks given by:
#6
xoft, I think you added themTongue
Reply
Thanks given by:
#7
Nope, you did, I just checked the Git blame:
https://github.com/mc-server/MCServer/bl...y.cpp#L943
Reply
Thanks given by:
#8
Well, I can't seem to get the assertion error anymore. Though it's slow, I can log into my debug server now. I guess it got it out it's system?

Would you guys like me to post the logs?
Reply
Thanks given by:
#9
No, that code was just me copying over the drowning code from Player.cpp to Entity.cpp. The actual history seems to have gone after the source -> src renaming. I think we need to find an old fork and have a look Smile
Reply
Thanks given by:
#10
I"m like 100% sure xoft didn't made the drowning code, but neither did you. It was someone who like some more people do a pull request and then don't here from them for a while.
Reply
Thanks given by:




Users browsing this thread: 3 Guest(s)