jeffburger

I'm experiencing what appears to be a memory leak in jit.net.recv. The attached illustrative test patch is a simple mod/combo of the jit.net.send and jit.net.recv help files, with the resolution boosted to the 1920 x 1920 I'm running. Mac Activity Monitor shows decreasing free memory and increasing VM size before eventually stabalizing at less desirable stats.

This test patch doesn't actually crash, but my actual patch (too complex to send) does sometimes when I have a lot more going on. (Per another thread, I've tried modifying max.java.config.txt (max.jvm.option -Xms256m and max.jvm.option -Xmx1024m), which has resulted in fewer crashes and longer runs before crashes.) Some of the potentially relevant other differences between the attached simple test patch and my actual (crashing) patch are 1) separate standalones for the send and receive sides of things on one machine via localhost, 2) bitmap images rather than generated noise, 3) net.tcp.send/recv are simultaneously using Java to communicate control data between standalones but on a different port than jit.net.send/recv.

System: Mac 2.66Ghz quad core, 8GB RAM, OS 10.6.8, 64-bit mode

BTW, I'll eventually need to port this to Windows as well.

I'm experiencing what appears to be a memory leak in jit.net.recv. The attached illustrative test patch is a simple mod/combo of the jit.net.send and jit.net.recv help files, with the resolution boosted to the 1920 x 1920 I'm running. Mac Activity Monitor shows decreasing free memory and increasing VM size before eventually stabalizing at less desirable stats. 

jit-net-recv-memory-leak-eventual-crash

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.

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. 

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.

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


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.

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

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.

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

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?

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

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.

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

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?

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?


jit.net.recv memory leak > eventual crash