Jack data race #902
Replies: 8 comments 4 replies
-
I run jack with -fsanitize=thread quite often and can't remember seeing
something like this.
Which version of jack do you use?
Any code you can show?
…On Thu, Nov 17, 2022 at 7:04 PM Andzelmas ***@***.***> wrote:
Hi,
I might be doing something incorrectly but:
I activate two jack clients, one with output port, the other with input
and output.
First client does some processing and simply memcpy to the out buffer.
The second client memcpy from input buffer to the output buffer.
When the first client out port is connected with input of the second
client input port, the ports are of the same address now (not sure which
one changes, but if not connected they are different addresses).
This is a data race, no?
Gcc reports it as so, with -fsanitize=thread too.
Is this correct behavior and i should do something more complex with the
port buffers if i know they might be connected?
Thank you!
—
Reply to this email directly, view it on GitHub
<#902>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIX3J4QJQI4XF2WVSJ6NJTWIZXSRANCNFSM6AAAAAASDU4FPY>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Sorry, I didn't read your comment. You have two clients you transfer data
between inside the same process? I haven't tried that, sorry.
On Thu, Nov 17, 2022 at 7:12 PM Kjetil Matheussen ***@***.***>
wrote:
… I run jack with -fsanitize=thread quite often and can't remember seeing
something like this.
Which version of jack do you use?
Any code you can show?
On Thu, Nov 17, 2022 at 7:04 PM Andzelmas ***@***.***>
wrote:
> Hi,
> I might be doing something incorrectly but:
> I activate two jack clients, one with output port, the other with input
> and output.
> First client does some processing and simply memcpy to the out buffer.
> The second client memcpy from input buffer to the output buffer.
> When the first client out port is connected with input of the second
> client input port, the ports are of the same address now (not sure which
> one changes, but if not connected they are different addresses).
> This is a data race, no?
> Gcc reports it as so, with -fsanitize=thread too.
> Is this correct behavior and i should do something more complex with the
> port buffers if i know they might be connected?
> Thank you!
>
> —
> Reply to this email directly, view it on GitHub
> <#902>, or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAIX3J4QJQI4XF2WVSJ6NJTWIZXSRANCNFSM6AAAAAASDU4FPY>
> .
> You are receiving this because you are subscribed to this thread.Message
> ID: ***@***.***>
>
|
Beta Was this translation helpful? Give feedback.
-
Sorry, I didn't really mean anything. :-) I just wanted to point out
that I don't think I've tried what I think is your scenario while
running thread sanitizer.
Regarding running several clients with several callbacks in the same
process, I don't think there's any reason why that wouldn't work, so
if you get thread sanitizer hits that's probably a bug in jack. But we
need to see your code. :-)
…On Thu, Nov 17, 2022 at 8:28 PM Andzelmas ***@***.***> wrote:
Oh, i see what you mean by the same process.
So same process should only have a single client with one callback?
Wouldn't it be more efficient to have several clients inside your program for different contexts (for lets say a plugin host part, for some sort of audio recorder etc.)?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
are you using pipewire by any chance? reusing the same buffer from one output port as the other input port is quite normal in jack2. there should be no data race though, because when clients are connected to each other they run sequentially. and when not connected to each other they wont share any buffers. |
Beta Was this translation helpful? Give feedback.
-
No errors here:
***@***.***:~/test$ jackd --version
jackdmp version 1.9.12 tmpdir /dev/shm protocol 8
***@***.***:~/test$ gcc -fsanitize=thread jacktest.c -ljack
***@***.***:~/test$ ./a.out
^C
***@***.***:~/test$
…On Fri, Nov 18, 2022 at 11:29 AM Andzelmas ***@***.***> wrote:
I'm running jack simply with jack_control start.
I have pipewire installed but only because i am using plasma desktop and
it has pipewire dependencies. I am not running it as
far as i can tell. I mean i am not using pipewire-jack for jack support or
similar.
falkTX do you not get the data race in the example i attached?
Thank you all for help.
—
Reply to this email directly, view it on GitHub
<#902 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIX3JYLUX2MBQO4U2EX5BLWI5LA3ANCNFSM6AAAAAASDU4FPY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
And jackd output:
***@***.***:~$ jackd -ddummy
jackdmp 1.9.12
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2016 Grame.
Copyright 2016-2017 Filipe Coelho.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
no message buffer overruns
no message buffer overruns
no message buffer overruns
JACK server starting in realtime mode with priority 10
self-connect-mode is "Don't restrict self connect requests"
JackEngine::XRun: client = test_B was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackEngine::XRun: client = test_B was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error
Cannot write socket fd = 13 err = Broken pipe
CheckRes error
Could not write notification
ClientNotify fails name = test_A notification = 1 val1 = 0 val2 = 0
JackEngine::XRun: client = test_B was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackEngine::XRun: client = test_B was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error
Cannot write socket fd = 13 err = Broken pipe
CheckRes error
Could not write notification
ClientNotify fails name = test_A notification = 1 val1 = 0 val2 = 0
On Sun, Nov 20, 2022 at 12:09 PM Kjetil Matheussen ***@***.***>
wrote:
… No errors here:
***@***.***:~/test$ jackd --version
jackdmp version 1.9.12 tmpdir /dev/shm protocol 8
***@***.***:~/test$ gcc -fsanitize=thread jacktest.c -ljack
***@***.***:~/test$ ./a.out
^C
***@***.***:~/test$
On Fri, Nov 18, 2022 at 11:29 AM Andzelmas ***@***.***>
wrote:
> I'm running jack simply with jack_control start.
> I have pipewire installed but only because i am using plasma desktop and
> it has pipewire dependencies. I am not running it as
> far as i can tell. I mean i am not using pipewire-jack for jack support
> or similar.
> falkTX do you not get the data race in the example i attached?
> Thank you all for help.
>
> —
> Reply to this email directly, view it on GitHub
> <#902 (reply in thread)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAIX3JYLUX2MBQO4U2EX5BLWI5LA3ANCNFSM6AAAAAASDU4FPY>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
|
Beta Was this translation helpful? Give feedback.
-
And for alsa:
***@***.***:~$ jackd -dalsa
jackdmp 1.9.12
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2016 Grame.
Copyright 2016-2017 Filipe Coelho.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
no message buffer overruns
no message buffer overruns
no message buffer overruns
JACK server starting in realtime mode with priority 10
self-connect-mode is "Don't restrict self connect requests"
audio_reservation_init
Acquire audio card Audio0
creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 32bit integer little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 32bit integer little-endian
ALSA: use 2 periods for playback
On Sun, Nov 20, 2022 at 12:10 PM Kjetil Matheussen ***@***.***>
wrote:
… And jackd output:
***@***.***:~$ jackd -ddummy
jackdmp 1.9.12
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2016 Grame.
Copyright 2016-2017 Filipe Coelho.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
no message buffer overruns
no message buffer overruns
no message buffer overruns
JACK server starting in realtime mode with priority 10
self-connect-mode is "Don't restrict self connect requests"
JackEngine::XRun: client = test_B was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackEngine::XRun: client = test_B was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error
Cannot write socket fd = 13 err = Broken pipe
CheckRes error
Could not write notification
ClientNotify fails name = test_A notification = 1 val1 = 0 val2 = 0
JackEngine::XRun: client = test_B was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackEngine::XRun: client = test_B was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error
Cannot write socket fd = 13 err = Broken pipe
CheckRes error
Could not write notification
ClientNotify fails name = test_A notification = 1 val1 = 0 val2 = 0
On Sun, Nov 20, 2022 at 12:09 PM Kjetil Matheussen <
***@***.***> wrote:
> No errors here:
>
> ***@***.***:~/test$ jackd --version
> jackdmp version 1.9.12 tmpdir /dev/shm protocol 8
> ***@***.***:~/test$ gcc -fsanitize=thread jacktest.c -ljack
> ***@***.***:~/test$ ./a.out
> ^C
> ***@***.***:~/test$
>
>
>
> On Fri, Nov 18, 2022 at 11:29 AM Andzelmas ***@***.***>
> wrote:
>
>> I'm running jack simply with jack_control start.
>> I have pipewire installed but only because i am using plasma desktop and
>> it has pipewire dependencies. I am not running it as
>> far as i can tell. I mean i am not using pipewire-jack for jack support
>> or similar.
>> falkTX do you not get the data race in the example i attached?
>> Thank you all for help.
>>
>> —
>> Reply to this email directly, view it on GitHub
>> <#902 (reply in thread)>,
>> or unsubscribe
>> <https://github.com/notifications/unsubscribe-auth/AAIX3JYLUX2MBQO4U2EX5BLWI5LA3ANCNFSM6AAAAAASDU4FPY>
>> .
>> You are receiving this because you commented.Message ID:
>> ***@***.***>
>>
>
|
Beta Was this translation helpful? Give feedback.
-
Well, then i guess this is answered for me. Its not an issue with jack but with my system configuration. Will have to look into that. WARNING: ThreadSanitizer: data race (pid=2655) Previous write of size 8 at 0x7f2b6552fe80 by thread T5: Location is global '' at 0x000000000000 (jack-1000-0+0x2491e80) Thread T4 (tid=2665, running) created by main thread at: Thread T5 (tid=2666, running) created by main thread at: And output of jack -dalsa |
Beta Was this translation helpful? Give feedback.
-
Hi,
I might be doing something incorrectly but:
I activate two jack clients, one with output port, the other with input and output.
First client does some processing and simply memcpy to the out buffer.
The second client memcpy from input buffer to the output buffer.
When the first client out port is connected with input of the second client input port, the ports are of the same address now (not sure which one changes, but if not connected they are different addresses).
This is a data race, no?
Gcc reports it as so, with -fsanitize=thread too.
Is this correct behavior and i should do something more complex with the port buffers if i know they might be connected?
Thank you!
Beta Was this translation helpful? Give feedback.
All reactions