Loading buffers with samples exit server with code 0

[kesey]

Thanks to all for your help.
@jamshark70, I don’t know if it’s what you’re suggesting but I will use lazy loading.
I’ve test it and it works well.

Anyway, I have to confess that I 'm a bit disapointed.
I follow the advices for debugging and it’s not working at all for my case, the exit is not reproducible in debug mode and something clearly behave differently in this case.
I think, it’s a bit scary.

@smoge can you explain the differences between debugging by opening scsynth in gdb and debugging by attaching gdb to scsynth please ?
I’d be happy to avoid wasting time by recompiling sc etc. to figure out that I can’t reproduce the exit with this way too.

I have a bit of feeling of hiding the dust under the carpet here.

[jamshark70]

@kesey

I’d be happy to avoid wasting time by recompiling sc

SC isn’t exactly a light build, but it isn’t very, very heavy either (complete build on my machine is, oh, 15 minutes, or less?). I’d suggest to change your build_type to RelWithDebInfo, rebuild once, and leave it with that setting. I don’t think there’s a strong benefit to building as Release.

Re: attaching – it’s a bit of a stab in the dark. I know you’re not going to like that, but the fact is, this is a very weird problem.

I was able to attach by asking sclang s.pid, then plugging that pid into sudo gdb -p xxxxxx. I could get it to work only with sudo. If you don’t use sudo, there’s some message about changing a ptrace setting. I changed the setting, but wasn’t willing to reboot, so I don’t know if that’s entirely effective.

After attaching with sudo, quitting the server caused the JACK server to freeze – had to kill -9 it. That’s not wonderful, but it’s worth it if it gets more information than you got before.

@kesey

Anyway, I have to confess that I 'm a bit disapointed.
I follow the advices for debugging and it’s not working at all for my case, the exit is not reproducible in debug mode and something clearly behave differently in this case.

I think I would look at it from a different perspective.

Bombarding the server with 2017* b_allocRead messages all at once, without any sort of partitioning or interim waiting, doesn’t strike me as an ideal thing to do. (As I noted in an earlier message, I take pains in my code to avoid doing anything like this. And… 2017? You’re never going to use all 2017 samples in one set. That’s a lot of wasted effort.)

Doing something that is not ideal may or may not work. You might get away with it on some machines, and then find another machine or environment where it fails.

The fact that a high stress use case didn’t fail in x and y environments isn’t a guarantee that it won’t fail in z.

“Sweeping it under the rug”… well ok, I haven’t exactly refuted that. But … speaking for myself, if SuperDirt were mine, I would bend over backward to avoid mass loading that many samples without any breaks in the process. Load them a hundred at a time, s.sync in between each chunk, I bet the problem goes away.

hjh

* For giggles:

p = "808 (6) 808bd (25) 808cy (25) 808hc (5) 808ht (5) 808lc (5) 808lt (5) 808mc (5) 808mt (5) 808oh (5) 808sd (25) 909 (1) ab (12) ade (10) ades2 (9) ades3 (7) ades4 (6) alex (2) alphabet (26) amencutup (32) armora (7) arp (2) arpy (11) auto (11) baa (7) baa2 (7) bass (4) bass0 (3) bass1 (30) bass2 (5) bass3 (11) bassdm (24) bassfoo (3) battles (2) bd (24) bend (4) bev (2) bin (2) birds (10) birds3 (19) bleep (13) blip (2) blue (2) bottle (13) breaks125 (2) breaks152 (1) breaks157 (1) breaks165 (1) breath (1) bubble (8) can (14) casio (3) cb (1) cc (6) chin (4) circus (3) clak (2) click (4) clubkick (5) co (4) coins (1) control (2) cosmicg (15) cp (2) cr (6) crow (4) d (4) db (13) diphone (38) diphone2 (12) dist (16) dork2 (4) dorkbot (2) dr (42) dr2 (6) dr55 (4) dr_few (8) drum (6) drumtraks (13) e (8) east (9) electro1 (13) em2 (6) erk (1) f (1) feel (7) feelfx (8) fest (1) fire (1) flick (17) fm (17) foo (27) future (17) gab (10) gabba (4) gabbaloud (4) gabbalouder (4) glasstap (3) glitch (8) glitch2 (8) gretsch (24) gtr (3) h (7) hand (17) hardcore (12) hardkick (6) haw (6) hc (6) hh (13) hh27 (13) hit (6) hmm (1) ho (6) hoover (6) house (8) ht (16) if (5) ifdrums (3) incoming (8) industrial (32) insect (3) invaders (18) jazz (8) jungbass (20) jungle (13) juno (12) jvbass (13) kicklinn (1) koy (2) kurt (7) latibro (8) led (1) less (4) lighter (33) linnhats (6) lt (16) made (7) made2 (1) mash (2) mash2 (4) metal (10) miniyeah (4) monsterb (6) moog (7) mouth (15) mp3 (4) msg (9) mt (16) mute (28) newnotes (15) noise (1) noise2 (8) notes (15) numbers (9) oc (4) odx (15) off (1) outdoor (6) pad (3) padlong (1) pebbles (1) perc (6) peri (15) pluck (17) popkick (10) print (11) proc (2) procshort (8) psr (30) rave (8) rave2 (4) ravemono (2) realclaps (4) reverbkick (1) rm (2) rs (1) sax (22) sd (2) seawolf (3) sequential (8) sf (18) sheffield (1) short (5) sid (12) sine (6) sitar (8) sn (52) space (18) speakspell (12) speech (7) speechless (10) speedupdown (9) stab (23) stomp (10) subroc3d (11) sugar (2) sundance (6) tabla (26) tabla2 (46) tablex (3) tacscan (22) tech (13) techno (7) tink (5) tok (4) toys (13) trump (11) ul (10) ulgab (5) uxay (3) v (6) voodoo (5) wind (10) wobble (1) world (3) xmas (1) yeah (31)"
.findRegexp("\\([0-9]+\\)")

p.sum { |row| row[1].select(_.isDecDigit).asInteger }
-> 2017

[smoge]

Yes, what James wrote makes sense to me, too.

Perhaps there is some space for a slight enhancement in the SuperDirt quark to avoid problems like this, i.e., partitioning the loading of buffers into chunks with s.sync in between. That is a simple thing and would prevent an uncommon edge case.

[jamshark70]

E.g., add a var to DirtSoundLibrary:

	var <>syncAfter = 10;  // or nil to load all-at-once

And change loadSoundFiles to:

	loadSoundFiles { |paths, appendToExisting = false, namingFunction = (_.basename), action| // paths are folderPaths
		var folderPaths, memory;

		paths = paths ?? { "../../Dirt-Samples/*".resolveRelative };
		folderPaths = if(paths.isString) { paths.pathMatch } { paths.asArray };
		folderPaths = folderPaths.select(_.endsWith(Platform.pathSeparator.asString));
		if(folderPaths.isEmpty) {
			"no folders found in paths: '%'".format(paths).warn; ^this
		};
		memory = this.memoryFootprint;
		"\n\n% existing sample bank%:\n".postf(folderPaths.size, if(folderPaths.size > 1) { "s" } { "" });
		fork {
			var i = 0;
			folderPaths.do { |folderPath|
				this.loadSoundFileFolder(folderPath, namingFunction.(folderPath), appendToExisting);
				i = i + 1;
				if(doNotReadYet.not and: { i >= syncAfter }) {
					i = 0;
					server.sync;
				};
			};
			if(doNotReadYet) {
				"\n ... sample banks registered, will read files as necessary".postln;
			} {
				"\n... file reading complete. Required % MB of memory.\n\n".format(
					this.memoryFootprint - memory div: 1e6
				).post
			};
			action.value(this);
		};
	}

There were just over 200 sample libraries referenced in the original post. Pausing after 10 libraries ~= 20 sync calls. The sync round-trip, worst-case, shouldn’t be higher than the audio hardware driver’s period (e.g., now I’m running with a relatively large buffer; scsynth reports 42.7 ms maximum latency, and if I measure the time that s.sync takes, it’s always less than this). Worst case, then, it would add ~= 40 ms/chunk * 20 chunks ~= 800 ms, or sample loading would finish less than a second later than it would without syncing – or less, if you’re running with a smaller HW buffer size. It will take longer than that second to switch back to the Tidal window and type an expression, so the sync time shouldn’t make a difference to human users.

After this change, though, loadSoundFiles becomes asynchronous. If other parts of SuperDirt code assume that it’s synchronous, those would have to be updated to use the new action function.

hjh

[julian]

Thanks for helping with the explanations!

There are two ways you could try:

1. Set the doNotReadYet instance variable to true. Then your samples will only be read when you use them. This means that the first time you play a sample it may not sound, but it will load in the background.
2. You can read your sound files explicitly and amortize over time, either by waiting or, as James has suggested, by calling a s.sync in between. The method to be used for this is loadSoundFile(path, name, appendToExisting) – the methods loadSoundFiles etc. are just convenient wrappers around it.

Maybe it would be good if we add the sync as an argument to the method, but doNotReadYet was intended to solve these kinds of issues.

[kesey]

Thank you very much everybody for your answers and sorry for my late reply (I was away from my computer a few days)

If I set the doNotReadYet instance variable to true,
it´s ok for starting SuperDirt, it´s a good workaround and I thank you for that.

But aside from SuperDirt, I find out that I have the same problem everytime I try to load a bunch of samples in Buffers.
Even with a few of them (61).

Aside from that, I don´t know if it´s related but I have the same message:

Server 'localhost' exited with exit code 0.
server 'localhost' disconnected shared memory interface

if I try to run this chunk of code from the FluidDataSet help file examples (Flucoma)

// Using routine
(
fork{
    var point = Buffer.alloc(s,1);
    var ds = FluidDataSet(s);
    s.sync;
    10.do{
        arg i;
        point.set(0,i);
        ds.addPoint("point-%".format(i),point);
        s.sync;
    };
    ds.print;
};
)

So I follow your advices and rebuild SuperCollider with this

cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -DNATIVE=ON -DSC_EL=OFF ..

reinstall and start SuperCollider, boot the server, run s.pid, get 18846 and finally run sudo gdb -p 18846 in a terminal.
This is what I get from the terminal:

sudo gdb -p 18846
[sudo] Mot de passe de fabien : 
GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 18846
[New LWP 18855]
[New LWP 18854]
[New LWP 18853]
[New LWP 18852]
[New LWP 18850]
[New LWP 18849]
[New LWP 18848]

warning: could not find '.gnu_debugaltlink' file for /usr/lib/x86_64-linux-gnu/pipewire-0.3/jack/libjack.so.0

warning: could not find '.gnu_debugaltlink' file for /lib/x86_64-linux-gnu/libcap.so.2

warning: could not find '.gnu_debugaltlink' file for /usr/lib/x86_64-linux-gnu/spa-0.2/support/libspa-support.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/x86_64-linux-gnu/spa-0.2/support/libspa-journal.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_eqbw.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/delay.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/ZamAutoSat-ladspa.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_reflector.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/ZamComp-ladspa.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/mvclpf24.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_chorusflanger.so

warning: could not find '.gnu_debugaltlink' file for /lib/x86_64-linux-gnu/libcsound64.so.6.0

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/ZamDynamicEQ-ladspa.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/ZamGEQ31-ladspa.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_autopan.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_dynamics_m.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_eq.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/ZamTube-ladspa.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/ZamGateX2-ladspa.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/amp.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/ZamGrains-ladspa.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/cs_chorus.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_dynamics_st.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/filter.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/ZaMultiCompX2-ladspa.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_limiter.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/ZamEQ2-ladspa.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/sine.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/ZamGate-ladspa.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_pinknoise.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/cs_phaser.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_reverb.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_tremolo.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/ZamCompX2-ladspa.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_tubewarmth.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/mvchpf24.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_doubler.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/ZamDelay-ladspa.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/noise.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_sigmoid.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_vibrato.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_deesser.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_rotspeak.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_echo.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_pitch.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/ZaMaximX2-ladspa.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/x86_64-linux-gnu/spa-0.2/support/libspa-dbus.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/x86_64-linux-gnu/pipewire-0.3/libpipewire-module-rt.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/x86_64-linux-gnu/pipewire-0.3/libpipewire-module-protocol-native.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/x86_64-linux-gnu/pipewire-0.3/libpipewire-module-client-node.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/x86_64-linux-gnu/pipewire-0.3/libpipewire-module-metadata.so
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x000071a5b3298d61 in __futex_abstimed_wait_common64 (private=<optimized out>, 
    cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x5ed145398950)
    at ./nptl/futex-internal.c:57

warning: 57	./nptl/futex-internal.c: Aucun fichier ou dossier de ce nom
(gdb) 

and in SuperCollider the server seems to freeze (the status infos under the post window turn from green to yellow) without any messages in the post window.
(just after running sudo gdb -p 18846)

I don´t know what to do from here.
Any help is welcome.

[kesey]

I can have more informations by using valgrind.
I run: s.options.asOptionsString in SuperCollider to get cmd line args.

and in a terminal I run: valgrind --leak-check=yes scsynth (paste the cmd line args here).

back in SuperCollider I run:

Server.default = s = Server.remote(\debug, NetAddr("127.0.0.1", 57110), s.options);
// then
s.connectSharedMemory;

and finally when I run: SuperDirt.start; in SuperCollider,
I get this in the terminal from valgrind:

valgrind --leak-check=yes scsynth -u 57110 -a 1024 -i 2 -o 2 -b 262144 -n 32768 -d 4096 -m 2097152 -w 512 -R 0 -C 1 -l 1
==30021== Memcheck, a memory error detector
==30021== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==30021== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==30021== Command: scsynth -u 57110 -a 1024 -i 2 -o 2 -b 262144 -n 32768 -d 4096 -m 2097152 -w 512 -R 0 -C 1 -l 1
==30021== 
no more csLADSPA plugins
Found 237 LADSPA plugins
==30021== Warning: set address range perms: large range [0x59c93040, 0xd9c930e0) (undefined)
JackDriver: client name is 'SuperCollider'
SC_AudioDriver: sample rate = 44100.000000, driver's block size = 512
SuperCollider 3 server ready.
==30021== Thread 4:
==30021== Conditional jump or move depends on uninitialised value(s)
==30021==    at 0x4890528: ??? (in /usr/lib/x86_64-linux-gnu/libsndfile.so.1.0.37)
==30021==    by 0x487C785: ??? (in /usr/lib/x86_64-linux-gnu/libsndfile.so.1.0.37)
==30021==    by 0x487ED1B: ??? (in /usr/lib/x86_64-linux-gnu/libsndfile.so.1.0.37)
==30021==    by 0x147845: sndfileOpen (SC_SndFileHelpers.hpp:194)
==30021==    by 0x147845: sndfileOpenFromCStr (SC_SndFileHelpers.hpp:198)
==30021==    by 0x147845: BufAllocReadCmd::Stage2() (SC_SequencedCommand.cpp:489)
==30021==    by 0x14BD00: SC_SequencedCommand::CallNextStage() (SC_SequencedCommand.cpp:193)
==30021==    by 0x1342A0: Perform (SC_FifoMsg.h:47)
==30021==    by 0x1342A0: Perform (MsgFifo.h:62)
==30021==    by 0x1342A0: SC_AudioDriver::RunThread() (SC_CoreAudio.cpp:375)
==30021==    by 0x4C80DB3: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.33)
==30021==    by 0x4FC5A93: start_thread (pthread_create.c:447)
==30021==    by 0x5052A33: clone (clone.S:100)
==30021== 
==30021== Conditional jump or move depends on uninitialised value(s)
==30021==    at 0x484F238: strlen (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==30021==    by 0x48B9A20: ??? (in /usr/lib/x86_64-linux-gnu/libsndfile.so.1.0.37)
==30021==    by 0x489054D: ??? (in /usr/lib/x86_64-linux-gnu/libsndfile.so.1.0.37)
==30021==    by 0x487C785: ??? (in /usr/lib/x86_64-linux-gnu/libsndfile.so.1.0.37)
==30021==    by 0x487ED1B: ??? (in /usr/lib/x86_64-linux-gnu/libsndfile.so.1.0.37)
==30021==    by 0x147845: sndfileOpen (SC_SndFileHelpers.hpp:194)
==30021==    by 0x147845: sndfileOpenFromCStr (SC_SndFileHelpers.hpp:198)
==30021==    by 0x147845: BufAllocReadCmd::Stage2() (SC_SequencedCommand.cpp:489)
==30021==    by 0x14BD00: SC_SequencedCommand::CallNextStage() (SC_SequencedCommand.cpp:193)
==30021==    by 0x1342A0: Perform (SC_FifoMsg.h:47)
==30021==    by 0x1342A0: Perform (MsgFifo.h:62)
==30021==    by 0x1342A0: SC_AudioDriver::RunThread() (SC_CoreAudio.cpp:375)
==30021==    by 0x4C80DB3: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.33)
==30021==    by 0x4FC5A93: start_thread (pthread_create.c:447)
==30021==    by 0x5052A33: clone (clone.S:100)
==30021== 
==30021== Conditional jump or move depends on uninitialised value(s)
==30021==    at 0x484F238: strlen (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==30021==    by 0x48D4550: ??? (in /usr/lib/x86_64-linux-gnu/libsndfile.so.1.0.37)
==30021==    by 0x488FA1C: ??? (in /usr/lib/x86_64-linux-gnu/libsndfile.so.1.0.37)
==30021==    by 0x487C785: ??? (in /usr/lib/x86_64-linux-gnu/libsndfile.so.1.0.37)
==30021==    by 0x487ED1B: ??? (in /usr/lib/x86_64-linux-gnu/libsndfile.so.1.0.37)
==30021==    by 0x147845: sndfileOpen (SC_SndFileHelpers.hpp:194)
==30021==    by 0x147845: sndfileOpenFromCStr (SC_SndFileHelpers.hpp:198)
==30021==    by 0x147845: BufAllocReadCmd::Stage2() (SC_SequencedCommand.cpp:489)
==30021==    by 0x14BD00: SC_SequencedCommand::CallNextStage() (SC_SequencedCommand.cpp:193)
==30021==    by 0x1342A0: Perform (SC_FifoMsg.h:47)
==30021==    by 0x1342A0: Perform (MsgFifo.h:62)
==30021==    by 0x1342A0: SC_AudioDriver::RunThread() (SC_CoreAudio.cpp:375)
==30021==    by 0x4C80DB3: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.33)
==30021==    by 0x4FC5A93: start_thread (pthread_create.c:447)
==30021==    by 0x5052A33: clone (clone.S:100)
==30021== 
==30021== Conditional jump or move depends on uninitialised value(s)
==30021==    at 0x484F238: strlen (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==30021==    by 0x48D4617: ??? (in /usr/lib/x86_64-linux-gnu/libsndfile.so.1.0.37)
==30021==    by 0x488FA1C: ??? (in /usr/lib/x86_64-linux-gnu/libsndfile.so.1.0.37)
==30021==    by 0x487C785: ??? (in /usr/lib/x86_64-linux-gnu/libsndfile.so.1.0.37)
==30021==    by 0x487ED1B: ??? (in /usr/lib/x86_64-linux-gnu/libsndfile.so.1.0.37)
==30021==    by 0x147845: sndfileOpen (SC_SndFileHelpers.hpp:194)
==30021==    by 0x147845: sndfileOpenFromCStr (SC_SndFileHelpers.hpp:198)
==30021==    by 0x147845: BufAllocReadCmd::Stage2() (SC_SequencedCommand.cpp:489)
==30021==    by 0x14BD00: SC_SequencedCommand::CallNextStage() (SC_SequencedCommand.cpp:193)
==30021==    by 0x1342A0: Perform (SC_FifoMsg.h:47)
==30021==    by 0x1342A0: Perform (MsgFifo.h:62)
==30021==    by 0x1342A0: SC_AudioDriver::RunThread() (SC_CoreAudio.cpp:375)
==30021==    by 0x4C80DB3: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.33)
==30021==    by 0x4FC5A93: start_thread (pthread_create.c:447)
==30021==    by 0x5052A33: clone (clone.S:100)
==30021== 

[kesey]

if I try to load few samples in Buffers (61 samples), I get this from valgrind:

valgrind --leak-check=yes scsynth -u 57110 -a 1024 -i 2 -o 2 -b 262144 -n 32768 -d 4096 -m 2097152 -w 512 -R 0 -C 1 -l 1
==30521== Memcheck, a memory error detector
==30521== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==30521== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==30521== Command: scsynth -u 57110 -a 1024 -i 2 -o 2 -b 262144 -n 32768 -d 4096 -m 2097152 -w 512 -R 0 -C 1 -l 1
==30521== 
no more csLADSPA plugins
Found 237 LADSPA plugins
==30521== Warning: set address range perms: large range [0x59c93040, 0xd9c930e0) (undefined)
JackDriver: client name is 'SuperCollider'
SC_AudioDriver: sample rate = 44100.000000, driver's block size = 512
SuperCollider 3 server ready.
==30521== Warning: set address range perms: large range [0x2b056080, 0x3b976b00) (undefined)
==30521== Warning: set address range perms: large range [0xe012e080, 0x101a46b60) (undefined)
==30521== Warning: set address range perms: large range [0x11ff1a040, 0x13083aac0) (undefined)
==30521== Warning: set address range perms: large range [0x11ff1a028, 0x13083aad8) (noaccess)
==30521== Warning: set address range perms: large range [0x12e514080, 0x13f1a05f0) (undefined)
==30521== Warning: set address range perms: large range [0x13f1a1040, 0x160ab9b20) (undefined)
==30521== Warning: set address range perms: large range [0x13f1a1028, 0x160ab9b38) (noaccess)

[kesey]

and if I try to run this chunk of code from the FluidDataSet help file examples (Flucoma):

// Using routine
(
fork{
    var point = Buffer.alloc(s,1);
    var ds = FluidDataSet(s);
    s.sync;
    10.do{
        arg i;
        point.set(0,i);
        ds.addPoint("point-%".format(i),point);
        s.sync;
    };
    ds.print;
};
)

I get this from valgrind:

valgrind --leak-check=yes scsynth -u 57110 -a 1024 -i 2 -o 2 -b 262144 -n 32768 -d 4096 -m 2097152 -w 512 -R 0 -C 1 -l 1
==30959== Memcheck, a memory error detector
==30959== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==30959== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==30959== Command: scsynth -u 57110 -a 1024 -i 2 -o 2 -b 262144 -n 32768 -d 4096 -m 2097152 -w 512 -R 0 -C 1 -l 1
==30959== 
no more csLADSPA plugins
Found 237 LADSPA plugins
==30959== Warning: set address range perms: large range [0x59c93040, 0xd9c930e0) (undefined)
JackDriver: client name is 'SuperCollider'
SC_AudioDriver: sample rate = 44100.000000, driver's block size = 512
SuperCollider 3 server ready.
==30959== Thread 7:
==30959== Invalid read of size 8
==30959==    at 0x16B32318: fluid::client::copyReplyAddress(void*) (in /home/fabien/.local/share/SuperCollider/Extensions/Ext_Classes/FluidCorpusManipulation/Plugins/FluidManipulation.so)
==30959==    by 0x16A2AA02: fluid::client::impl::NonRealTime<fluid::client::NRTThreadingAdaptor<fluid::client::NRTSharedInstanceAdaptor<fluid::client::dataset::DataSetClient> >, fluid::client::FluidSCWrapper<fluid::client::NRTThreadingAdaptor<fluid::client::NRTSharedInstanceAdaptor<fluid::client::dataset::DataSetClient> > > >::defineNRTCommand<fluid::client::impl::NonRealTime<fluid::client::NRTThreadingAdaptor<fluid::client::NRTSharedInstanceAdaptor<fluid::client::dataset::DataSetClient> >, fluid::client::FluidSCWrapper<fluid::client::NRTThreadingAdaptor<fluid::client::NRTSharedInstanceAdaptor<fluid::client::dataset::DataSetClient> > > >::CommandNew>()::{lambda(World*, void*, sc_msg_iter*, void*)#1}::_FUN(World*, void*, sc_msg_iter*, void*) (in /home/fabien/.local/share/SuperCollider/Extensions/Ext_Classes/FluidCorpusManipulation/Plugins/FluidManipulation.so)
==30959==    by 0x1695607B: fluid::client::impl::NonRealTime<fluid::client::NRTThreadingAdaptor<fluid::client::NRTSharedInstanceAdaptor<fluid::client::dataset::DataSetClient> >, fluid::client::FluidSCWrapper<fluid::client::NRTThreadingAdaptor<fluid::client::NRTSharedInstanceAdaptor<fluid::client::dataset::DataSetClient> > > >::setup(InterfaceTable*, char const*)::{lambda(World*, void*, sc_msg_iter*, void*)#1}::_FUN(World*, void*, sc_msg_iter*, void*) (in /home/fabien/.local/share/SuperCollider/Extensions/Ext_Classes/FluidCorpusManipulation/Plugins/FluidManipulation.so)
==30959==    by 0x1578A1: PlugIn_DoCmd(World*, int, char*, ReplyAddress*) (SC_UnitDef.cpp:159)
==30959==    by 0x13A440: SC_LibCmd::Perform(World*, int, char*, ReplyAddress*) (SC_Lib.cpp:188)
==30959==    by 0x13491B: PerformOSCPacket(World*, OSC_Packet*, void (*)(World*, OSC_Packet*)) (SC_CoreAudio.cpp:249)
==30959==    by 0x1349A0: Perform_ToEngine_Msg(FifoMsg*) (SC_CoreAudio.cpp:287)
==30959==    by 0x16F3C7: Perform (SC_FifoMsg.h:47)
==30959==    by 0x16F3C7: Perform (MsgFifo.h:62)
==30959==    by 0x16F3C7: SC_JackDriver::Run() (SC_Jack.cpp:392)
==30959==    by 0x16FB0F: sc_jack_process_cb(unsigned int, void*) (SC_Jack.cpp:165)
==30959==    by 0x493543E: ??? (in /usr/lib/x86_64-linux-gnu/pipewire-0.3/jack/libjack.so.0.3.1005)
==30959==    by 0x5C6964C: ??? (in /usr/lib/x86_64-linux-gnu/spa-0.2/support/libspa-support.so)
==30959==    by 0x544B7B5: ??? (in /usr/lib/x86_64-linux-gnu/libpipewire-0.3.so.0.1005.0)
==30959==  Address 0x6c6db88 is 0 bytes after a block of size 72 alloc'd
==30959==    at 0x4846828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==30959==    by 0x12FD78: scsynth::SC_UdpInPort::handleReceivedUDP(boost::system::error_code const&, unsigned long) (SC_ComPort.cpp:224)
==30959==    by 0x12E9DA: operator()<scsynth::SC_UdpInPort*&> (mem_fn.hpp:74)
==30959==    by 0x12E9DA: call_impl<boost::_mfi::mf<void (scsynth::SC_UdpInPort::*)(const boost::system::error_code&, long unsigned int), void, scsynth::SC_UdpInPort, const boost::system::error_code&, long unsigned int>, boost::_bi::rrlist<const boost::system::error_code&, long unsigned int const&>, 0, 1, 2> (bind.hpp:192)
==30959==    by 0x12E9DA: operator()<void, boost::_mfi::mf<void (scsynth::SC_UdpInPort::*)(const boost::system::error_code&, long unsigned int), void, scsynth::SC_UdpInPort, const boost::system::error_code&, long unsigned int>, boost::_bi::rrlist<const boost::system::error_code&, long unsigned int const&> > (bind.hpp:208)
==30959==    by 0x12E9DA: operator()<const boost::system::error_code&, long unsigned int const&> (bind.hpp:321)
==30959==    by 0x12E9DA: operator() (bind_handler.hpp:181)
==30959==    by 0x12E9DA: complete<boost::asio::detail::binder2<boost::_bi::bind_t<boost::_bi::unspecified, boost::_mfi::mf<void (scsynth::SC_UdpInPort::*)(const boost::system::error_code&, long unsigned int), void, scsynth::SC_UdpInPort, const boost::system::error_code&, long unsigned int>, boost::_bi::list<boost::_bi::value<scsynth::SC_UdpInPort*>, boost::arg<1>, boost::arg<2> > >, boost::system::error_code, long unsigned int> > (handler_work.hpp:470)
==30959==    by 0x12E9DA: boost::asio::detail::reactive_socket_recvfrom_op<boost::asio::mutable_buffers_1, boost::asio::ip::basic_endpoint<boost::asio::ip::udp>, boost::_bi::bind_t<boost::_bi::unspecified, boost::_mfi::mf<void (scsynth::SC_UdpInPort::*)(boost::system::error_code const&, unsigned long), void, scsynth::SC_UdpInPort, boost::system::error_code const&, unsigned long>, boost::_bi::list<boost::_bi::value<scsynth::SC_UdpInPort*>, boost::arg<1>, boost::arg<2> > >, boost::asio::any_io_executor>::do_complete(void*, boost::asio::detail::scheduler_operation*, boost::system::error_code const&, unsigned long) (reactive_socket_recvfrom_op.hpp:156)
==30959==    by 0x129EF6: complete (scheduler_operation.hpp:40)
==30959==    by 0x129EF6: boost::asio::detail::scheduler::do_run_one(boost::asio::detail::conditionally_enabled_mutex::scoped_lock&, boost::asio::detail::scheduler_thread_info&, boost::system::error_code const&) (scheduler.ipp:493)
==30959==    by 0x121630: boost::asio::detail::scheduler::run(boost::system::error_code&) [clone .isra.0] (scheduler.ipp:210)
==30959==    by 0x121921: run (io_context.ipp:64)
==30959==    by 0x121921: scsynth::asioFunction() (SC_ComPort.cpp:453)
==30959==    by 0x4C80DB3: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.33)
==30959==    by 0x4FC5A93: start_thread (pthread_create.c:447)
==30959==    by 0x5052A33: clone (clone.S:100)
==30959== 
==30959== Thread 4:
==30959== Use of uninitialised value of size 8
==30959==    at 0x6DBE9D2: ???
==30959==    by 0x656E2F7465536173: ???
==30959==    by 0x69692C00000076: ???
==30959==    by 0xE6E38736: ???
==30959== 
==30959== Invalid read of size 4
==30959==    at 0x6DBE9F1: ???
==30959==    by 0x656E2F7465536173: ???
==30959==    by 0x69692C00000076: ???
==30959==    by 0xE6E38736: ???
==30959==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==30959== 
==30959== 
==30959== Process terminating with default action of signal 11 (SIGSEGV)
==30959==  Access not within mapped region at address 0x0
==30959==    at 0x6DBE9F1: ???
==30959==    by 0x656E2F7465536173: ???
==30959==    by 0x69692C00000076: ???
==30959==    by 0xE6E38736: ???
==30959==  If you believe this happened as a result of a stack
==30959==  overflow in your program's main thread (unlikely but
==30959==  possible), you can try to increase the size of the
==30959==  main thread stack using the --main-stacksize= flag.
==30959==  The main thread stack size used in this run was 8388608.
==30959== 
==30959== HEAP SUMMARY:
==30959==     in use at exit: 2,192,261,793 bytes in 58,852 blocks
==30959==   total heap usage: 357,370 allocs, 298,518 frees, 2,275,091,014 bytes allocated
==30959== 
==30959== Thread 1:
==30959== 64 bytes in 1 blocks are possibly lost in loss record 3,002 of 4,921
==30959==    at 0x484D953: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==30959==    by 0xCC6E3E1: ??? (in /usr/lib/x86_64-linux-gnu/pipewire-0.3/libpipewire-module-protocol-native.so)
==30959==    by 0xCC57C36: ??? (in /usr/lib/x86_64-linux-gnu/pipewire-0.3/libpipewire-module-protocol-native.so)
==30959==    by 0x544D9A1: ??? (in /usr/lib/x86_64-linux-gnu/libpipewire-0.3.so.0.1005.0)
==30959==    by 0x544DD9F: pw_context_connect (in /usr/lib/x86_64-linux-gnu/libpipewire-0.3.so.0.1005.0)
==30959==    by 0x4937DE7: jack_client_open (in /usr/lib/x86_64-linux-gnu/pipewire-0.3/jack/libjack.so.0.3.1005)
==30959==    by 0x16E7F4: SC_JackDriver::DriverSetup(int*, double*) (SC_Jack.cpp:236)
==30959==    by 0x133C18: SC_AudioDriver::Setup() (SC_CoreAudio.cpp:418)
==30959==    by 0x16096D: World_New (SC_World.cpp:454)
==30959==    by 0x11F81F: scsynth_main(int, char**) (scsynth_main.cpp:417)
==30959==    by 0x4F531C9: (below main) (libc_start_call_main.h:58)
==30959== 
==30959== 102 bytes in 4 blocks are definitely lost in loss record 4,126 of 4,921
==30959==    at 0x4846828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==30959==    by 0xA766A38: LADSPAPluginSearch (in /usr/local/lib/SuperCollider/plugins/LadspaUGen.so)
==30959==    by 0xA76676F: load (in /usr/local/lib/SuperCollider/plugins/LadspaUGen.so)
==30959==    by 0x1367BC: PlugIn_Load (SC_Lib_Cintf.cpp:372)
==30959==    by 0x1367BC: PlugIn_LoadDir(std::filesystem::__cxx11::path const&, bool) [clone .isra.0] (SC_Lib_Cintf.cpp:405)
==30959==    by 0x1374E2: initialize_library(char const*) (SC_Lib_Cintf.cpp:195)
==30959==    by 0x15FD9B: World_New (SC_World.cpp:319)
==30959==    by 0x11F81F: scsynth_main(int, char**) (scsynth_main.cpp:417)
==30959==    by 0x4F531C9: (below main) (libc_start_call_main.h:58)
==30959== 
==30959== 144 bytes in 2 blocks are possibly lost in loss record 4,254 of 4,921
==30959==    at 0x484D953: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==30959==    by 0x546B827: pw_memblock_map (in /usr/lib/x86_64-linux-gnu/libpipewire-0.3.so.0.1005.0)
==30959==    by 0x49292AD: ??? (in /usr/lib/x86_64-linux-gnu/pipewire-0.3/jack/libjack.so.0.3.1005)
==30959==    by 0xCD78B05: ??? (in /usr/lib/x86_64-linux-gnu/pipewire-0.3/libpipewire-module-client-node.so)
==30959==    by 0xCC56EE0: ??? (in /usr/lib/x86_64-linux-gnu/pipewire-0.3/libpipewire-module-protocol-native.so)
==30959==    by 0xCC576C7: ??? (in /usr/lib/x86_64-linux-gnu/pipewire-0.3/libpipewire-module-protocol-native.so)
==30959==    by 0x5C67D15: ??? (in /usr/lib/x86_64-linux-gnu/spa-0.2/support/libspa-support.so)
==30959==    by 0x5497C66: ??? (in /usr/lib/x86_64-linux-gnu/libpipewire-0.3.so.0.1005.0)
==30959==    by 0x4FC5A93: start_thread (pthread_create.c:447)
==30959==    by 0x5052A33: clone (clone.S:100)
==30959== 
==30959== 352 bytes in 1 blocks are possibly lost in loss record 4,584 of 4,921
==30959==    at 0x484D953: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==30959==    by 0x40145AB: calloc (rtld-malloc.h:44)
==30959==    by 0x40145AB: allocate_dtv (dl-tls.c:370)
==30959==    by 0x40145AB: _dl_allocate_tls (dl-tls.c:629)
==30959==    by 0x4FC6606: allocate_stack (allocatestack.c:429)
==30959==    by 0x4FC6606: pthread_create@@GLIBC_2.34 (pthread_create.c:655)
==30959==    by 0x4C80EB0: std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> >, void (*)()) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.33)
==30959==    by 0x8B8F0C0: thread<std::_Bind<void ((anonymous namespace)::DiskIOThread::*((anonymous namespace)::DiskIOThread*))()> > (std_thread.h:164)
==30959==    by 0x8B8F0C0: launchThread (DiskIO_UGens.cpp:173)
==30959==    by 0x8B8F0C0: load (DiskIO_UGens.cpp:634)
==30959==    by 0x1367BC: PlugIn_Load (SC_Lib_Cintf.cpp:372)
==30959==    by 0x1367BC: PlugIn_LoadDir(std::filesystem::__cxx11::path const&, bool) [clone .isra.0] (SC_Lib_Cintf.cpp:405)
==30959==    by 0x1374E2: initialize_library(char const*) (SC_Lib_Cintf.cpp:195)
==30959==    by 0x15FD9B: World_New (SC_World.cpp:319)
==30959==    by 0x11F81F: scsynth_main(int, char**) (scsynth_main.cpp:417)
==30959==    by 0x4F531C9: (below main) (libc_start_call_main.h:58)
==30959== 
==30959== 352 bytes in 1 blocks are possibly lost in loss record 4,585 of 4,921
==30959==    at 0x484D953: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==30959==    by 0x40145AB: calloc (rtld-malloc.h:44)
==30959==    by 0x40145AB: allocate_dtv (dl-tls.c:370)
==30959==    by 0x40145AB: _dl_allocate_tls (dl-tls.c:629)
==30959==    by 0x4FC6606: allocate_stack (allocatestack.c:429)
==30959==    by 0x4FC6606: pthread_create@@GLIBC_2.34 (pthread_create.c:655)
==30959==    by 0x4C80EB0: std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> >, void (*)()) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.33)
==30959==    by 0x8CD7C61: thread<void (&)()> (std_thread.h:164)
==30959==    by 0x8CD7C61: load (UIUGens.cpp:268)
==30959==    by 0x1367BC: PlugIn_Load (SC_Lib_Cintf.cpp:372)
==30959==    by 0x1367BC: PlugIn_LoadDir(std::filesystem::__cxx11::path const&, bool) [clone .isra.0] (SC_Lib_Cintf.cpp:405)
==30959==    by 0x1374E2: initialize_library(char const*) (SC_Lib_Cintf.cpp:195)
==30959==    by 0x15FD9B: World_New (SC_World.cpp:319)
==30959==    by 0x11F81F: scsynth_main(int, char**) (scsynth_main.cpp:417)
==30959==    by 0x4F531C9: (below main) (libc_start_call_main.h:58)
==30959== 
==30959== 880 bytes in 1 blocks are possibly lost in loss record 4,724 of 4,921
==30959==    at 0x484D953: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==30959==    by 0x40145AB: calloc (rtld-malloc.h:44)
==30959==    by 0x40145AB: allocate_dtv (dl-tls.c:370)
==30959==    by 0x40145AB: _dl_allocate_tls (dl-tls.c:629)
==30959==    by 0x4FC6606: allocate_stack (allocatestack.c:429)
==30959==    by 0x4FC6606: pthread_create@@GLIBC_2.34 (pthread_create.c:655)
==30959==    by 0x4C80EB0: std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> >, void (*)()) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.33)
==30959==    by 0x133BD5: thread<std::_Bind<void (SC_AudioDriver::*(SC_AudioDriver*))()> > (std_thread.h:164)
==30959==    by 0x133BD5: SC_AudioDriver::Setup() (SC_CoreAudio.cpp:412)
==30959==    by 0x16096D: World_New (SC_World.cpp:454)
==30959==    by 0x11F81F: scsynth_main(int, char**) (scsynth_main.cpp:417)
==30959==    by 0x4F531C9: (below main) (libc_start_call_main.h:58)
==30959== 
==30959== 896 bytes in 1 blocks are possibly lost in loss record 4,725 of 4,921
==30959==    at 0x484D953: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==30959==    by 0x40145AB: calloc (rtld-malloc.h:44)
==30959==    by 0x40145AB: allocate_dtv (dl-tls.c:370)
==30959==    by 0x40145AB: _dl_allocate_tls (dl-tls.c:629)
==30959==    by 0x4FC6606: allocate_stack (allocatestack.c:429)
==30959==    by 0x4FC6606: pthread_create@@GLIBC_2.34 (pthread_create.c:655)
==30959==    by 0x548F23D: ??? (in /usr/lib/x86_64-linux-gnu/libpipewire-0.3.so.0.1005.0)
==30959==    by 0xC5F8878: ??? (in /usr/lib/x86_64-linux-gnu/pipewire-0.3/libpipewire-module-rt.so)
==30959==    by 0x544E289: pw_data_loop_start (in /usr/lib/x86_64-linux-gnu/libpipewire-0.3.so.0.1005.0)
==30959==    by 0x54500F5: pw_context_new (in /usr/lib/x86_64-linux-gnu/libpipewire-0.3.so.0.1005.0)
==30959==    by 0x4937B12: jack_client_open (in /usr/lib/x86_64-linux-gnu/pipewire-0.3/jack/libjack.so.0.3.1005)
==30959==    by 0x16E7F4: SC_JackDriver::DriverSetup(int*, double*) (SC_Jack.cpp:236)
==30959==    by 0x133C18: SC_AudioDriver::Setup() (SC_CoreAudio.cpp:418)
==30959==    by 0x16096D: World_New (SC_World.cpp:454)
==30959==    by 0x11F81F: scsynth_main(int, char**) (scsynth_main.cpp:417)
==30959== 
==30959== 896 bytes in 1 blocks are possibly lost in loss record 4,726 of 4,921
==30959==    at 0x484D953: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==30959==    by 0x40145AB: calloc (rtld-malloc.h:44)
==30959==    by 0x40145AB: allocate_dtv (dl-tls.c:370)
==30959==    by 0x40145AB: _dl_allocate_tls (dl-tls.c:629)
==30959==    by 0x4FC6606: allocate_stack (allocatestack.c:429)
==30959==    by 0x4FC6606: pthread_create@@GLIBC_2.34 (pthread_create.c:655)
==30959==    by 0x548F23D: ??? (in /usr/lib/x86_64-linux-gnu/libpipewire-0.3.so.0.1005.0)
==30959==    by 0x54988AD: pw_thread_loop_start (in /usr/lib/x86_64-linux-gnu/libpipewire-0.3.so.0.1005.0)
==30959==    by 0x4938868: jack_client_open (in /usr/lib/x86_64-linux-gnu/pipewire-0.3/jack/libjack.so.0.3.1005)
==30959==    by 0x16E7F4: SC_JackDriver::DriverSetup(int*, double*) (SC_Jack.cpp:236)
==30959==    by 0x133C18: SC_AudioDriver::Setup() (SC_CoreAudio.cpp:418)
==30959==    by 0x16096D: World_New (SC_World.cpp:454)
==30959==    by 0x11F81F: scsynth_main(int, char**) (scsynth_main.cpp:417)
==30959==    by 0x4F531C9: (below main) (libc_start_call_main.h:58)
==30959== 
==30959== 896 bytes in 1 blocks are possibly lost in loss record 4,727 of 4,921
==30959==    at 0x484D953: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==30959==    by 0x40145AB: calloc (rtld-malloc.h:44)
==30959==    by 0x40145AB: allocate_dtv (dl-tls.c:370)
==30959==    by 0x40145AB: _dl_allocate_tls (dl-tls.c:629)
==30959==    by 0x4FC6606: allocate_stack (allocatestack.c:429)
==30959==    by 0x4FC6606: pthread_create@@GLIBC_2.34 (pthread_create.c:655)
==30959==    by 0x548F23D: ??? (in /usr/lib/x86_64-linux-gnu/libpipewire-0.3.so.0.1005.0)
==30959==    by 0xC5F8878: ??? (in /usr/lib/x86_64-linux-gnu/pipewire-0.3/libpipewire-module-rt.so)
==30959==    by 0x544E289: pw_data_loop_start (in /usr/lib/x86_64-linux-gnu/libpipewire-0.3.so.0.1005.0)
==30959==    by 0x4936D06: jack_activate (in /usr/lib/x86_64-linux-gnu/pipewire-0.3/jack/libjack.so.0.3.1005)
==30959==    by 0x16EDA8: SC_JackDriver::DriverStart() (SC_Jack.cpp:320)
==30959==    by 0x16097F: World_New (SC_World.cpp:458)
==30959==    by 0x11F81F: scsynth_main(int, char**) (scsynth_main.cpp:417)
==30959==    by 0x4F531C9: (below main) (libc_start_call_main.h:58)
==30959== 
==30959== 896 bytes in 1 blocks are possibly lost in loss record 4,728 of 4,921
==30959==    at 0x484D953: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==30959==    by 0x40145AB: calloc (rtld-malloc.h:44)
==30959==    by 0x40145AB: allocate_dtv (dl-tls.c:370)
==30959==    by 0x40145AB: _dl_allocate_tls (dl-tls.c:629)
==30959==    by 0x4FC6606: allocate_stack (allocatestack.c:429)
==30959==    by 0x4FC6606: pthread_create@@GLIBC_2.34 (pthread_create.c:655)
==30959==    by 0x4C80EB0: std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> >, void (*)()) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.33)
==30959==    by 0x121B6F: thread<void (*)()> (std_thread.h:164)
==30959==    by 0x121B6F: scsynth::startAsioThread() (SC_ComPort.cpp:457)
==30959==    by 0x1609A4: World_New (SC_World.cpp:473)
==30959==    by 0x11F81F: scsynth_main(int, char**) (scsynth_main.cpp:417)
==30959==    by 0x4F531C9: (below main) (libc_start_call_main.h:58)
==30959== 
==30959== 4,096 bytes in 1 blocks are possibly lost in loss record 4,841 of 4,921
==30959==    at 0x484D953: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==30959==    by 0xCC6EDC3: ??? (in /usr/lib/x86_64-linux-gnu/pipewire-0.3/libpipewire-module-protocol-native.so)
==30959==    by 0xCC56F31: ??? (in /usr/lib/x86_64-linux-gnu/pipewire-0.3/libpipewire-module-protocol-native.so)
==30959==    by 0xCC576C7: ??? (in /usr/lib/x86_64-linux-gnu/pipewire-0.3/libpipewire-module-protocol-native.so)
==30959==    by 0x5C67D15: ??? (in /usr/lib/x86_64-linux-gnu/spa-0.2/support/libspa-support.so)
==30959==    by 0x5497C66: ??? (in /usr/lib/x86_64-linux-gnu/libpipewire-0.3.so.0.1005.0)
==30959==    by 0x4FC5A93: start_thread (pthread_create.c:447)
==30959==    by 0x5052A33: clone (clone.S:100)
==30959== 
==30959== 29,344 (312 direct, 29,032 indirect) bytes in 13 blocks are definitely lost in loss record 4,880 of 4,921
==30959==    at 0x484DECC: memalign (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==30959==    by 0x497F3D8: fftwf_malloc_plain (in /usr/lib/x86_64-linux-gnu/libfftw3f.so.3.6.10)
==30959==    by 0x4A733C5: fftwf_mkapiplan (in /usr/lib/x86_64-linux-gnu/libfftw3f.so.3.6.10)
==30959==    by 0x4A7DB26: fftwf_plan_many_dft_r2c (in /usr/lib/x86_64-linux-gnu/libfftw3f.so.3.6.10)
==30959==    by 0x4A7CFE8: fftwf_plan_dft_r2c (in /usr/lib/x86_64-linux-gnu/libfftw3f.so.3.6.10)
==30959==    by 0x4A7CEF6: fftwf_plan_dft_r2c_1d (in /usr/lib/x86_64-linux-gnu/libfftw3f.so.3.6.10)
==30959==    by 0x11E0CC: scfft_global_initialization (SC_fftlib.cpp:209)
==30959==    by 0x11E0CC: __static_initialization_and_destruction_0 (SC_fftlib.cpp:225)
==30959==    by 0x11E0CC: _GLOBAL__sub_I__Z12scfft_createmm20SCFFT_WindowFunctionPfS0_15SCFFT_DirectionR15SCFFT_Allocator (SC_fftlib.cpp:446)
==30959==    by 0x4F53303: call_init (libc-start.c:145)
==30959==    by 0x4F53303: __libc_start_main@@GLIBC_2.34 (libc-start.c:347)
==30959==    by 0x11E794: (below main) (in /usr/local/bin/scsynth)
==30959== 
==30959== 32,896 bytes in 6 blocks are possibly lost in loss record 4,884 of 4,921
==30959==    at 0x4846828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==30959==    by 0x4004EDC: malloc (rtld-malloc.h:56)
==30959==    by 0x4004EDC: _dlfo_mappings_segment_allocate (dl-find_object.c:217)
==30959==    by 0x4004EDC: _dl_find_object_update_1 (dl-find_object.c:671)
==30959==    by 0x4004EDC: _dl_find_object_update (dl-find_object.c:805)
==30959==    by 0x400DC37: dl_open_worker_begin (dl-open.c:756)
==30959==    by 0x400151B: _dl_catch_exception (dl-catch.c:237)
==30959==    by 0x400CD1F: dl_open_worker (dl-open.c:803)
==30959==    by 0x400151B: _dl_catch_exception (dl-catch.c:237)
==30959==    by 0x400D163: _dl_open (dl-open.c:905)
==30959==    by 0x4FC1193: dlopen_doit (dlopen.c:56)
==30959==    by 0x400151B: _dl_catch_exception (dl-catch.c:237)
==30959==    by 0x4001668: _dl_catch_error (dl-catch.c:256)
==30959==    by 0x4FC0C72: _dlerror_run (dlerror.c:138)
==30959==    by 0x4FC124E: dlopen_implementation (dlopen.c:71)
==30959==    by 0x4FC124E: dlopen@@GLIBC_2.34 (dlopen.c:81)
==30959== 
==30959== 39,456 (312 direct, 39,144 indirect) bytes in 13 blocks are definitely lost in loss record 4,889 of 4,921
==30959==    at 0x484DECC: memalign (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==30959==    by 0x497F3D8: fftwf_malloc_plain (in /usr/lib/x86_64-linux-gnu/libfftw3f.so.3.6.10)
==30959==    by 0x4A733C5: fftwf_mkapiplan (in /usr/lib/x86_64-linux-gnu/libfftw3f.so.3.6.10)
==30959==    by 0x4A7D978: fftwf_plan_many_dft_c2r (in /usr/lib/x86_64-linux-gnu/libfftw3f.so.3.6.10)
==30959==    by 0x4A7CEC8: fftwf_plan_dft_c2r (in /usr/lib/x86_64-linux-gnu/libfftw3f.so.3.6.10)
==30959==    by 0x4A7CDD6: fftwf_plan_dft_c2r_1d (in /usr/lib/x86_64-linux-gnu/libfftw3f.so.3.6.10)
==30959==    by 0x11E117: scfft_global_initialization (SC_fftlib.cpp:216)
==30959==    by 0x11E117: __static_initialization_and_destruction_0 (SC_fftlib.cpp:225)
==30959==    by 0x11E117: _GLOBAL__sub_I__Z12scfft_createmm20SCFFT_WindowFunctionPfS0_15SCFFT_DirectionR15SCFFT_Allocator (SC_fftlib.cpp:446)
==30959==    by 0x4F53303: call_init (libc-start.c:145)
==30959==    by 0x4F53303: __libc_start_main@@GLIBC_2.34 (libc-start.c:347)
==30959==    by 0x11E794: (below main) (in /usr/local/bin/scsynth)
==30959== 
==30959== LEAK SUMMARY:
==30959==    definitely lost: 726 bytes in 30 blocks
==30959==    indirectly lost: 68,176 bytes in 534 blocks
==30959==      possibly lost: 42,368 bytes in 17 blocks
==30959==    still reachable: 2,192,150,523 bytes in 58,271 blocks
==30959==         suppressed: 0 bytes in 0 blocks
==30959== Reachable blocks (those to which a pointer was found) are not shown.
==30959== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==30959== 
==30959== Use --track-origins=yes to see where uninitialised values come from
==30959== For lists of detected and suppressed errors, rerun with: -s
==30959== ERROR SUMMARY: 17 errors from 17 contexts (suppressed: 0 from 0)
Erreur de segmentation (core dumped)

This one is huge,
I don´t know if I have to open another thread for this one cause I don´t know how to interpret the output of valgrind.
Maybe the title of this thread is wrong too, because my problem doesn´t seem to be SuperDirt specific after all.

Any help is very much appreciated.

[dscheiba]

@kesey

and if I try to run this chunk of code from the FluidDataSet help file examples (Flucoma):

I assume you are using a current develop build - we had to update a dependency (boost) which broke support with Flucoma, but there will be a future Flucoma release which will fix this. For further information see Bug: FluidDataSet results in server crash on Linux · Issue #174 · flucoma/flucoma-sc · GitHub

[jamshark70]

@kesey

reinstall and start SuperCollider, boot the server, run s.pid, get 18846 and finally run sudo gdb -p 18846 in a terminal.
This is what I get from the terminal:

After scsynth crashes, what is the result in gdb of the where command?

hjh

[kesey]

@dscheiba

I assume you are using a current develop build

I build SuperCollider following the steps descibe here:

supercollider/supercollider/blob/develop/README_LINUX.md

I run cmake with these flags:
cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -DNATIVE=ON -DSC_EL=OFF ..

When I start SuperCollider I can see: SuperCollider 3.14.0-dev in the help browser.
So I think I 'm using a current develop build.

On Flucoma side, I use the latest release 1.0.7.

I’m happy to know that a future Flucoma release will fix this but for the moment is there a workaround, that allow me to use Flucoma in SuperCollider ?
Can I build another version of SuperCollder ? maybe I can build a version with an older version of boost ?

Something is really confusing for me in the link you share with me:

Bug: FluidDataSet results in server crash on Linux

I can read:
“i’ve found a workaround - compiling the latest SuperCollider 3.14.0-dev from source fixes the issue, and works fine with 1.0.2 and 1.0.7 - so it sounds like it could be an issue with the SC 3.13 ubuntu package rather than flucoma”

Is this not contradictory with your explanations ?

[kesey]

Can you explain what is the where command in gdb and how to use it ?

[jamshark70]

@kesey

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x000071a5b3298d61 in __futex_abstimed_wait_common64 (private=<optimized out>, 
    cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x5ed145398950)
    at ./nptl/futex-internal.c:57

warning: 57	./nptl/futex-internal.c: Aucun fichier ou dossier de ce nom

^^ that’s an indication of something going wrong.

(gdb) 

And this is the gdb command prompt.

So the way that you use the where command is, at the gdb command prompt, you type where and hit return.

hjh

[smoge]

@kesey

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x000071a5b3298d61 in __futex_abstimed_wait_common64 (private=<optimized out>, 
    cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x5ed145398950)
    at ./nptl/futex-internal.c:57

warning: 57	./nptl/futex-internal.c: Aucun fichier ou dossier de ce nom

Also, to debug, use the bc command. That’s also very important.

Type this:

>bc

Pieces of information:

→ Indicates sc hangs while waiting for thread synchronization // thread blocked
→ Maybe sc is deadlocked while waiting for thread synchronization (possibly a side-effect of loading a high number of buffers)

In other words, one semaphore freezes the main process, and it doesn’t even manage to shut down.

→ Memory leaks:

• Thread-local storage: SEVERA blocks from pthread creation everywhere
• LADSPA plugin: bytes/plugin search
• FFTW lib:
• JACK

Nothing bombastic I think

Let’s wait for the debug and for the one who really understands those things: Low-Level Ninja @Spacechild1

[dscheiba]

@kesey

I’m happy to know that a future Flucoma release will fix this but for the moment is there a workaround, that allow me to use Flucoma in SuperCollider ?

I haven’t read the whole thread, but if 3.13.0 is still an option for you, this would still work with flucoma.

The current problem is caused by the fact that flucoma used some internals of scsynth which we had to update (the boost library), so these things are not where/how they were when flucoma uploaded their latest release of flucoma, which is now resulting in a crash.

In order to avoid this crash you need to use a SuperCollider build prior to the boost upgrade (e.g. 3.13.0) or build Flucoma-SC yourself using the current development version of SuperCollider (haven’t tried, only guessing here).

[smoge]

I mean, scsynth kind of could try to be robust even for this case.

Or include a warning about this operation in the documentation. And have a sense of a “safe zone”?

[kesey]

Hello, thank you for your answer.

the result in gdb after running the where command:

sudo gdb -p 8525
[sudo] Mot de passe de fabien : 
GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 8525
[New LWP 8534]
[New LWP 8533]
[New LWP 8532]
[New LWP 8531]
[New LWP 8529]
[New LWP 8528]
[New LWP 8527]

warning: could not find '.gnu_debugaltlink' file for /usr/lib/x86_64-linux-gnu/pipewire-0.3/jack/libjack.so.0

warning: could not find '.gnu_debugaltlink' file for /lib/x86_64-linux-gnu/libcap.so.2

warning: could not find '.gnu_debugaltlink' file for /usr/lib/x86_64-linux-gnu/spa-0.2/support/libspa-support.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/x86_64-linux-gnu/spa-0.2/support/libspa-journal.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_eqbw.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/delay.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/ZamAutoSat-ladspa.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_reflector.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/ZamComp-ladspa.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/mvclpf24.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_chorusflanger.so

warning: could not find '.gnu_debugaltlink' file for /lib/x86_64-linux-gnu/libcsound64.so.6.0

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/ZamDynamicEQ-ladspa.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/ZamGEQ31-ladspa.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_autopan.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_dynamics_m.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_eq.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/ZamTube-ladspa.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/ZamGateX2-ladspa.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/amp.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/ZamGrains-ladspa.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/cs_chorus.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_dynamics_st.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/filter.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/ZaMultiCompX2-ladspa.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_limiter.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/ZamEQ2-ladspa.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/sine.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/ZamGate-ladspa.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_pinknoise.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/cs_phaser.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_reverb.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_tremolo.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/ZamCompX2-ladspa.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_tubewarmth.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/mvchpf24.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_doubler.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/ZamDelay-ladspa.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/noise.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_sigmoid.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_vibrato.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_deesser.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_rotspeak.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_echo.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/tap_pitch.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/ladspa/ZaMaximX2-ladspa.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/x86_64-linux-gnu/spa-0.2/support/libspa-dbus.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/x86_64-linux-gnu/pipewire-0.3/libpipewire-module-rt.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/x86_64-linux-gnu/pipewire-0.3/libpipewire-module-protocol-native.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/x86_64-linux-gnu/pipewire-0.3/libpipewire-module-client-node.so

warning: could not find '.gnu_debugaltlink' file for /usr/lib/x86_64-linux-gnu/pipewire-0.3/libpipewire-module-metadata.so
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007f91c2498d61 in __futex_abstimed_wait_common64 (private=<optimized out>, 
    cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x57a3f4b2d950)
    at ./nptl/futex-internal.c:57

warning: 57	./nptl/futex-internal.c: Aucun fichier ou dossier de ce nom
(gdb) where
#0  0x00007f91c2498d61 in __futex_abstimed_wait_common64 (
    private=<optimized out>, cancel=true, abstime=0x0, op=393, expected=0, 
    futex_word=0x57a3f4b2d950) at ./nptl/futex-internal.c:57
#1  __futex_abstimed_wait_common (cancel=true, private=<optimized out>, 
    abstime=0x0, clockid=0, expected=0, futex_word=0x57a3f4b2d950)
    at ./nptl/futex-internal.c:87
#2  __GI___futex_abstimed_wait_cancelable64 (
    futex_word=futex_word@entry=0x57a3f4b2d950, expected=expected@entry=0, 
    clockid=clockid@entry=0, abstime=abstime@entry=0x0, 
    private=<optimized out>) at ./nptl/futex-internal.c:139
#3  0x00007f91c24a4f0f in do_futex_wait (sem=sem@entry=0x57a3f4b2d950, 
    abstime=0x0, clockid=0) at ./nptl/sem_waitcommon.c:111
#4  0x00007f91c24a4fa8 in __new_sem_wait_slow64 (sem=0x57a3f4b2d950, 
    abstime=0x0, clockid=0) at ./nptl/sem_waitcommon.c:183
#5  0x000057a3f31d8d0f in boost::sync::linux_::semaphore::wait (
    this=0x57a3f4b2d950)
    at /home/fabien/Logiciels_Son/SuperCollider/external_libraries/boost_sync/include/boost/sync/detail/semaphore/semaphore_posix.hpp:83
#6  World_WaitForQuit (inWorld=0x57a3f4d025c0, unload_plugins=true)
    at /home/fabien/Logiciels_Son/SuperCollider/server/scsynth/SC_World.cpp:765
#7  0x000057a3f31988df in operator() (__closure=0x7ffcb1bfd560)
    at /home/fabien/Logiciels_Son/SuperCollider/server/scsynth/scsynth_main.cpp:460
--Type <RET> for more, q to quit, c to continue without paging--

if I type RET, I have this:

--Type <RET> for more, q to quit, c to continue without paging--
#8  std::__invoke_impl<void, scsynth_main(int, char**)::<lambda()>&> (__f=...)
    at /usr/include/c++/13/bits/invoke.h:61
#9  std::__invoke_r<void, scsynth_main(int, char**)::<lambda()>&> (__fn=...)
    at /usr/include/c++/13/bits/invoke.h:111
#10 std::_Function_handler<void(), scsynth_main(int, char**)::<lambda()> >::_M_invoke (__functor=...) at /usr/include/c++/13/bits/std_function.h:290
#11 std::function<void ()>::operator()() const (this=0x7ffcb1bfd560)
    at /usr/include/c++/13/bits/std_function.h:591
#12 EventLoop::run(std::function<void ()>) (waitFunction=...)
    at /home/fabien/Logiciels_Son/SuperCollider/common/SC_EventLoop.hpp:38
#13 scsynth_main (argc=25, argv=<optimized out>)
    at /home/fabien/Logiciels_Son/SuperCollider/server/scsynth/scsynth_main.cpp:460
#14 0x00007f91c242a1ca in __libc_start_call_main (
    main=main@entry=0x57a3f3196240 <main(int, char**)>, argc=argc@entry=25, 
    argv=argv@entry=0x7ffcb1bfd858)
    at ../sysdeps/nptl/libc_start_call_main.h:58
#15 0x00007f91c242a28b in __libc_start_main_impl (
    main=0x57a3f3196240 <main(int, char**)>, argc=25, argv=0x7ffcb1bfd858, 
    init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, 
    stack_end=0x7ffcb1bfd848) at ../csu/libc-start.c:360
#16 0x000057a3f3197795 in _start ()
(gdb) 

[kesey]

Thank you for your answer.

Where do I type ?

>bc

I try to type it in gbd, but I got this:

(gdb) bc
Undefined command: "bc".  Try "help".

[smoge]

@kesey

Where do I type ?

Oh, that’s gdb command for backtrace. TYPO: it’s bt