RDD (Data Decoder) process spins at ~590% of one CPU core indefinitely on cn.aliyun.com while Edge stays at ~0%
Categories
(Core :: Audio/Video, defect, P3)
Tracking
()
People
(Reporter: 3112513, Unassigned, NeedInfo)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:157.0) Gecko/20100101 Firefox/157.0
Steps to reproduce
- Firefox 157.0 (build 20260924084938) on Windows 10 26H2 (build 26300.9457), AMD Radeon graphics.
- Open https://cn.aliyun.com/
- Open about:processes
- Watch the row labelled "数据解码器" / "Data Decoder" (the RDD process).
Actual results
The RDD ("Data Decoder") process sustains ~550-620% of one CPU core indefinitely — observed for 15+ minutes and reproduced across multiple independent 5 s / 10 s / 60 s samples. No media is visible or playing. The tab's own content process sits at ~90-140%. Closing that tab returns RDD to idle; restarting Firefox does not help — the spin reappears as soon as the page is reopened.
Same machine, same moment, cross-browser control:
- Microsoft Edge: https://www.aliyun.com/ open since 07:09:18 plus 4 other pages -> ~0% (60 s curve 0/82/9/0/1/0; the 82% was a single page-load spike)
- Firefox 157.0: https://cn.aliyun.com/ -> 588% sustained
Per-process CPU, 10 s window (PowerShell Get-Process):
rdd / Data Decoder 588% of one core 494 MB
tab (cn.aliyun.com) 122% 292 MB
GPU 26% 125 MB
utility (WMF audio) 36% 47 MB
Total Firefox ~7.7 cores on a 12-core machine.
Ruled out:
- Hardware acceleration: with media.hardware-video-decoding disabled and Firefox restarted, RDD still ~550% (see screenshot 2)
- GPU TDR: none in the System event log
- Extensions: one installed, no permissions, process idle
- Network/DNS: challenges.cloudflare.com resolves and returns HTTP 200 from this machine
Local workaround that eliminates it (identical page left open):
media.autoplay.default = 5
media.rdd-retryonfailure.enabled = false
-> RDD goes from 588% sustained / 2731 CPU-s lifetime ==> idle / 1 CPU-s lifetime
Both prefs were applied together, so this does not isolate which one is load-bearing.
media.rdd-retryonfailure.enabled is the primary suspect: an unbounded decode "retry on failure" loop.
Also observed: crashhelper.exe v157.0.0.11 crashed 9 times with exception 0xc0000409 (fail-fast), clustered at browser startup (2026-10-04 21:27-21:29, 2026-10-05 07:04-07:06). about:crashes shows no submitted reports, so automatic crash reporting on this machine is dead (screenshot 5). Possibly a separate bug, reported because it removes our ability to attach crash data.
Expected results
An idle page with no playing media should not keep a decoder process busy. Decode work should be paced to actual playback and bounded; a failed decode should error out rather than retry in a loop.
Cross-reference — the three existing [RDD] bugs all live in Core :: Audio/Video: Playback,
so this likely belongs there too:
1761217 [RDD] When video decoder is restarted, audio decoder fails
1761942 [RDD] Limit maximal number of RDD process restart
2032292 ...OOB access in RDD process
Note on attachments: the guided form accepts only one file, so the full write-up and all
five about:processes screenshots are inside the single PDF — pages 1-3 are text, pages 4-8
are the screenshots (620% -> 550% with HW accel off -> idle after closing the tab -> 84%
with many tabs -> about:crashes empty).
|
||
Comment 2•1 month ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Networking: DNS' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Updated•1 month ago
|
|
||
Comment 3•1 month ago
|
||
I'm experiencing this too, but not on this particular website. Dada Decoder goes to 100% even when not playing any video.
|
||
Comment 4•1 month ago
|
||
| gecko-triage | ||
Thank you for the detailed report.
Analysis
Our tool cannot read the attached PDF, so this triage uses the text in comment 0. Your workaround changes two prefs from their default values: media.autoplay.default (default 1) and media.rdd-retryonfailure.enabled (default true). The bug has no profile yet, so we do not know which work keeps the RDD process busy.
Next steps
Before the capture, set media.autoplay.default and media.rdd-retryonfailure.enabled back to their default values in about:config. Then close all Firefox windows and start Firefox again. The problem must come back for the capture to show it.
Please capture a profile:
- Open
about:logging. - On the Logging presets tab, choose the "Media playback" preset.
- Under Logging output, select "Logging to the Firefox Profiler".
- Click Start Logging.
- Reload the page. Then do the steps that show the problem.
- Click Stop Logging. The profile opens in the Firefox Profiler.
- Click Upload Local Profile. This is the share button.
- Copy the share URL. Add it to this bug.
The instruction video shows these steps. If the profile or the media content is private, send it to media-alerts@mozilla.com instead.
Could you please also add the full text of about:support to this bug?
The crashhelper.exe crashes are a different problem. We recommend a new bug in Toolkit :: Crash Reporting for them.
Ori, could you please tell us the URL of a page that shows the problem for you? A capture from that page, with the steps above, also helps.
To give feedback on this comment, add a thumbs-up or thumbs-down reaction.
|
|
||
Comment 5•1 month ago
•
|
||
Here's the profiler output: https://share.firefox.dev/47nND9b
Steps performed:
- Started fresh profile with "firefox -profile /tmp/empty_profile -no-remote". Tried the steps below without logging. Closed the window and launched firefox again.
- Started logging.
- Opened main page of youtube.com. Data Decoder started taking up 100% of CPU.
- Closed youtube tab. Data decoder stayed at 100% CPU.
- Stopped logging.
This doesn't happen on my work machine, so maybe it has to do with hardware decoding and my particular graphics card and driver.
|
|
||
Comment 6•1 month ago
|
||
mozregression identified Bug 2067742 - "Update ffvpx Vulkan Video sources with FFmpeg ebb6f28da5" as the culprit.
|
|
||
Updated•1 month ago
|
|
|
||
Comment 7•1 month ago
|
||
My mistake, is was originally about an earlier version, from before the change that affects me was introduced.
I opened bug 2082667.
|
|
||
Updated•1 month ago
|
|
|
||
Comment 8•1 month ago
|
||
| gecko-triage | ||
Thank you, Ori. The profile and the about:support in comment 5 show a different problem, so you filed bug 2082667 for it. That problem occurs on Linux with Vulkan video decoding on an NVIDIA GPU. The profile shows no code in the general media pipeline that could also cause this report on Windows.
Analysis
This bug occurs on Windows 10 with an AMD GPU, also with hardware decoding off. We still do not know which work keeps the RDD process busy on cn.aliyun.com. This bug now blocks bug 1445470, the video performance meta bug.
Next steps
The bug still waits for the data that comment 4 asks for.
Pearl, could you please add the profile that comment 4 describes? Capture it on Windows on cn.aliyun.com, with both prefs at their default values.
Could you please also add the full text of about:support?
To give feedback on this comment, add a thumbs-up or thumbs-down reaction.
Status update from the reporter — the version has changed and I can no longer reproduce.
Environment now:
Firefox 157.0.1 (build 20261005135250). Comment 0 was filed on 157.0
(build 20260924084938); the browser has auto-updated since then.
I did what comment 4 asks, before any capture:
media.autoplay.default 5 -> 1 (default)
media.rdd-retryonfailure.enabled false -> true (default)
Note on why this took a while: both prefs were being re-applied at every start
from a profile-level user.js. Changing them in about:config did not stick. I
removed those overrides, verified the effective values are the defaults, and
restarted Firefox.
Result — the spin does not reproduce anymore on this machine:
- https://cn.aliyun.com/ loads normally (window title confirms the site).
- Fresh tab, 20 s after load, then a 12 s per-process CPU sample:
RDD (Data Decoder) 0.0% 107 MB
tab (cn.aliyun.com) 0.0% 266 MB
parent 0.4% 383 MB - RDD is clearly engaged with the page (working set rose 31 MB -> 107 MB)
but it is idle, not spinning. - For comparison, the original symptom was 588% sustained at 494 MB.
So there is nothing to profile right now, per your point that the problem has to
come back for the capture to show it.
Questions:
- Is any change in 157.0.1 expected to have affected this, or should I keep
trying to reproduce (e.g. specific page sections, playing a video, many tabs)? - If it does come back, is the about:logging "Media playback" preset still the
capture you want, or should I use something else?
On about:support: I can paste the full text if you still want it, but I left it out
because it seems more useful once the bug actually reproduces. Tell me and I will
add it right away.
|
|
||
Comment 10•22 days ago
|
||
| gecko-triage | ||
Thank you for the update and for the clear test.
Analysis
We found no change in Firefox 157.0.1 that touches the RDD process or the media decoders. Thus nothing confirms a fix in Firefox. A change on cn.aliyun.com can also explain the new result. The cause of the high CPU use is still not known. Our tool cannot read the attached PDF.
The pref media.rdd-retryonfailure.enabled only controls a new launch of the RDD process after an earlier launch failed (RDDProcessManager.cpp). It does not control a decode retry inside a running RDD process.
Next steps
Could you please add the full text of about:support to this bug now? It shows the decoders and the graphics state of your computer.
For your second question: the capture that comment 4 describes is still the correct one. If the high CPU use comes back, please make that capture while the problem occurs. You do not need to try other pages or more tabs.
If you'd like to provide feedback on this comment, please use the 👍 or 👎 reaction.
Description
•