Memory leakage in Max?

    robin
    Dec 03 2010 | 5:40 pm
    Hi,
    I've recently been putting together a patch for a permanent installation. Previous projects I've done like this have always involved using Windows' scheduler (don't ask me why it's on Windows, something about budget constraints apparently) to restart the machine and the patch periodically to reduce the likelihood of the machine crashing. Apparently, so the client tells me, hardware constraints are such that this cannot happen. Does anybody with any experience in this know how likely it is that Windows (I think Vista) or indeed Max 5 will last before memory leakage or something else awful causes the computer to keel over? It's especially annoying as the installation is in Warsaw and we're in the UK, so rebooting every now and then isn't really a practical option.
    Thanks
    • andrea agostini
      Dec 03 2010 | 6:02 pm
      Hi.
      One explaination might be that you're filling up Max's symbol table. Every symbol you create is stored in memory and never erased until you quit Max. This is not a memory leak, is part of Max's design and has specific purposes, but can become a serious issue for long-running patches.
      If this is what causes your crashes, the only solution is reducing the number of symbols you create, using numbers whenever possible and being careful with [sprintf], [combine] and things like that.
      hth aa
    • robin
      Dec 03 2010 | 6:12 pm
      Thanks for the reply. When you say 'create', does that apply to just being used? I have various messages that are printed to the Max window to give some feedback about the patch's behaviour so it can be monitored long term. Some of these are routed to various locations. Will banging these messages be classed as 'creating' them do you know?
    • AlexHarker
      Dec 03 2010 | 11:53 pm
      Each new symbol will bloat the table by a very small amount. When symbols are reused there is no additional memory overhead, so unless you are doing something like auto-generating symbols (from date / time combinations for example) then you shouldn't worry about this.
      I'd suggest that you could try running your patch whilst monitoring memory usage, and see if there is an increase over time at all. Beyond that the best way to find out is probably to run a dummy run for as long as possible in the most similar conditions you can create, although that may not be practical in your case...
      Alex
    • Roman Thilenius
      Dec 04 2010 | 4:30 am
    • Roman Thilenius
      Dec 04 2010 | 4:34 am
      and a serious answer, too.
      i have seen memory leakage some year ago quite often when using maxmsp in classic mac os.
      the memory usage, which you could see in the console was continiously rising and when the glass was full the computer froze.
      i never found out what caused this, i think it was in 4.05 and went away with 4.09, and it was not rleated to poly~.
      eventually it might have been something with the m-audio delta hardware i was using back in the days.
      -110
    • Roman Thilenius
      Dec 04 2010 | 4:36 am
      "Every symbol you create is stored in memory and never erased until you quit Max"
      the same is true for namespaces .. but they cant be the problem i guess. ;)
    • robin
      Dec 04 2010 | 9:30 am
      Thanks for all the info. I guess we just need to monitor it. Fingers crossed it won't be too bad...
    • Emmanuel Jourdan
      Dec 04 2010 | 1:57 pm
      If you can reproduce please send an example to support and we'll look into it. It's also worth mentioning that Max uses a memory pool to be more efficient, and this memory pool can give you the impression that Max is leaking but if in fact the memory can be reused. The Max window for instance uses memory in the pool, so if you clear it from time to time, you'll see that it reuses this memory. If you need to monitor things over a long period of time, I would recommend you store things into an external text file.
      HTH