Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

2021-10-04 Thread Ryan Thoryk 

Upstream made a couple of commits which fix the Jack issue for me:
https://gitlab.gnome.org/GNOME/glibmm/-/commit/b67b77cb8cd37a7ec33ad15702831ab45ced7f64
https://gitlab.gnome.org/GNOME/glibmm/-/commit/f8b8e70fee19487df19019b4f8810715a7c77ad0

nos...@kota.moe also made some test code that triggers the bug, the bug 
goes away after commits.


--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

2021-10-04 Thread ‍小太 
On Sun, 3 Oct 2021 12:33:48 +0100 Simon McVittie  wrote:
> On Sat, 02 Oct 2021 at 20:48:55 +1000, ‍小太 wrote:
> > What I can add is from reading the documentation of 
> > g_quark_from_static_string()
> > (https://docs.gtk.org/glib/func.quark_from_static_string.html)
> > is these particular lines seem to be of importance:
> >
> > > It can be used with statically allocated strings in the main program,
> > > but not with statically allocated memory in dynamically loaded
> > > modules, if you expect to ever unload the module again
> >
> > However, jackd will load jack_firewire.so three times (which means
> > loading and unloading its glibmm dependency three times)
>
> Perhaps jack_firewire.so and/or glibmm should be linked with -Wl,-z,nodelete
> to prevent it from being removed from the address space even after
> dlclose()? That would ensure that its static strings remain in memory.

I suppose that would solve the problem too.
But I think we should try to have the root cause fixed upstream first.

I wrote a short PoC without the involvement of JACK to demonstrate it is not
a JACK problem and the bug has existed (hidden) for 18 years already:
https://gitlab.gnome.org/GNOME/glibmm/-/issues/96#note_1281881

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

2021-10-03 Thread Ryan Thoryk 

I posted this to the upstream bug report:

---

After debugging glib for a while, I might've found the issue.  According 
to the documentation of g_quark_from_static_string(), that function 
shouldn't be used to initialize a global variable, but that's how it's 
being used in the crash location in glibmm.


As part of doing symbol checks, Jack loads and unloads the firewire 
module a number of times, that has the glibmm dependency.  Then it loads 
the module normally.  Glibmm initializes each load, it shows the glib 
functions being called each time.  Since the glibmm initialization uses 
the static_string function, glib stores the pointer to the static string 
inside it's hash table and creates a new gquark (the doc says a gquark 
object creation at this stage is too early).  What should be happening, 
is that due to the module unloads, previously stored string references 
become invalid in the hash table, causing a segfault when doing an 
strcmp, the function doc says to not use that function if you're going 
to unload the module.  The hash table's address itself remains the same 
during all of the loads and unloads, showing that it's not being 
unloaded.  The g_quark_from_string() function works, because it creates 
copies of the strings instead, so it's unload-safe.


Unlike what we thought of before, the string that glibmm passes to the 
glib function remains valid all the way to the crash, the culprit is 
that strcmp compares against a pointer to invalid memory that comes from 
the glib hash table.


--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

2021-10-03 Thread Ryan Thoryk 
I found that my edits were affecting the wrong file (I was working on a 
cached file instead, there were multiple copies of the code), and so my 
string modification doesn't actually work, it results in the same segfault.


Changing the function to q_quark_from_string() works.

--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

2021-10-03 Thread Ryan Thoryk 

On 10/3/21 6:33 AM, Simon McVittie wrote:

On Sat, 02 Oct 2021 at 20:48:55 +1000, ‍小太 wrote:
Perhaps jack_firewire.so and/or glibmm should be linked with -Wl,-z,nodelete
to prevent it from being removed from the address space even after
dlclose()? That would ensure that its static strings remain in memory.


I think my code only showed a dlopen() with a single call, but my 
backtrace shows that it attempts to load the library twice (with caught 
exceptions), followed by a possible success the third time, then the 
glibmm init and segfault.  I don't know why the library load is failing. 
 Since I did a stack allocation instead, I'd think that memory would 
become invalid if the library unloaded before the glibmm init.


I'd mainly have to play with it in gdb more to see what's happening. 
nos...@kota.moe might've done more debugging than I did.


--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

2021-10-03 Thread Simon McVittie 
On Sat, 02 Oct 2021 at 20:48:55 +1000, ‍小太 wrote:
> What I can add is from reading the documentation of 
> g_quark_from_static_string()
> (https://docs.gtk.org/glib/func.quark_from_static_string.html)
> is these particular lines seem to be of importance:
> 
> > It can be used with statically allocated strings in the main program,
> > but not with statically allocated memory in dynamically loaded
> > modules, if you expect to ever unload the module again
> 
> However, jackd will load jack_firewire.so three times (which means
> loading and unloading its glibmm dependency three times)

Perhaps jack_firewire.so and/or glibmm should be linked with -Wl,-z,nodelete
to prevent it from being removed from the address space even after
dlclose()? That would ensure that its static strings remain in memory.

smcv

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

2021-10-03 Thread Ryan Thoryk 

On 10/3/21 4:59 AM, 小太 wrote:

On Sun, 3 Oct 2021 at 20:47, Ryan Thoryk  wrote:
"Bad permissions for mapped region at address" can also mean it tried
to read from unreadable memory. The memory was mapped at some
point in the past, so it doesn't say unallocated memory

Also consider the segfault comes from strcmp(). Why would strcmp()
ever need to write to memory? You can verify with a disassember the
segfault comes from a read


The strcmp stumped me too.  I assumed it was trying to copy from a null 
pointer, but valgrind shows that the address wasn't null.  I forgot 
about the strcmp detail when writing my comment, strcmp is read-only.




I suspect this "worked" to fix the issue only due to a memory layout
change, and luck would have it that after your rebuild it now tries to
read from readable memory (albeit still not the expected memory)



After looking over the glib docs, the function does a const on the 
string, so it shouldn't be able to do a write.


I don't know enough about handling C-strings (I've mostly done C++ 
strings), but the only difference is the location of stored memory, 
maybe it's getting an access error when trying to access the literal 
(since it's being done from an external library), as opposed to a stack 
allocation.  That's the only thing I can think of.  Valgrind doesn't 
show any warning or error using this method, so it appears to be fine. 
I'll bring this up on the glibmm upstream and see what they say.  I 
think the proper way to to define it is "static const char[]" instead of 
"char[]", but it might not matter that much.


--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

2021-10-03 Thread ‍小太 
On Sun, 3 Oct 2021 at 20:47, Ryan Thoryk  wrote:
>
> When I had jack dump out it's module filenames during library load, it
> only appeared to load jack_firewire once.  The clue as to what's
> happening is that valgrind reports "Bad permissions for mapped region",
> if you look at the function, it's trying to pass a string literal, the
> valgrind error means that it's trying to modify the string, and since
> it's read-only, it results in a segfault.  The string and address are valid.

"Bad permissions for mapped region at address" can also mean it tried
to read from unreadable memory. The memory was mapped at some
point in the past, so it doesn't say unallocated memory

Also consider the segfault comes from strcmp(). Why would strcmp()
ever need to write to memory? You can verify with a disassember the
segfault comes from a read

> or to create a C string and pass it to the function:

I suspect this "worked" to fix the issue only due to a memory layout
change, and luck would have it that after your rebuild it now tries to
read from readable memory (albeit still not the expected memory)

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

2021-10-03 Thread Ryan Thoryk 

I also reported my solution comment to your upstream ticket.

--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

2021-10-03 Thread Ryan Thoryk 
When I had jack dump out it's module filenames during library load, it 
only appeared to load jack_firewire once.  The clue as to what's 
happening is that valgrind reports "Bad permissions for mapped region", 
if you look at the function, it's trying to pass a string literal, the 
valgrind error means that it's trying to modify the string, and since 
it's read-only, it results in a segfault.  The string and address are valid.


The appropriate fix appears to be to either use your alternative 
function, or to create a C string and pass it to the function:


---
char binding[] = "glibmm__Glib::Binding::manage");
GQuark quark_manage = g_quark_from_static_string(binding);
---
or
---
GQuark quark_manage = g_quark_from_string("glibmm__Glib::Binding::manage");
---

Both of those changes work on my system, and jack_firewire now works for 
me again.  One thing online says about that function, "This function 
must not be used before library constructors have finished running."


--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

2021-10-02 Thread ‍小太 
Since the offending code seems to be present upstream in the
glibmm-2-66 branch, I've also reported it upstream:
https://gitlab.gnome.org/GNOME/glibmm/-/issues/96

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

2021-10-02 Thread ‍小太 
I can also confirm this issue also happens to me, and that downgrading
glibmm from 2.66.1-1 to 2.64.2-2 successfully resolves the issue.

I followed similar debugging steps as r...@thoryk.com above which
produced the same backtrace, before finding this bug already reported.

What I can add is from reading the documentation of g_quark_from_static_string()
(https://docs.gtk.org/glib/func.quark_from_static_string.html)
is these particular lines seem to be of importance:

> It can be used with statically allocated strings in the main program,
> but not with statically allocated memory in dynamically loaded
> modules, if you expect to ever unload the module again

However, jackd will load jack_firewire.so three times (which means
loading and unloading its glibmm dependency three times) from the
following backtraces:

> Breakpoint 1, __dlopen (file=0x7fffd400 
> "/tmp/jackd2/lib/jack/jack_firewire.so", mode=258) at dlopen.c:75
> 75dlopen.c: No such file or directory.
> (gdb) bt
> #0  __dlopen (file=0x7fffd400 "/tmp/jackd2/lib/jack/jack_firewire.so", 
> mode=258) at dlopen.c:75
> #1  0x77f73f9b in check_symbol (sofile=0x555720f3 
> "jack_firewire.so", symbol=0x77f9b528 "jack_internal_initialize", 
> driver_dir=0x77f9b4de "/tmp/jackd2/lib/jack", res_dllhandle=0x0) at 
> ../common/JackDriverLoader.cpp:432
> #2  0x77f7430d in jack_drivers_load (drivers=0x0) at 
> ../common/JackDriverLoader.cpp:602
> #3  0x77f795ff in jackctl_drivers_load (server_ptr=0x5556fbb0) at 
> ../common/JackControlAPI.cpp:390
> #4  0x77f7a4b6 in jackctl_server_create2 (on_device_acquire=0x0, 
> on_device_release=0x0, on_device_reservation_loop=0x0) at 
> ../common/JackControlAPI.cpp:935
> #5  0x6d7d in main (argc=3, argv=0x7fffdfa8) at 
> ../common/Jackdmp.cpp:334


> Thread 1 "jackd" hit Breakpoint 1, __dlopen (file=0x7fffcfa0 
> "/tmp/jackd2/lib/jack/jack_firewire.so", mode=258) at dlopen.c:75
> 75in dlopen.c
> (gdb) bt
> #0  __dlopen (file=0x7fffcfa0 "/tmp/jackd2/lib/jack/jack_firewire.so", 
> mode=258) at dlopen.c:75
> #1  0x77f73f9b in check_symbol(file_char_t const*, char const*, 
> file_char_t const*, void**) (sofile=0x555720f3 "jack_firewire.so", 
> symbol=0x77f9b541 "driver_get_descriptor", driver_dir=0x77f9b4de 
> "/tmp/jackd2/lib/jack", res_dllhandle=0x7fffd3e8)
> at ../common/JackDriverLoader.cpp:432
> #2  0x77f740b0 in jack_get_descriptor(JSList*, file_char_t const*, 
> char const*, file_char_t const*) (drivers=0x0, sofile=0x555720f3 
> "jack_firewire.so", symbol=0x77f9b541 "driver_get_descriptor", 
> driver_dir=0x77f9b4de "/tmp/jackd2/lib/jack")
> at ../common/JackDriverLoader.cpp:465
> #3  0x77f74339 in jack_drivers_load(_JSList*) (drivers=0x0) at 
> ../common/JackDriverLoader.cpp:606
> #4  0x77f795ff in jackctl_drivers_load(jackctl_server*) 
> (server_ptr=0x5556fbb0) at ../common/JackControlAPI.cpp:390
> #5  0x77f7a4b6 in jackctl_server_create2(bool (*)(char const*), void 
> (*)(char const*), void (*)()) (on_device_acquire=0x0, on_device_release=0x0, 
> on_device_reservation_loop=0x0) at ../common/JackControlAPI.cpp:935
> #6  0x6d7d in main(int, char**) (argc=3, argv=0x7fffdfa8) at 
> ../common/Jackdmp.cpp:334


> Thread 1 "jackd" hit Breakpoint 1, __dlopen (file=0x7fffd400 
> "/tmp/jackd2/lib/jack/jack_firewire.so", mode=258) at dlopen.c:75
> 75in dlopen.c
> (gdb) bt
> #0  __dlopen (file=0x7fffd400 "/tmp/jackd2/lib/jack/jack_firewire.so", 
> mode=258) at dlopen.c:75
> #1  0x77f73f9b in check_symbol(file_char_t const*, char const*, 
> file_char_t const*, void**) (sofile=0x555e5ab3 "jack_firewire.so", 
> symbol=0x77f9b528 "jack_internal_initialize", driver_dir=0x77f9b4de 
> "/tmp/jackd2/lib/jack", res_dllhandle=0x0)
> at ../common/JackDriverLoader.cpp:432
> #2  0x77f74511 in jack_internals_load(_JSList*) (internals=0x0) at 
> ../common/JackDriverLoader.cpp:723
> #3  0x77f797c1 in jackctl_internals_load(jackctl_server*) 
> (server_ptr=0x5556fbb0) at ../common/JackControlAPI.cpp:459
> #4  0x77f7a4cb in jackctl_server_create2(bool (*)(char const*), void 
> (*)(char const*), void (*)()) (on_device_acquire=0x0, on_device_release=0x0, 
> on_device_reservation_loop=0x0) at ../common/JackControlAPI.cpp:941
> #5  0x6d7d in main(int, char**) (argc=3, argv=0x7fffdfa8) at 
> ../common/Jackdmp.cpp:334


So the issue here seems like glibmm should not be using
g_quark_from_static_string(), but g_quark_from_string() instead

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

2021-10-01 Thread Ryan Thoryk 
After installing a debug version of glibmm, I've attached the related 
backtrace showing the glibmm code lines.  The "binding.cc" is the 
glib/glibmm/binding.cc file.  The old (working) version doesn't appear 
to use the related g_quark_from_static_string() function that crashes.


--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net

#0  __strcmp_sse2_unaligned () at 
../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31
#1  0x7f0771e943b9 in g_str_equal () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7f0771e92e03 in g_hash_table_lookup () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f0771eb5c8a in g_quark_from_static_string () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7f0771e0ead0 in __static_initialization_and_destruction_0 
(__priority=65535, __initialize_p=1)
at binding.cc:32
#5  _GLOBAL__sub_I_binding.cc(void) () at binding.cc:370
#6  0x7f0773b0610e in call_init (l=, argc=argc@entry=3, 
argv=argv@entry=0x7ffdbb8e0208, 
env=env@entry=0x7ffdbb8e0228) at dl-init.c:74

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

2021-09-30 Thread Ryan Thoryk 
I tried force-downgrading the libglibmm package to the Debian Bullseye 
version (2.66 back to 2.64), the crash goes away, and my audio hardware 
works again with Jack.


--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

2021-09-30 Thread Ryan Thoryk 
I wanted to chime in on this bug, since I'm getting basically the same 
issue.  I'm running Debian Testing.


My situation is a little different, because I'm using an M-Audio 
firewire device with Jack2 on a VIA VT6315 card, and so I need the 
firewire module.  I recently swapped out the firewire card but couldn't 
get the audio device to work, since Jack kept segfaulting on startup. 
Tonight I booted a Debian 11 live cd, and the device and Jack work 
flawlessly on it.  The device has trouble working with ALSA, so I use 
the FFADO system instead.


This is what it looks like when running:

ryan@andromeda:~$ jackd -d firewire
jackdmp 1.9.19
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2016 Grame.
Copyright 2016-2021 Filipe Coelho.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
no message buffer overruns
no message buffer overruns
no message buffer overruns
JACK server starting in realtime mode with priority 10
self-connect-mode is "Don't restrict self connect requests"
Segmentation fault (core dumped)


I downloaded the Jack source code and did some GDB debugging, and found 
that it's segfaulting when doing a dlopen() on the jack_firewire.so 
module.  Jack appears to run fine with the ALSA module instead, but not 
firewire.


I attached the backtrace from GDB.  I had been going over my system's 
linker configuration to see if there was something wrong, and then I 
found this bug report.  Since glib is crashing during a string 
comparison, the culprit appears to be the glibmm frontend's constructor. 
 I didn't set up an environment to debug glibmm yet, but let me know if 
there's something you'd like me to try out.  I was wanting to find out 
details on that string comparison.  You might be able to reproduce it if 
you try to use the firewire device module like I did.


This is the output when running Valgrind on Jack:

==8689==
==8689== Process terminating with default action of signal 11 (SIGSEGV): 
dumping core

==8689==  Bad permissions for mapped region at address 0x6594034
==8689==at 0x4D09370: __strcmp_sse2_unaligned 
(strcmp-sse2-unaligned.S:24)
==8689==by 0x6800F58: g_str_equal (in 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7000.0)
==8689==by 0x67FF9E1: g_hash_table_lookup (in 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7000.0)
==8689==by 0x6822C99: g_quark_from_static_string (in 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7000.0)
==8689==by 0x6938BAF: ??? (in 
/usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1.3.0)

==8689==by 0x401010D: call_init.part.0 (dl-init.c:74)
==8689==by 0x40101EF: call_init (dl-init.c:37)
==8689==by 0x40101EF: _dl_init (dl-init.c:121)
==8689==by 0x4DAAB6C: _dl_catch_exception (dl-error-skeleton.c:182)
==8689==by 0x4014483: dl_open_worker (dl-open.c:783)
==8689==by 0x4DAAB0F: _dl_catch_exception (dl-error-skeleton.c:208)
==8689==by 0x4013D09: _dl_open (dl-open.c:864)
==8689==by 0x5025257: dlopen_doit (dlopen.c:66)

--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net
#0  __strcmp_sse2_unaligned () at 
../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31
#1  0x7f7abc466f59 in g_str_equal () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7f7abc4659e2 in g_hash_table_lookup () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f7abc488c9a in g_quark_from_static_string () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7f7abc3dbbb0 in  () at /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
#5  0x7f7abe0df10e in call_init
(l=, argc=argc@entry=3, argv=argv@entry=0x7ffca09e2288, 
env=env@entry=0x7ffca09e22a8) at dl-init.c:74
#6  0x7f7abe0df1f0 in call_init (env=0x7ffca09e22a8, argv=0x7ffca09e2288, 
argc=3, l=) at dl-init.c:37
#7  _dl_init (main_map=0x55dd66345d90, argc=3, argv=0x7ffca09e2288, 
env=0x7ffca09e22a8) at dl-init.c:121
#8  0x7f7abdc19b6d in __GI__dl_catch_exception
(exception=exception@entry=0x0, operate=operate@entry=0x7f7abe0e2a00 
, args=args@entry=0x7ffca09e1800)
at dl-error-skeleton.c:182
#9  0x7f7abe0e3484 in dl_open_worker (a=a@entry=0x7ffca09e19a0) at 
dl-open.c:783
#10 0x7f7abdc19b10 in __GI__dl_catch_exception
(exception=exception@entry=0x7ffca09e1980, 
operate=operate@entry=0x7f7abe0e30e0 , 
args=args@entry=0x7ffca09e19a0) at dl-error-skeleton.c:208
#11 0x7f7abe0e2d0a in _dl_open
(file=0x7ffca09e1980 "", mode=-2147483390, caller_dlopen=0x7f7abe038bee 
, nsid=-2, argc=3, 
argv=0x7ffca09e2288, env=0x7ffca09e22a8)
at dl-open.c:864
#12 0x7f7abd8ef258 in dlopen_doit (a=a@entry=0x7ffca09e1bd0) at dlopen.c:66
#13 0x7f7abdc19b10 in __GI__dl_catch_exception
(exception=exception@entry=0x7ffca09e1b70, 
operate=operate@entry=0x7f7abd8ef200 , 
args=args@entry=0x7ffca09e1bd0) at dl-error-skeleton.c:208
#14 0x7f7abdc19bcf in __GI__dl_catch_error
(objname=objname@entry=0x55dd662d70b0,

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

2021-09-26 Thread Francesco Poli 
On Sat, 25 Sep 2021 18:58:53 +0200 Sebastian Ramacher wrote:

[...]
> If you don't have a firewire port, then jackd2-firewire is of no use.

Thank you so much for confirming!   :-)
Bye.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpuRGlck57H_.pgp
Description: PGP signature

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

2021-09-25 Thread Sebastian Ramacher 
On 2021-09-25 15:31:31 +0200, Francesco Poli wrote:
> On Sat, 25 Sep 2021 12:25:16 +0200 Sebastian Ramacher wrote:
> 
> [...]
> > So this is crashing somewhere during the initialization of libglibmm.
> > Hence I'm reassigning to libglibmm.
> [...]
> 
> Thanks, Sebastian!
> 
> 
> By the way, I am now wondering whether I really need jackd2-firewire.
> Maybe I can keep it out of my system, even after this bug gets fixed?!?
> I don't think I have a FireWire port, hence maybe the JACK FireWire
> support is useless to me.
> Could you please confirm?

If you don't have a firewire port, then jackd2-firewire is of no use.

Cheers

> 
> -- 
>  http://www.inventati.org/frx/
>  There's not a second to spare! To the laboratory!
> . Francesco Poli .
>  GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE



-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

2021-09-25 Thread Francesco Poli 
On Sat, 25 Sep 2021 12:25:16 +0200 Sebastian Ramacher wrote:

[...]
> So this is crashing somewhere during the initialization of libglibmm.
> Hence I'm reassigning to libglibmm.
[...]

Thanks, Sebastian!


By the way, I am now wondering whether I really need jackd2-firewire.
Maybe I can keep it out of my system, even after this bug gets fixed?!?
I don't think I have a FireWire port, hence maybe the JACK FireWire
support is useless to me.
Could you please confirm?

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpgMqnF5HNPu.pgp
Description: PGP signature

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

2021-09-25 Thread Jeremy Bicha 
On Sat, Sep 25, 2021 at 6:25 AM Sebastian Ramacher  wrote:
> So this is crashing somewhere during the initialization of libglibmm.
> Hence I'm reassigning to libglibmm.

Sebastian, My first guess is that this is more fallout from the
incomplete libffi transition. See https://bugs.debian.org/995032

Thanks,
Jeremy Bicha

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

2021-09-25 Thread Sebastian Ramacher 
Control: tags -1 =
Control: reassign -1 libglibmm-2.4-1v5 2.66.1-1

On 2021-09-25 12:03:54 +0200, Francesco Poli wrote:
> Control: tags -1 - moreinfo
> 
> 
> On Fri, 24 Sep 2021 21:46:57 +0200 Sebastian Ramacher wrote:
> 
> [...]
> > I haven't tried that yet, but otherwise you can always install -dbgsym
> > packages until all symbols are resolved.
> 
> I have just tried.
> Not sure the Debuginfod method worked fine enough, but here's what I
> did.
> I first re-installed jackd2-firewire:
> 
>   # aptitude install jackd2-firewire+M
>   The following NEW packages will be installed:
> jackd2-firewire{a} libconfig++9v5{a} libffado2{a} libxml++2.6-2v5{a} 
>   0 packages upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
>   [...]
> 
> Then, as a regular user:
> 
>   $ export DEBUGINFOD_URLS="https://debuginfod.debian.net;
>   $ gdb -batch -n -ex 'set pagination off' -ex run -ex bt -ex 'bt full' -ex 
> 'thread apply all bt full' --args jackd --realtime -d alsa --device hw:PCH 
> --softmode --hwmeter --rate 44100 > jackd_bt.out 2>&1

The relevant part seems to be:

Thread 1 "jackd" received signal SIGSEGV, Segmentation fault.
__strcmp_avx2 () at ../sysdeps/x86_64/multiarch/strcmp-avx2.S:101
Download failed: Invalid argument.  Continuing without source file 
./string/../sysdeps/x86_64/multiarch/strcmp-avx2.S.
101 ../sysdeps/x86_64/multiarch/strcmp-avx2.S: Inappropriate ioctl for 
device.
#0  __strcmp_avx2 () at ../sysdeps/x86_64/multiarch/strcmp-avx2.S:101
#1  0x76bc4b19 in g_str_equal () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x76bc3563 in g_hash_table_lookup () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x76be674a in g_quark_from_static_string () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x76dfdbb0 in ?? () from 
/usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
#5  0x77fe210e in call_init (l=, argc=argc@entry=10, 
argv=argv@entry=0x7fffe168, env=env@entry=0x7fffe1c0) at dl-init.c:74
#6  0x77fe21f0 in call_init (env=0x7fffe1c0, argv=0x7fffe168, 
argc=10, l=) at dl-init.c:37
#7  _dl_init (main_map=0x5557ae80, argc=10, argv=0x7fffe168, 
env=0x7fffe1c0) at dl-init.c:121
#8  0x77b41b6d in __GI__dl_catch_exception (exception=, 
operate=, args=) at dl-error-skeleton.c:182
#9  0x77fe6484 in dl_open_worker (a=a@entry=0x7fffd3d0) at 
dl-open.c:783
#10 0x77b41b10 in __GI__dl_catch_exception (exception=0x7fffd3b0, 
operate=0x77fe60e0 , args=0x7fffd3d0) at 
dl-error-skeleton.c:208
#11 0x77fe5d0a in _dl_open (file=0x7fffd3b0 
"\340\323\377\377\377\177", mode=-2147483390, caller_dlopen=0x77f5f80c, 
nsid=-2, argc=10, argv=0x7fffe168, env=0x7fffe1c0) at dl-open.c:864
#12 0x77817258 in dlopen_doit (a=a@entry=0x7fffd600) at dlopen.c:66
#13 0x77b41b10 in __GI__dl_catch_exception 
(exception=exception@entry=0x7fffd5a0, operate=0x77817200 
, args=0x7fffd600) at dl-error-skeleton.c:208
#14 0x77b41bcf in __GI__dl_catch_error (objname=0x5557ccb0, 
errstring=0x5557ccb8, mallocedp=0x5557cca8, operate=, 
args=) at dl-error-skeleton.c:227
#15 0x77817a65 in _dlerror_run (operate=operate@entry=0x77817200 
, args=args@entry=0x7fffd600) at dlerror.c:170
#16 0x778172e4 in __dlopen (file=, mode=) 
at dlopen.c:87
#17 0x77f5f80c in ?? () from 
/usr/lib/x86_64-linux-gnu/libjackserver.so.0
#18 0x77f60a8d in ?? () from 
/usr/lib/x86_64-linux-gnu/libjackserver.so.0
#19 0x77f64f5e in jackctl_server_create2 () from 
/usr/lib/x86_64-linux-gnu/libjackserver.so.0
#20 0x8111 in ?? ()
#21 0x77a31e4a in __libc_start_main (main=0x75b0, argc=10, 
argv=0x7fffe168, init=, fini=, 
rtld_fini=, stack_end=0x7fffe158) at ../csu/libc-start.c:314

So this is crashing somewhere during the initialization of libglibmm.
Hence I'm reassigning to libglibmm.

Cheers

> 
> The output file is attached (compressed with xz).
> 
> I am not familiar with jackd source code, hence I do not fully grasp
> the backtrace, but I seem to understand that the segfault definitely
> has something to do with some dl_open related to jackd2-firewire and
> the libglibmm-2.4-1v5 package.
> 
> As I said in another message, jackd works flawlessly, as soon as I
> purge jackd2-firewire .
> Have you had a chance to try and reproduce the bug with jackd2-firewire
> installed (assuming that you had previously tried without that package)?
> 
> 
> P.S.: I dropped the moreinfo tag from the bug report, as I think I
> provided the requested additional information. Needless to say, feel
> free to re-add the tag, in case you need anything more!
> 
> -- 
>  http://www.inventati.org/frx/
>  There's not a second to spare! To the laboratory!
> . Francesco Poli .
>  GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE





--

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

2021-09-25 Thread Francesco Poli 
Control: tags -1 - moreinfo


On Fri, 24 Sep 2021 21:46:57 +0200 Sebastian Ramacher wrote:

[...]
> I haven't tried that yet, but otherwise you can always install -dbgsym
> packages until all symbols are resolved.

I have just tried.
Not sure the Debuginfod method worked fine enough, but here's what I
did.
I first re-installed jackd2-firewire:

  # aptitude install jackd2-firewire+M
  The following NEW packages will be installed:
jackd2-firewire{a} libconfig++9v5{a} libffado2{a} libxml++2.6-2v5{a} 
  0 packages upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
  [...]

Then, as a regular user:

  $ export DEBUGINFOD_URLS="https://debuginfod.debian.net;
  $ gdb -batch -n -ex 'set pagination off' -ex run -ex bt -ex 'bt full' -ex 
'thread apply all bt full' --args jackd --realtime -d alsa --device hw:PCH 
--softmode --hwmeter --rate 44100 > jackd_bt.out 2>&1

The output file is attached (compressed with xz).

I am not familiar with jackd source code, hence I do not fully grasp
the backtrace, but I seem to understand that the segfault definitely
has something to do with some dl_open related to jackd2-firewire and
the libglibmm-2.4-1v5 package.

As I said in another message, jackd works flawlessly, as soon as I
purge jackd2-firewire .
Have you had a chance to try and reproduce the bug with jackd2-firewire
installed (assuming that you had previously tried without that package)?


P.S.: I dropped the moreinfo tag from the bug report, as I think I
provided the requested additional information. Needless to say, feel
free to re-add the tag, in case you need anything more!

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


jackd_bt.out.xz
Description: application/xz


pgp9iwMGD64Kl.pgp
Description: PGP signature

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

2021-09-24 Thread Sebastian Ramacher 
On 2021-09-24 19:18:33 +0200, Francesco Poli wrote:
> On Fri, 24 Sep 2021 11:11:27 +0200 Sebastian Ramacher wrote:
> 
> [...]
> > I'm unable to reproduce the crash on an updated bookworm installation.
> 
> First of all, thank you so much for your very prompt reply!
> That's really appreciated.
> 
> It's unfortunate (especially for me!) that you do not experience the
> segfault that I see...   :-p
> 
> I tried to figure out which exact package upgrade is the cause of the
> regression on my box. In order to do so, I re-upgraded all the packages
> I had upgraded (and then downgraded again...) this morning. One small
> set of related packages at a time.
> Now I have only 1 package left to upgrade: libglibmm-2.4-1v5
> 
> If I upgrade that package too:
> 
>   # aptitude --purge-unused safe-upgrade 
>   The following packages will be upgraded: 
> libglibmm-2.4-1v5 
>   1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>   [...]
> 
> I get the segfault:
> 
>   $ jackd --realtime -d alsa --device hw:PCH --softmode --hwmeter --rate 
> 44100 &
>   jackdmp 1.9.19
>   Copyright 2001-2005 Paul Davis and others.
>   Copyright 2004-2016 Grame.
>   Copyright 2016-2021 Filipe Coelho.
>   jackdmp comes with ABSOLUTELY NO WARRANTY
>   This is free software, and you are welcome to redistribute it
>   under certain conditions; see the file COPYING for details
>   no message buffer overruns
>   no message buffer overruns
>   
>   [1]+  Segmentation fault  jackd --realtime -d alsa --device hw:PCH 
> --softmode --hwmeter --rate 44100
> 
> If I downgrade that package again:
> 
>   # dpkg -i /var/cache/apt/archives/libglibmm-2.4-1v5_2.64.2-2_amd64.deb 
>   dpkg: warning: downgrading libglibmm-2.4-1v5:amd64 from 2.66.1-1 to 2.64.2-2
>   [...]
> 
> I no longer get any segfault:
> 
>   $ jackd --realtime -d alsa --device hw:PCH --softmode --hwmeter --rate 
> 44100 &
>   jackdmp 1.9.19
>   Copyright 2001-2005 Paul Davis and others.
>   Copyright 2004-2016 Grame.
>   Copyright 2016-2021 Filipe Coelho.
>   jackdmp comes with ABSOLUTELY NO WARRANTY
>   This is free software, and you are welcome to redistribute it
>   under certain conditions; see the file COPYING for details
>   no message buffer overruns
>   no message buffer overruns
>   no message buffer overruns
>   JACK server starting in realtime mode with priority 10
>   self-connect-mode is "Don't restrict self connect requests"
>   audio_reservation_init
>   Acquire audio card Audio1
>   creating alsa driver ... 
> hw:PCH|hw:PCH|1024|2|44100|0|0|nomon|hwmeter|soft-mode|32bit
>   configuring for 44100Hz, period = 1024 frames (23.2 ms), buffer = 2 periods
>   ALSA: final selected sample format for capture: 32bit integer little-endian
>   ALSA: use 2 periods for capture
>   ALSA: final selected sample format for playback: 32bit integer little-endian
>   ALSA: use 2 periods for playback
> 
> and jackd seems to work correctly (tested with audacious output,
> I can listen to music without any issue).
> 
> Hence, it seems that the bug is in libglibmm-2.4-1v5/2.66.1-1  .
> Now I wonder why you are not experiencing the same bug...
> 
> > Could you please provide a backtrace of the crash so that we can try to
> > pinpoint the problem?
> 
> I can try to do so.
> Could you please assist me?
> 
> I would like to use the new method that loads debugging symbols from
> the Debuginfod server, but I have never done so before...
> Should I follow [instructions] on the Debian Wiki?

I haven't tried that yet, but otherwise you can always install -dbgsym
packages until all symbols are resolved.

Cheers

> 
> [instructions]: 
> 
> 
> -- 
>  http://www.inventati.org/frx/
>  There's not a second to spare! To the laboratory!
> . Francesco Poli .
>  GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE



-- 
Sebastian Ramacher

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

2021-09-24 Thread Francesco Poli 
On Fri, 24 Sep 2021 19:18:33 +0200 Francesco Poli wrote:

[...]
> Hence, it seems that the bug is in libglibmm-2.4-1v5/2.66.1-1  .
> Now I wonder why you are not experiencing the same bug...

Please let me add one further comment: I have just found out something
very weird.

If I purge jackd2-firewire (which was present on my box, since it is
recommended by jackd2):

  # aptitude --purge-unused purge jackd2-firewire
  The following packages will be REMOVED:  
jackd2-firewire{p} libconfig++9v5{pu} libffado2{pu} libxml++2.6-2v5{pu} 
  0 packages upgraded, 0 newly installed, 4 to remove and 1 not upgraded.
  [...]

I can complete the upgrade:

  # aptitude --purge-unused safe-upgrade 
  The following packages will be upgraded: 
libglibmm-2.4-1v5 
  1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
  [...]

and jackd works without segfaulting:

  $ jackd --realtime -d alsa --device hw:PCH --softmode --hwmeter --rate 44100 &
  jackdmp 1.9.19
  Copyright 2001-2005 Paul Davis and others.
  Copyright 2004-2016 Grame.
  Copyright 2016-2021 Filipe Coelho.
  jackdmp comes with ABSOLUTELY NO WARRANTY
  This is free software, and you are welcome to redistribute it
  under certain conditions; see the file COPYING for details
  JACK server starting in realtime mode with priority 10
  self-connect-mode is "Don't restrict self connect requests"
  audio_reservation_init
  Acquire audio card Audio1
  creating alsa driver ... 
hw:PCH|hw:PCH|1024|2|44100|0|0|nomon|hwmeter|soft-mode|32bit
  configuring for 44100Hz, period = 1024 frames (23.2 ms), buffer = 2 periods
  ALSA: final selected sample format for capture: 32bit integer little-endian
  ALSA: use 2 periods for capture
  ALSA: final selected sample format for playback: 32bit integer little-endian
  ALSA: use 2 periods for playback


Could this explain why you do not experience the segfault?
Did you have the recommended packages (in particular jackd2-firewire)
installed on your up-to-date bookworm system?


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpb9LUbHV6hi.pgp
Description: PGP signature

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

2021-09-24 Thread Francesco Poli 
On Fri, 24 Sep 2021 11:11:27 +0200 Sebastian Ramacher wrote:

[...]
> I'm unable to reproduce the crash on an updated bookworm installation.

First of all, thank you so much for your very prompt reply!
That's really appreciated.

It's unfortunate (especially for me!) that you do not experience the
segfault that I see...   :-p

I tried to figure out which exact package upgrade is the cause of the
regression on my box. In order to do so, I re-upgraded all the packages
I had upgraded (and then downgraded again...) this morning. One small
set of related packages at a time.
Now I have only 1 package left to upgrade: libglibmm-2.4-1v5

If I upgrade that package too:

  # aptitude --purge-unused safe-upgrade 
  The following packages will be upgraded: 
libglibmm-2.4-1v5 
  1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
  [...]

I get the segfault:

  $ jackd --realtime -d alsa --device hw:PCH --softmode --hwmeter --rate 44100 &
  jackdmp 1.9.19
  Copyright 2001-2005 Paul Davis and others.
  Copyright 2004-2016 Grame.
  Copyright 2016-2021 Filipe Coelho.
  jackdmp comes with ABSOLUTELY NO WARRANTY
  This is free software, and you are welcome to redistribute it
  under certain conditions; see the file COPYING for details
  no message buffer overruns
  no message buffer overruns
  
  [1]+  Segmentation fault  jackd --realtime -d alsa --device hw:PCH 
--softmode --hwmeter --rate 44100

If I downgrade that package again:

  # dpkg -i /var/cache/apt/archives/libglibmm-2.4-1v5_2.64.2-2_amd64.deb 
  dpkg: warning: downgrading libglibmm-2.4-1v5:amd64 from 2.66.1-1 to 2.64.2-2
  [...]

I no longer get any segfault:

  $ jackd --realtime -d alsa --device hw:PCH --softmode --hwmeter --rate 44100 &
  jackdmp 1.9.19
  Copyright 2001-2005 Paul Davis and others.
  Copyright 2004-2016 Grame.
  Copyright 2016-2021 Filipe Coelho.
  jackdmp comes with ABSOLUTELY NO WARRANTY
  This is free software, and you are welcome to redistribute it
  under certain conditions; see the file COPYING for details
  no message buffer overruns
  no message buffer overruns
  no message buffer overruns
  JACK server starting in realtime mode with priority 10
  self-connect-mode is "Don't restrict self connect requests"
  audio_reservation_init
  Acquire audio card Audio1
  creating alsa driver ... 
hw:PCH|hw:PCH|1024|2|44100|0|0|nomon|hwmeter|soft-mode|32bit
  configuring for 44100Hz, period = 1024 frames (23.2 ms), buffer = 2 periods
  ALSA: final selected sample format for capture: 32bit integer little-endian
  ALSA: use 2 periods for capture
  ALSA: final selected sample format for playback: 32bit integer little-endian
  ALSA: use 2 periods for playback

and jackd seems to work correctly (tested with audacious output,
I can listen to music without any issue).

Hence, it seems that the bug is in libglibmm-2.4-1v5/2.66.1-1  .
Now I wonder why you are not experiencing the same bug...

> Could you please provide a backtrace of the crash so that we can try to
> pinpoint the problem?

I can try to do so.
Could you please assist me?

I would like to use the new method that loads debugging symbols from
the Debuginfod server, but I have never done so before...
Should I follow [instructions] on the Debian Wiki?

[instructions]: 


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpQcC9V8wsro.pgp
Description: PGP signature

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

2021-09-24 Thread Sebastian Ramacher 
Control: tags -1 moreinfo unreproducible

On 2021-09-24 09:23:08, Francesco Poli (wintermute) wrote:
> Package: jackd2
> Version: 1.9.19~dfsg-2
> Severity: grave
> Justification: renders package unusable
> 
> Hello!
> After today's upgrade, jackd stopped working on my Debian testing box.
> 
>   $ jackd --realtime -d alsa --device hw:PCH --softmode --hwmeter --rate 
> 44100 &
>   jackdmp 1.9.19
>   Copyright 2001-2005 Paul Davis and others.
>   Copyright 2004-2016 Grame.
>   Copyright 2016-2021 Filipe Coelho.
>   jackdmp comes with ABSOLUTELY NO WARRANTY
>   This is free software, and you are welcome to redistribute it
>   under certain conditions; see the file COPYING for details
>   no message buffer overruns
>   no message buffer overruns
>   
>   [1]+  Segmentation fault  jackd --realtime -d alsa --device hw:PCH 
> --softmode --hwmeter --rate 44100

I'm unable to reproduce the crash on an updated bookworm installation.
Could you please provide a backtrace of the crash so that we can try to
pinpoint the problem?

Cheers

> 
> 
> I tried to selectively downgrade the libraries that appeared related to
> jackd2, but to no avail: the segfault was still reproducible.
> 
> The list of package upgrades that broke jackd is:
> 
>   
>   [REMOVE, NOT USED] libbox2d2.3.0:amd64 2.3.1+ds-7
>   [REMOVE, NOT USED] libcmis-0.5-5v5:amd64 0.5.2-3
>   [REMOVE, NOT USED] libqrcodegencpp1:amd64 1.6.0-1
>   [INSTALL, DEPENDENCIES] libbox2d2:amd64 2.4.1-2
>   [INSTALL, DEPENDENCIES] libzxingcore1:amd64 1.2.0-1
>   [UPGRADE] adwaita-icon-theme:amd64 40.1.1-2 -> 41.0-1
>   [UPGRADE] binutils:amd64 2.37-5 -> 2.37-7
>   [UPGRADE] binutils-common:amd64 2.37-5 -> 2.37-7
>   [UPGRADE] binutils-x86-64-linux-gnu:amd64 2.37-5 -> 2.37-7
>   [UPGRADE] cpp-10:amd64 10.3.0-9 -> 10.3.0-11
>   [UPGRADE] diffoscope:amd64 182 -> 185
>   [UPGRADE] diffoscope-minimal:amd64 182 -> 185
>   [UPGRADE] eatmydata:amd64 129-3 -> 129-4
>   [UPGRADE] fonts-opensymbol:amd64 2:102.12+LibO7.1.5-2 -> 
> 2:102.12+LibO7.2.1-3
>   [UPGRADE] g++-10:amd64 10.3.0-9 -> 10.3.0-11
>   [UPGRADE] gcc-10:amd64 10.3.0-9 -> 10.3.0-11
>   [UPGRADE] gcc-10-base:amd64 10.3.0-9 -> 10.3.0-11
>   [UPGRADE] gcc-11-base:amd64 11.2.0-4 -> 11.2.0-7
>   [UPGRADE] libasan6:amd64 11.2.0-4 -> 11.2.0-7
>   [UPGRADE] libatk-wrapper-java:amd64 0.38.0-4 -> 0.38.0-5
>   [UPGRADE] libatk-wrapper-java-jni:amd64 0.38.0-4 -> 0.38.0-5
>   [UPGRADE] libatomic1:amd64 11.2.0-4 -> 11.2.0-7
>   [UPGRADE] libbinutils:amd64 2.37-5 -> 2.37-7
>   [UPGRADE] libcc1-0:amd64 11.2.0-4 -> 11.2.0-7
>   [UPGRADE] libctf-nobfd0:amd64 2.37-5 -> 2.37-7
>   [UPGRADE] libctf0:amd64 2.37-5 -> 2.37-7
>   [UPGRADE] libeatmydata1:amd64 129-3 -> 129-4
>   [UPGRADE] libgcc-10-dev:amd64 10.3.0-9 -> 10.3.0-11
>   [UPGRADE] libgcc-s1:amd64 11.2.0-4 -> 11.2.0-7
>   [UPGRADE] libgfortran5:amd64 11.2.0-4 -> 11.2.0-7
>   [UPGRADE] libglibmm-2.4-1v5:amd64 2.64.2-2 -> 2.66.1-1
>   [UPGRADE] libgomp1:amd64 11.2.0-4 -> 11.2.0-7
>   [UPGRADE] libitm1:amd64 11.2.0-4 -> 11.2.0-7
>   [UPGRADE] liblibreoffice-java:amd64 1:7.1.5-2 -> 1:7.2.1-3
>   [UPGRADE] liblsan0:amd64 11.2.0-4 -> 11.2.0-7
>   [UPGRADE] libmanette-0.2-0:amd64 0.2.5-1 -> 0.2.6-3
>   [UPGRADE] libobjc4:amd64 11.2.0-4 -> 11.2.0-7
>   [UPGRADE] libquadmath0:amd64 11.2.0-4 -> 11.2.0-7
>   [UPGRADE] libreoffice:amd64 1:7.1.5-2 -> 1:7.2.1-3
>   [UPGRADE] libreoffice-base:amd64 1:7.1.5-2 -> 1:7.2.1-3
>   [UPGRADE] libreoffice-base-core:amd64 1:7.1.5-2 -> 1:7.2.1-3
>   [UPGRADE] libreoffice-base-drivers:amd64 1:7.1.5-2 -> 1:7.2.1-3
>   [UPGRADE] libreoffice-calc:amd64 1:7.1.5-2 -> 1:7.2.1-3
>   [UPGRADE] libreoffice-common:amd64 1:7.1.5-2 -> 1:7.2.1-3
>   [UPGRADE] libreoffice-core:amd64 1:7.1.5-2 -> 1:7.2.1-3
>   [UPGRADE] libreoffice-draw:amd64 1:7.1.5-2 -> 1:7.2.1-3
>   [UPGRADE] libreoffice-impress:amd64 1:7.1.5-2 -> 1:7.2.1-3
>   [UPGRADE] libreoffice-java-common:amd64 1:7.1.5-2 -> 1:7.2.1-3
>   [UPGRADE] libreoffice-l10n-de:amd64 1:7.1.5-2 -> 1:7.2.1-3
>   [UPGRADE] libreoffice-l10n-it:amd64 1:7.1.5-2 -> 1:7.2.1-3
>   [UPGRADE] libreoffice-math:amd64 1:7.1.5-2 -> 1:7.2.1-3
>   [UPGRADE] libreoffice-report-builder-bin:amd64 1:7.1.5-2 -> 1:7.2.1-3
>   [UPGRADE] libreoffice-sdbc-hsqldb:amd64 1:7.1.5-2 -> 1:7.2.1-3
>   [UPGRADE] libreoffice-style-colibre:amd64 1:7.1.5-2 -> 1:7.2.1-3
>   [UPGRADE] libreoffice-writer:amd64 1:7.1.5-2 -> 1:7.2.1-3
>   [UPGRADE] libscalar-list-utils-perl:amd64 1:1.55-1+b1 -> 1:1.59-1
>   [UPGRADE] libstdc++-10-dev:amd64 10.3.0-9 -> 10.3.0-11
>   [UPGRADE] libstdc++6:amd64 11.2.0-4 -> 11.2.0-7
>   [UPGRADE] libtsan0:amd64 11.2.0-4 -> 11.2.0-7
>   [UPGRADE] libubsan1:amd64 11.2.0-4 -> 11.2.0-7
>   [UPGRADE] libuno-cppu3:amd64 1:7.1.5-2 -> 1:7.2.1-3
>   [UPGRADE] libuno-cppuhelpergcc3-3:amd64 1:7.1.5-2 -> 1:7.2.1-3
>   [UPGRADE] libuno-purpenvhelpergcc3-3:amd64 1:7.1.5-2 -> 1:7.2.1-3
>   [UPGRADE] libuno-sal3:amd64 1:7.1.5-2 -> 1:7.2.1-3
>   [UPGRADE] libuno-salhelpergcc3-3:amd64 1:7.1.5-2 -> 1:7.2.1-3
>

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

2021-09-24 Thread Francesco Poli (wintermute) 
Package: jackd2
Version: 1.9.19~dfsg-2
Severity: grave
Justification: renders package unusable

Hello!
After today's upgrade, jackd stopped working on my Debian testing box.

  $ jackd --realtime -d alsa --device hw:PCH --softmode --hwmeter --rate 44100 &
  jackdmp 1.9.19
  Copyright 2001-2005 Paul Davis and others.
  Copyright 2004-2016 Grame.
  Copyright 2016-2021 Filipe Coelho.
  jackdmp comes with ABSOLUTELY NO WARRANTY
  This is free software, and you are welcome to redistribute it
  under certain conditions; see the file COPYING for details
  no message buffer overruns
  no message buffer overruns
  
  [1]+  Segmentation fault  jackd --realtime -d alsa --device hw:PCH 
--softmode --hwmeter --rate 44100


I tried to selectively downgrade the libraries that appeared related to
jackd2, but to no avail: the segfault was still reproducible.

The list of package upgrades that broke jackd is:

  
  [REMOVE, NOT USED] libbox2d2.3.0:amd64 2.3.1+ds-7
  [REMOVE, NOT USED] libcmis-0.5-5v5:amd64 0.5.2-3
  [REMOVE, NOT USED] libqrcodegencpp1:amd64 1.6.0-1
  [INSTALL, DEPENDENCIES] libbox2d2:amd64 2.4.1-2
  [INSTALL, DEPENDENCIES] libzxingcore1:amd64 1.2.0-1
  [UPGRADE] adwaita-icon-theme:amd64 40.1.1-2 -> 41.0-1
  [UPGRADE] binutils:amd64 2.37-5 -> 2.37-7
  [UPGRADE] binutils-common:amd64 2.37-5 -> 2.37-7
  [UPGRADE] binutils-x86-64-linux-gnu:amd64 2.37-5 -> 2.37-7
  [UPGRADE] cpp-10:amd64 10.3.0-9 -> 10.3.0-11
  [UPGRADE] diffoscope:amd64 182 -> 185
  [UPGRADE] diffoscope-minimal:amd64 182 -> 185
  [UPGRADE] eatmydata:amd64 129-3 -> 129-4
  [UPGRADE] fonts-opensymbol:amd64 2:102.12+LibO7.1.5-2 -> 2:102.12+LibO7.2.1-3
  [UPGRADE] g++-10:amd64 10.3.0-9 -> 10.3.0-11
  [UPGRADE] gcc-10:amd64 10.3.0-9 -> 10.3.0-11
  [UPGRADE] gcc-10-base:amd64 10.3.0-9 -> 10.3.0-11
  [UPGRADE] gcc-11-base:amd64 11.2.0-4 -> 11.2.0-7
  [UPGRADE] libasan6:amd64 11.2.0-4 -> 11.2.0-7
  [UPGRADE] libatk-wrapper-java:amd64 0.38.0-4 -> 0.38.0-5
  [UPGRADE] libatk-wrapper-java-jni:amd64 0.38.0-4 -> 0.38.0-5
  [UPGRADE] libatomic1:amd64 11.2.0-4 -> 11.2.0-7
  [UPGRADE] libbinutils:amd64 2.37-5 -> 2.37-7
  [UPGRADE] libcc1-0:amd64 11.2.0-4 -> 11.2.0-7
  [UPGRADE] libctf-nobfd0:amd64 2.37-5 -> 2.37-7
  [UPGRADE] libctf0:amd64 2.37-5 -> 2.37-7
  [UPGRADE] libeatmydata1:amd64 129-3 -> 129-4
  [UPGRADE] libgcc-10-dev:amd64 10.3.0-9 -> 10.3.0-11
  [UPGRADE] libgcc-s1:amd64 11.2.0-4 -> 11.2.0-7
  [UPGRADE] libgfortran5:amd64 11.2.0-4 -> 11.2.0-7
  [UPGRADE] libglibmm-2.4-1v5:amd64 2.64.2-2 -> 2.66.1-1
  [UPGRADE] libgomp1:amd64 11.2.0-4 -> 11.2.0-7
  [UPGRADE] libitm1:amd64 11.2.0-4 -> 11.2.0-7
  [UPGRADE] liblibreoffice-java:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] liblsan0:amd64 11.2.0-4 -> 11.2.0-7
  [UPGRADE] libmanette-0.2-0:amd64 0.2.5-1 -> 0.2.6-3
  [UPGRADE] libobjc4:amd64 11.2.0-4 -> 11.2.0-7
  [UPGRADE] libquadmath0:amd64 11.2.0-4 -> 11.2.0-7
  [UPGRADE] libreoffice:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-base:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-base-core:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-base-drivers:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-calc:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-common:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-core:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-draw:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-impress:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-java-common:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-l10n-de:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-l10n-it:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-math:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-report-builder-bin:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-sdbc-hsqldb:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-style-colibre:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-writer:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libscalar-list-utils-perl:amd64 1:1.55-1+b1 -> 1:1.59-1
  [UPGRADE] libstdc++-10-dev:amd64 10.3.0-9 -> 10.3.0-11
  [UPGRADE] libstdc++6:amd64 11.2.0-4 -> 11.2.0-7
  [UPGRADE] libtsan0:amd64 11.2.0-4 -> 11.2.0-7
  [UPGRADE] libubsan1:amd64 11.2.0-4 -> 11.2.0-7
  [UPGRADE] libuno-cppu3:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libuno-cppuhelpergcc3-3:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libuno-purpenvhelpergcc3-3:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libuno-sal3:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libuno-salhelpergcc3-3:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libunoloader-java:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libxml2:amd64 2.9.10+dfsg-6.7 -> 2.9.12+dfsg-5
  [UPGRADE] python3-uno:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] rsync:amd64 3.2.3-4 -> 3.2.3-7
  [UPGRADE] uno-libs-private:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] ure:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] ure-java:amd64 1:7.1.5-2 -> 1:7.2.1-3
  


After some tests, I decided to completely undo today's upgrade: