[BUG] Plugin uses insane amount of memory when using css animations

Jncls commented 4 years ago

Platform

Operating system and version: MacOS 10.14.4 OBS Studio version: 25.0.7

Expected Behavior

I'm using the browser plugin to show interactive contents during my streams. Until last week everything worked like charm but at this time I made a new site to show a little blinking dot in the top right corner by using html and css animations. While not streaming/ recording OBS is using ~250 MB memory on my machine. My expectation is that it should increase a bit but not more than a few MB.

Current Behavior

When using the site with the css animation in a scene the memory consumption raises incrementally to several hundred megabytes. Sometimes (after switching scenes back and forth) it goes up to several gigabytes until the OS warning is shown - after the warning MacOS kills the entire OBS instance to protect the system. Also CPU consumption is going through the roof. The interesting thing is that memory usage of "obs-browser-page" looks quite normal but memory of the main OBS process is taking all the memory.

Steps to Reproduce

Use the html that is attached below as an overlay in a scene and watch MacOS's activity monitor.

Additional information

HTML to reproduce the behavior:

<!doctype html>
<html lang="en">
<head>
    <meta charset="utf-8">

    <style>
        .blink {
            animation: blinker 1.2s cubic-bezier(.5, 0, 1, 1) infinite alternate;            
        }

        @keyframes blinker {
            100% {
                opacity: 0;
            }
        }

        .dot {
            height: 18px;
            width: 18px;
            background-color: #ed553b;
            border-radius: 50%;
            display: inline-block;
            vertical-align: middle;            
        }

        .top-right {
            line-height: 40px;
            position: absolute;
            right: 20px;
            top: 10px;
        }

        .font {
            font-family: Arial, Helvetica, sans-serif;
            font-size: 20px;
            font-weight: bold;
            vertical-align: middle;
            padding-left: 4px;
        }
    </style>

</head>

<body>
    <div class="top-right">
        <span class="dot blink"></span> <span class="font">LIVE</span>
    </div>
</body>

</html>

njutn95 commented 4 years ago

Similar issue on my end as well, except it's a windows machine and it's not hurting obs process but obs-browser-page. I've opened #223 to keep things separate in case they're different problems.

bStyler commented 4 years ago

This issue seems to still exist in OBS Studio version 25.0.8 on PC / Windows

bardiir commented 3 years ago

I can confirm this on OBS 26.1 on Big Sur M1 - If there are CSS Animations present on the page code in any form or function the OBS browser does start leaking memory as long as it is visible until the memory depletion triggers and kills OBS.

It's allocating around 10MB/sec per open browser instance, so quite a significant memory leak. I had OBS reach 64GB of memory usage previously.

If the page does not contain any CSS animation code - it will not leak. Even on BigSur which currently is plagued by a lot of other issues anyway.

If there is any experiment/testing you might want checked, let me know and I'll gladly help to trace this :)

njutn95 commented 3 years ago

@bardiir Out of curiousity, how long were you running OBS when you reached 64GB memory usage? Is it exponential or linear grow? And also, which process is it actually - obs or obs-browser-page? Might be useful information in case this gains any attention :slightly_smiling_face:

bardiir commented 3 years ago

@njutn95 It was running quite a while - it was open in the background and started swapping there - system was surprisingly responsive until it ran out of memory. It's linear grow, it grows faster the more browser instances you got visible. But the growth per browser seems to be static and very linear over time (I would guess there are rendered frames or something like that leaking into the memory).

The memory is leaking into the OBS process - not the browser page itself. After running for a few minutes (OBS base with no browsers open uses around 700-800MB memory for me):

WizardCM commented 3 years ago

Hi there, is this still an issue in OBS 26.1.2? We overhauled how the browser backend is run and updated the browser library. Let us know!

bardiir commented 3 years ago

@WizardCM the memory leak I experienced is fixed in 26.1.2

WizardCM commented 3 years ago

@bardiir As a final test with 26.1.2, could you go to Settings -> Advanced and at the bottom disable Hardware Acceleration, and see if the issue comes back? If the issue returns, it'll confirm your theory about it happening during the non-accellerated render function.

Once you've verified, you can turn Hardware Acceleration back on.

bStyler commented 3 years ago

@WizardCM I'd love to test the same on Windows, may I know what's the ETA for 26.1.2 on Windows?

bardiir commented 3 years ago

@WizardCM I can confirm - disabling hardware acceleration does enable a memory leak, OBS is slowly creeping up again, I think it's slower than before but that is just a gut feeling no measurement. It's definitely leaking without the hardware acceleration. OBS usually sits around 400-500MB for me, now it is already at 1.5GB after around an hour.

WizardCM commented 3 years ago

@WizardCM I'd love to test the same on Windows, may I know what's the ETA for 26.1.2 on Windows?

Windows has had hardware acceleration on by default for at least a year and a half now. If the issue exists on Windows, disabling hardware acceleration the same way n Settings -> Advanced would be a way to reproduce it.

The browser update in 26.1.2 is purely a change on the macOS version, as it previously didn't support hardware acceleration. To update the browser dependency on Windows, it requires more work. It's on the to do list but nobody with the required skillset has had time to dive into it.

@WizardCM I can confirm - disabling hardware acceleration does enable a memory leak,

OK, good to know. That definitely shortens the list of potential causes.

In terms of next steps, I'll coordinate internally (and verify myself) as to which functions run when hardware acceleration is on vs when it's off. As the memory leak occurs in the OBS process and not the CEF process, this means it could be a larger issue and not limited to the browser source.

I'll post an update as soon as I know more.

bStyler commented 3 years ago

Windows has had hardware acceleration on by default for at least a year and a half now. If the issue exists on Windows, disabling hardware acceleration the same way n Settings -> Advanced would be a way to reproduce it.

The browser update in 26.1.2 is purely a change on the macOS version, as it previously didn't support hardware acceleration. To update the browser dependency on Windows, it requires more work. It's on the to do list but nobody with the required skillset has had time to dive into it.

Thank you for your efforts @WizardCM -- anxious to hear your updates on Windows.

PatTheMav commented 3 years ago

I just finished a profiling run of our current master branch with CEF 4183 and disabled hardware acceleration, logging memory allocation activity over more than an hour and was not able to observe increased memory usage.

Memory usage breakdown

* ~35% by IOSurfaceClientCreate (which might warrant additional research as I'm not aware of IOSurfaces being used outside of Syphon and CEF _with_ hardware acceleration * ~28% by CEF itself * ~18% by OBS' graphics thread implementation * ~14% by - what looks like - CEF's rendering helper So about 42% of memory usage is down to CEF, which should come as no surprise - Chromium is not exactly known for being easy on memory.

Persistent usage was more or less stable, whereas total virtual memory usage was ballooning by the second, but that's to be expected with web-based animations (and not an issue as the memory is freed and reclaimed automatically anyway).

I found some leaks but none where related to the browser source (and total impact was a few bytes).

Total memory usage after about 2 hours of just running the CSS animation: ~239MB.

So this issue is either not present in recent code anymore or there are other factors involved. @bardiir as you tested with 26.1.2, can you give precise "steps to reproduce"?

RytoEX commented 2 years ago

Per @PatTheMav 's comment above, we are unable to reproduce this and do not believe this issue to be present in obs-browser anymore, so we will be closing this Issue. If someone can provide steps-to-reproduce in the current stable or beta release of OBS Studio (at time of writing, stable is 27.1.3 and beta is 27.2.0), then we can reopen this and investigate further.

obsproject / obs-browser