triggers the bug, the bug
goes away after commits.
--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net
ares against a pointer to invalid memory that comes from
the glib hash table.
--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net
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 Tho
iling.
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
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 consid
I also reported my solution comment to your upstream ticket.
--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net
r
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
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 crash
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
9==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-una
re 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.
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-arm
u 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
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.) t
ould 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
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
tall 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
he 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]
ches/cssysdef.diff
Ryan Thoryk
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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
20 matches
Mail list logo
