Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

jacko hangs because of 'e' #1

Closed
gogins opened this issue Oct 24, 2023 · 51 comments
Closed

jacko hangs because of 'e' #1

gogins opened this issue Oct 24, 2023 · 51 comments
Assignees
Labels
bug Something isn't working documentation Improvements or additions to documentation

Comments

@gogins
Copy link
Owner

gogins commented Oct 24, 2023

This from @tjingboem:

i came across an issue that prevents me from using the Jacko opcodes making the Jack connections i want.
I want to use the Jacko opcodes in Blue, to use some external hardware synths via Midi. Now, Blue uses an 'event "e"' to tell the playbackhead to stop. As it turns out, Jacko does not like this and Csound does not stop at the designated time.

For this to test, i have attached several thing

event.csd - makes Csound crazy
Catia_JackConnection.png - showing the Jacko connection
Event_CPU.png - showing Csound going nuts
Event_NoStop.png - the output form Visual Studio Code, where (illegally) Jacko re-started after the csd has finished
no_event.csd - leaving out the 'event "e' and all works just fine
Images and csds:
JackoImages.zip
Jacko_csd.zip

@gogins
Copy link
Owner Author

gogins commented Oct 24, 2023

I think I have had other, different problems with 'e' myself. Might be related.

@gogins
Copy link
Owner Author

gogins commented Oct 25, 2023

@gogins
Copy link
Owner Author

gogins commented Oct 25, 2023

Trouble getting things going on macOS. However, this works:

  • Start jackd in a terminal: michaelgogins@Michaels-MBP ~ % jackd -d coreaudio
  • Configure QjackCtl to not start the server or shut down the server.

@gogins
Copy link
Owner Author

gogins commented Oct 25, 2023

I don't have a MIDI interface showing up in Jack. However, I can still reproduce the problem. It looks like I need to get on Linux to debug this properly. The thread to close the Jack state completes, but then the Jack state starts up again.

There is probably a simple solution -- either check some existing or new flag or condition in the Jack state creation code, or put in diagnostics to see if there is a data race.

@tjingboem
Copy link

Yes that the problem; the Jack state starts up again. Sorry you had to find out how to run Jack on OSX and then have to go to Linux anyway....

@gogins
Copy link
Owner Author

gogins commented Oct 25, 2023 via email

@gogins gogins changed the title jacko hangs because of 'event' jacko hangs because of 'e' Oct 30, 2023
@gogins
Copy link
Owner Author

gogins commented Oct 30, 2023

I have build Csound 6.19 and the plugins on Ubuntu and can reproduce the error. But I get another error, stack smashing, and can't open the MIDI port on my Focusrite.

It's not clear to me what MIDI port events.csd should be connecting to -- capture, or playback? Well, capture is "in" and playback is "out."

It's also not clear to me whether to use "raw" or "seq" MIDI.

@tjingboem
Copy link

tjingboem commented Oct 30, 2023

I'm running Linux Mint with KXStudio applications like Cadence and Catia. There is a screenshot in JackoImages.zip that shows the names and what connection should be made.
I use the ALSA sequencer but i do not think that it should matter.

Catia_JackConnection

here a screenshot of my Cadence Jack Settings:
Screenshot from 2023-10-30 14-52-07
and
Screenshot from 2023-10-30 14-52-36

I hope this information is of some use for you.

Addendum: rightclicking on a Port in Catia reveals its name and aliases

@gogins
Copy link
Owner Author

gogins commented Oct 30, 2023

mkg@xenakis:/etc$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.3 LTS
Release: 22.04
Codename: jammy

@tjingboem
Copy link

Re: stack smashing
i did file another issue: JackoInit crashes Csound #2
with this error

@gogins
Copy link
Owner Author

gogins commented Oct 31, 2023

I have fixed the stack smashing, which was caused by faulty or, at least, flaky logic in the JackoMidiInConnect and JackoMidiOutConnect opcodes, which were unnecessarily translating back and forth between port objects and port names; I have simplified the code to use only port names.

I rewrote the test csds, combined them into one, and added some stuff it; it's attached. jacko_test.txt

@tjingboem
Copy link

Where can i find these improved Jacko opcodes?

@gogins
Copy link
Owner Author

gogins commented Nov 2, 2023

Some more progress. I changed CMakeLists.txt to link with -ljack instead of -ljackserver. After that, I do not get the 'default' server already active error when running the test piece when the Jack daemon is already running, and all the appropriate connections show up in QjackCtl's graph, and there is no stack smashing. The piece appears to run and complete normally.

But there is no sound!

@tjingboem
Copy link

Can you test if the Midi connection is working?

@gogins
Copy link
Owner Author

gogins commented Nov 2, 2023

Now there is sound. I had introduced a new bug!

Now the sound is perfect when Csound instruments are playing, but there is a buzz when Csound is silent. I think this will be easy to fix.

@tjingboem
Copy link

sounds spooky!

@gogins
Copy link
Owner Author

gogins commented Nov 2, 2023

@gogins
Copy link
Owner Author

gogins commented Nov 2, 2023 via email

gogins added a commit that referenced this issue Nov 3, 2023
gogins added a commit that referenced this issue Nov 3, 2023
@gogins
Copy link
Owner Author

gogins commented Nov 3, 2023

Updated test, so that it tests:

  • JackoAudioOut out to Jack.
  • JackoNoteOut out to external Jack synth.
  • e event (not currently working). Seems to work now, needs more testing and some code cleanup.

gogins added a commit that referenced this issue Nov 3, 2023
@tjingboem
Copy link

i am still unable to build and test.
i changed line 5 in CMakeLists.txt of jackops so that it would find jack.so instead of jackdmp.
find_path (JACK_INCLUDE_DIR jack/jack.so HINTS /lib/x86_64-linux-gnu)

But i do not know what i am doing and get the same:
-- JACK_LIB="", so disabling BUILD_JACK_OPCODES
-- BUILD_JACK_OPCODES is disabled.

@gogins
Copy link
Owner Author

gogins commented Nov 3, 2023

Now that everything seems to be working, I'll do some more testing. I'll put a binary up here right away, and I'll try to fix the build system also. If the build system works and your tests are OK I will do a pull request.

gogins added a commit that referenced this issue Nov 3, 2023
@gogins gogins self-assigned this Nov 3, 2023
@gogins gogins added the bug Something isn't working label Nov 3, 2023
@tjingboem
Copy link

tjingboem commented Nov 4, 2023

I will do the testing tomorrow, and get back to you with a report. Thanks!

@tjingboem
Copy link

tjingboem commented Nov 5, 2023

i was able to build the Plugins.
There are a few opcodes i will not use and do not have their dependencies on my computer. So, in CMakeLists.txt, i manually deleted:

add_subdirectory(./src/faustcsound)
add_subdirectory(./src/AbletonLinkOpcodes)
add_subdirectory(./src/CUDA)
add_subdirectory(./src/websockets)
add_subdirectory(./src/wiimote)
add_subdirectory(./src/p5glove)
add_subdirectory(./src/hdf5)
add_subdirectory(./src/widgets)

result with cmake:

//Path to a library.
JACK_LIB:FILEPATH=/usr/lib/x86_64-linux-gnu/libjack.so

//Dependencies for the target
jackTransport_LIB_DEPENDS:STATIC=general;/usr/lib/x86_64-linux-gnu/libjack.so;

//Dependencies for the target
jacko_LIB_DEPENDS:STATIC=general;/usr/lib/x86_64-linux-gnu/libjack.

installing:

[ 77%] Linking CXX shared module libjacko.so

Installed succesfully:
-- Install configuration: ""
-- Installing: /usr/local/lib/csound/plugins64-6.0/libchua.so
-- Installing: /usr/local/lib/csound/plugins64-6.0/libimage.so
-- Installing: /usr/local/lib/csound/plugins64-6.0/libpy.so
-- Installing: /usr/local/lib/csound/plugins64-6.0/libstkops.so
-- Installing: /usr/local/lib/csound/plugins64-6.0/liblinear_algebra.so
-- Installing: /usr/local/lib/csound/plugins64-6.0/libmp3out.so
-- Installing: /usr/local/lib/csound/plugins64-6.0/libjacko.so
-- Installing: /usr/local/lib/csound/plugins64-6.0/libjackTransport.so
-- Installing: /usr/local/lib/csound/plugins64-6.0/libfluidOpcodes.so

Then, over to the jacko_test csd in Visual Studio Code:

  • I activated zynaddsubfx as requested.

Then an error:

...
     40:   Input    8 bit raw midi             zynaddsubfx:osc
     41:   Output   8 bit raw midi             system:midi_capture_6
           Alias: alsa_pcm:Csound/midi_playback_1
           Alias: Csound:midi/playback_1
     42:   Input    8 bit raw midi             zynaddsubfx:midi_input
*** stack smashing detected ***: terminated

csound command: Aborted
inactive allocs returned to freespace
end of score.		   overall amps:      0.0      0.0
	   overall samples out of range:        0        0
0 errors in performance
Elapsed time at end of performance: real: 0.277s, CPU: 0.013s
JackoState::close...
Jack client deactivated.
Jack ports unregistered.
Jack client closed.
JackoState::close.
...

Even now that Csound Aborted, i still see the Csound Midiout port active:

Screenshot from 2023-11-05 13-18-20

i manually killed Zyn and Csound.

Then i started to try and cut back the csd. I stopped Jackd from Cadence, and restarted it.

I noticed that in the jacko_test.csd, 2 times JackoInfo was set. So i deleted one of them to see what happens.

*** stack smashing detected ***: terminated

csound command: Aborted

So i took out JackoInfo to avoid the error, and ran the csd. A VERY LOUD sine wave was piercing my head!
But i saw the connection: JackoMidiInConnect "system:midi_capture_1", "midiin"
and
JackoAudioOutConnect "audio_out_left", "system:playback_1"
JackoAudioOutConnect "audio_out_right", "system:playback_2"
and
JackoMidiOutConnect "midiout", "zynaddsubfx:midi_input" but as i deleten Zyn, it was not connecting.

instr 801:  p1 = 801.000  p2 = 10.000  p3 = 3.000  p4 = 69.000  p5 = 60.000

csound command: Segmentation fault
jack_port_get_buffer called with an incorrect port 0
jack_midi_event_reserve: port buffer is set to NULL

So i changed this connection so that it would connect to some hardware synth i have:
JackoMidiOutConnect "midiout", "M-Audio-Delta-1010:midi/capture_1"

and in the score i changed the amplitude of instr 1 to a MUCH lower level:
from

i1     5  3 63 60
i801  10  3 69 60	
i1	  15  3 72 60

to

i1     5  3 63 3
i801  10  3 69 60	
i1	  15  3 72 3

Then run the csd again:

instr 900:  p1 = 900.000  p2 = 0.000  p3 = -1.000
Jacko is now driving Csound performance...
B  0.000 ..  5.000 T  5.000 TT  5.000 M:      0.0      0.0
new alloc for instr 1:
instr 1:  p1 = 1.000  p2 = 5.000  p3 = 3.000  p4 = 63.000  p5 = 3.000
instr 1:  i_frequency = 311.127  i_amplitude = 1.413
B  5.000 .. 10.000 T 10.000 TT 10.000 M:      1.4      1.4
new alloc for instr 801:
instr 801:  p1 = 801.000  p2 = 10.000  p3 = 3.000  p4 = 69.000  p5 = 60.000
noteon:  144  69  60
Sent note to midiout.
noteoff: 128  69   0
B 10.000 .. 15.000 T 15.000 TT 15.000 M:      0.0      0.0
instr 1:  p1 = 1.000  p2 = 15.000  p3 = 3.000  p4 = 72.000  p5 = 3.000
instr 1:  i_frequency = 523.251  i_amplitude = 1.413
B 15.000 .. 20.000 T 20.000 TT 20.000 M:      1.4      1.4
new alloc for instr 1000:
instr 1000:  p1 = 1000.000  p2 = 20.000  p3 = 1.000
Ending Csound performance with 'e' event
  rtevent:	   T 20.003 TT 20.003 M:      0.0      0.0
Score finished in csoundPerformKsmpsInternal().
Csound performance driven by Jack has finished.
JackoState::close...
Jack client deactivated.
Jack ports unregistered.
Jack client closed.
Jacko has quit driving Csound performance.
JackoState::close.
WARNING: Buffer underrun in real-time audio output

After 20 seconds instr 1000 kicks in and closes all activity:

Ending Csound performance with 'e' event
  rtevent:	   T 20.003 TT 20.003 M:      0.0      0.0
Score finished in csoundPerformKsmpsInternal().
Csound performance driven by Jack has finished.
JackoState::close...
Jack client deactivated.
Jack ports unregistered.
Jack client closed.
Jacko has quit driving Csound performance.
JackoState::close.
B 20.000 .. 60.000 T 60.000 TT 60.000 M:      0.0      0.0
Score finished in csoundPerform().
inactive allocs returned to freespace
end of score.		   overall amps:      1.4      1.4
	   overall samples out of range:        0        0
0 errors in performance
Elapsed time at end of performance: real: 70.025s, CPU: 4.902s
11250 512 sample blks of 64-bit floats written to dac

Q: is JackoOn not needed anymore?

I do think the issue is solved. Thanks for your work!

It still crashes Blue immediately and do not know why.I think i will have to turn to Steven and hope he might have a peak and debug why this is not working in Blue.

@gogins
Copy link
Owner Author

gogins commented Nov 5, 2023 via email

@gogins
Copy link
Owner Author

gogins commented Nov 5, 2023

Up to now, I was testing on Ubuntu 22.04. I am now trying to test on macOS 14.1.

On my Mac, I need to start jackd -d coreaudio, then I can start from QjackCtl and see the graph.

Audio works, but MIDI is shown as disabled in QjackCtl and does not work.

The Audio MIDI Setup app is no help.

I'll try with GarageBand... still no help.

@gogins
Copy link
Owner Author

gogins commented Nov 5, 2023

I tried using valgrind memory check, no unusual reports, no help.

@gogins
Copy link
Owner Author

gogins commented Nov 5, 2023

But with valgrind --tool=helgrind many reports of this kind:

==9194== Possible data race during write of size 8 at 0x6181B50 by thread #4
==9194== Locks held: none
==9194==    at 0x490F992: scanflt (in /usr/local/lib/libcsound64.so.6.0)
==9194==    by 0x490FDC8: rdscor (in /usr/local/lib/libcsound64.so.6.0)
==9194==    by 0x490CD62: sensevents (in /usr/local/lib/libcsound64.so.6.0)
==9194==    by 0x48DCE22: csoundPerformKsmpsInternal (in /usr/local/lib/libcsound64.so.6.0)
==9194==    by 0x100544DB: JackoState::JackProcessCallback(unsigned int) (in /usr/local/lib/csound/plugins64-6.0/libjacko.so)
==9194==    by 0x1005335A: JackProcessCallback_(unsigned int, void*) (in /usr/local/lib/csound/plugins64-6.0/libjacko.so)
==9194==    by 0xF5D5B0E: ??? (in /usr/lib/x86_64-linux-gnu/libjack.so.0.1.0)
==9194==    by 0xF5D57D7: ??? (in /usr/lib/x86_64-linux-gnu/libjack.so.0.1.0)
==9194==    by 0xF5F290F: ??? (in /usr/lib/x86_64-linux-gnu/libjack.so.0.1.0)
==9194==    by 0x485396A: ??? (in /usr/libexec/valgrind/vgpreload_helgrind-amd64-linux.so)
==9194==    by 0x4D24AC2: start_thread (pthread_create.c:442)
==9194==    by 0x4DB5BF3: clone (clone.S:100)
==9194== 
==9194== This conflicts with a previous write of size 8 by thread #1
==9194== Locks held: 1, at address 0x654DDB0
==9194==    at 0x490F992: scanflt (in /usr/local/lib/libcsound64.so.6.0)
==9194==    by 0x490FDC8: rdscor (in /usr/local/lib/libcsound64.so.6.0)
==9194==    by 0x490CD62: sensevents (in /usr/local/lib/libcsound64.so.6.0)
==9194==    by 0x48DD18A: csoundPerform (in /usr/local/lib/libcsound64.so.6.0)
==9194==    by 0x10AB0C: main (in /usr/local/bin/csound)
==9194==  Address 0x6181b50 is 22,448 bytes inside a block of size 81,760 alloc'd
==9194==    at 0x484A919: malloc (in /usr/libexec/valgrind/vgpreload_helgrind-amd64-linux.so)
==9194==    by 0x48DA720: csoundCreate (in /usr/local/lib/libcsound64.so.6.0)
==9194==    by 0x10AACC: main (in /usr/local/bin/csound)
==9194==  Block was alloc'd by thread #1
==9194== 
==9194== ----------------------------------------------------------------
==9194== 
==9194==  Lock at 0x654DDB0 was first observed
==9194==    at 0x4854BFE: pthread_mutex_init (in /usr/libexec/valgrind/vgpreload_helgrind-amd64-linux.so)
==9194==    by 0x4AC6E67: csoundCreateMutex (in /usr/local/lib/libcsound64.so.6.0)
==9194==    by 0x48DA81A: csoundCreate (in /usr/local/lib/libcsound64.so.6.0)
==9194==    by 0x10AACC: main (in /usr/local/bin/csound)
==9194==  Address 0x654ddb0 is 0 bytes inside a block of size 40 alloc'd
==9194==    at 0x484A919: malloc (in /usr/libexec/valgrind/vgpreload_helgrind-amd64-linux.so)
==9194==    by 0x4AC6E45: csoundCreateMutex (in /usr/local/lib/libcsound64.so.6.0)
==9194==    by 0x48DA81A: csoundCreate (in /usr/local/lib/libcsound64.so.6.0)
==9194==    by 0x10AACC: main (in /usr/local/bin/csound)
==9194==  Block was alloc'd by thread #1

But I think this is a false positive in this context.

@gogins
Copy link
Owner Author

gogins commented Nov 6, 2023

I'm experimenting to see if the Valgrind errors also occur without Jacko, i.e. simply running xanadu.csd.

The answer is NO, which means that the errors with Jacko are probably not false positives, but are pointing at something.

And I get possible data races in running the jacko_test.csd WITHOUT ANY NOTES.

@gogins
Copy link
Owner Author

gogins commented Nov 6, 2023

I reordered code as follows. I changed

instr 900 
print p1, p2, p3
outs ga_audio_out, ga_audio_out
JackoAudioOut "audio_out_left",  ga_audio_out
outs ga_audio_out, ga_audio_out
JackoAudioOut "audio_out_right", ga_audio_out
ga_audio_out = 0
endin

to

instr 900 
print p1, p2, p3
JackoAudioOut "audio_out_left",  ga_audio_out
JackoAudioOut "audio_out_right", ga_audio_out
ga_audio_out = 0
outs ga_audio_out, ga_audio_out
endin

This vastly reduced the "possible data race" notifications from Valgrind.

@tjingboem
Copy link

tjingboem commented Nov 6, 2023

it still produces a very loud signal
even after commenting out
;outs ga_audio_out, ga_audio_out

@gogins
Copy link
Owner Author

gogins commented Nov 6, 2023

it still produces a very loud signal even after commenting out ;outs ga_audio_out, ga_audio_out

The audio is going out through the Jack audio ports. The outs opcode is writing to a soundfile.

@gogins
Copy link
Owner Author

gogins commented Nov 6, 2023

With outs before JackoAudioOut: ERROR SUMMARY: 906548 errors from 298 contexts (suppressed: 18997 from 179)
With JackoAudioOut before outs: ERROR SUMMARY: 918649 errors from 286 contexts (suppressed: 18182 from 155)

I'm not sure if this is telling me anything.

I'm going to look at ways of doing this within one thread.

@gogins
Copy link
Owner Author

gogins commented Nov 6, 2023

Question: Does SenseEventsCallback get called at the start of csoundPerformKsmps, or at the end?

@tjingboem
Copy link

( i hope that this is a rhetorical question...)

@gogins
Copy link
Owner Author

gogins commented Nov 6, 2023

( i hope that this is a rhetorical question...)

It is a question to myself. And the answer is in the API documentation:

Register a function to be called once in every control period by sensevents(). Any number of functions may be registered, and will be called in the order of registration. The callback function takes two arguments: the Csound instance pointer, and the userData pointer as passed to this function. This facility can be used to ensure a function is called synchronously before every csound control buffer processing. It is important to make sure no blocking operations are performed in the callback. The callbacks are cleared on csoundCleanup(). Returns zero on success.

Oops, that does NOT answer the question. "Before" in this context means before the default sense events processing, not before csoundPerformKsmps does most of its work. I'll have to read the source code.

OK, csoundPerformKsmps locks a mutex, calls senseevents, calls kperf, then unlocks the mutex. But the mutex is NOT used in realtime performance! Could that be the problem here?

I will try running without writing audio to a soundfile, but rather using the Jack command line audio output instead.

@gogins
Copy link
Owner Author

gogins commented Nov 6, 2023

It may be necessary to use the client name provided on the command line, e.g. -+jack_client=myname.

No help, this way we end up with two clients, many xruns, and Csound hangs at the end of performance.

The implication is that at the current state of implementation in both Csound and Jacko, mixing Jacko with -+rtaudio=jack is not advisable.

@gogins
Copy link
Owner Author

gogins commented Nov 6, 2023

Current order of processing:

  1. sensevents callback
  2. sensevents
  3. kperf

@gogins
Copy link
Owner Author

gogins commented Nov 6, 2023

There is no kperf callback, that is why I came up with this design.

@tjingboem
Copy link

The implication is that at the current state of implementation in both Csound and Jacko, mixing Jacko with -+rtaudio=jack is not advisable.
That is a pity for me as a Blue user, but can not be changed. But it is good to have established that.

I think this would be good to add this to the manual.

@gogins
Copy link
Owner Author

gogins commented Nov 7, 2023

I have fixed some bugs that showed up when connecting Jack audio input to Csound using Jacko.

valgrind shows a lot of possible data races but I think these are false positives.

There will be "stack smashing" if there happens to be a zombie Jack daemon when running the test CSD.

@gogins
Copy link
Owner Author

gogins commented Nov 7, 2023

Is it possible to use csoundPerformBuffer in Jacko? It would be possible, but it wouldn't help.

@gogins
Copy link
Owner Author

gogins commented Nov 7, 2023

I replaced the relatively low-level pthreads code with somewhat higher-level std::thread code.

@gogins
Copy link
Owner Author

gogins commented Nov 7, 2023

I think some of the data race notifications from valgrind thread checking are caused by creating Jack ports and connections while Csound is running. Perhaps I need to synchronize this code.

@tjingboem
Copy link

when i run the example in VSC and the example finishes with JackoState::Close, the sound of a youtube video (also connected to Jack) also hangs. After a while Jack gets back to life.
It must be a big shock for the Jack system.

@gogins
Copy link
Owner Author

gogins commented Nov 7, 2023

What a mess. Csound implements both csoundPerformKsmps and csoundPerformKsmpsInternal, and valgrind reports errors in csoundPerformKsmpsInternal even though the Jacko called actually calls csoundPerformKsmps. That may be what leads to this:

==47824== Possible data race during write of size 8 at 0x60772D8 by thread #4
==47824== Locks held: none
==47824==    at 0x48DCC24: kperf_nodebug (csound.c:1810)
==47824==    by 0x48DB07D: csoundPerformKsmpsInternal (csound.c:2272)
==47824==    by 0xFEBEA0F: JackoState::JackProcessCallback(unsigned int) (jacko.cpp:656)
==47824==    by 0xF47AB0E: ??? (in /usr/lib/x86_64-linux-gnu/libjack.so.0.1.0)
==47824==    by 0xF47A7D7: ??? (in /usr/lib/x86_64-linux-gnu/libjack.so.0.1.0)
==47824==    by 0xF49790F: ??? (in /usr/lib/x86_64-linux-gnu/libjack.so.0.1.0)
==47824==    by 0x485396A: ??? (in /usr/libexec/valgrind/vgpreload_helgrind-amd64-linux.so)
==47824==    by 0x4C0BAC2: start_thread (pthread_create.c:442)
==47824==    by 0x4C9CBF3: clone (clone.S:100)
==47824== 
==47824== This conflicts with a previous write of size 8 by thread #1
==47824== Locks held: 1, at address 0x6434E80
==47824==    at 0x48EE608: init_pass (insert.c:114)
==47824==    by 0x48F2379: insert_event (insert.c:493)
==47824==    by 0x48F8475: process_score_event (musmon.c:859)
==47824==    by 0x48FA0FD: sensevents (musmon.c:1068)
==47824==    by 0x48DE1DA: csoundPerform (csound.c:2342)
==47824==    by 0x10A7B6: main (csound_main.c:328)
==47824==  Address 0x60772d8 is 81,720 bytes inside a block of size 81,760 alloc'd
==47824==    at 0x484A919: malloc (in /usr/libexec/valgrind/vgpreload_helgrind-amd64-linux.so)
==47824==    by 0x48DF411: csoundCreate (csound.c:1354)
==47824==    by 0x10A670: main (csound_main.c:322)
==47824==  Block was alloc'd by thread #1
==47824== 
==47824== ----------------------------------------------------------------
==47824== 
==47824==  Lock at 0x6434E80 was first observed
==47824==    at 0x4854BFE: pthread_mutex_init (in /usr/libexec/valgrind/vgpreload_helgrind-amd64-linux.so)
==47824==    by 0x4A0DB3C: csoundCreateMutex (threads.c:501)
==47824==    by 0x48DF4A1: csoundCreate (csound.c:1371)
==47824==    by 0x10A670: main (csound_main.c:322)
==47824==  Address 0x6434e80 is 0 bytes inside a block of size 40 alloc'd
==47824==    at 0x484A919: malloc (in /usr/libexec/valgrind/vgpreload_helgrind-amd64-linux.so)
==47824==    by 0x4A0DB29: csoundCreateMutex (threads.c:499)
==47824==    by 0x48DF4A1: csoundCreate (csound.c:1371)
==47824==    by 0x10A670: main (csound_main.c:322)
==47824==  Block was alloc'd by thread #1

So it seems that the value of the csoundPerformKsmps member of the CSOUND struct is actually the address of csoundPerformKsmpsInternal. It is a mistake to have two functions in the first place, and a worse mistake to invisibly switch the name. I will debug this to confirm.

That is correct:

Thread 4 "csound" hit Breakpoint 1, csoundPerformKsmpsInternal (csound=0x555555577d30) at /home/mkg/csound/Top/csound.c:2248
2248	{
(gdb) bt
#0  csoundPerformKsmpsInternal (csound=0x555555577d30) at /home/mkg/csound/Top/csound.c:2248
#1  0x00007fffecd14a10 in JackoState::JackProcessCallback(unsigned int) (this=0x5555558a0c10, frames=<optimized out>) at /home/mkg/plugins/src/jackops/jacko.cpp:656
#2  0x00007fffed72fb0f in  () at /lib/x86_64-linux-gnu/libjack.so.0
#3  0x00007fffed72f7d8 in  () at /lib/x86_64-linux-gnu/libjack.so.0
#4  0x00007fffed74c910 in  () at /lib/x86_64-linux-gnu/libjack.so.0
#5  0x00007ffff7b12ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#6  0x00007ffff7ba4a40 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
(gdb) up
#1  0x00007fffecd14a10 in JackoState::JackProcessCallback (this=0x5555558a0c10, frames=<optimized out>) at /home/mkg/plugins/src/jackops/jacko.cpp:656
656	            int finished = csound->PerformKsmps(csound);
(gdb) 

If, then, csoundPerform is not calling kperf while Jacko is also calling kperf, the "possible data race" notification is not relevant.

The registered sensevents callback is called not at the beginning of sensevents, but just before handling any real-time events.

@gogins
Copy link
Owner Author

gogins commented Nov 7, 2023

I need to find whether kperf (it is actually kperf_nodebug) is called once and only once per kperiod, or more than once. _It is called once and only once!

I assume I can now ignore the helgrind warnings.

@gogins
Copy link
Owner Author

gogins commented Nov 8, 2023

I issued a pull request, which built in the cloud, and was merged by @stekyne.

I am closing this issue for the time being.

@gogins gogins closed this as completed Nov 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

2 participants