Memory leak: Load track with cover art

Bug #1767068 reported by mm-mbs
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
Critical
Uwe Klotz

Bug Description

On work with mixxx 2.1.0 I have a memory leak.

I can reproduce it on Windows (installer) and Linux (compile on Debian) on new workspace.

Load a track at deck 1 (e.g. double click on track).
Repeat this (with same track or other track) until mixxx use all memory.
If the track is big (MB) than the memory usage grow faster.

The attachment show the memory grow to ~4GB, than I stop to reload the track into the deck.

Revision history for this message
mm-mbs (mm-mbs) wrote :
Revision history for this message
mm-mbs (mm-mbs) wrote :

For test, I have only one track in library, and reload this again, again, again ...

Revision history for this message
Daniel Schürmann (daschuer) wrote :

I cannot confirm this with win 10 64 bit.
On Wich os are you?

Changed in mixxx:
importance: Undecided → Critical
milestone: none → 2.1.1
Revision history for this message
mm-mbs (mm-mbs) wrote :

My OS is Windows 7 64-Bit 2.1.0 (build 2.1 r6681) and Debian Linux (Stretch) 64-Bit.

Revision history for this message
mm-mbs (mm-mbs) wrote :

When I load a big MP3 (~200MB) 100x in deck one, the memory usage grow to 3GB. 100 more times (ca 200x load the track) the memory grow to 5.2GB. 100 more times (ca 300x load the track) the memory grow to 6.9GB. 100 more times (ca 400x load the track) the memory grow to 9GB.

Revision history for this message
mm-mbs (mm-mbs) wrote :

Here the memory graph of the last test at Windows 7.

Revision history for this message
Uwe Klotz (uklotzde) wrote :

Did some tests too:

     VSZ RSS
     ... ...
 7606476 2408108
 7803084 2554880 | 20x MP3 200 MB, with cover 500x500 ~95 kB
 7810512 2673444 | 20x MP3 200 MB, with cover 500x500 ~95 kB
 7876364 2801548 | 20x MP3 200 MB, with cover 500x500 ~95 kB
 8541100 3551628 | 20x M4A 7,5 MB, with cover 1400x1400 ~240 kB
 9450408 4471592 | 20x M4A 7,5 MB, with cover 1400x1400 ~240 kB
10302376 5391764 | 20x M4A 7,5 MB, with cover 1400x1400 ~240 kB
10302376 5399660 | 20x FLAC, without cover
10306204 5405740 | 20x M4A 7,5 MB, without cover
10306204 5405772 | 20x M4A 7,5 MB, without cover

This is caused by cover art loading!! The size and format of the file doesn't matter.

Revision history for this message
Uwe Klotz (uklotzde) wrote :

After removing the cover art from the M4A file the memory usage is stable.

Changed in mixxx:
status: New → Confirmed
summary: - Memory leak on load track
+ Memory leak: Load track with cover art
Revision history for this message
Uwe Klotz (uklotzde) wrote :

Looks like I found and fixed it:
5900632 330568 | initial
5947424 492736 | 50x M4A 7,5 MB, with cover 1400x1400 ~240 kB
5951244 496956 | 50x M4A 7,5 MB, with cover 1400x1400 ~240 kB
5951244 621060 | 50x M4A 7,5 MB, with cover 1400x1400 ~240 kB
6204624 884284 | 50x MP3 200 MB, with cover 500x500 ~95 kB
6204752 884248 | 50x MP3 200 MB, with cover 500x500 ~95 kB
6018020 810032 | 50x M4A 7,5 MB, with cover 1400x1400 ~240 kB
6018020 810032 | 50x M4A 7,5 MB, with cover 1400x1400 ~240 kB

Changed in mixxx:
assignee: nobody → Uwe Klotz (uklotzde)
status: Confirmed → In Progress
Revision history for this message
Uwe Klotz (uklotzde) wrote :
Revision history for this message
mm-mbs (mm-mbs) wrote :

OK, I can confirm this. If I remove the cover art, than the memory isn't growing.

Revision history for this message
mm-mbs (mm-mbs) wrote :

I compiled on Linux with your patch and the memory leak was fixed.

Thanks for great job.

Uwe Klotz (uklotzde)
Changed in mixxx:
status: In Progress → Fix Committed
Changed in mixxx:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers