AQAAAA after 680 fingerprints using dylib on OS X

[Henry Z]

I've built the latest code on OS X with default options, imported the dylib into my project, and wrote some really simple code using a Swift adapter (https://github.com/NeoTeo/fingerprinter-chromaprint) that basically just loops over a library of songs (~4k tracks) and tries to generate a fingerprint for each.

Everything works great for the first 679 or 680 tracks, but at either 680 or 681, the library starts returning AQAAAA for all tracks. Restarting my app on those same tracks returns the proper fingerprint.

I can't find any errors or logs that would clue me in to what's going on -- I'm happy to provide more detail if someone can tell me how to pull debug logs or something.

[Henry Z]

Found some more detail, looks to be a memory leak..

[Lukáš Lalinský]

The memory leak is a problem in the test app. There are two problems:

1) You should call chromaprint_free on the ChromaprintContext pointer, not chromaprint_dealloc. Calling chromaprint_dealloc on it will probably work (as in, not crash), but it's not intentional and it's definitely leaking some internal pointers.

2) You should call chromaprint_dealloc on the string returned from chromaprint_get_fingerprint.

Check the comments in the header file for more details. I think that fixing these two issues will also fix the original problem, since you are definitely getting some memory corruption there.

[Henry Z]

I noticed those this morning and updated my code, so I no longer see leaks. However, it seems to progressively slow down on each subsequent call in the loop, and I still see odd behavior after 680 records -- I'm now getting: Chromaprint::FingerprintCalculator::Calculate() -- Not enough data. Image has 0 rows, needs at least 16 rows.

[Lukáš Lalinský]

Well, are you sure there is enough audio data to generate the fingerprint? I'd need to see the code, but in general the library is often used on thousands of tracks within the same run and this was never a problem, so I'm first assuming it's a problem in your application. Maybe it's a problem with the way you are decoding the audio files?

[Henry Z]

I'm pretty positive -- if I re-run the app and start with the tracks that fail, they work fine (up to 680).. My code is nothing proprietary, if you have a mac and sufficient tracks (~700 or more should do it) I'm happy to push my current repo as a repro case, it's pretty trivial code.

[Lukáš Lalinský]

I don't have a Mac recent enough to run Swift, so I can't really build and run the code. I could only have a look at the code and see if there is something obviously wrong.

I'd suggest to add some logging to the app and for each file, print how many samples are you sending to Chromaprint. If you are using one ChromaprintContext for all the files, see if using one per file makes a difference. If it does, that would suggest a bug in Chromaprint. See if completely removing Chromaprint from the audio decoding loop still causes the slow down.

[Henry Zektser]

Wound up being my mistake -- bad pointer dereference was leaking memory and eventually overflowed the process.

I don't have access, but feel free to close this..