Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages
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
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
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
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
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
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
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
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
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
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@
Bug#986709: Rsnapshot removal
Upon upgrading my backup server tonight, I found that rsnapshot was removed from Debian Bullseye. In my opinion, this shouldn't have happened. I currently use it for backups on my main production server, and even in my previous Linux admin job, I had implemented it for company systems. There is no practical alternative to it, it's just a wrapper around rsync, nothing else works like that as far as I know. I also noticed that a newer version is in sid, couldn't that have been migrated to testing and released? I've been using it since 2014 (daily) as far as I know. I could look for alternatives, but it works too well in my opinion. To add what I think is a very good point for this, I recently opened a bug report for a package called statsvn, which didn't even work in both stable and testing, apparently nobody even verified that it worked before releasing it in Buster, it would fail with a java version check. Rsnapshot, a fine working package, was removed, but a perpetually broken package wasn't. Statsvn hasn't been released upstream for apparently 11 years. For now, I might see if I can use the sid version on stable. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)
On 7/17/21 10:09 AM, Ryan Thoryk wrote: On 7/17/21 9:44 AM, Steve McIntyre wrote: I found that I was using an older ARM image from last year, but that doesn't mean the issue was fixed later. In AWS's community AMI section, the main one I tried is listed as "debian-10-arm64-20200511-260". When you launch it, if you do a package upgrade it installs a newer version of grub. Then running a grub-install makes it unbootable. If you do the dpkg-reconfigure method, you have to choose "yes" to the "force extra installation" question, if you choose "no", it won't boot anymore. I tried launching a newer AMI, titled "debian-10-arm64-20210621-680", and that one reboots fine if you do a "grub-install", but that's because it didn't install a newer version of grub, since the packages are recent. I don't know what would happen if it installed a newer grub, you might have to look into that. In the boot folder the EFI boot loader is listed as "/boot/efi/EFI/BOOT/BOOTAA64.EFI", there's no "EFI/debian" folder. I'm not sure what they did to generate the AMI image. The AMI IDs I used are: ami-00249fe66e0872181 and ami-025a7500c83d92798 I didn't try the Marketplace one. One thing to add to that - when I did a "grub-install" on the newer AMI, it didn't write a "EFI/debian" folder, just an "EFI/BOOT" folder, which means that it might be working properly. If that's the case, then the older instances are broken, which would affect existing systems. I'm not sure if a grub upgrade would change that or not. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)
On 7/17/21 9:44 AM, Steve McIntyre wrote: Hi Ryan, So when you say "spin up a new Debian ARM VM on AWS", what exact image are you using here? It sounds like the build process for that image needs to be fixed to DTRT for the platform. Then you and other users won't be bitten by this problem... I found that I was using an older ARM image from last year, but that doesn't mean the issue was fixed later. In AWS's community AMI section, the main one I tried is listed as "debian-10-arm64-20200511-260". When you launch it, if you do a package upgrade it installs a newer version of grub. Then running a grub-install makes it unbootable. If you do the dpkg-reconfigure method, you have to choose "yes" to the "force extra installation" question, if you choose "no", it won't boot anymore. I tried launching a newer AMI, titled "debian-10-arm64-20210621-680", and that one reboots fine if you do a "grub-install", but that's because it didn't install a newer version of grub, since the packages are recent. I don't know what would happen if it installed a newer grub, you might have to look into that. In the boot folder the EFI boot loader is listed as "/boot/efi/EFI/BOOT/BOOTAA64.EFI", there's no "EFI/debian" folder. I'm not sure what they did to generate the AMI image. The AMI IDs I used are: ami-00249fe66e0872181 and ami-025a7500c83d92798 I didn't try the Marketplace one. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)
On 7/17/21 8:18 AM, Steve McIntyre wrote: On Sat, Jul 17, 2021 at 07:57:48AM -0500, Ryan Thoryk wrote: EFI/debian is *NOT* wrong, it's the correct location for a system that has working firmware which supports setting UEFI boot variables. If you *also* need to write a copy of grub (etc.) to the removable media location (EFI/boot) then that's supported as well by the Debian packaging - run "dpkg-reconfigure grub-efi-arm64" and say yes when the system asks about that. Thanks for that suggestion, that explains the correct procedure in resolving the issue. What I'm trying to point out though (I tried this), is that if you spin up a new Debian ARM VM on AWS, and run "grub-install" *without* doing a dpkg-reconfigure, it results in an unbootable system. To recover the system, you have to attach the disk on a different VM and replace the old boot loader image with the new one, then it boots again. After running the dpkg-reconfigure command though like you suggested, it copied over the EFI boot image to the "BOOT" folder, and also set the nvram variables to apparently boot from the "debian" folder, so that solved the problem for me. After doing that, the system comes up after a reboot with the newer grub modules. With others on here, the issue might have to do with the system executing an older EFI boot image resulting in a module mismatch, like what happened to me. Your dpkg-reconfigure suggestion might fix their issues too. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)
On Sat, 10 Jul 2021 23:15:15 +0100 Colin Watson wrote: In general, this means that grub-install is not installing to the place that your firmware is actually booting from, which causes the core image (installed to a file under /boot/efi/ on UEFI systems) to be out of sync with the modules (installed to a subdirectory of /boot/grub/). This is much rarer on UEFI systems than on BIOS systems, but it's still possible in some misconfigured cases. Could you please attach the output of "sudo grub-install --debug", "sudo efibootmgr -v", and "sudo find /boot/efi -ls"? Thanks for looking into this issue. I did some investigating this morning for my situation, and found the problem. Your suggestion is what helped me. The test case I had was that if you start a new Debian ARM VM on AWS, and run grub-install on it, future boots fail, where they stop at the rescue prompt and an "insmod normal" shows the error message. In other words, "grub-install" was breaking grub, which is pretty bad. After some investigating I found that grub-install was writing the EFI boot loader image (grubaa64.efi) to the wrong location on the system. It should be installing into /boot/efi/EFI/BOOT but is putting it into /boot/efi/EFI/debian. Future boots fail because the loader image that executes (the one in BOOT) is the older version and is out of sync with the modules. I tried deleting the /boot/efi/EFI/BOOT folder to see what would happen, wondering if it would try to use the "EFI/debian" one, and after rebooting the system was stuck in an EFI shell (couldn't find a boot loader), so the "EFI/debian" folder is clearly wrong. This could be similar to what's happening with others on here. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#990488: statsvn: Package in stable does not work
Package: statsvn Version: 0.7.0.dfsg-9 Severity: grave Justification: renders package unusable Dear Maintainer, When trying to use the statsvn utility, this fatal error message is encountered: SEVERE: Subversion binary is incorrect version. Found: 1.10.4, required: 1.3.0 This makes the utility broken on both stable and testing. It appears that FreeBSD has a patch for this, that disables the version check: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229325 -- System Information: Debian Release: 10.10 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'oldoldstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-13-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages statsvn depends on: ii default-jre [java-runtime] 2:1.11-71 ii java-wrappers 0.3 ii libsvnkit-java 1.8.14-3 ii openjdk-11-jre [java-runtime] 11.0.11+9-1~deb10u1 ii statcvs1:0.7.0.dfsg-7 ii subversion 1.10.4-1+deb10u2 statsvn recommends no packages. statsvn suggests no packages. -- no debconf information
Bug#984760: grub-pc: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)
I have something to add to this. This morning I was writing up a document on how to convert an existing Debian amd64 AWS VM to arm64 without reinstalling, which is something I was interested in doing in the future to a fairly complex system install that I wasn't excited about trying to reinstall/migrate. Everything worked with the conversion, except for the grub stage, grub failed to start on the ARM instance and was stuck at the grub-rescue prompt. When typing "insmod normal", it shows the "symbol `grub_is_lockdown` not found" error. I managed to get it working by copying grub modules from an existing Debian ARM VM over to it, I did that because I noticed that the modules were of a newer version and a different size. I'm not sure if the "grub-install" step was needed, but after investigating I found that when I ran grub-install a standard Debian-provided ARM AWS community instance and rebooted, the instance fails to boot in the same way. This is my document if you were interested, I mention the error in it: https://ryan.thoryk.com/linux/arm_convert.html -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#408147: xosview: incorrect search patch for X defaults file
Package: xosview Veraion: 1.8.2-10 Severity: serious Xosview doesn't properly search for the XOsview file (in app-defaults). In etch, this is at /etc/X11/app-defaults/XOsview, but the primary search path is /usr/X11R6/lib/X11/app-defaults/XOsview and there's no symlink associating the two (no app-defaults in /usr/X11R6/lib/X11), and so the config file never gets processed. Ryan Thoryk [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#358044: Fixed upstream
This bug has been fixed upstream as part of a series of patches I made that fix platform issues (mainly for Solaris and IRIX). Upstream SVN: http://crystal.svn.sourceforge.net/viewvc/crystal/CS/trunk/include/cssysdef.h?r1=26026r2=26189 Original patch: http://www.tliquest.net/ryan/cs_patches/cssysdef.diff Ryan Thoryk [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337496: basilisk2: Always crashes when starting up (home-built version does too)
It looks like your system is using the Udev system and HAL. Those files are not automatically allocated by those systems (so would this be a bug in Basilisk or UDEV?) Udev moves them to /dev/.static/dev Ryan Thoryk Unix and Network Specialist [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
