You are right,

it is not pipewire-jack, it is also without pipewire...

will try the dev and report

see,

::

gdb pd ... (gdb) run -jack -channels 16 Starting program: /usr/bin/pd -jack -channels 16 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Detaching after fork from child process 3779] [Detaching after fork from child process 3782] [New Thread 0x7ffff6bfc6c0 (LWP 3783)] [New Thread 0x7ffff6a0f6c0 (LWP 3784)] [New Thread 0x7ffff698e6c0 (LWP 3785)] double free or corruption (out)

Thread 4 "pd" received signal SIGABRT, Aborted. [Switching to Thread 0x7ffff698e6c0 (LWP 3785)] 0x00007ffff7bd8e3c in ?? () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x00007ffff7bd8e3c in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffff7b89fb2 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007ffff7b74472 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #3 0x00007ffff7bcd430 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #4 0x00007ffff7be27ba in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #5 0x00007ffff7be4820 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #6 0x00007ffff7be6e9f in free () from /lib/x86_64-linux-gnu/libc.so.6 #7 0x000055555567ec3a in ?? () #8 0x00007ffff7d73b5d in ?? () from /lib/x86_64-linux-gnu/libjack.so.0 #9 0x00007ffff7d73828 in ?? () from /lib/x86_64-linux-gnu/libjack.so.0 #10 0x00007ffff7d9006c in ?? () from /lib/x86_64-linux-gnu/libjack.so.0 #11 0x00007ffff7bd7144 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #12 0x00007ffff7c577dc in ?? () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) watchdog: signaling pd... quit A debugging session is active.

Inferior 1 [process 3776] will be killed.

mfG winfried

Zitat von Christof Ressi info@christofressi.com:

Hi,

this sounds very much like https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/thread/HEUGAEWO362B...

It should already be fixed on develop with https://github.com/pure-data/pure-data/pull/2433/commits/6710a3441ff5ec73efe....

Can you verify?

Christof

On 08.10.2024 12:41, Winfried Ritsch wrote:

...

Hello,

Using Debian bookworm backport puredata and pipewire-audio and pipewire-jack backports, it crashes with 16 channels, but not with 15 channel.

To narrow down the problem, before bug issue it, anybody the same or only system specific ?

Here the debug output:

Here the gdb output:

$ pd -version Pd-0.55.1 ("") compiled for Debian (0.55.1+ds-2~bpo12+1) on 2024/09/22 at 20:24:41 UTC

$ gdb pd ...

(gdb) run -jack -channels 16 Starting program: /usr/bin/pd -jack -channels 16

[Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Detaching after fork from child process 55024] [Detaching after fork from child process 55027] [New Thread 0x7ffff74a56c0 (LWP 55028)] [Thread 0x7ffff74a56c0 (LWP 55028) exited] [New Thread 0x7ffff74a56c0 (LWP 55029)] [New Thread 0x7ffff6ca46c0 (LWP 55030)] [New Thread 0x7ffff639f6c0 (LWP 55031)]

double free or corruption (out)

Thread 5 "data-loop.0" received signal SIGABRT, Aborted. [Switching to Thread 0x7ffff639f6c0 (LWP 55031)]

0x00007ffff7be3e3c in ?? () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) watchdog: signaling pd... watchdog: signaling pd... watchdog: signaling pd... bt #0 0x00007ffff7be3e3c in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffff7b94fb2 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007ffff7b7f472 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #3 0x00007ffff7bd8430 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #4 0x00007ffff7bed7ba in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #5 0x00007ffff7bef820 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #6 0x00007ffff7bf1e9f in free () from /lib/x86_64-linux-gnu/libc.so.6 #7 0x000055555567ec3a in ?? () #8 0x00007ffff7d952c7 in ?? () from /usr/lib/x86_64-linux-gnu/pipewire-0.3/jack/libjack.so.0 #9 0x00007ffff7faa44e in ?? () from /usr/lib/x86_64-linux-gnu/spa-0.2/support/libspa-support.so #10 0x00007ffff7a971b0 in ?? () from /lib/x86_64-linux-gnu/libpipewire-0.3.so.0 #11 0x00007ffff7be2144 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #12 0x00007ffff7c627dc in ?? () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) watchdog: signaling pd... watchdog: signaling pd... ...

kernel: 6.1.0-26-amd64

mfg

winfried

--

• ao.Univ.Prof. DI Winfried Ritsch

• ritsch@iem.at - http://iem.at/ritsch

• Institut fuer Elektronische Musik und Akustik,  University of Music and

Dramatic Art Graz

• mobil: ++43-664-2439369 Tel. ++43-316-389-3510 (3170)

---

pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/MXII5RNAW2I...

On 08.10.2024 16:49, Miller Puckette wrote:

This might be serious enough to warrant putting out 0.55-2.

Can we be confident that alloca will always work for any size of temporary allocation that jack might choose to make?  (e.g. 1024 channels at 256 blocksize --> 1 megabyte)?

We don't use plain alloca(), we use the ALLOCA() macro which only allocates on the stack up to a certain limit and then switches to heap allocation. The crash was caused by a duplicate call to FREEA() which would cause a double-free (but only for larger buffer sizes - that would trigger heap allocation).

That being said, I don't think it's a good idea to continously allocate and free large memory blocks in the audio callback.

@IOhannes: why don't we just allocate the buffer on the heap *once* before we start the stream?

Christof

cheers

Miller

On 10/8/24 5:53 AM, Christof Ressi wrote:

...

Hi,

this sounds very much like https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/thread/HEUGAEWO362B...

It should already be fixed on develop with https://github.com/pure-data/pure-data/pull/2433/commits/6710a3441ff5ec73efe....

Can you verify?

Christof

On 08.10.2024 12:41, Winfried Ritsch wrote:

...

Hello,

Using Debian bookworm backport puredata and pipewire-audio and pipewire-jack backports, it crashes with 16 channels, but not with 15 channel.

To narrow down the problem, before bug issue it, anybody the same or only system specific ?

Here the debug output:

Here the gdb output:

$ pd -version Pd-0.55.1 ("") compiled for Debian (0.55.1+ds-2~bpo12+1) on 2024/09/22 at 20:24:41 UTC

$ gdb pd ...

(gdb) run -jack -channels 16 Starting program: /usr/bin/pd -jack -channels 16

[Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Detaching after fork from child process 55024] [Detaching after fork from child process 55027] [New Thread 0x7ffff74a56c0 (LWP 55028)] [Thread 0x7ffff74a56c0 (LWP 55028) exited] [New Thread 0x7ffff74a56c0 (LWP 55029)] [New Thread 0x7ffff6ca46c0 (LWP 55030)] [New Thread 0x7ffff639f6c0 (LWP 55031)]

double free or corruption (out)

Thread 5 "data-loop.0" received signal SIGABRT, Aborted. [Switching to Thread 0x7ffff639f6c0 (LWP 55031)]

0x00007ffff7be3e3c in ?? () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) watchdog: signaling pd... watchdog: signaling pd... watchdog: signaling pd... bt #0 0x00007ffff7be3e3c in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffff7b94fb2 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007ffff7b7f472 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #3 0x00007ffff7bd8430 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #4 0x00007ffff7bed7ba in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #5 0x00007ffff7bef820 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #6 0x00007ffff7bf1e9f in free () from /lib/x86_64-linux-gnu/libc.so.6 #7 0x000055555567ec3a in ?? () #8 0x00007ffff7d952c7 in ?? () from /usr/lib/x86_64-linux-gnu/pipewire-0.3/jack/libjack.so.0 #9 0x00007ffff7faa44e in ?? () from /usr/lib/x86_64-linux-gnu/spa-0.2/support/libspa-support.so #10 0x00007ffff7a971b0 in ?? () from /lib/x86_64-linux-gnu/libpipewire-0.3.so.0 #11 0x00007ffff7be2144 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #12 0x00007ffff7c627dc in ?? () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) watchdog: signaling pd... watchdog: signaling pd... ...

kernel: 6.1.0-26-amd64

mfg

winfried

--

• ao.Univ.Prof. DI Winfried Ritsch

• ritsch@iem.at - http://iem.at/ritsch

• Institut fuer Elektronische Musik und Akustik,  University of

Music and

Dramatic Art Graz

• mobil: ++43-664-2439369 Tel. ++43-316-389-3510 (3170)

--- pd-dev@lists.iem.at  - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/MXII5RNAW2I...

--- pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...

---

pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/YE6VDFROW7R...

but 95b614656cd62214d6779014e5173d8af697814b wasn't me :-)

Sorry :)

why don't we just allocate the buffer on the heap *once* before we start the stream?

So the original code did exactly this... @Miller I think we should go back to the original solution to avoid continuous (de)allocations on the audio callback.

I've noticed that the old code used a hardcoded max. buffer size of 4096 samples (BUF_JACK). Alternatively, we could get the actual buffer size with jack_get_buffer_size() and register a callback with jack_set_buffer_size_callback() to handle buffer size changes.

Christof

On 08.10.2024 23:28, IOhannes m zmölnig wrote:

On 08/10/2024 22:04, Christof Ressi wrote:

...

@IOhannes: why don't we just allocate the buffer on the heap *once* before we start the stream?

no idea. but 95b614656cd62214d6779014e5173d8af697814b wasn't me :-)

gfmdsaf IOhannes

---

pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/RDKQWLSVMMW...

On 09.10.2024 02:30, Miller Puckette wrote:

Well, it's best _if_ the memory can be allocated on stack to do so (better cache behavior).  OTOH, if you're using jack you probably don't care about being as efficient as possible anyhow.

It's not so much about efficiency and more about realtime safety. You really don't want to allocate and free large memory blocks continuously in the audio callback...

OTOH I didn't know that there was ever a version with pre-allocated memory - and yes, it's going to be complicated because of the need to react to changing buffer sizes - I'm not sure it's worth the trouble.

It's not that complicated: allocate before starting the stream and reallocate in the buffer size callback.

An easier, but slightly wasteful, solution would be the original one: just overallocate by using a fixed large buffer size.

In both cases, you could still allocate on the stack up to a certain limit, but I don't really think this is necessary. After all, the audio callback does nothing but transferring samples between the jack buffers and the ringbuffers. In this case, performance does not matter that much, but realtime-safety does! (Keep in mind that the system allocator may need to take a lock.)

|Christof|

cheers

Miller

On 10/8/24 4:47 PM, Christof Ressi wrote:

...

...

but 95b614656cd62214d6779014e5173d8af697814b wasn't me :-)

Sorry :)

...

why don't we just allocate the buffer on the heap *once* before we start the stream?

So the original code did exactly this... @Miller I think we should go back to the original solution to avoid continuous (de)allocations on the audio callback.

I've noticed that the old code used a hardcoded max. buffer size of 4096 samples (BUF_JACK). Alternatively, we could get the actual buffer size with jack_get_buffer_size() and register a callback with jack_set_buffer_size_callback() to handle buffer size changes.

Christof

On 08.10.2024 23:28, IOhannes m zmölnig wrote:

...

On 08/10/2024 22:04, Christof Ressi wrote:

...

@IOhannes: why don't we just allocate the buffer on the heap *once* before we start the stream?

no idea. but 95b614656cd62214d6779014e5173d8af697814b wasn't me :-)

gfmdsaf IOhannes

--- pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...

---

pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...

---

pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/BKTFMJJCMP2...

So if it was commit 95b614656cd62214d6779014e5173d8af697814b was Aug 2021,

There's a misunderstanding. https://github.com/pure-data/pure-data/commit/95b614656cd62214d6779014e5173d... the one that switched to stack allocation.

The commit that (very likely) causes your crash is https://github.com/pure-data/pure-data/commit/150858a65e7f580a32b39746338c0f... resp. https://github.com/pure-data/pure-data/commit/3539e1d8d4d64149c2507527cfc444....

So can you please try the latest develop branch and report if it fixes your issue?

Christof

On 09.10.2024 12:04, Winfried Ritsch wrote:

Thanks for the find

I now confirm it's Version 0.55 where I found it, so I changed Subject.

So if it was commit 95b614656cd62214d6779014e5173d8af697814b was Aug 2021, and I had it only after Debian bookworm-backports upgrade. Maybe there is something else which changed.

Interims solution: downgrade to stable and use 0.53.1.

mfg winfried

PS.: My gut feeling tells me, it would be better one allocation, since within an installation a lot of RAM can be grabbed by others making it more erratic behaviour, but I'm not that deeply familiar with the "threads" matte .

Am Dienstag, 8. Oktober 2024, 23:28:44 CEST schrieb IOhannes m zmölnig:

...

On 08/10/2024 22:04, Christof Ressi wrote:

...

@IOhannes: why don't we just allocate the buffer on the heap *once* before we start the stream?

no idea. but 95b614656cd62214d6779014e5173d8af697814b wasn't me :-)

...

gfmdsaf IOhannes