Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Encounter "bad allocation" error when running ReplayGain scan (Read 1658 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Encounter "bad allocation" error when running ReplayGain scan

I encountered intermittent "bad allocation" errors when running ReplayGain scan on 24/192k material.
When I retry the scan again, different track will encounter the "bad allocation" error.
This problem seem to affect only huge files like 24/192k content, does not seem to affect 16/44k content.

I found out that by restarting foobar, the problem went away totally.

I suspect it'll come back after some time.

May I know what debug log/traces I should collect the next time around?

I am running foobar v2.1.5 x86 (32-bit).

Thank you.

Re: Encounter "bad allocation" error when running ReplayGain scan

Reply #1 –
Why aren't you using the 64-bit version?

Re: Encounter "bad allocation" error when running ReplayGain scan

Reply #2 –
Quote from: Gus. on
Why aren't you using the 64-bit version?

Makes no difference.  I just tested the 32-bit version with 192 KHz/24-bit files and the scan works just fine.

Re: Encounter "bad allocation" error when running ReplayGain scan

Reply #3 –
Quote from: Chibisteven on
Quote from: Gus. on
Why aren't you using the 64-bit version?

Makes no difference.  I just tested the 32-bit version with 192 KHz/24-bit files and the scan works just fine.

Same on my side, per my post above -- after I close & restart foobar, ReplayGain scan works just fine for me too.

I suspect that foobar may have some memory leak issue over time, therefore I expect this problem to come back again.
That is why I ask what logs/traces to collect the next time this happens.

Re: Encounter "bad allocation" error when running ReplayGain scan

Reply #4 –
Quote from: Gus. on
Why aren't you using the 64-bit version?

Because I have 32-bit plugin that I absolutely require, and that plugin do not have 64-bit version. :(

Re: Encounter "bad allocation" error when running ReplayGain scan

Reply #5 –
Quote from: boxerfan88 on
Quote from: Chibisteven on
Quote from: Gus. on
Why aren't you using the 64-bit version?

Makes no difference.  I just tested the 32-bit version with 192 KHz/24-bit files and the scan works just fine.

Same on my side, per my post above -- after I close & restart foobar, ReplayGain scan works just fine for me too.

I suspect that foobar may have some memory leak issue over time, therefore I expect this problem to come back again.
That is why I ask what logs/traces to collect the next time this happens.

1. Check your files for any corruption issues.
2. Check all 3rd party components carefully for any updates if possible or rollback any to a previous version that are having problems after being updated.
3. Check your ReplayGain Scanning Preferences.  (File > Preference > Tools > ReplayGain Scanner), the settings to double check are "Downsample high definition content" and "True-peak scanner", especially the former if 192/24 files are giving you trouble.
4. Try a different Resampler to see if the problem goes away under "Downsample high definition content" and "True-peak scanner".  1st party resamplers are "dBpoweramp/SSRC" and "RetroArch", any other resampler is 3rd party.
5. Reset the ReplayGain scanner page if you're still having problems by clicking on "Reset page".
6. Try a portable clean install if all else fails.

Debugging / Bug Report Tips
1. Go to "File" "Preferences" and click on the "Advanced" tab on the bottom of the left pane.
2. Scroll all the way down to the bottom on the right pane and check these debugging functions "Crash on Playback error" and "Crash on tag read/write error" (remember to uncheck these when done).
3. Now go to "View" and choose "Console".  Click on "write log" and choose a folder to write the log to.  Remember to uncheck write log when done.

Crash logs are typically found in "C:\Users\%YOUR CURRENT USER NAME HERE%\AppData\Roaming\foobar2000-v2\crash reports"

Re: Encounter "bad allocation" error when running ReplayGain scan

Reply #6 –
If ReplayGain causes allocation failures it sounds like your foobar2000 process is running at near maximum memory usage. Hard to believe a setup like that is stable.

Re: Encounter "bad allocation" error when running ReplayGain scan

Reply #7 –
I noticed that RG/TP scans can lead to high memory usage and crashes. https://hydrogenaud.io/index.php/topic,121957.0.html
I assume that it still behaves like this. So if you need to scan many files you might have to do it in separate sessions, closing and reopening Foobar between them.

Re: Encounter "bad allocation" error when running ReplayGain scan

Reply #8 –
Looking at the advanced preferences it appears to use as many cores as you have available. Maybe look at reducing that if you have an above average spec CPU. I'm slumming it on a 10 year old i5 so no issues here. :P

Re: Encounter "bad allocation" error when running ReplayGain scan

Reply #9 –
I have 24 cores, doing the supposedly crashy operation in the linked thread with 1 MHz TP scanning target makes foobar2000 use a bit over 200 MB of memory at times, memory use of course changes all the time as memory gets released when a track finishes. If someone manages to get a high memory usage it requires something more.

Re: Encounter "bad allocation" error when running ReplayGain scan

Reply #10 –
Correction, I didn't do as the linked thread said. It was about 1.6.x and I tried with 2.2 series. I just tried with 1.6.18 and its memory use kept increasing until the scanning died. No crash logged and player seems to function but memory use stays near 4 GB.

Edit: testing foobar2000 v2.1.5 now. Memory use low like with 2.2 series.

Re: Encounter "bad allocation" error when running ReplayGain scan

Reply #11 –
FWIW, I can run a per-track RG scan on 5000 tracks using a Win7 netbook, Intel Atom with 1GB RAM, no problem (slowly, obviously).  I'm still running 1.6.12 (if it ain't broke I don't fix it).
It's your privilege to disagree, but that doesn't make you right and me wrong.

Re: Encounter "bad allocation" error when running ReplayGain scan

Reply #12 –
Hi all, thank you for your suggestions. A few more data points to add from my side.
* my PC has 48Gb RAM, and normal usage runs at around 25%. (I doubt 32-bit foobar would chew up all of it)
* when the RG scan fails with "bad allocation" on some tracks, the foobar2000 is actually playing music with no problems at all.
* after seeing the "bad allocation" RG errors, I checked the console -- no errors that I could see.
* after I restart foobar2000 and retry RG scan, it succeeds with no problems at all. so the cause of the problem must be unique to the earlier session.

So if it happens again, I should:
* take a snapshot from windows task manager-details tab showing foobar memory usage
* Go to "File" "Preferences" and click on the "Advanced" tab on the bottom of the left pane.
* Scroll all the way down to the bottom on the right pane and check these debugging functions "Crash on Playback error" and "Crash on tag read/write error" (remember to uncheck these when done).
* Now go to "View" and choose "Console".  Click on "write log" and choose a folder to write the log to.  Remember to uncheck write log when done.
* Stop playback
* Disable all DSP
* Check your ReplayGain Scanning Preferences.  (File > Preference > Tools > ReplayGain Scanner), the settings to double check are "Downsample high definition content" and "True-peak scanner", especially the former if 192/24 files are giving you trouble.
>> my setting for "Downsample high definition content" was switched OFF, I just switched it ON <<

=> Retry RG scan to trigger the failure

=> save all the captured data

As an aside, could this >> my setting for "Downsample high definition content" was switched OFF, I just switched it ON << cause the problem I encountered?

.

Re: Encounter "bad allocation" error when running ReplayGain scan

Reply #13 –
This is the most relevant post:

Quote from: Case on
If ReplayGain causes allocation failures it sounds like your foobar2000 process is running at near maximum memory usage. Hard to believe a setup like that is stable.

You need to check memory usage with task manager before doing any scan. Check when fb2k starts and also after an extended period of normal playback to see if it's grown at all.

Re: Encounter "bad allocation" error when running ReplayGain scan

Reply #14 –
Quote from: boxerfan88 on
* my PC has 48Gb RAM, and normal usage runs at around 25%. (I doubt 32-bit foobar would chew up all of it)
32-bit apps can only access a maximum of 4GB RAM (I assume you mean gigabytes [GB] not gigabits [Gb]).
It's your privilege to disagree, but that doesn't make you right and me wrong.

Re: Encounter "bad allocation" error when running ReplayGain scan

Reply #15 –
Quote from: marc2k3 on
This is the most relevant post:

Quote from: Case on
If ReplayGain causes allocation failures it sounds like your foobar2000 process is running at near maximum memory usage. Hard to believe a setup like that is stable.

You need to check memory usage with task manager before doing any scan. Check when fb2k starts and also after an extended period of normal playback to see if it's grown at all.


Hi @marc2k3 @Case :

Today, I managed to capture about 6 hrs of foobar memory footprint at 1 minute intervals.
Foobar was either playing music or paused during the said period.
It clearly shows the memory footprint keeps growing over the 6hr period which suggest some sort of memory leak.

foobar2000 v2.1.5 32-bit

If you have a suggested debug utility that I can run externally to "peek into" foobar memory footprint, maybe it can help narrow down the problem area.

encl: script + memory log


ps: at the next opportunity, I'll install a fresh copy of foobar2000 (portable) with noDSP noVisualization,  play music and log the memory usage...

Re: Encounter "bad allocation" error when running ReplayGain scan

Reply #16 –
Another set of logs attached.
In this one, PID 20664 is the clean install foobar, PID 15180 is my main foobar instance.
The clean install foobar (20664) memory footprint isn't growing ... next step is to hunt down which plugin is causing the memory leak...
This is gonna be a painful process...

Re: Encounter "bad allocation" error when running ReplayGain scan

Reply #17 –
Another set of logs attached.
After lots of trial & error bug hunting, I think I found the memory leak culprit ... foo_loudness_peakmeter
In this one, PID 6448 is my main foobar instance, PID 20192 is the clean install this time with foo_loudness_peakmeter visualization.
Now, in both instances the memory footprint keeps growing and growing and growing.

Re: Encounter "bad allocation" error when running ReplayGain scan

Reply #18 –
I doubt it's foo_loudness_peakmeter. I got that one and a whole slew of other plugins installed. Even some of the ones labeled as 'problematic'. It's been running for days, idlng when I sleep. Memory footprint is still extremely low. Like you I'm running 2.1.5 32bit

X

Re: Encounter "bad allocation" error when running ReplayGain scan

Reply #19 –
If you're tracking a memory leak, add the 'Commit size' column to Task Manager. 'Memory (active private working set)' doesn't count memory that has been paged out, so won't give you an accurate view of a memory leak.
.

Re: Encounter "bad allocation" error when running ReplayGain scan

Reply #20 –
including commit size and with Loudness Peakmeter active..

 

Re: Encounter "bad allocation" error when running ReplayGain scan

Reply #21 –
Taking in your feedback, I installed again a fresh instance of foobar (fbtest) and only added the foo_loudness_peakmeter visualization, no DSP whatsoever is active, standard DUI, playback to NULL output.

PID 22908 is the second newly installed instance. The memory footprint grew from 61,980K @ 07/25/2024 18:16:10.11 all the way to 274,152K @ 07/26/2024  8:22:10.16.

This kind of problem is hard to catch by looking at one data point in time in TaskMgr. Need to run the script to log every minute over a period of time and see if there is a pattern of growth. My logger is in the enclosed ZIP.

encl.