brl.socket crashes

Monkey Forums/Monkey Bug Reports/brl.socket crashes

k.o.g.(Posted 2014) [#1]
Hello all

My App with brl.sockets crashes randomly...
i have no idea what is the issue.



It crashes on many requests / received data.


marksibly(Posted 2014) [#2]
Can you post some runnable code that reproduces the problem? Otherwise, there's not much I can do.

Also, if you're not already, try the latest version of Monkey as there have been a few fixes to the threading/gc interaction along the way.


k.o.g.(Posted 2014) [#3]
HI mark

with Version 80c it doesn't crash until now.
but i receive multiple "RACE!" messages, when my server gets many requests.

another question...
is it possible to add getBuffer method for brl.datastream?
https://github.com/blitz-research/monkey/blob/develop/modules/brl/datastream.monkey#L21
	Method GetBuffer:DataBuffer()
		Return _buffer
	end


so we can easy access the DataStream buffer. in my server looks like:
		Local sendstream:DataStream = client.sendStream
		sendstream.Seek(0)
		sendstream.WriteByte(FIN | TEXT)
		
		Local l:Int = length
		
		If l <= 125
			sendstream.WriteByte(l)
		Else If l >= 126 And l <= 65535
			sendstream.WriteByte(126)
			sendstream.WriteByte((l & $FF00) Shr 8)
			sendstream.WriteByte(l & $FF)
		Else
			sendstream.WriteByte(127)
		EndIf
		
		If l > 0
			sendstream.WriteAll(senddata, offset, length)
		EndIf
		
		If client._socket.Send(sendstream.GetBuffer(), 0, sendstream.Position()) > 0 Return True


thanks mark for your great work


***
very funny memory pattern of a stdcpp async tcp server:



ImmutableOctet(SKNG)(Posted 2014) [#4]
Besides wanting network byte-order, the whole 'GetData' thing is why I made 'PublicDataStream'. Originally, the classes were different, but it ended up being very similar to the standard data stream class. As for the whole "RACE!" thing, I get that all the time if I send a lot of packets. I also have a weird bug with my own code where it produces a packet (Stream) whenever I send a few hundred packets within a few seconds. I'm pretty sure that's my own issue, but it likely has something to do with my 'brl.socket' code, as my QuickSock code base doesn't have this issue. And on top of that, I can send a few thousand packets with QuickSock, whereas 'brl.socket' still has issues.

By the way, since I never got a straight answer on this, does the asynchronous code for 'brl.socket' copy the original buffer, or use the one originally sent in? I copy to buffers specifically for async operations, but I have no idea if that's what I need to do or not. Also keep in mind that I need to send while writing to the main buffer, so what I really need to know is if 'brl.socket' copies it or not.

Anyway, I'd recommend 'publicdatastream' and 'byteorder', but I doubt that'll help you with this problem.


marksibly(Posted 2014) [#5]
> i receive multiple "RACE!" messages, when my server gets many requests.

Oops! That's just a diagnostic thing - you can safely remove the print statement from socket.monkey. I'll do this for the next release. Actually, it's nice to see I'd picked up that race condition ahead of time - I could never get it to happen myself!

> is it possible to add getBuffer method for brl.datastream?

Sounds reasonable. I guess there also needs to be a way to retrieve the ctor 'start' index. There's already a Length() property I think...

> By the way, since I never got a straight answer on this, does the asynchronous code for 'brl.socket' copy the original buffer, or use the one originally sent in?

It doesn't copy - you shouldn't touch the data until it's finished being sent.

> Anyway, I'd recommend 'publicdatastream' and 'byteorder', but I doubt that'll help you with this problem.

Will have a look at these, thanks.