Bad Memory Leak

[mxklb]

I experience heavy memory consumption when sending "fast" signals. I tested it to receive MIDI note and clock signals but memory looks like it gets never freed, just accumulating. I'm just sending some simple MIDI notes. It's easy to reproduce, try:

#!/usr/bin/env python
import sys
from pythonosc.dispatcher import Dispatcher
from pythonosc.osc_server import ThreadingOSCUDPServer

osc_port = 1377
receiver = "localhost"

# Default handler to process OSC messages ..
def defaultHandler(address, *arguments):
    print(f"DEFAULT {address}: {arguments}", flush=True)

# Special handler for MIDI messages only ..
def midiMessageHandler(address, *arguments):
    print(f"MIDI Trigger <- {address}: {arguments}", flush=True)

# Setup message handlers ..
dispatcher = Dispatcher()
dispatcher.map("/midi/*", midiMessageHandler)
dispatcher.set_default_handler(defaultHandler)

# Init and start osc server ..
try:
    server = ThreadingOSCUDPServer((receiver, osc_port), dispatcher)
    server.serve_forever()  # Blocks forever
except:
    print(str(sys.exc_info()))
    print("OSC server failed ..")
    sys.exit(1)  

Now when sending (midi) messages at 300 BPM, I'll get the following cumulative memory usage (~ +100MB/10min):

This looks not good. Am I doing something wrong here? Sadly this is more or less your example code :(

In fact memory get's never freed even when signal sending is stopped! This is not acceptable (for my purpose) ..

Please point me to a solution how fix this, I can't figure out what shall be wrong with the code, thanks

Or is this a bug? If so, when could I expect it to be fixed? Is this project still under development?

[mxklb]

P.S. May be related to #110 which is quiet old 👎

[attwad]

Yes this could be related indeed 👀
This library is maintained in that I am happy to review PRs to improve/fix things but I'm not actively working on it so if you want to send a PR please do so. Thank you.

[mxklb]

Thank you for your quick reply, if I'll find time I'll have a look, but I don't know when and if I can fix it, so we'll c ..
Besides this issue, the lib works like a charm, cheers

[mxklb]

Because I couldn't find another quick solution I switched to https://github.com/Xinne/osc4py3 (which implements a nearly similar lib interface) and the RAM leak issue is gone! Sorry but also CPU is slightly less abused by using osc4py3 compared to python-osc. Hopefully you find some time to optimize this, good luck ..

So my solution to avoid this nasty RAM issue is to use the alternate OSC lib https://github.com/Xinne/osc4py3