+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Development (https://forum.cuberite.org/forum-13.html)
+--- Thread: Debug Mode: SetSwimState Failure (/thread-1385.html)
Pages:
1
2
Debug Mode: SetSwimState Failure - Narroo - 02-21-2014
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?
RE: Debug Mode: SetSwimState Failure - bearbin - 02-21-2014
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.
RE: Debug Mode: SetSwimState Failure - Narroo - 02-21-2014
(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~~~
RE: Debug Mode: SetSwimState Failure - tigerw - 02-21-2014
Comment out the ENABLE_LEAK_FINDER defines in main.cpp and Server.cpp for faster debug speeds.
RE: Debug Mode: SetSwimState Failure - xoft - 02-21-2014
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!
RE: Debug Mode: SetSwimState Failure - tigerw - 02-21-2014
xoft, I think you added them
RE: Debug Mode: SetSwimState Failure - xoft - 02-21-2014
Nope, you did, I just checked the Git blame:
https://github.com/mc-server/MCServer/blame/master/src/Entities/Entity.cpp#L943
RE: Debug Mode: SetSwimState Failure - Narroo - 02-22-2014
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?
RE: Debug Mode: SetSwimState Failure - tigerw - 02-22-2014
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
RE: Debug Mode: SetSwimState Failure - NiLSPACE - 02-22-2014
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.