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
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
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
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
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
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
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
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,
I also reported my solution comment to your upstream ticket.
--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net
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
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
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
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
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
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
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!
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
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
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
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
Processing control commands:
> tags -1 =
Bug #994969 [jackd2] jackd2: segfaults after today's upgrade of other Debian
testing packages
Removed tag(s) unreproducible.
> reassign -1 libglibmm-2.4-1v5 2.66.1-1
Bug #994969 [jackd2] jackd2: segfaults after today's upgrade of other Debian
t
Processing control commands:
> tags -1 - moreinfo
Bug #994969 [jackd2] jackd2: segfaults after today's upgrade of other Debian
testing packages
Removed tag(s) moreinfo.
--
994969: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994969
Debian Bug Tracking System
Contact ow...@bugs.debian.
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
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.
>
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
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
Processing control commands:
> tags -1 moreinfo unreproducible
Bug #994969 [jackd2] jackd2: segfaults after today's upgrade of other Debian
testing packages
Added tag(s) unreproducible and moreinfo.
--
994969: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994969
Debian Bug Tracking Sys
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.
>
> $
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
29 matches
Mail list logo
