OBS Studio memory leak

OBS Studio memory leak

[Robby Zambito]

Hi Guixers,

For some reason when I use the obs package I quickly leak memory until
my system runs out completely, and I have to reboot to resolve it. I had
obs-wlrobs, but removing it made no difference. I am able to use the
most recent release through Flatpak / Flathub, but ideally I could use
the Guix package instead.

Is anyone else having this issue? Or could anyone provide insight into
how I could resolve this on my system?

Thanks,
Robby

Re: OBS Studio memory leak

[Robby Zambito]

Ott Joon <ott.joon@tutanota.com> writes:

> Hey there
>
> I have the exact same issue and I think this has to do with
> gstreamer. Some other programs are also affected by this bug. What
> seems to happen is the gst-plugin-scanner starts searching for plugins
> and just doesn't finish and leaks memory a ton. My 128GB of RAM will
> be full in seconds if I launch anything that uses gstreamer. Even
> virt-manager if you have gst-plugin-* packages installed as then the
> gst-plugin-scanner is awakened. I had to remove them or unset
> GST_PLUGIN_SYSTEM_PATH. Unfortunately OBS seems to have this feature
> built in, so it's not something you can remove. This is all I know at
> the moment.
>
> Ott

Hi Ott,

Thanks for the lead. I tried pinning gstreamer and gst-plugins-base to
older versions available in Guix, and removing gst-plugins-base from
being an input to OBS (though I'm not positive this removes it from all
recursive inputs), but I'm still having the issue :(

Here is what I have so far:

(let ((parent (specification->package "obs")))
  (package
   (inherit parent)
   (inputs (modify-inputs (package-inputs parent)
                          (replace "gstreamer"
                                   ((options->transformation '((with-version . "gstreamer=1.20.3")))
                                    (specification->package "gstreamer")))
                          (replace "gst-plugins-base"
                                   ((options->transformation '((with-version . "gst-plugins-base=1.20.3")))
                                    (specification->package "gst-plugins-base")))))))

Also tried with (remove "gst-plugins-base") instead of the replace.

Robby

Re: OBS Studio memory leak

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 2321 bytes --]

Robby Zambito <contact@robbyzambito.me> skribis:

> Ott Joon <ott.joon@tutanota.com> writes:
>
>> Hey there
>>
>> I have the exact same issue and I think this has to do with
>> gstreamer. Some other programs are also affected by this bug. What
>> seems to happen is the gst-plugin-scanner starts searching for plugins
>> and just doesn't finish and leaks memory a ton. My 128GB of RAM will
>> be full in seconds if I launch anything that uses gstreamer. Even
>> virt-manager if you have gst-plugin-* packages installed as then the
>> gst-plugin-scanner is awakened. I had to remove them or unset
>> GST_PLUGIN_SYSTEM_PATH. Unfortunately OBS seems to have this feature
>> built in, so it's not something you can remove. This is all I know at
>> the moment.
>>
>> Ott
>
> Hi Ott,
>
> Thanks for the lead. I tried pinning gstreamer and gst-plugins-base to
> older versions available in Guix, and removing gst-plugins-base from
> being an input to OBS (though I'm not positive this removes it from all
> recursive inputs), but I'm still having the issue :(
>
> Here is what I have so far:
>
> (let ((parent (specification->package "obs")))
>   (package
>    (inherit parent)
>    (inputs (modify-inputs (package-inputs parent)
>                           (replace "gstreamer"
>                                    ((options->transformation '((with-version . "gstreamer=1.20.3")))
>                                     (specification->package "gstreamer")))
>                           (replace "gst-plugins-base"
>                                    ((options->transformation '((with-version . "gst-plugins-base=1.20.3")))
>                                     (specification->package "gst-plugins-base")))))))
>
> Also tried with (remove "gst-plugins-base") instead of the replace.
>
> Robby

Hi,

I don't know if its related, but I have a big memory leak issue with
vlc. When trying to play a video with it, if the video output module it
set to gl or vdpau_display, it consumes all the RAM of the machine in
a few seconds (and I have to kill it fast to prevent the machine from
hanging). However if I force the video output module to xcb_xv, it works
fine.

Do you have the same issue with vlc? If yes, it may indicate a bug
with video acceleration (VA-API/VDPAU or mesa).

PS: My machine's GPU is an AMD Radeon RX 6800 XT.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: OBS Studio memory leak

[Ott Joon via]

Hey

Tried the same thing in VLC and it freezes on GPU accel and starts leaking memory while also becoming hard to kill.
Maybe this also explains why some mpv GPU accel settings don't work also in the exact same way.
I have an AMD RX 6900 XT on this machine.

I could probably try this on the laptop with Intel and the unmentionable video devices.

PS: Might need to switch to a traditional email service or get my own up and running. Tutanota is just no good for this mailing list stuff.
Ott



13. juuni 2023 10:50 poolt glv@posteo.net:

> Robby Zambito <contact@robbyzambito.me> skribis:
>
>> Ott Joon <ott.joon@tutanota.com> writes:
>>
>>> Hey there
>>>
>>> I have the exact same issue and I think this has to do with
>>> gstreamer. Some other programs are also affected by this bug. What
>>> seems to happen is the gst-plugin-scanner starts searching for plugins
>>> and just doesn't finish and leaks memory a ton. My 128GB of RAM will
>>> be full in seconds if I launch anything that uses gstreamer. Even
>>> virt-manager if you have gst-plugin-* packages installed as then the
>>> gst-plugin-scanner is awakened. I had to remove them or unset
>>> GST_PLUGIN_SYSTEM_PATH. Unfortunately OBS seems to have this feature
>>> built in, so it's not something you can remove. This is all I know at
>>> the moment.
>>>
>>> Ott
>>>
>>
>> Hi Ott,
>>
>> Thanks for the lead. I tried pinning gstreamer and gst-plugins-base to
>> older versions available in Guix, and removing gst-plugins-base from
>> being an input to OBS (though I'm not positive this removes it from all
>> recursive inputs), but I'm still having the issue :(
>>
>> Here is what I have so far:
>>
>> (let ((parent (specification->package "obs")))
>> (package
>> (inherit parent)
>> (inputs (modify-inputs (package-inputs parent)
>> (replace "gstreamer"
>> ((options->transformation '((with-version . "gstreamer=1.20.3")))
>> (specification->package "gstreamer")))
>> (replace "gst-plugins-base"
>> ((options->transformation '((with-version . "gst-plugins-base=1.20.3")))
>> (specification->package "gst-plugins-base")))))))
>>
>> Also tried with (remove "gst-plugins-base") instead of the replace.
>>
>> Robby
>>
>
> Hi,
>
> I don't know if its related, but I have a big memory leak issue with
> vlc. When trying to play a video with it, if the video output module it
> set to gl or vdpau_display, it consumes all the RAM of the machine in
> a few seconds (and I have to kill it fast to prevent the machine from
> hanging). However if I force the video output module to xcb_xv, it works
> fine.
>
> Do you have the same issue with vlc? If yes, it may indicate a bug
> with video acceleration (VA-API/VDPAU or mesa).
>
> PS: My machine's GPU is an AMD Radeon RX 6800 XT.
>

Re: OBS Studio memory leak

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 773 bytes --]

Ott Joon <ott.joon@tutanota.com> skribis:

> Hey
>
> Tried the same thing in VLC and it freezes on GPU accel and starts leaking memory while also becoming hard to kill.
> Maybe this also explains why some mpv GPU accel settings don't work also in the exact same way.
> I have an AMD RX 6900 XT on this machine.
>
> I could probably try this on the laptop with Intel and the unmentionable video devices.
>
> PS: Might need to switch to a traditional email service or get my own up and running. Tutanota is just no good for this mailing list stuff.
> Ott

It looks like an issue with the shader cache of mesa.
After clearing it, I don't see the memory leak anymore.

Could you try doing a "rm -r $HOME/.cache/mesa_shader_cache/*" and see
if it also solves the issue for you?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: OBS Studio memory leak

[Robby Zambito]

Hey,

>>
>> Hi,
>>
>> I don't know if its related, but I have a big memory leak issue with
>> vlc. When trying to play a video with it, if the video output module it
>> set to gl or vdpau_display, it consumes all the RAM of the machine in
>> a few seconds (and I have to kill it fast to prevent the machine from
>> hanging). However if I force the video output module to xcb_xv, it works
>> fine.
>>
>> Do you have the same issue with vlc? If yes, it may indicate a bug
>> with video acceleration (VA-API/VDPAU or mesa).
>>
>> PS: My machine's GPU is an AMD Radeon RX 6800 XT.
>>
> Hey
>
> Tried the same thing in VLC and it freezes on GPU accel and starts leaking memory while also becoming hard to kill.
> Maybe this also explains why some mpv GPU accel settings don't work also in the exact same way.
> I have an AMD RX 6900 XT on this machine.
>
> I could probably try this on the laptop with Intel and the unmentionable video devices.

I think we may be on to something here. I have an AMD RX 6650 XT, and
VLC does also start to leak for me.

Guillaume, when you say you forced the video output module to gl,
vdpau_display, or xcb_xv, how did you set that?

Robby

Re: OBS Studio memory leak

[Robby Zambito]

Guillaume Le Vaillant <glv@posteo.net> writes:

> It looks like an issue with the shader cache of mesa.
> After clearing it, I don't see the memory leak anymore.
>
> Could you try doing a "rm -r $HOME/.cache/mesa_shader_cache/*" and see
> if it also solves the issue for you?

This worked for me! Thank you!

Re: OBS Studio memory leak

[Ott Joon via]

Awesome! Worked for me, too! 
Also fixed the issue with the gst-plugin-helper memory leak. 
So it must have all been to do something with the mesa shader cache. 
VLC seems to struggle playing an HEVC encoded 2K video however while mpv does it just fine. 
virt-manager is running smoothly again.


13. juuni 2023 16:04 poolt contact@robbyzambito.me:

>
> Guillaume Le Vaillant <glv@posteo.net> writes:
>
>> It looks like an issue with the shader cache of mesa.
>> After clearing it, I don't see the memory leak anymore.
>>
>> Could you try doing a "rm -r $HOME/.cache/mesa_shader_cache/*" and see
>> if it also solves the issue for you?
>>
>
> This worked for me! Thank you!
>

stateful caches (was Re: OBS Studio memory leak)

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 2152 bytes --]

Hi Guillaume Le Vaillant and Guix Devels,

sorry for cross-posting but IMHO the workaround you found [1] for the memory
leak affecting a number of media processing applications is of interest
for many people potentially not subscribed to help-guix

AFAIK this was not filed as a Guix bug

Guillaume Le Vaillant <glv@posteo.net> writes:

> Ott Joon <ott.joon@tutanota.com> skribis:
>
>> Hey
>>
>> Tried the same thing in VLC and it freezes on GPU accel and starts
>> leaking memory while also becoming hard to kill.  Maybe this also
>> explains why some mpv GPU accel settings don't work also in the exact
>> same way.  I have an AMD RX 6900 XT on this machine.

[...]

> It looks like an issue with the shader cache of mesa.
> After clearing it, I don't see the memory leak anymore.

good catch: please can you tell us how you managed to spot that problem?
Did you straced it or did yoy find a related mesa bug report?

do you think this bug (is it a bug, right?) needs to be reported
upstream?

I'm asking this because I "feel" we (I mean Guix users) could do
something to help upstream removing this "status mismanagement"

> Could you try doing a "rm -r $HOME/.cache/mesa_shader_cache/*" and see
> if it also solves the issue for you?

AFAIU this is "just" another instance of the "mismanaged state" error
class, like the one(s) discussed back in Oct 2019 [2] and probably
periodically recurring since the beginning of some (many) the upstream
applications lifecycle.

Back then, Efraim Flashner was using this snippet [2] in his OS-config:

--8<---------------cut here---------------start------------->8---

;; This directory shouldn't exist
(file-system
  (device "none")
  (mount-point "/var/cache/fontconfig")
  (type "tmpfs")
  (flags '(read-only))
  (check? #f))

--8<---------------cut here---------------end--------------->8---

It seems that a similar snippet could also be useful for all
"~/.cache/*" :-O

Happy hacking! Gio'



[1] message id:87y1kozvny.fsf@robbyzambito.me

[2] message id:20191018073501.GB1224@E5400

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: stateful caches (was Re: OBS Studio memory leak)

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 8608 bytes --]

Giovanni Biscuolo <g@xelera.eu> skribis:

> Hi Guillaume Le Vaillant and Guix Devels,
>
> sorry for cross-posting but IMHO the workaround you found [1] for the memory
> leak affecting a number of media processing applications is of interest
> for many people potentially not subscribed to help-guix
>
> AFAIK this was not filed as a Guix bug
>
> Guillaume Le Vaillant <glv@posteo.net> writes:
>
>> Ott Joon <ott.joon@tutanota.com> skribis:
>>
>>> Hey
>>>
>>> Tried the same thing in VLC and it freezes on GPU accel and starts
>>> leaking memory while also becoming hard to kill.  Maybe this also
>>> explains why some mpv GPU accel settings don't work also in the exact
>>> same way.  I have an AMD RX 6900 XT on this machine.
>
> [...]
>
>> It looks like an issue with the shader cache of mesa.
>> After clearing it, I don't see the memory leak anymore.
>
> good catch: please can you tell us how you managed to spot that problem?
> Did you straced it or did yoy find a related mesa bug report?

I used gdb on versions of mesa and vlc with debug symbols:

--8<---------------cut here---------------start------------->8---
guix build --with-debug-info=mesa --with-debug-info=vlc vlc

gdb /gnu/store/...-vlc-3.0.18/bin/.vlc-real
(gdb) run some-video.mkv
--8<---------------cut here---------------end--------------->8---

Then I sent a SIGSTOP signal to the vlc process, and in gdb I looked at
the backtrace of all the threads of vlc. There was only one thread
allocating things:

--8<---------------cut here---------------start------------->8---
Thread 34

#0  0x00007ffff7e127c7 in sysmalloc () from /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libc.so.6
#1  0x00007ffff7e13cfb in _int_malloc () from /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libc.so.6
#2  0x00007ffff7e145b5 in malloc () from /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libc.so.6
#3  0x00007fff810822b1 in ralloc_size () from /gnu/store/5gwcwadzfm48j9cm2b7imw9qcywjyzdz-mesa-23.0.3/lib/dri/radeonsi_drv_video.so
#4  0x00007fff81710b2c in read_constant () from /gnu/store/5gwcwadzfm48j9cm2b7imw9qcywjyzdz-mesa-23.0.3/lib/dri/radeonsi_drv_video.so
#5  0x00007fff817110f2 in read_var_list () from /gnu/store/5gwcwadzfm48j9cm2b7imw9qcywjyzdz-mesa-23.0.3/lib/dri/radeonsi_drv_video.so
#6  0x00007fff81711865 in nir_deserialize () from /gnu/store/5gwcwadzfm48j9cm2b7imw9qcywjyzdz-mesa-23.0.3/lib/dri/radeonsi_drv_video.so
#7  0x00007fff8162c874 in tgsi_to_nir () from /gnu/store/5gwcwadzfm48j9cm2b7imw9qcywjyzdz-mesa-23.0.3/lib/dri/radeonsi_drv_video.so
#8  0x00007fff8146cba1 in si_create_compute_state () from /gnu/store/5gwcwadzfm48j9cm2b7imw9qcywjyzdz-mesa-23.0.3/lib/dri/radeonsi_drv_video.so
#9  0x00007fff8118e1ba in vl_compositor_cs_create_shader () from /gnu/store/5gwcwadzfm48j9cm2b7imw9qcywjyzdz-mesa-23.0.3/lib/dri/radeonsi_drv_video.so
#10 0x00007fff8118e800 in vl_compositor_cs_init_shaders () from /gnu/store/5gwcwadzfm48j9cm2b7imw9qcywjyzdz-mesa-23.0.3/lib/dri/radeonsi_drv_video.so
#11 0x00007fff811882af in vl_compositor_init () from /gnu/store/5gwcwadzfm48j9cm2b7imw9qcywjyzdz-mesa-23.0.3/lib/dri/radeonsi_drv_video.so
#12 0x00007fff810692a8 in __vaDriverInit_1_18 () from /gnu/store/5gwcwadzfm48j9cm2b7imw9qcywjyzdz-mesa-23.0.3/lib/dri/radeonsi_drv_video.so
#13 0x00007fffacfacdb8 in ?? () from /gnu/store/xf6x5qmp75vdnvph041zjdz5779l5q7p-libva-2.18.0/lib/libva.so.2
#14 0x00007fffacfadf26 in vaInitialize () from /gnu/store/xf6x5qmp75vdnvph041zjdz5779l5q7p-libva-2.18.0/lib/libva.so.2
#15 0x00007fff942a7657 in vlc_vaapi_InitializeInstance (o=0x7fff7c001ee0, dpy=0x7fff7c21d6c0, native=native@entry=0x7fff7c2137d0, 
    native_destroy_cb=native_destroy_cb@entry=0x7fff942a64a0 <x11_native_destroy_cb>) at hw/vaapi/vlc_vaapi.c:95
#16 0x00007fff942a7198 in x11_init_vaapi_instance (priv=0x7fff7c2135c0, tc=0x7fff7c212e00) at video_output/opengl/converter_vaapi.c:438
#17 Open (obj=0x7fff7c212e00) at video_output/opengl/converter_vaapi.c:521
#18 0x00007ffff7c9b3f8 in module_load (obj=obj@entry=0x7fff7c212e00, m=m@entry=0x4bb570, init=init@entry=0x7ffff7c9b320 <generic_start>, args=args@entry=0x7fff9478a688)
    at modules/modules.c:183
#19 0x00007ffff7c9b9a4 in vlc_module_load (obj=obj@entry=0x7fff7c212e00, capability=capability@entry=0x7fff94685f34 "glconv", name=0x7ffff7d38487 "", name@entry=0x7fff94685f33 "$glconv", 
    strict=strict@entry=true, probe=probe@entry=0x7ffff7c9b320 <generic_start>) at modules/modules.c:280
#20 0x00007ffff7c9bfa4 in module_need (obj=obj@entry=0x7fff7c212e00, cap=cap@entry=0x7fff94685f34 "glconv", name=name@entry=0x7fff94685f33 "$glconv", strict=strict@entry=true)
    at modules/modules.c:372
#21 0x00007fff9467b46b in opengl_init_program (vgl=vgl@entry=0x7fff7c210690, prgm=prgm@entry=0x7fff7c210998, 
    glexts=glexts@entry=0x7fff7c210d80 "GL_ARB_multisample GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_copy_texture GL_EXT_subtexture GL_EXT_texture_object GL_EXT_vertex_array GL_EXT_compiled_"..., fmt=fmt@entry=0x7fff7c0014a8, subpics=subpics@entry=false, b_dump_shaders=b_dump_shaders@entry=false)
    at video_output/opengl/vout_helper.c:671
#22 0x00007fff9467c558 in vout_display_opengl_New (fmt=fmt@entry=0x7fff7c0014a8, subpicture_chromas=subpicture_chromas@entry=0x7fff9478a8c0, gl=0x7fff7c001ee0, viewpoint=0x7fff7c00115c)
    at video_output/opengl/vout_helper.c:902
#23 0x00007fff94684166 in Open (obj=0x7fff7c0013c0) at video_output/opengl/display.c:145
#24 0x00007ffff7c9b3f8 in module_load (obj=obj@entry=0x7fff7c0013c0, m=m@entry=0x4bb070, init=init@entry=0x7ffff7c9b320 <generic_start>, args=args@entry=0x7fff9478a9c8)
    at modules/modules.c:183
#25 0x00007ffff7c9b9a4 in vlc_module_load (obj=obj@entry=0x7fff7c0013c0, capability=capability@entry=0x7ffff7d379ca "vout display", name=0x7fff7c001073 "", 
    name@entry=0x7ffff7d48cd9 "$vout", strict=<optimized out>, probe=probe@entry=0x7ffff7c9b320 <generic_start>) at modules/modules.c:280
#26 0x00007ffff7c9bfa4 in module_need (obj=obj@entry=0x7fff7c0013c0, cap=cap@entry=0x7ffff7d379ca "vout display", name=name@entry=0x7ffff7d48cd9 "$vout", strict=<optimized out>)
    at modules/modules.c:372
#27 0x00007ffff7ceb465 in vout_display_New (owner=<synthetic pointer>, cfg=0x7fff7c001130, fmt=0x7fff88065b20, load_module=255, module=0x7ffff7d48cd9 "$vout", obj=0x7fff88065ae0)
    at video_output/display.c:109
#28 DisplayNew (vout=vout@entry=0x7fff88065ae0, source=0x7fff88065b20, state=state@entry=0x7fff9478ac20, module=module@entry=0x7ffff7d48cd9 "$vout", is_splitter=is_splitter@entry=false, 
    double_click_timeout=double_click_timeout@entry=300000, hide_timeout=1000000, owner_ptr=0x0) at video_output/display.c:1198
#29 0x00007ffff7cecf33 in vout_NewDisplay (vout=vout@entry=0x7fff88065ae0, source=<optimized out>, state=state@entry=0x7fff9478ac20, module=module@entry=0x7ffff7d48cd9 "$vout", 
    double_click_timeout=double_click_timeout@entry=300000, hide_timeout=<optimized out>) at video_output/display.c:1255
#30 0x00007ffff7cfd7d8 in vout_OpenWrapper (vout=vout@entry=0x7fff88065ae0, splitter_name=0x0, state=state@entry=0x7fff9478ac20) at video_output/vout_wrapper.c:67
#31 0x00007ffff7ceffd1 in ThreadStart (vout=vout@entry=0x7fff88065ae0, state=0x7fff9478ac20, state@entry=0x0) at video_output/video_output.c:1531
#32 0x00007ffff7cf1ccc in ThreadControl (cmd=..., vout=<optimized out>) at video_output/video_output.c:1686
#33 Thread (object=0x7fff88065ae0) at video_output/video_output.c:1807
#34 0x00007ffff7e053aa in start_thread () from /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libc.so.6
#35 0x00007ffff7e85f7c in clone3 () from /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libc.so.6
--8<---------------cut here---------------end--------------->8---

Then I looked at the code of mesa to see what the
'si_create_compute_state', 'tgsi_to_nir' etc were trying to do, and they
were trying to load things from the shader cache. Which is why I tried
deleting the cache, and it worked.


> do you think this bug (is it a bug, right?) needs to be reported
> upstream?

I guess it would be better if the code reading the shader cache was more
robust when reading possibly incompatible or corrupted data. However
I have not tried more recent versions of mesa, maybe they are better at
it...

And it seems that Maxim has already reported the issue upstream,
see <https://issues.guix.gnu.org/63197> and
<https://gitlab.freedesktop.org/mesa/mesa/-/issues/8937>.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: stateful caches (was Re: OBS Studio memory leak)

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]

Hi!

Guillaume Le Vaillant <glv@posteo.net> writes:

[...]

> I used gdb on versions of mesa and vlc with debug symbols:
>
> --8<---------------cut here---------------start------------->8---
> guix build --with-debug-info=mesa --with-debug-info=vlc vlc
>
> gdb /gnu/store/...-vlc-3.0.18/bin/.vlc-real
> (gdb) run some-video.mkv
> --8<---------------cut here---------------end--------------->8---
>
> Then I sent a SIGSTOP signal to the vlc process, and in gdb I looked at
> the backtrace of all the threads of vlc.

got it, thanks!

[...]

>> do you think this bug (is it a bug, right?) needs to be reported
>> upstream?
>
> I guess it would be better if the code reading the shader cache was more
> robust when reading possibly incompatible or corrupted data. However
> I have not tried more recent versions of mesa, maybe they are better at
> it...
>
> And it seems that Maxim has already reported the issue upstream,
> see <https://issues.guix.gnu.org/63197>

oh I missed it: I'll make my comments in that issue then, thanks!

> and <https://gitlab.freedesktop.org/mesa/mesa/-/issues/8937>

I see

Happy hacking. Gio'


-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: OBS Studio memory leak

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 530 bytes --]


Robby Zambito <contact@robbyzambito.me> writes:

> Guillaume Le Vaillant <glv@posteo.net> writes:
>
>> It looks like an issue with the shader cache of mesa.
>> After clearing it, I don't see the memory leak anymore.
>>
>> Could you try doing a "rm -r $HOME/.cache/mesa_shader_cache/*" and see
>> if it also solves the issue for you?
>
> This worked for me! Thank you!

With this, obs runs again for me! Thank you!

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]