Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER Bug Reports

Reply
 
Thread Tools Display Modes
Old 07-05-2024, 04:05 PM   #1
cfillion
Human being with feelings
 
cfillion's Avatar
 
Join Date: May 2015
Location: Québec, Canada
Posts: 5,108
Default SIGKILLs on Linux with PipeWire

REAPER is unavoidably killed via SIGKILL if the main thread is busy for 200ms or longer in the default configuration of many Linux distributions.

This happens because REAPER calls jack_client_open (EDIT: jack_activate) from the main thread and PipeWire's libjack implementation enables realtime scheduling on the calling thread via the RT module.

If the system is configured to allow the user to set a thread's realtime priority, by default PipeWire sets RLIMIT_RTTIME to RLIM_INFINITY (user-configurable via rt.time.{soft,hard}). However, if it's not allowed, PipeWire fallbacks to using the RTKit daemon instead. RTKit sets RLIMIT_RTTIME to 200ms by default (user-configurable via --rttime-usec-max)!

The latter scenario is what happens out-of-the-box on many common distributions with RTKit being often pre-installed.

(EDIT: The problem is specific to the RTKit path combined with jack_set_thread_creator resulting in the thread that calls jack_active becoming realtime.)



This prints "initialized using RTKit" instead of "initialized using regular realtime scheduling":

Code:
PIPEWIRE_DEBUG=mod.rt:D reaper
The RTKit fallback may be disabled via the configuration file for PipeWire's RT module or temporarily via an environment variable:

Code:
DISABLE_RTKIT=1 reaper
To temporarily disable realtime permissions and have PipeWire do the problematic RTKit fallback:

Code:
prlimit --rtprio=0 reaper
This issue is the cause behind many bug reports:
The main thread should not have realtime scheduling!

Last edited by cfillion; 07-05-2024 at 10:55 PM.
cfillion is offline   Reply With Quote
Old 07-05-2024, 05:57 PM   #2
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,868
Default

thanks for diagnosing this!

the behavior of pipewire seems wrong to me! shouldn't it be setting the jack processing thread to realtime, rather than the main thread?

the workaround would be to create a thread that calls jack_client_open() and has no other purpose? or any other suggestions? I guess I need to install a more recent distro to reproduce this heh.

Last edited by Justin; 07-05-2024 at 06:14 PM.
Justin is offline   Reply With Quote
Old 07-05-2024, 07:30 PM   #3
cfillion
Human being with feelings
 
cfillion's Avatar
 
Join Date: May 2015
Location: Québec, Canada
Posts: 5,108
Default

Quote:
Originally Posted by Justin View Post
the behavior of pipewire seems wrong to me! shouldn't it be setting the jack processing thread to realtime, rather than the main thread?

the workaround would be to create a thread that calls jack_client_open() and has no other purpose? or any other suggestions? I guess I need to install a more recent distro to reproduce this heh.
I think it's wrong too. Debugged it further and jack_client_open was incorrect: it's jack_activate that leads to the main thread's priority getting changed in RTKit fallback mode.

PipeWire gets the correct thread (reaper/libjack), it's not in their impl->threads_list, ignores it and tells RTKit to change the priority of gettid() instead.

Code:
jack_client_open
  impl_acquire_rt(pt=data-loop.0)
    if ((thr = find_thread_by_pt(impl, pt)) != NULL)
      params.pid = thr->pid // data-loop.0 (pipewire's)
    do_make_realtime(params)

jack_activate
  impl_acquire_rt(pt=reaper/libjack)
    else
      params.pid = _gettid() // thread that called jack_activate
    do_make_realtime(params)
https://gitlab.freedesktop.org/pipew....c?page=2#L819

EDIT: Checked with Jack's simple_client.c example and mpv: it gets different but samely-named data-loop.0 threads in both client_open and activate calls + no bug, they're in the list both times.

EDIT2: Threads created using jack_set_thread_creator trigger the bug by not being added to PipeWire's RT module's thread list. https://gitlab.freedesktop.org/pipew...e-jack.c#L2837 Jack's docs say "No normal application/client should consider calling this" though.

Code:
#include <jack/jack.h>
#include <jack/thread.h>

int main()
{
  jack_client_t *client = jack_client_open("bug", JackNullOption, NULL, NULL);
  jack_set_thread_creator(pthread_create);
  jack_activate(client);
  while(1); // SIGKILL
}
EDIT3: I reported it to PipeWire: https://gitlab.freedesktop.org/pipew.../-/issues/4099

Last edited by cfillion; 07-06-2024 at 10:56 AM.
cfillion is offline   Reply With Quote
Old 07-05-2024, 07:56 PM   #4
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,868
Default

I've got it reproduced, I'll debug and play with it too. Thanks again!
Justin is offline   Reply With Quote
Old 07-06-2024, 04:55 AM   #5
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,868
Default

Quote:
Originally Posted by cfillion View Post
EDIT2: Threads created using jack_set_thread_creator trigger the bug by not being added to PipeWire's RT module's thread list. https://gitlab.freedesktop.org/pipew...e-jack.c#L2837 Jack's docs say "No normal application/client should consider calling this" though.
Wow amazing thank you. Removing use of set_thread_creator fixes. No real downside other than the loss of the thread name.
Justin is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 11:09 PM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.