jit.net.recv memory leak > eventual crash
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.
Any insights appreciated. Thanks!
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.
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.
-- Pasted Max Patch, click to expand. --Copy all of the following text. Then, in Max, select New From Clipboard.----------begin_max5_patcher---------- 1597.3oc2as0aaaCE9YmeEDFCXa.dB7tDySYXCC6Gv.1CCCEzxrNr05xnnSR aQ+uORJIa2zXIYWKkj9PjsNhl5b9N2OR4SWMa9xhGTUyAWC9GvrYe5pYyBj7 Dl0b9r4YxGR2HqBKadZQVlJ2NeQ80rpGrA5rqAEkpbfL0puSa+.HqHWaKLfe JSl9y.Y9Jv8Ra5sfLUVg4C.cdpQIqTf601aAJo6Ju0HyTsa7FctJsXadX2IM DK86fNe8aLpTaMWKfzH3B.IAGkffhX5B.hA8jnwQPv+17K0qBbYwx28KXZ68 3sE41b+8zeoe0nka1cEy5kdp9MplR91Lc9FkMfBnC1fJ8GCa.Be3ZK1ZaWLz S7yWck+vhuQTldMvJeuBTpSsaM6.qm.WPPjGDX7vGIb+QL7HHB40KhPtFTYk FaGPAwYOf3TJV3rMfhnjDAhuyL4XfBR75ETvW6sPduyIqbqEj53cirC.hIhC NLb1PwljWuXC5ZvZkErRcmNUA1nq5xzgxIgnKdFqWPI9kOnjqt2wpeElTApT adqtq3IXXP34zZSkjtPBV+.wzJ1K2ZsE48KcLJOhPXrXjSDEQDryaH4fu9TB 6tXm07n8Ckp58b9RY95469IOoD+khF5xoQ+3FfQsd.5SW7PuoMJNh0QBh9Un ekzOeg6umV5wmh9FOJ5aQhWdErHLlFCOA0M5ko91BPfk8KvHQPcSncFHCcFp asOT6fvfmOsN0Yy6Ag3fSN8Dz5zWtJcvltJ8AWWEHlVmfuK0d72nV+396mjl mb4vGsUY5GbnHTDmhwwDG1Dxt4o+jNFmSXvS.RHGARtnlLoaTxtPEpO3.DGS icPCgDwwTDkuy34HPC9bRQTyJOS.TlppRtV8UHzcMUF9CnAX5HHQHFESb3Sb vECINB9Htb1N3wFZ15Jbd6.j988K3rQ5x5f2uvWJ8c+6bXeiJWtbSXEvdB6b pgbNFF0NdAW7hrlggL+Ojop+Rmo.+4uC9slFn.yW3OrxHu0dux79erBn+a0x l9q1wHRio395gYbYKSuznJU4q.xR+GCPAcf6KB1o+axq+PaF21p.d22dZpqA cNbjQIcG2GNA0+RtfUBcrXa9Iz00b.H0vfHzZ.QzU.M1qo.ZGCOR2TT0USuT gqzfXDLAOPTgC+N.UVqrgAG02rQPGZszc5ON56CbY.QWZZx.yC.RLoSXg8JB VrEqWuQ0eOlMRNtygkIvmch+molsb7no.3xnRHC.CDrHTLjy74VfckaQPNCS fNZ5D+Lk88cZazZiboyVGCcUaj.A2rMW+eaUtlTuwo2TlR.pejyOr91rx8TU o3b7db74axjVi9gKU0imSBZo0Z1p6bj7HmgFgDfAVyzVQcN0F1HWB2wZXucw dYJbKWoylOgSxr8I.BY6LbncF6I46twYJhYgnNL9demtg.3KxAZY5+4Pznsw 738Z6te3lWvRxfmjewkM3ZtxFU4696FcoOHaDhmDghDbvMkEFKfRYPWjVWKh 9yPCvg4vHs0OAvihgic4aCACCaW38B3QuvBAQzS+KA1phslzVlo0uGrW9Vop b04JsZmq09E4E0CVzs5UqT4Gp6Woq7kor5381OT9wm+pe9wsFzzwNndXGeqv cBOY5UkEtz8UssTV20TLOhzXqQHgBj2SZ+s7xIKjA.sOB+6UVHvPdXBIIRHf IHur7XRigrLDy1GIviocRBb.7yi705EaEIr5lI2mDW3p3hcHoQ.aSFfnvmLj M1cmvWZiVV3I6xXtFR3PJG49tyyiwHIB5woSn6Kkn0HeGoQPQvYifCKEUG7A iinPFkEuWV1QZLjEzXHKXdHp4TKKvQPVbEp35NtdrZSt.MjbthIykmIFC7k9 rXqPGRvT1jAsjAVc0zvM3gnnimN1AeAx783PTTWB61mbLGGwPNmbwtB91SZD r8vWjhRtf7y.XmoyU.MFYW4PW+iMinxcLR3hqjbPnlcjFA0MZHN2noqUNzfR 4imV9oud4XhSrTRb3gYfoz12URVyYigFdHNz3SrKi1HQ9W5wXlHwEb5KBZsi 9yk.MgVrCId4YxM0SpQVVdmxT0rkAFYdl7cEggDyWDNUmWeZXxhyMp6zsqON PQZRuUaU0+yN3G4zCI74W4uOe9p+GucTjqA -----------end_max5_patcher-----------
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.
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
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?
Forums > Jitter