Engine DJ 4.0 memory leak on Mac?

Hey! Sorry to post this in the general area but I can’t find anywhere else or other posts that match my symptoms. So basically myself and my girlfriend are running Engine DJ 4.0 on our Mac computers. Both are running macOS Sonoma on fully patched MacBook Air M1s.

On both computers, if we leave Engine DJ running in the background, perhaps overnight or over a weekend (the MacBooks go to sleep) then when we come back, the system complains of running out of Application Memory, and the culprit every single time is Engine DJ.

This looks to me to be the classic symptom of a leaky application. What I’d like to find out is whether anyone else is suffering from this, are we doing something wrong, or is it in fact a recognised issue that might be fixed in future releases? Needless to say, it causes quite a few problems!

Topic moved :wink:

Hi Mark, I use an M1 MacBook Pro (with 1tb hard drive and 16gb of RAM and I haven’t noticed this.

Out of interest, what is stopping you from closing it down before you finish using the computer? I never leave Engine running for any longer than necessary.

Thanks Reese :wink:

Stu-C - There’s nothing stopping me closing it down after use; it’s just habit I guess. I leave multiple apps open on my Mac as part of regular use. And sure enough if I DO close it own then this doesn’t happen. However logic would dictate that I should be able to leave it open in the background without it consuming all the memory on my Mac over time.

Yeah it’s a fair point, is it after you have ran any of the tasks like disk cleanup or sync manager?

I have a different issue with Engine whereby it constantly pops up over the top of other apps when I’m using them so I close it down as soon as I’ve finished with it.

I think with the MacBook Air (especially the 8gb ram models) they ‘borrow’ some of your hard drive memory to run applications if the ram runs out, this could also be a factor.

Nope, there’s no pattern of behaviour needed for it to happen. Just leave Engine DJ running in the background (not doing anything, just open) and shut your Mac lid. Go back after maybe 24 hours and tadaaa, memory leak.

We do have other issues with Engine too, but this is the most annoying! Other issues include when we add and analyse new music sometimes Engine just becomes unresponsive. Can’t drag tracks into the player windows or in fact do anything. Engine isn’t processing anything that I can see at this stage, and we have to force quit and restart. Anyhoo, I am getting off topic!

What are your computer specs and what other apps do you have running/open at the same time?

I have some photo editing software called capture one pro that runs its own sort of optimisation when I fire it up, so I never have this open when using other apps as it can kill my laptop.

I have the same issue!!! It makes that i can’t export anything to any Hard drive or USB drive anymore.

I asked on several places for a solution. Nothing in return yet…

HELP!!

Good afternoon,

Yesterday I had a performance at a nice party. Just before I wanted to update the latest changes in some playlists. �I have 1 SSD external disk, which physically contains all the music. Because the hard disk of my MacBook is simply too small for all my music files. I also use this SSD disk to write my Engine DJ export to it, and so it has to be connected to my controller while i’m DJ’ing. (Denon prime 4 or Numark mixstream pro.)

When I wanted to shut down and ‘sync’ Engine DJ, the hard drive of my Macbook turned out to be ‘too full’. �I had to free up some space first. I did that. 50GB freed up. �But… now EngineDJ can start again, after which it immediately starts with “Aggregating Drives”. �Only he can’t get through. I even left it on all night. But in the morning it turned out that the Macbook had restarted itself due to a problem. The MacBook indicates that there is insufficient (working) memory. The forced stop also states that Engine DJ is currently using 50 GB. (That’s all the free space on the internal hard drive.) This really ■■■■■!!�Tomorrow I have another gig. And ik can’t get to my music database, while my Externe SSD can’t get connected to Engine DJ. (because it starts Aggregating Drives. And can’t be stopped.)— gestrest.

My questions?�

1. Can I solve it in a simple way that keeps all my playlists etc?�

2. If not, should I reinstall Engine DJ and what is the best way to do that so that my playlists are retained.�

3. Is there any way that I can recover the External SSD (Samsung T7)? So that all music remains stored the same on this external drive. ��

4. Does anybody had a good advice about your physical music on a extern SSD drive, as a Engine DJ library?

Thanks in advance for your help!!

GreetingsDingeman Knaap

M1, 8GB memory. I’m not running anything particularly resource intensive or that’s doing any out-of-hours processing. Just the usual things like Mail, Notes, etc.

Y’know if we just have to remember to shut Engine DJ down then that’s a workaround, I just kinda wanted to see if there was any “official” recognition that there is a memory leak of some kind in Engine 4.0, and that it might be fixed in future. Hopefully someone in the development team might see this …!

Nah you’ve done the right thing, no way should it be consuming that in idle state. Hopefully one of the team will see it and investigate. There are quite a few other Mac users on here, although mainly with specced out MacBook Pro’s so maybe would never have seen the issue (or at least not had a warning message).

Im wondering if there is a way of seeing the consumption, is it in the activity monitor anywhere? I can leave mine running today then check it when I get back to see what its done.

I ran into this issue and escalated to the team and am diving into the schema again today to figure out what the offending record/s is/are.

It’s not great that Engine just silently fails and for most users the best bet is to nuke the DB and start from scratch, which is not ideal at all! :frowning:

3 Likes

Welcome to the forum @Mark_Walker !

With that much RAM usage, yeah, that’s a memory leak for sure. Especially since it’s caught in an endless loop (not responding) outside of the event manager being able to do it’s thing. There is no reason Engine should be using that much RAM at all.

Would be great to have someone test this with Valgrind or similar.

I’ll admit, I’m one of those users who has loads of system, but still uses it as if I don’t, so i quit applications that I don’t use, even though I have loads of RAM.

We currently have an old & unused intel imac with 8GB RAM that I booted up and put a fresh copy of Engine DJ 4.0.0 on it. I’m doing a screen recording to watch the Memory go up over time.

I can tell you that I’ve observed this already on my M2 MacbookPro, so yeah, I suspect there is a leak issue with 4.0.

2 Likes

Yeah… this won’t happen because support for MacOS has been withered away by Apple. Last version of MacOS Valgrind officially supports is 10.13. :frowning:

Seems that there is a tool called leaks and when attaching it to Engine 4.0.0, it definitely has stuff to say. There is a lot here and the below list should not be interpreted as “The sky is falling”, but rather “maybe this is something to look at”.

sudo leaks 54903 --list
sudo(55418) MallocStackLogging: could not tag MSL-related memory as no_footprint, so those pages will be included in process footprint - (null)
sudo(55418) MallocStackLogging: stack logs being written to /private/tmp/stack-logs.55418.1027c4000.sudo.zYLHCz.index
sudo(55418) MallocStackLogging: recording malloc and VM allocation stacks to disk using standard recorder
sudo(55419) MallocStackLogging: turning off stack logging (had been recording malloc and VM allocation stacks to disk using standard recorder)
Process 54903 is not debuggable. Due to security restrictions, leaks can only show or save contents of readonly memory of restricted processes.

Process:         Engine DJ [54903]
Path:            /Applications/Engine DJ.app/Contents/MacOS/Engine DJ
Load Address:    0x1028e4000
Identifier:      com.air-music-technology.EnginePrime
Version:         4.0.0.778d88f94d (4.0.0.778d88f94d)
Code Type:       ARM64
Platform:        macOS
Parent Process:  launchd [1]

Date/Time:       2024-09-03 13:08:16.944 -0400
Launch Time:     2024-09-03 13:02:50.558 -0400
OS Version:      macOS 14.6.1 (23G93)
Report Version:  7
Analysis Tool:   /usr/bin/leaks

Physical footprint:         415.8M
Physical footprint (peak):  435.8M
Idle exit:                  untracked
----

leaks Report Version: 3.0
Process 54903: 471237 nodes malloced for 215263 KB
Process 54903: 1413 leaks for 91328 total leaked bytes.

Leak: 0x107512fe0  size=416  zone: MallocHelperZone_0x106110000   CFString  ObjC  CoreFoundation
Leak: 0x10d00ea00  size=1536  zone: MallocHelperZone_0x106110000   NSMutableDictionary (Storage)  C  CoreFoundation
Leak: 0x10f87ae00  size=1536  zone: MallocHelperZone_0x106110000   NSMutableDictionary (Storage)  C  CoreFoundation
Leak: 0x10f8fb600  size=1536  zone: MallocHelperZone_0x106110000   NSMutableDictionary (Storage)  C  CoreFoundation
Leak: 0x10f912200  size=1536  zone: MallocHelperZone_0x106110000   NSMutableDictionary (Storage)  C  CoreFoundation
Leak: 0x12f12be20  size=464  zone: MallocHelperZone_0x106110000   CFString  ObjC  CoreFoundation
Leak: 0x12f15caf0  size=416  zone: MallocHelperZone_0x106110000   CFString  ObjC  CoreFoundation
Leak: 0x12f164c40  size=528  zone: MallocHelperZone_0x106110000   CFString  ObjC  CoreFoundation
Leak: 0x12f16ca60  size=528  zone: MallocHelperZone_0x106110000   CFString  ObjC  CoreFoundation
Leak: 0x12f669d10  size=608  zone: MallocHelperZone_0x106110000   CFString  ObjC  CoreFoundation
Leak: 0x12f672e20  size=464  zone: MallocHelperZone_0x106110000   CFString  ObjC  CoreFoundation
Leak: 0x12f67d3f0  size=416  zone: MallocHelperZone_0x106110000   CFString  ObjC  CoreFoundation
Leak: 0x12f6d31f0  size=608  zone: MallocHelperZone_0x106110000   CFString  ObjC  CoreFoundation
Leak: 0x12f7bdf60  size=464  zone: MallocHelperZone_0x106110000   CFString  ObjC  CoreFoundation
Leak: 0x12f7be130  size=608  zone: MallocHelperZone_0x106110000   CFString  ObjC  CoreFoundation
Leak: 0x12f7be530  size=528  zone: MallocHelperZone_0x106110000   CFString  ObjC  CoreFoundation
Leak: 0x12f7cf320  size=416  zone: MallocHelperZone_0x106110000   CFString  ObjC  CoreFoundation
Leak: 0x12f7d0050  size=464  zone: MallocHelperZone_0x106110000   CFString  ObjC  CoreFoundation
Leak: 0x12f7d0260  size=608  zone: MallocHelperZone_0x106110000   CFString  ObjC  CoreFoundation
Leak: 0x12f7d06c0  size=528  zone: MallocHelperZone_0x106110000   CFString  ObjC  CoreFoundation
Leak: 0x12f866a00  size=1536  zone: MallocHelperZone_0x106110000   NSMutableDictionary (Storage)  C  CoreFoundation
Leak: 0x12f869c00  size=1536  zone: MallocHelperZone_0x106110000   NSMutableDictionary (Storage)  C  CoreFoundation
Leak: 0x12f8ad400  size=1536  zone: MallocHelperZone_0x106110000   NSMutableDictionary (Storage)  C  CoreFoundation
Leak: 0x12f8d3000  size=1536  zone: MallocHelperZone_0x106110000   NSMutableDictionary (Storage)  C  CoreFoundation
Leak: 0x12f96c000  size=1536  zone: MallocHelperZone_0x106110000   NSMutableDictionary (Storage)  C  CoreFoundation
Leak: 0x12f99e000  size=1536  zone: MallocHelperZone_0x106110000   NSMutableDictionary (Storage)  C  CoreFoundation
Leak: 0x12fdf0800  size=1536  zone: MallocHelperZone_0x106110000   NSMutableDictionary (Storage)  C  CoreFoundation
Leak: 0x130060c00  size=1536  zone: MallocHelperZone_0x106110000   NSMutableDictionary (Storage)  C  CoreFoundation
Leak: 0x130061200  size=1536  zone: MallocHelperZone_0x106110000   NSMutableDictionary (Storage)  C  CoreFoundation
Leak: 0x130161400  size=1536  zone: MallocHelperZone_0x106110000   NSMutableDictionary (Storage)  C  CoreFoundation
Leak: 0x130161a00  size=1536  zone: MallocHelperZone_0x106110000   NSMutableDictionary (Storage)  C  CoreFoundation
Leak: 0x1301d2600  size=1536  zone: MallocHelperZone_0x106110000   NSMutableDictionary (Storage)  C  CoreFoundation
Leak: 0x1301e1600  size=1536  zone: MallocHelperZone_0x106110000   NSMutableDictionary (Storage)  C  CoreFoundation
Leak: 0x1301e4a00  size=1536  zone: MallocHelperZone_0x106110000   NSMutableDictionary (Storage)  C  CoreFoundation
Leak: 0x1301f2e00  size=1536  zone: MallocHelperZone_0x106110000   NSMutableDictionary (Storage)  C  CoreFoundation
...
Leak: 0x600003c34640  size=32  zone: DefaultMallocZone_0x10612c000   NSNumber  ObjC  CoreFoundation
Leak: 0x600003c34660  size=32  zone: DefaultMallocZone_0x10612c000   NSMutableDictionary  ObjC  CoreFoundation
Leak: 0x600003cd9400  size=32  zone: DefaultMallocZone_0x10612c000   NSMutableDictionary  ObjC  CoreFoundation
Leak: 0x600003cd97a0  size=32  zone: DefaultMallocZone_0x10612c000   CFString  ObjC  CoreFoundation
Leak: 0x600003cda040  size=32  zone: DefaultMallocZone_0x10612c000   CFString  ObjC  CoreFoundation
Leak: 0x600003cda100  size=32  zone: DefaultMallocZone_0x10612c000   CFString  ObjC  CoreFoundation
Leak: 0x600003cda140  size=32  zone: DefaultMallocZone_0x10612c000   CFString  ObjC  CoreFoundation
Leak: 0x600003cda180  size=32  zone: DefaultMallocZone_0x10612c000   NSMutableDictionary  ObjC  CoreFoundation
Leak: 0x600003cda200  size=32  zone: DefaultMallocZone_0x10612c000   NSMutableDictionary  ObjC  CoreFoundation
Leak: 0x600003cdaae0  size=32  zone: DefaultMallocZone_0x10612c000   NSMutableDictionary  ObjC  CoreFoundation
Leak: 0x600003cdac20  size=32  zone: DefaultMallocZone_0x10612c000   NSNumber  ObjC  CoreFoundation
sudo(55418) MallocStackLogging: stack logs deleted from /private/tmp/stack-logs.55418.1027c4000.sudo.zYLHCz.index

– Edit –

IDK if leak is smoking crack or not, but I had Engine 4.0.0 run for a number of hours and it got stable after time. No where near the half GB of RAM mark.

I recorded the video of it and compressed the time.

– Edit #2

I ran Engine 4.0 with an empty DB four 12 hours and noted that it had not increased RAM usage.

Note the PID (process ID) is the same in the two screenshots:

START:

END:

1 Like

When it happens, what processes are running and consuming RAM? look in the activity monitor. Sonoma had all sorts of leak issues associated with windowsserver. Not sure if that would show up as the app using all that memory, but if you are using external monitors and things re-sizing to fit the external monitors when you open and close the laptop, I could see this being a thing.

Hmm but how many of us use Engine DJ with an empty database. Think I might set this up on my Mac and see what results I get!!

1 Like

Good point, but it is a nice control type experiment.

Thanks @Mark_Walker for taking the time to report this and everyone else who chimed in and provided input. We’re trying to reproduce this issue in-house but have not been able at this point.

Were you able to check on an empty database? Does it also happen if you open Engine DJ and leave it idle without performing any actions, or does it always happen when leaving idle after usage (analysis, import, export, etc).

Thanks!

1 Like

Hi! I haven’t managed to check it yet to be honest. I’ve upgraded to 4.0.1 now so let me test it and come back to you. My girlfriend is still on 4.0.0 so we can compare the two.

1 Like

Hello, just chipping in my ux on the issue… I also have the M1 Air but with 16GB and I haven’t experienced any drains, often leave Engine running for days active and idle. But I do experience it being unresponsive at times. For example when right clicking a cue button, I usually get the spinning wheel for about a minute before it shows the edit window and “snaps” out, back to normal response. Also while exporting library (to P4+, fast internal SSD) with Sync Manager it looks frozen and doesn’t show progress until done. (Although this might be one of the fixes in 4.01, I’m on Sonoma). Never had it hard freeze and nneding to force quit tho. …except for that one first time I used it which bricked my Prime and I had to get it replaced…