Long Drambo sessions while hosting plugins crash

I usually keep my iPad plugged in to a power supply and audio interface, have a long running session and work on it in short bursts. After running for a number of hours, Drambo crashes and a JetsamEvent log file is generated. Sometimes, the crash makes the audio interface require a power cycle in order to work again.

This only happens when I use an AUv3 plugin in Drambo, a session with only native modules can run for days without crashing. I've tried using just one plugin at a time, from different vendors, but I couldn't isolate the issue; I always get crashes.

As a point of comparison, I've tried the same plugins in AUM and it has never crashed with long sessions.

As far as I know (which is not much) JetsamEvents are caused when the OS tries to reclaim memory from high consuming processes, which may be indicative of a memory leak in Drambo.

I'm attaching the log of the latest JetsamEvent in case it helps.


Comments

  • If you search that file for "reason (note the quote), you see that Drambo was indeed singled out for "per-process-limit" with 327680 pages (of 16 K bytes). That's exactly 5 GiB, or quite a lot. iPadOS apparently felt that was too much and killed the process. As you say, that seems to indicate a problem in the interface between Drambo and an AUv3 plugin. It should be evident to the dev almost immeditately, seeing the memory usage creeping up; no need to wait for hours.

    As a work-around, you could save the project and exit Drambo (force-quit) between sessions. Not as handy, but maybe less inconvenient.

  • @uncleDave thanks for helping me understand the log and the workaround suggestion! I've learned to live with the issue and it's not that big of a deal for my workflow (loading the autosaved session is usually enough), but I decided to report it once I noticed it only affected sessions with AUv3s and couldn't reproduce it with AUM. I'd be glad if this helps Drambo be even better :)

  • I'm curious which AUv3's were used to cause this?

    I mostly use quite light-weight AUv3's and have never had this happen...

  • @samu this particular session had VTines and Other Desert Cities, but I've tried many others with the same result.

    I wonder if there's any way for me to measure the memory consumption of processes in real time, either with an app or connecting the iPad to my Mac (using Instruments, I guess). That could allow me to isolate the issue further.

  • I usually use the Console.app on the Mac and monitor what's happening on the iPad/iPhone when I need to track down animalities.

    (I think it needs cable connection to the Mac to work properly).

    You can select the iPad on the left side and start streaming the data and when the crash happens you can pause it and search for stuff.

    I've used it a couple of times to track down crash-issues with some other apps...

    The last time I tracked down an app it was using deprecated libraries causing it to bail on newer iOS versions (the app had not been updated for a while, once I forwarded the info to the developer an update was issued a few weeks later, it's not a music app though).

    It's worth a shot!

  • Thanks! I'll try that tonight

  • That's worth a try, but it's not really a "crash". It's an app shutdown initiated by the system. The app doesn't do anything that causes it to fail (bad memory address, invalid instruction), it just becomes too large. The system needs memory for some other purpose and notices that Drambo has exceeded the allocation allowed for such an app ("per-process-limit") and shuts it down. You might be able to tell when or why Drambo is requesting (and retaining) memory. But you really need to know more about the Drambo code to understand it. Good luck!

  • So I actually took the plunge and crafted some test cases. It seems to me like there is a memory leak in Drambo when hosting AUv3 instruments, but not effects.

    Here's a summary of what I've tested so far:


  • Great analysis @NoiseFloored!

  • @NoiseFloored - does it still happen if you have background audio disabled and switch to the Home Screen or press the sleep button when not actively working? If so, that might be an easier workaround.

  • @rs2000 thanks!

    @number37 in my experience with background audio disabled (that's what I normally use in my phone), even though there's no leak and Drambo doesn't crash, when trying to restore the session to the foreground after some time (in the order of minutes) all plugins appear as crashed (their icon is replaced with an "error" message). I think I'm fine with my current workaround for the ipad, so at this point, now that I think I've isolated the problem enough, I just hope this helps Giku track down the root cause.

  • Alright, I did one last experiment, with 20 Troublemaker instances. It took a little less than 2 hours for Drambo to crash, and it did precisely when it hit the 5 GB mark. It's interesting to see how the system memory is released, along with the flags when the process was terminated:

    @giku I think there's enough here to work with, please let me know if you need anything else from me when/if you take a look at this issue. Thanks!

  • edited March 1

    It looks like caling maximumFramesToRender on AUv3 instance causes a leak.. (system issue). I'm going to add a workarround for this and file a bug.

    It happens only with AUv3 instruments, effects shouldn't cause this.

  • @giku Great! Thanks for spending time on addressing this :)

  • @giku just closing the loop here: this has been fixed, thank you!

Sign In or Register to comment.