Possible new big memory leak in tcpsocket

Targets
1

I have a EASYTCPSOCKET which I am sending a file out from it. This is the code

Dim ReadStream As BinaryStream = BinaryStream.Open(readFile, False)
ReadStream.LittleEndian = True

’ if file exists etc…

Do Until ReadStream.EOF
  app.YieldToNextThread
  SendMessage(1,EncodeBase64(ReadStream.Read(1024*1000)))
  app.DoEvents(100) ' be nice to xojo
Loop
ReadStream.Close
ReadStream=Nil
purge

This is being done in the received event of the EASYTCP socket.

If I send a 9 mbytes of data, the Xojo EXE uses 75 MB of memory and never releases it until the socket is closed. (even base64 should only treble it)
I need the socket open all the time so the client can get updates.

*Note its not held in memory waiting to be sent, the file arrives the other end fine, and still the memory is not released.

Anyone seen this?

2

Hi Dave,
this is a known issue at least for me on Windows platform.
For example in a WebApplication if you create a big webfile the memory used to send its contents it’s never released until the session closes: in this case I’m supposing that when session closes all the sockets for that session are closed.
Please file a bug report with your example.

Thanks.

3

without going deeper into this issue: To me your AppYieldTo Next Thread and DoEvents look kinda strange… do you run this as a service, within a thread or within a desktop app?

4

[quote=158679:@dave duke]If I send a 9 mbytes of data, the Xojo EXE uses 75 MB of memory and never releases it until the socket is closed. (even base64 should only treble it)
I need the socket open all the time so the client can get updates.[/quote]

Have you tried using Purge ?
http://documentation.xojo.com/index.php/SocketCore.Purge

9

I just added some notes to your case. From what I can see, the big problem is that the Flush method appears to hang when using EasyTCP sockets for some reason.

13

Dave I have successfully sent files > 10Gb over crappy NZ DSL (upload speed 600K). Not using EasyTCPSocket or flush, but with an event driven model. In fact I found using 6 TCPSockets with 256k of data per concurrent send gave the best results. I achieved this by sending an xml string terminated by an end of file marker (CharB(26)) followed by the raw data. The Xml file included a file offset position for that block, a checksum for that block & the length of the block. The server would respond with a good or bad depending on the checksum match whereupon the client would either resend the corrupt block or send a new block.

Of course this was before JSON was available in Real Studio, so maybe my solution no longer works.

But I’d be happy to discuss/help you work through the issue privately.

Cheers
Wayne

16

No idea if this is related, but I reported a very bad memory leak using IPCSockets under Cocoa: <https://xojo.com/issue/34107>