Weird crash

12/14/2013 21:13 12tails#1

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:

Code:

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....

12/14/2013 21:53 CptSky#2

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 ;)

12/14/2013 22:04 12tails#3

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

12/14/2013 22:23 pro4never#4

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

12/14/2013 22:26 12tails#5

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

12/16/2013 12:12 Super Aids#6

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

12/16/2013 19:24 12tails#7

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

Code:

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

12/16/2013 22:50 Super Aids#8

You should lock the crypto until the packet is send.

[Only registered and activated users can see links. Click Here To Register...]
[Only registered and activated users can see links. Click Here To Register...]

12/20/2013 12:30 -impulse-#9

Quote:

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.

12/22/2013 01:47 FatalError-#10

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.

12/22/2013 18:20 Super Aids#11

Quote:

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:
[Only registered and activated users can see links. Click Here To Register...]

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.

12/23/2013 01:52 -impulse-#12

Quote:

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:
[Only registered and activated users can see links. Click Here To Register...]

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

Quote:

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): [Only registered and activated users can see links. Click Here To Register...]

The question has been answered here: [Only registered and activated users can see links. Click Here To Register...]. (comment #2 to that answer)

12/27/2013 17:46 12tails#13

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