Weird crash

[12tails]

Heya, maybe someone can help me out with this,

Currently version is 5095.

While you're playing the client just close without source error or any msg at screen, but into the debug client folder i get this:

Got a player with hero id! 1000000 -- Sat Dec 14 10:14:04 2013
Got a player with hero id! 11254550 -- Sat Dec 14 12:44:26 2013
Got a player with hero id! 1611455 -- Sat Dec 14 17:06:55 2013

the client just close, don't have a reason to.... when jumping, walking or even talking to an npc..... i did a packet log to check if was the crypto, but the packets get encrypted normally and all things normal.... maybe a client bug?

aaa... the "hero id" is the same id as my character in game....

[CptSky]

It's normal to have those lines in the debug files. It just means that the client received the MsgUserInfo packet.

Check when you broadcast the message, if you correctly change the TQClient to TQServer

[12tails]

hmmm but i don't send any packet back to client, they're all written by the source, anyway... going to check ;S

[pro4never]

The client will crash if you pass it invalid data. This can be caused by a few things.


-Missing TQServer seal at specified packet length
-Packet sent is too large (1024 bytes iirc)
-Cryptography error

[12tails]

Well, i guess the problem its the crypto ;S

TQSEAL is ok, packets are not larger than 100 bytes when it crashes....

tested some 3 different sorts of socket systems.... so the only thing left is crypto... ;S

[Super Aids]

Are you locking the crypto when encrypting? It could be a race condition too, if using BeginSend.

[12tails]

Well, i use SendAsync (i'm using Async Sockets, i think it is safer than other ones) but.... no i'm not locking the encrypt method...... i'll do some tests... let's see what happens...

also.... could it be caused by client too??

@EDIT

Got a player with hero id! 1611455 -- Sat Dec 14 17:06:55 2013

this msg JUST come to the debug file when the client crash... i'm nearly giving up haha xD

[Super Aids]

You should lock the crypto until the packet is send.

[-impulse-]

Originally Posted by Super Aids

Are you locking the crypto when encrypting? It could be a race condition too, if using BeginSend.

Not necessarly. If you use begin send within a lock, the packet sequence will be kept.

PHP Code:

lock(cryptSyncRoot){ 
crypt.Encrypt(buffer);
socket.beginsend(buffer);
} 


works just as well as

PHP Code:

lock(cryptSyncRoot){ 
crypt.Encrypt(buffer);
socket.send(buffer);
} 


@talis: since you say you don't send packets with the length (written at offset 0) is not more than 1024 and the client CRASHES then I can think of one reason... you send to your client your entity spawn (a spawn entity with the same UID of your client).
And do lock the crypto + the sockets together until the send (/beginsend) is complete.

[FatalError-]

I was having this issue when I hadn't implemented the Entity spawn packet (Packet ID 102 in version 5017). Packet just sends spawn info for the requested UID.

[Super Aids]

Originally Posted by -impulse-

Not necessarly. If you use begin send within a lock, the packet sequence will be kept.

PHP Code:

lock(cryptSyncRoot){ 
crypt.Encrypt(buffer);
socket.beginsend(buffer);
} 


works just as well as

PHP Code:

lock(cryptSyncRoot){ 
crypt.Encrypt(buffer);
socket.send(buffer);
} 


@talis: since you say you don't send packets with the length (written at offset 0) is not more than 1024 and the client CRASHES then I can think of one reason... you send to your client your entity spawn (a spawn entity with the same UID of your client).
And do lock the crypto + the sockets together until the send (/beginsend) is complete.

There is no order in which way asynchronous events are executed.

Let's say you send packet a and then packet b using BeginSend.

Then the asynchronous event for packet b may be executed before the asynchronous event for packet a.

You may want to look into this as well:


Also remember that Socket.Send() does not actually send the packets, it just copies the buffer into the kernel which then proceeds it or whatever.

Since .NET sockets are build upon the berkeley sockets, then this applies as well.

So saying that Send() and BeginSend() sends the packet is actually invalid.

[-impulse-]

Originally Posted by Super Aids

There is no order in which way asynchronous events are executed.

Let's say you send packet a and then packet b using BeginSend.

Then the asynchronous event for packet b may be executed before the asynchronous event for packet a.

You may want to look into this as well:


Also remember that Socket.Send() does not actually send the packets, it just copies the buffer into the kernel which then proceeds it or whatever.

Since .NET sockets are build upon the berkeley sockets, then this applies as well.

So saying that Send() and BeginSend() sends the packet is actually invalid.

I never said that Send or BeginSend 'effectively' send the packet.

I only said that

If you use begin send within a lock, the packet sequence will be kept.

, which is true since .net's async functions for sockets are actually just a wrapper for the wsa functions. Here is the BeginSend function (click on DoBeginSend):

The question has been answered here: . (comment #2 to that answer)

[12tails]

thanks to all answers, basically the problem IS when the packet is encrypted.... so yeah, the lock was missing.... anyway.... it's just weird hehe... also i'm using SendAsync.... i guess it's more safe than BeginSend and Send in async sockets....

i was locking the sendasync only... the crypto was $#@#! up the whole thing :]

Now it's working fine .... xD