https://bugs.winehq.org/show_bug.cgi?id=50779
Bug ID: 50779 Summary: winegstreamer is leaking something Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winegstreamer Assignee: wine-bugs@winehq.org Reporter: galtgendo@o2.pl Distribution: ---
A rough summary of the problem and things said on chat.
Awhile ago a thing, that had been working reasonably well for quite a few years (with exception of a short period when code changes made the music stop looping), has began to randomly freeze to a point that you'd needed to wait for wm's kill dialog to appear after trying to close the main window.
The messages in the console were saying something about being unable to create thread due to running out of resources. The freezes usually took a quite a bit of time, but didn't seem to have any obvious trigger.
As far as free memory went, the situation was still fine at such time, but zf suggested it was an address space problem. Forcibly setting the executable to LARGE_ADDRESS_AWARE gave it more running time, but eventually seem to have resulted in a whole system freeze.
As such, I was once put into realm of wild ass guesses and even crazier attempted solutions.
So, I took a gamble and removed gst_object_ref calls from mpeg_audio_parser_init_gst and wave_parser_init_gst first.
This didn't seem to have any effect.
Then I've removed the last gst_object_ref - one in pad_added_cb.
This resulted in a flood of 'gst_object_unref: assertion '((GObject *) object)->ref_count > 0' failed', yet after running for quite awhile the freeze is yet to happen.
Now, this is far from conclusive, as we're trying to literally prove a negative here, but it would align well with the fact that free memory used at the time of freeze isn't all that significant.
I'm not sure when the problem began. I think it was somewhere between 5.22 and 6.1 (though only the upper bound being definite).