Bug bounty

Joriom · 2018-05-22 00:57:53

jasonrohrer wrote:

Yeah, I've thought about this.
The problem is that the client currently outputs all the relevant messages to stdout and doesn't save them in RAM at all. On Windows, this is conveniently saved in stdout.txt, so people can email it to me. I don't think Windows would let me open this file for reading if it was still open for writing.

Ofc it would. You might need to flush before reading though, just to make sure you read all that was supposed to be written - because writing to file is buffered system side.
Thats also how all the coordinate-spoofing stuff worked. I even just used text editor with "reload" feature on secod screen to read contants real-time manually.

sliderule · 2018-05-24 04:05:56

I was able to accidentally force this bug by flushing the state table on the my firewall while my wife was mid-game. I don't know if this is the source of other peoples' bouncing but I can imagine that similar failures (primarily in NAT firewalls) could cause the connection to fail in such a manner.

Relying on a TCP connection that remains established is common to many applications, but if players have connection resets and there is no recovery mechanism, death is inevitable.

I can envision a potential solution:

1. Detect bouncing on client side
2. Restart tcp connections (I don't know if your protocol / server design supports reconnects, but it would need to.)

Because I can force it, I could reproduce it, but the above solution (or similar) would be required if a NAT router loses state.

Again, I don't know if this is the bug that others are experiencing, but it is a flaw. :shrug:

mikekchar · 2018-05-24 05:56:22

I'll put money on sliderule's explanation being the correct one. As someone who used ssh a lot before they added a workaround for this, I can tell you that there are lots of ways for TCP connections to get closed :-) One side or the other should get an indication that the connection was closed, though. The other side will hang because there is no way to detect if the connection is down other than to wait until the socket times out. The easiest way to solve the problem is by adding a "heartbeat". So basically you record how long it's been since you got a packet from the other side. If it's more than a certain amount of time (say 1 second, for a game), you send a "heartbeat" request. The other side sends the "heartbeat". If you receive the heartbeat out of order from your client request, then you can assume that there is a bug in your code and resend your request. If you don't receive a heartbeat after a certain amount of time, you can close the connection and reconnect (from the client -- the server can just close the connection and potentially wait for a reconnect request).

Uncle Gus · 2018-05-24 07:07:45

Surely those situations would cause a disconnect? This bug seems to be something else. The connection isn't lost.

sliderule · 2018-05-24 13:09:23

Lineage server said she died of starvation as did the client.

Edit: CORRECTION

My wife says the client said connection lost.

So if that's an indicator that this is NOT the bug, then that's that.

Last edited by sliderule (2018-05-24 16:15:06)

Realcooldude · 2018-05-24 17:15:26

How do i know what file to share? There are 18. I have had it happen recently.

Stylingirl · 2018-05-25 04:43:59

Realcooldude wrote:

How do i know what file to share? There are 18. I have had it happen recently.

They are listed in order, with the larger numbers being the most recent. You can also probably check the timestamps on the files.

jasonrohrer · 2018-05-28 16:15:38

Lynne C. sent me a stdout.txt that helped me track down the following bug:

If a baby is standing on the ground and attempts to move, and at that very same moment, an adult picks them up, and the server receives these messages in the same server step, it processes the pick-up first (because the parent occurs earlier on the player list), then it processes the baby move, which causes the baby to jump out of arms where the parent is standing. This causes a player update for the baby at the parent's location.

However, from the baby-client's point of view, the baby has already started moving, and it's waiting for a Player Update (PU) message at the end of the baby's path to signal that the move is done. Instead, this weird PU arrives at the jump-out-of-arms location, but the client never finds out that the baby was picked up in the first place.

Thus, the baby-client bounces forever on the action following the move, because it never hears from the server that the move was successful. And in fact, the move didn't happen on the server (the baby is standing where they were dropped).

Normally, the baby-client will receive a PU message for the adult telling it that the adult is holding them, and then another PU for the adult later telling it that the adult's arms are empty again. But in this case, server-side, the adult's arms become full and then empty in the same step, and only one PU is sent per player per step, so only the final PU about their arms being empty is sent. So the baby-client doesn't know that they were picked up at all.

There is a FORCE parameter on PU messages that is used for move truncations and other things (like if a door slams in your face and cuts off your long move). This should be used for baby drops, but wasn't being used. Adding this to the baby drop PU messages fixes this. The baby-client doesn't know it's held, and thinks it's walking along, but then it gets a forced PU and bam---that overrides everything.

Lynne gets the reward, and I'll fix this server-side right now.

BUT...

There might be other sources of this bouncing bug, so keep watching for it.

jasonrohrer · 2018-05-29 17:39:18

Another source of the bouncing bug has been caught by Gabriel today.

This one is caused again by baby holding.

If you're held as a baby, and you manage to click multiple times before the server registers your "jump out of arms" request, multiple move messages are sent (a baby trying to move triggers a jump out of arms---probably a bad overloading of the move message on my part, in retrospect). The server registers the first one as a jump-out-of-arms, and the second move as a real move. The client, however, thinks all these move messages are "jump out" requests, and doesn't make the baby move. So the server and client's positions get out of sync for the baby, and the next baby action causes bouncing forever.

This is fixed client-side by only sending one "jump out" move message, no matter how many times the player clicks.

Morti · 2018-05-30 05:33:06

Sent my stdout.txt and recordedGame00216.txt (most recent).

Hope it helps.

Realcooldude · 2018-05-31 03:26:31

Jason,

Just sent you both the game file and the SDTout.txt with a link to download both from my dropbox. Hope this helps you track down any bugs, was a really bouncy game, worst i have ever seen.

jasonrohrer · 2018-06-01 22:41:25

Just found and fixed two more bugs thanks to these stdout.txt reports.

These bugs are getting more and more rare as the various causes are eliminated.

Keep the reports coming, please!

Realcooldude · 2018-06-02 03:03:14

Just glad i could help out.

One Hour One Life Forums

#26 2018-05-22 00:57:53

Re: Bug bounty

#27 2018-05-24 04:05:56

Re: Bug bounty

#28 2018-05-24 05:56:22

Re: Bug bounty

#29 2018-05-24 07:07:45

Re: Bug bounty

#30 2018-05-24 13:09:23

Re: Bug bounty

#31 2018-05-24 17:15:26

Re: Bug bounty

#32 2018-05-25 04:43:59

Re: Bug bounty

#33 2018-05-28 16:15:38

Re: Bug bounty

#34 2018-05-29 17:39:18

Re: Bug bounty

#35 2018-05-30 05:33:06

Re: Bug bounty

#36 2018-05-31 03:26:31

Re: Bug bounty

#37 2018-06-01 22:41:25

Re: Bug bounty

#38 2018-06-02 03:03:14

Re: Bug bounty

Board footer