logo
Main

Forums

Downloads

Unreal-Netiquette

Donate for Oldunreal:
Donate

borderline

Links to our wiki:
Wiki

Walkthrough

Links

Tutorials

Unreal Reference

Usermaps

borderline

Contact us:
Submit News
Page Index Toggle Pages: 1 [2]  Send TopicPrint
Hot Topic (More than 10 Replies) In serious need of some help fixing server crashes (Read 9977 times)
Smirftsch
Forum Administrator
*****
Offline



Posts: 8013
Location: at home
Joined: Apr 30th, 1998
Gender: Male
Re: In serious need of some help fixing server crashes
Reply #15 - Jan 19th, 2013 at 6:38am
Print Post  
another few interesting details, especially with the actor. I indeed didn't expect it to behave any different Smiley - wish I had this information back then too, lol, but on the other hand wouldn't have changed much. Guess can't know everything.
But it would be interesting to know if it really could be caught with UScript this way with a string check or if the crash happens before it would appear there.
  

Sometimes you have to lose a fight to win the war.
Back to top
WWWICQ  
IP Logged
 
GreatEmerald
Oldunreal MasterPoster
*
Offline


The Great Emerald

Posts: 5361
Location: Vilnius, Lithuania
Joined: May 21st, 2007
Gender: Male
Re: In serious need of some help fixing server crashes
Reply #16 - Jan 19th, 2013 at 7:59am
Print Post  
Smirftsch wrote on Jan 18th, 2013 at 7:58pm:
It's just that the value which is returned is invalid, no real number if you wish, causing the engine to crash, because you can't calculate with a "non existing" number. Was just calling it garbage, because that fits very well Smiley


So it's not real memory garbage? From my experience working with C, uninitialised values are always garbage by default, which can lead to some frustrating situations (since you can't check if it's valid at all, because garbage is basically a random number in memory). But in this case, it looks like it shows something else when converted into a string, so it looks like it's not memory garbage...
  
Back to top
WWW  
IP Logged
 
Zombie
Forum Administrator
The One Who Wanted To Have A Special Title In Forum
*****
Offline


Living Dead

Posts: 323
Joined: May 9th, 2002
Re: In serious need of some help fixing server crashes
Reply #17 - Jan 19th, 2013 at 12:14pm
Print Post  
I recall the important difference of a tester actor is having 'bCollideWhenPlacing' property enabled. This treats the actor sensitively to collisions with world geometry during a spawn attempt when a pawn normally is not. My guess is that since a tester actor has to pass more checks for the spawn attempt to succeed it is unlikely to be placed at an unsuitable or invalid location to trigger this type of crash.


-Zombie
  
Back to top
 
IP Logged
 
Tim-_-
New Member
*
Offline


Oldunreal member

Posts: 11
Joined: Jan 16th, 2013
Re: In serious need of some help fixing server crashes
Reply #18 - Jan 26th, 2013 at 1:53pm
Print Post  
Wow!  Thank you thank you thank you for all of these details.  This is incredibly helpful.

I haven't had time to try out all of your suggestions yet but I should have some time later on today.  Although it seems to be getting harder to find enough willing people to test 5v5 CTF lately because most players seem to have given up on the mod (at least for CTF).
Embarrassed
  
Back to top
 
IP Logged
 
Tim-_-
New Member
*
Offline


Oldunreal member

Posts: 11
Joined: Jan 16th, 2013
Re: In serious need of some help fixing server crashes
Reply #19 - Jan 26th, 2013 at 3:50pm
Print Post  
Zombie wrote on Jan 18th, 2013 at 10:43pm:
If one wants check if location X/Y/Z values are invalid one must convert them to strings (Ex. string(Location.X) ). Within the string check for ".#IN" or anything not numerical (yes this works).

Ohh also, while I'm thinking about it... why ".#IN"?  Edit: Never mind, just googled it, which leads me to ask: would I need to check for "NaN" as well to account for Linux servers?  Or better yet, I could just check for the letter "N" eh?
  
Back to top
 
IP Logged
 
Zombie
Forum Administrator
The One Who Wanted To Have A Special Title In Forum
*****
Offline


Living Dead

Posts: 323
Joined: May 9th, 2002
Re: In serious need of some help fixing server crashes
Reply #20 - Jan 26th, 2013 at 6:28pm
Print Post  
If there is a difference between platforms then checking for "N" would be sufficient.

The crash might occur more frequently on specific maps with your mod. So if you can gather enough information you may see a map trend which may help speed up your testing or allow you to reproduce the crash on your own to verify the effect of code changes.


-Zombie
  
Back to top
 
IP Logged
 
Tim-_-
New Member
*
Offline


Oldunreal member

Posts: 11
Joined: Jan 16th, 2013
Re: In serious need of some help fixing server crashes
Reply #21 - Feb 4th, 2013 at 1:28pm
Print Post  
Hey guys!  I finally got around to implementing most of the changes you'd all suggested, and it seems to work for the most part!  Again, thank you!

Smiley

We made it through 14 maps with no crashes until it finally did crash with a slightly different error message.  I've seen this one a few times before but on rare occasion.  And I've read other threads about it but have not yet found any definitive way to prevent the error.

Quote:
Critical: TouchTo
Critical: AActor::BeginTouch
Critical: ULevel::MoveActor
Critical: APawn::physWalking
Critical: APawn::performPhysics
Critical: UObject:TonguerocessEvent
Critical: (bbTFemale2 CTF-McSwartzly][.bbTFemale1, Function GlobalUnrealv0_3z.bbPlayer.xxServerMove)
Critical: RemoteCall
Critical: HandleStream
Critical: UActorChannel::ReceivedBunch
Critical: (Actor bbTFemale1)
Critical: UChannel::ReceivedSequencedBunch
Critical: Direct
Critical: UChannel::ReceivedRawBunch
Critical: DispatchDataToChannel
Critical: BunchData
Critical: UNetConnection::ReceivedPacket
Critical: UNetConnection::ReceivedRawPacket
Critical: UTcpNetDriver::TickDispatch
Critical: UpdatePreNet
Critical: ULevel::Tick
Critical: (NetMode=1)
Critical: TickLevel
Critical: UGameEngine::Tick
Critical: UpdateWorld
Critical: UServerCommandlet::Main
Exit: Executing UObject::StaticShutdownAfterError
Exit: Exiting.
Uninitialized: Name subsystem shut down
Uninitialized: Log file closed, 02/04/13 00:16:33


Any idea what that's about?  I have a feeling it's similar to the FCollisionHash error, but I have no idea what I would change to address it.

Edit: I'm betting I'll have to do the same thing for MoveSmooth function as I did for the SetLocation function; i.e., spawn the temporary collision actor at the destination and check to make sure it succeeded.  But then again, I thought MoveSmooth was supposed to take care of those kinds of things on its own?
  
Back to top
 
IP Logged
 
Zombie
Forum Administrator
The One Who Wanted To Have A Special Title In Forum
*****
Offline


Living Dead

Posts: 323
Joined: May 9th, 2002
Re: In serious need of some help fixing server crashes
Reply #22 - Feb 9th, 2013 at 11:34pm
Print Post  
Are there any other logs of that crash different in some way? I have seen touch involved crashes before but not that short. Also, please keep us up to date with your suspected code.

It could still be related to teleporting or it may be something else like MoveSmooth as you said. If it is MoveSmooth I am not quick to assume the crash trigger is the same as with SetLocation since Move/MoveSmooth does not rehash the actor.

According to Epic UDN the Move/MoveSmooth functions assume the actor's current location is valid/suitable. Also, when the actor (collision enabled) moves from one location to another it is supposed to touch other colliding actors along its way. So as an added safety you could check the pawn's current location before calling MoveSmooth.

Perhaps Smirftsch can say something about what processes/dependencies are in 'TouchTo' to maybe have some insight into the crash.


-Zombie
  
Back to top
 
IP Logged
 
.:..:
Board Moderator
Developer Team
*****
Offline



Posts: 1512
Location: Finland
Joined: Aug 16th, 2005
Gender: Male
Re: In serious need of some help fixing server crashes
Reply #23 - Feb 10th, 2013 at 3:42pm
Print Post  
TouchTo does the following:
- First attempts to find a free slot and use it in Touching list.
- If that fails and new touching actor is a pawn, it tries to untouch any non-pawn actors in Touching list and use that free slot for the new toucher.
- If that fails and new touching actor is a playerpawn, it tries to untouch any non-playerpawns to free up a slot.

So the amount of possibilities that could wrong there is quite large (due to the fact that there may be multiple events happening in between from the Untouch event call). It doesn't actually do any safe checks there if the forced untouch actor did actually successfully remove itself from the Touching list.
Go figure...

So I guess that is one advantage of having a dynamic touching actors array in 227 now.
  

Shivaxi wrote on Jul 25th, 2013 at 12:50pm:
...and now im stuck trying to fix everything you broke for the next 227 release xD Tongue

(ಠ_ಠ)
Back to top
IP Logged
 
Tim-_-
New Member
*
Offline


Oldunreal member

Posts: 11
Joined: Jan 16th, 2013
Re: In serious need of some help fixing server crashes
Reply #24 - Feb 12th, 2013 at 5:59am
Print Post  
Man, it is crazy how easily UE1 will crash.  I wish Epic had some kind of fallbacks to prevent complete failure or a way to try/catch.  But then again, they probably didn't expect people to push it to its limits.


Zombie wrote on Feb 9th, 2013 at 11:34pm:
Are there any other logs of that crash different in some way?

I know I've seen the TouchTo error a couple of times before, so I just looked through all the logs I have saved and found one instance, and it is slightly different.  It references the MoveSmooth function instead of performPhysics.


Zombie wrote on Feb 9th, 2013 at 11:34pm:
Also, please keep us up to date with your suspected code.

Each crash does seem to revolve around the xxServerMove function.  And the only difference now is I replaced SetLocation with NewSetLocation, which disables collision, spawns the temporary actor, and performs all the checks before actually setting the location.

Zombie wrote on Feb 9th, 2013 at 11:34pm:
So as an added safety you could check the pawn's current location before calling MoveSmooth.

Would casting Location.X/Y/Z to a string and checking for "N" work or did you have something else in mind?


.:..: wrote on Feb 10th, 2013 at 3:42pm:
TouchTo does the following:
- First attempts to find a free slot and use it in Touching list.
- If that fails and new touching actor is a pawn, it tries to untouch any non-pawn actors in Touching list and use that free slot for the new toucher.
- If that fails and new touching actor is a playerpawn, it tries to untouch any non-playerpawns to free up a slot.

So the amount of possibilities that could wrong there is quite large (due to the fact that there may be multiple events happening in between from the Untouch event call). It doesn't actually do any safe checks there if the forced untouch actor did actually successfully remove itself from the Touching list.
Go figure...

So I guess that is one advantage of having a dynamic touching actors array in 227 now.

Man that's some pretty ridiculous stuff by Epic.  Wow.

I wish I could run a UT99 server off of 227... it'd make life so much easier!


So... the servers went without crashing for over a week, but out of nowhere today they've crashed 4 times.  Twice it was the FCollisionHash error again.  I couldn't get a hold of one of the crash logs.  And the other one was completely new:
Quote:
Critical: UPackageMapLevel::SerializeObject
Critical: UObject::GetFullName
Critical: RemoteCall
Critical: HandleStream
Critical: UActorChannel::ReceivedBunch
Critical: (Actor bbTFemale3)
Critical: UChannel::ReceivedSequencedBunch
Critical: Direct
Critical: UChannel::ReceivedRawBunch
Critical: DispatchDataToChannel
Critical: BunchData
Critical: UNetConnection::ReceivedPacket
Critical: UNetConnection::ReceivedRawPacket
Critical: UTcpNetDriver::TickDispatch
Critical: UpdatePreNet
Critical: ULevel::Tick
Critical: (NetMode=1)
Critical: TickLevel
Critical: UGameEngine::Tick
Critical: UpdateWorld
Critical: UServerCommandlet::Main
Exit: Executing UObject::StaticShutdownAfterError
Exit: Exiting.
  
Back to top
 
IP Logged
 
Page Index Toggle Pages: 1 [2] 
Send TopicPrint
Bookmarks: del.icio.us Digg Facebook Google Google+ Linked in reddit StumbleUpon Twitter Yahoo