https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126661
Bug ID: 126661
Summary: Faulty mutex in LTO compilation
Product: gcc
Version: 16.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wedge009 at wedge009 dot net
Target Milestone: ---
Created attachment 65245
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=65245&action=edit
Detailed report on the background and reproduction
I encountered this in GCC 13.3.0 on Ubuntu 24.04 but it appears the problem is
still present in GCC 16.1.1 from Arch.
The high-level context is that I was trying resolve a hang-on-new-track when
dynamic recompilation is enabled in the Audacious USF plug-in:
https://github.com/saschaklick/audacious-usf-plugin
When compiling Audacious (https://github.com/audacious-media-player/audacious)
4.6.1 _without_ LTO enabled, the issue does not manifest. With LLM assistance,
I traced the issue to a faulty mutex in the LTO-compiled Audacious, resulting
in a race condition on the end of a track. This can happen with any track, it's
just practically guaranteed to be exposed with the USF plug-in with dynamic
recompilation enabled.
I did search for other issues before reporting this one. The closest I could
find is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89547, and doesn't appear
related.
This is a practical, real-world problem that just happens to be analysed with
LLM assistance, I don't think it should be immediately dismissed as slop.
The full report is attached, along with an attempt at a minimal reproduction
case. It was a struggle to trigger LTO, so it's not a very small example, but
hopefully should be able to demonstrate the problem.
Package maintainers seem to insist on LTO, so the only practical means to avoid
this is to compile Audacious myself, or go without dynamic recompilation in the
plug-in.
