Hi, Was this ever investigated more closely? I'm seeing the same thing on jit.net.send as well. Physical memory used by Max increases for each image sent (single frame, 1920 x 1080). Eventually it crashes.

I'll put together a patch that shows this, but was curious if others saw this as well.

Thanks, David

And here's a patch showing the leak. Mac 10.9.4, Max 6.1.7. Matrix sent to PC running windows 7, max 6.1.7. db

and a little more info:

seems that the memory keeps growing till it gets to ~500mb, on BOTH jit.net.send & jit.net.recv. Once it hits this threshold it's steady. Recreate the jit.net object and it releases the memory and the process starts over. Is there a buffer setting on these objects? I would hope that once the image made it to its destination it would be removed from the buffer (if this is what is going on).

Any thoughts on this? I'm still having to work in 32-bit land with a pretty big app, so losing 500mb of memory to this isn't really ideal.

Thanks, David

Returning back to this thread to see if anyone else sees this or has a recommendation for another solution. Here's the situation: For a museum exhibit I have 50+ tablets running around the museum space. If they do well in their quest the tablet takes a selfie and sends the image to a video server to be displayed on a big video wall. I'm using jit.net.send/recv to send the image from tablet to the server to be composited with other selfies.

The problem is hitting me in 2 ways: 1. each tablet needs it's own jit.net.recv object on the server side. I've tried every available published message to try to dynamically activate/deactivate the connection so others can send to the same recv object with no luck. 2. each jit.net.recv (and send) object eventually consumes ~500mb of RAM. 500mb * 50 tablets = way too much needed memory (and running in 32bit).

And here are some things I have tried: 1. setting a different IP address to the jit.net.send object. i.e. say I start by connecting to 192.168.1.100. On the receiving end I see that it's connected. I send an "ip 127.0.0.1" message to the send jit.net.send object and I see on the reserver side that the connection has stopped. However if I send the sender object an "ip 192.168.1.100" message again, it will not connect again till I restart of Max. 2. scripting the creation and deletion of the jit.net.send object on the fly as needed. This seems to sort of work, at least wrt to allowing all the tablets to send to the same port on the server, however I get a couple crashes a day on the sender side at the moment I try to delete the object via scripting.

Anything obvious that I'm missing? Another object for sending images, perhaps?

Some stats: Max 6.1.8, 32 bit. Seeing the crash issue in Windows 7 See the memory issue and the inability to re-assigned an IP to jit.net.send in Window 7, 8.1, and Mac OS 10.9.4

Thanks, David

I can't comment on the issues you're seeing, but I think jit.uldl would be much better suited to this type of situation than jit.net.send/recv since it's an asynchronous process. You could set up an ftp server on your video server, send from the tablets to a directory on the server, watch that directory and periodically display any new images?