Bug#958296: openvpn 2.4.9 seems to fail loading/reading client certificates
Am 20.04.20 um 12:15 schrieb Jonas Andradas: Hi Jonas, > I am not sure what openvpn version was there in see last week, > whether it was > 2.4.7 or 2.4.9 (the current package is 2.4.9-1). However, I see > that openvpn > has been updated over the weekend, since my openvpn files/binaries > have been > modified on April 19th. > > > Sorry, the spell corrector played me here: I meant "I am not sure what > openvpn version > was there in [Debian] SID last week (...) OpenVPN in all of buster (stable), testing and sid was 2.4.7-1 for the last year. > Yes, the client certificate is still valid, and if I use older > OpenVPN versions (such as 2.4.3), I can still connect successfully. Can you please downgrade to 2.4.7-1 and double check? Your response sounds like it did work with 2.4.7-1, but I want to be sure. Any way we could get this configuration file? Bernhard
Bug#958296: openvpn 2.4.9 seems to fail loading/reading client certificates
Am 20.04.20 um 11:12 schrieb Jonas Andradas: Dear Jonas, > Apparently, openvpn 2.4.9-1 has an issue when reading client-certificates used > to authenticate to the remote server. Thanks. Is this a regression compared to 2.4.7? Or what is the last version where this worked? There are a couple of SSL-related changes between 2.4.7 and 2.4.9, but nothing immediately obvious. Is the client certificate still valid? Bernhard
Bug#956381: Please additionally install grub-efi-amd64-signed
Hello Cyril Yes. You're right: this is a duplicate of bug #954856. You wrote in this bug report #954856: > Bugs, bugs everywhere! > > Feel free to file a separate bug if you want this to get tracked, but > I'm not sure I would spend time on it. So, i created this bug report with the lowest severity "wishlist". And for me, it is useless to install shim-signed without grub-efi-amd64-signed. > I'm not sure what you were hoping for by opening this new bug report? In my preseed configuration, i have a workaround for this issue. My hope was: if the package grub-efi-amd64-signed is installed automatically, i can remove my workaround. Best regards and thank you for your support. Bernhard signature.asc Description: This is a digitally signed message part
Bug#949699: 0ad dies with 'Assertion failed: "cache.Validate()"'
Dear Maintainer, I tried to have a look at the first call stack, and could reconstruct it using the dbgsym package to the backtrace below. @Bob Ham: could you supply some information about the CPU you are using. If it is an AMD Ryzen 3xxx the first two links below might describe your issue and the third link points to a workaround patch for this CPU. Kind regards, Bernhard 0x55b661de in debug_DumpStack(wchar_t*, unsigned long, void*, wchar_t const*) at ../../../source/lib/sysdep/os/linux/ldbg.cpp:82 0x55b11c51 in debug_BuildErrorMessage(wchar_t const*, wchar_t const*, int, char const*, void*, wchar_t const*, ErrorMessageMem*) at ../../../source/lib/debug.cpp:304 0x55b13148 in debug_DisplayError(wchar_t const*, unsigned long, void*, wchar_t const*, wchar_t const*, int, char const*, long volatile*) at ../../../source/lib/debug.cpp:471 0x55b13648 in debug_OnAssertionFailure(wchar_t const*, long volatile*, wchar_t const*, int, char const*) at /usr/include/c++/8/bits/basic_string.h:2290 0x55b5e59e in x86_x64::AddCache(x86_x64::Cache const&) at ../../../source/lib/sysdep/arch/x86_x64/cache.cpp:43 0x55b5ebf4 in x86_x64::AMD::DetectCacheAndTLB() at ../../../source/lib/sysdep/arch/x86_x64/cache.cpp:130 0x55b5f0b5 in x86_x64::DetectCacheAndTLB() at ../../../source/lib/sysdep/arch/x86_x64/cache.cpp:623 0x55b94343 in ModuleInit(long volatile*, long (*)()) at ../../../source/lib/module_init.cpp:46 0x55b5f8fe in x86_x64::Caches(unsigned long) at ../../../source/lib/sysdep/arch/x86_x64/cache.cpp:652 0x55b6078a in topology::MaxLogicalPerCache at ../../../source/lib/sysdep/arch/x86_x64/topology.cpp:392 0x55b94343 in ModuleInit(long volatile*, long (*)()) at ../../../source/lib/module_init.cpp:46 0x55b6036a in topology::NumCaches() at ../../../source/lib/sysdep/arch/x86_x64/topology.cpp:456 0x5580161f in RunHardwareDetection() at ../../../source/ps/GameSetup/HWDetect.cpp:310 0x557f8329 in InitGraphics(CmdLineArgs const&, int, std::vector > const&) at ../../../source/ps/GameSetup/GameSetup.cpp:1001 0x55608691 in RunGameOrAtlas(int, char const**) at ../../../source/main.cpp:631 0x555f40b7 in main(int, char**) at ../../../source/main.cpp:680 https://wildfiregames.com/forum/index.php?/topic/27550-problems-with-0ad/ https://wildfiregames.com/forum/index.php?/topic/26890-problem-with-ryzen-3000er-series/page/2/ https://github.com/0ad/0ad/commit/c6c8774a0712a80408bd07f9d9250b242753f713#diff-746bc8707bf20685fe8c98acfacb304f
Bug#954901: ghostscript: runtime error: malloc(): invalid size (unsorted)
Sorry, the file I attached in message #10 was for a different bug, unrelated to this one. Created upstream bug: https://bugs.ghostscript.com/show_bug.cgi?id=702346
Bug#934680: gjs-console crashed with signal 5
merge 934680 934770
Bug#919236: [Pkg-freeradius-maintainers] Bug#919236: Inappropriately broad default CA for EAP configuration
Am 16.04.20 um 17:11 schrieb sauro...@gmx.de: Hi, > Well at least i thought that this would let me on Squeeze, but i was wrong Could you please rephrase your question? BTW, Squeeze is Debian 6 and out of LTS since 2016. I assume you mean Stretch aka Debian 9? Bernhard
Bug#942502: Bug#954736: isc-dhcp rebuild enough?
Hi Ondrej, > > I think that simple binNMU should be enough. That’s the reason I have > introduced the src:bind9-libs package, so there’s a grace period for > isc-dhcp to either die or adapt. thanks, I've filed Bug#956895 for the binNMU. Bernhard
Bug#956895: nmu: isc-dhcp_4.4.1-2.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, please binNMU isc-dhcp in unstable. isc-dhcp has historically been patched to built against the internal ISC libraries built by src:bind9 9.11 via libbind-export-dev, instead of using the embedded copy in the isc-dhcp source tree. The bind9 version now in unstable (9.16) does not provide these libraries anymore. A bug had been filed on isc-dhcp (#942502) to switch to the internal copy, but nothing had happened. isc-dhcp is now blocking the bind9 migration to testing. To resolve the situation Ondrej has created src:bind9-libs which stays at 9.11 and took over the packages necessary to build isc-dhcp. A simple NMU of src:isc-dhcp should be enough to use the new package and unentangle them for good. The RC bug #954736 should also be resolved with this binNMU. nmu isc-dhcp_4.4.1-2.1 . ANY . unstable . -m "Rebuild against src:bind9-libs"
Bug#956381: Please additionally install grub-efi-amd64-signed
Hello, I have additional informations regarding installing this package. The package grub-efi-amd64-signed is installed with installing recommended packages. With my preseed-configuration, the recommended packages are not installed. Please see bug report #954856: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954856 Hopefully, this information helps and thank you for your support. Best regards Bernhard signature.asc Description: This is a digitally signed message part
Bug#919236: [Pkg-freeradius-maintainers] Bug#919236: Inappropriately broad default CA for EAP configuration
Am 15.04.20 um 13:57 schrieb sauro...@gmx.de: Hi, >> >>>>> "Michael" == Michael Stapelberg writes: >> I really don't think I'm going to be able to provide more on this prior >> to the buster release. I'm struggling trying to get through my own list >> of things to fix in my packages. > Is there any news on this? This bug keeps my last important machines i > have here on Squeeze, unfortunately. Why is this keeping your machine at Squeeze? It is a problem in the _default_ configuration, you can change it at will. And since it is a conffile (in /etc) it won't be overwritten by updates. I agree that this should be fixed though, but I need some input on how to do this properly, both on upgrades and on new installations. I think the option of dropping snakeoil-certs.diff and running make in /etc/freeradius/3.0/certs on postinst (accompanied by a NEWS entry) should be okay. What do you think? Bernhard
Bug#956119: asterisk: segfault in libspandsp.so.2.0.0 when using Set(FAXOPT(gateway)=yes,30) between SIP and iax
Control: found -1 1:16.2.1~dfsg-1
Control: forwarded -1 https://issues.asterisk.org/jira/browse/ASTERISK-27981
Hi,
> I tried to extract from the submitter's dmesg line the
> source location of the crash.
>
> I assume it happened here [1], with
> variable s containing an invalid pointer:
>
> 0x77f5bb90 in update_rx_timing at t38_gateway.c:2244
>
> 2242 static void update_rx_timing(t38_gateway_state_t *s, int len)
> 2243 {
> 2244 if (s->core.samples_to_timeout > 0)
> 2245 {
>
>
> https://sources.debian.org/src/spandsp/0.0.6+dfsg-2/src/t38_gateway.c/#L2244
>
>
> Maybe it is of some help.
> But a proper backtrace like described in following link would probably
> be way better: https://wiki.debian.org/HowToGetABacktrace
Thanks a lot. This looks very much like the backtrace in
https://issues.asterisk.org/jira/browse/ASTERISK-28450
---
Core was generated by `/usr/sbin/asterisk -f -U asterisk -G asterisk
-vvvg -c'.
Program terminated with signal 11, Segmentation fault.
#0 update_rx_timing (s=0x29b28, len=160) at t38_gateway.c:2189
2189if (s->core.samples_to_timeout > 0)
---
The bug itself is marked as duplicate of
https://issues.asterisk.org/jira/browse/ASTERISK-27981, which refers to
https://gerrit.asterisk.org/c/asterisk/+/11434
@Benoit: Can you test with that patch applied?
Bernhard
Bug#914813: Test with current daily
Hello, I did a test again. Within installer, there is no ethernet card detected. Attached, there is the complete Log from U-Boot to start of the installer. I assume, there is something wrong with the AXP-regulator. There is the message some times: >> sun8i-a83t-pinctrl 1c20800.pinctrl: 1c20800.pinctrl supply vcc-pb not found, >> using dummy regulator << If i can do some tests, please let me know. Thank you for the great support. Best regards Bernhard U-Boot SPL 2020.04-rc5+dfsg-1 (Apr 07 2020 - 15:50:37 +) DRAM: 2048 MiB Trying to boot from MMC1 U-Boot 2020.04-rc5+dfsg-1 (Apr 07 2020 - 15:50:37 +) Allwinner Technology CPU: Allwinner A83T (SUN8I 1673) Model: Banana Pi BPI-M3 DRAM: 2 GiB MMC: Device 'mmc@1c11000': seq 1 is in use by 'mmc@1c1' mmc@1c0f000: 0, mmc@1c1: 2, mmc@1c11000: 1 Loading Environment from FAT... Unable to use mmc 1:0... In:serial Out: serial Err: serial Net: phy interface7 eth0: ethernet@1c3 starting USB... Bus usb@1c19000: No host cable detected: Port not available. Bus usb@1c1a000: USB EHCI 1.00 scanning bus usb@1c1a000 for devices... Device NOT ready Request Sense returned 02 3A 00 3 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 2 1 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot.scr 1575 bytes read in 4 ms (383.8 KiB/s) ## Executing script at 4310 Mainline u-boot / new-style environment detected. 4682240 bytes read in 498 ms (9 MiB/s) 23681 bytes read in 17 ms (1.3 MiB/s) 24011772 bytes read in 2536 ms (9 MiB/s) Booting the Debian installer... ## Flattened Device Tree blob at 4300 Booting using the fdt blob at 0x4300 Loading Ramdisk to 48919000, end 49fff3fc ... OK Loading Device Tree to 4891, end 48918c80 ... OK Starting kernel ... [r] Booting Linux on physical CPU 0x0 [0.00] Linux version 5.5.0-1-armmp (debian-ker...@lists.debian.org) (gcc version 9.3.0 (Debian 9.3.0-8)) #1 SMP Debian 5.5.13-2 (2020-03-30) [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d [0.00] CPU: div instructions available: patching division code [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] OF: fdt: Machine model: Banana Pi BPI-M3 [0.00] Memory policy: Data cache writealloc [0.00] efi: Getting EFI parameters from FDT: [0.00] efi: UEFI not found. [0.00] cma: Reserved 16 MiB at 0xbf00 [0.00] percpu: Embedded 21 pages/cpu s53388 r8192 d24436 u86016 [0.00] Built 1 zonelists, mobility grouping on. Total pages: 521984 [0.00] Kernel command line: console=ttyS0,115200 [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear) [0.00] mem auto-init: stack:off, heap alloc:off, heap free:off [0.00] Memory: 2013244K/2097152K available (10240K kernel code, 1203K rwdata, 3116K rodata, 2048K init, 327K bss, 67524K reserved, 16384K cma-reserved, 1294336K highmem) [0.00] random: get_random_u32 called from __kmem_cache_create+0x48/0x514 with crng_init=0 [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1 [0.00] ftrace: allocating 35586 entries in 70 pages [0.00] ftrace: allocated 70 pages with 3 groups [0.00] rcu: Hierarchical RCU implementation. [0.00] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies. [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 [0.00] arch_timer: cp15 timer(s) running at 24.00MHz (virt). [0.00] clocksource: arch_sys_counter: mask: 0xff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns [0.11] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns [0.25] Switching to timer-based delay loop, resolution 41ns [0.001327] clocksource: timer: mask: 0x max_cycles: 0x, max_idle_ns: 79635851949 ns [0.002823] Console: colour dummy device 80x30 [0.002927] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=96000) [0.002944] pid_max: default: 32768 minimum: 301 [0.003309] LSM: Security Framework initializing [0.003408] Yama: disabled by default; enable with sysctl kernel.yama.* [0.003587] AppArmor: AppArmor initialized [0.003604] TOMOYO Linux initialized [0.003731] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, linear) [0.003756] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes, linear) [0.005728] CPU: Testing write buffer coherency: ok [0.006627] /cpus/cpu@0 missing clock-frequency property [0.006658] /cpus/cpu@1 missing clock-frequency property [0.006682] /cpus/cpu@2 missing clock-
Bug#956381: Please additionally install grub-efi-amd64-signed in UEFI
Package: grub-installer Severity: wishlist Hello, In UEFI mode, there is the package shim-signed installed. The package shim-signed is useless without grub-efi-amd64-signed. Please install also grub-efi-amd64-signed. Thank you for the great distribution. Best regards Bernhard signature.asc Description: This is a digitally signed message part
Bug#956119: asterisk: segfault in libspandsp.so.2.0.0 when using Set(FAXOPT(gateway)=yes,30) between SIP and iax
Dear Maintainer,
I tried to extract from the submitter's dmesg line the
source location of the crash.
I assume it happened here [1], with
variable s containing an invalid pointer:
0x77f5bb90 in update_rx_timing at t38_gateway.c:2244
2242 static void update_rx_timing(t38_gateway_state_t *s, int len)
2243 {
2244 if (s->core.samples_to_timeout > 0)
2245 {
https://sources.debian.org/src/spandsp/0.0.6+dfsg-2/src/t38_gateway.c/#L2244
Maybe it is of some help.
But a proper backtrace like described in following link would probably
be way better: https://wiki.debian.org/HowToGetABacktrace
Kind regards,
Bernhard
From submitter:
[14509242.948899] asterisk[27070]: segfault at 2c7b4 ip 7f9a52389b90 sp
7f9a23d8a4f8 error 4 in libspandsp.so.2.0.0[7f9a5234d000+56000]
[14509242.948908] Code: 00 00 00 00 00 5b c3 0f 1f 00 e9 1b fd ff ff 0f 1f 00
e8 33 ef ff ff eb e2 90 e9 2b ef ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 <8b> 87
8c 2c 00 00 85 c0 7e 0c 29 f0 89 87 8c 2c 00 00 85 c0 7e 0a
# https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash
"error 4"==0: no page found, 0: read access, 1: user-mode access
# Buster/stable amd64 qemu VM 2020-04-07
apt update
apt dist-upgrade
apt install systemd-coredump gdb asterisk asterisk-dbgsym libspandsp2-dbgsym
echo -n "find /b ..., ..., 0x" && \
echo "00 00 00 00 00 5b c3 0f 1f 00 e9 1b fd ff ff 0f 1f 00 e8 33 ef ff ff eb
e2 90 e9 2b ef ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 <8b> 87 8c 2c 00 00 85 c0
7e 0c 29 f0 89 87 8c 2c 00 00 85 c0 7e 0a" \
| sed 's/[<>]//g' | sed 's/ /, 0x/g'
gdb -q
set width 0
set pagination off
file /usr/sbin/asterisk
set environment LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libspandsp.so.2.0.0
b main
run
dele 1
info share
find /b 0x77f20520, 0x77f7473f, 0x00, 0x00, 0x00, 0x00, 0x00,
0x5b, 0xc3, 0x0f, 0x1f, 0x00, 0xe9, 0x1b, 0xfd, 0xff, 0xff, 0x0f, 0x1f, 0x00,
0xe8, 0x33, 0xef, 0xff, 0xff, 0xeb, 0xe2, 0x90, 0xe9, 0x2b, 0xef, 0xff, 0xff,
0x66, 0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x8b, 0x87,
0x8c, 0x2c, 0x00, 0x00, 0x85, 0xc0, 0x7e, 0x0c, 0x29, 0xf0, 0x89, 0x87, 0x8c,
0x2c, 0x00, 0x00, 0x85, 0xc0, 0x7e, 0x0a
b * (0x77f5bb66 + 42)
info b
disassemble /r 0x77f5bb66, 0x77f5bb66 + 62
set max-value-size 10
#
benutzer@debian:~$ echo -n "find /b ..., ..., 0x" && \
> echo "00 00 00 00 00 5b c3 0f 1f 00 e9 1b fd ff ff 0f 1f 00 e8 33 ef ff ff eb
> e2 90 e9 2b ef ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 <8b> 87 8c 2c 00 00 85
> c0 7e 0c 29 f0 89 87 8c 2c 00 00 85 c0 7e 0a" \
> | sed 's/[<>]//g' | sed 's/ /, 0x/g'
find /b ..., ..., 0x00, 0x00, 0x00, 0x00, 0x00, 0x5b, 0xc3, 0x0f, 0x1f, 0x00,
0xe9, 0x1b, 0xfd, 0xff, 0xff, 0x0f, 0x1f, 0x00, 0xe8, 0x33, 0xef, 0xff, 0xff,
0xeb, 0xe2, 0x90, 0xe9, 0x2b, 0xef, 0xff, 0xff, 0x66, 0x66, 0x2e, 0x0f, 0x1f,
0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x8b, 0x87, 0x8c, 0x2c, 0x00, 0x00, 0x85,
0xc0, 0x7e, 0x0c, 0x29, 0xf0, 0x89, 0x87, 0x8c, 0x2c, 0x00, 0x00, 0x85, 0xc0,
0x7e, 0x0a
benutzer@debian:~$ gdb -q
(gdb) set width 0
(gdb) set pagination off
(gdb) file /usr/sbin/asterisk
Reading symbols from /usr/sbin/asterisk...Reading symbols from
/usr/lib/debug/.build-id/23/f49a19a60d0fecbf537ba0f24d2f05792ccf44.debug...done.
done.
(gdb) set environment LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libspandsp.so.2.0.0
(gdb) b main
Breakpoint 1 at 0x42e40: file asterisk.c, line 3488.
(gdb) run
Starting program: /usr/sbin/asterisk
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, main (argc=1, argv=0x7fffe5d8) at asterisk.c:3488
3488asterisk.c: Datei oder Verzeichnis nicht gefunden.
(gdb) dele 1
(gdb) info share
FromTo Syms Read Shared Object Library
...
0x77f20520 0x77f7473f Yes
/usr/lib/x86_64-linux-gnu/libspandsp.so.2.0.0
...
(*): Shared library is missing debugging information.
(gdb) find /b 0x77f20520, 0x77f7473f, 0x00, 0x00, 0x00, 0x00,
0x00, 0x5b, 0xc3, 0x0f, 0x1f, 0x00, 0xe9, 0x1b, 0xfd, 0xff, 0xff, 0x0f, 0x1f,
0x00, 0xe8, 0x33, 0xef, 0xff, 0xff, 0xeb, 0xe2, 0x90, 0xe9, 0x2b, 0xef, 0xff,
0xff, 0x66, 0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x8b,
0x87, 0x8c, 0x2c, 0x00, 0x00, 0x85, 0xc0, 0x7e, 0x0c, 0x29, 0xf0, 0x89, 0x87,
0x8c, 0x2c, 0x00, 0x00, 0x85, 0xc0, 0x7e, 0x0a
0x77f5bb66
1 pattern found.
(gdb) b * (0x77f5bb66 + 42)
Breakpoint 2 at 0x77f5bb90: file t38_gateway.c, line 2244.
(gdb) info b
Num Type Disp Enb AddressWhat
2 breakpoint keep y 0x77f5bb90 in update_rx_timing at
t38_gateway.c:2244
(gdb) disassemble /r 0x77f5bb66, 0x77f5bb66 + 62
Dump of assembler code from 0x77f5bb66 to 0
Bug#942502: isc-dhcp rebuild enough?
Hi, since 9.16 the bind9 package is not building the bind9 shared libraries anymore, which have previously been used by isc-dhcp instead of the bundled bind9 source. Ondrej had filed Bug#942502 about this last October. bind9 9.16 has now been uploaded to unstable, but (among two RC bugs) the uninstallability of isc-dhcp prevents migration to testing. Ondrej has also uploaded src:bind9-libs, which take over the -dev packages and shared libraries with the most recent 9.11 code. If I'm not mistaken a simple rebuild of src:isc-dhcp, possibly with tightened build-dep on libbind-export-dev to ensure the use of the new src:bind9-libs package should be enough. Bug#942502: not using the embedded bind9 source, but the new dedicated source package Bug#954736: fixed by rebuilding isc-dhcp against the new libdns-export This would unentangle bind9 and isc-dhcp and allow the latter to propagate to testing. Is there something I'm missing? Bernhard
Bug#955279: sysdig: undefined symbol: _ZN4grpc13ClientContextC1Ev
Dear Maintainer,
I tried to have a look and it looks like being related
to the libgrpc++1 package.
The _ZN4grpc13ClientContextC1Ev symbol was included in
libgrpc++1 versions up to 1.17.2-1.
Since version 1.22.0-2 it is missing from that library.
Because 1.26.0-2 is the first version after 1.16.1-1,
which got uploaded to unstable (other versions just in
experimental), this issue got visible since 2020-03-21.
A local rebuild of sysdig against libgrpc++1 1.26.0-2
seems to work.
Therefore it looks like there was an ABI change in libgrpc++1.
I am not sure what actions on grpc side are needed,
but at least a rebuild of sysdig seems necessary.
Kind regards,
Bernhard
_ZN4grpc13ClientContextC1Ev
# https://demangler.com/
grpc::ClientContext::ClientContext()
https://buildd.debian.org/status/fetch.php?pkg=sysdig=amd64=0.26.4-1=1571110364=0
+==+
| sysdig 0.26.4-1 (amd64) Tue, 15 Oct 2019 03:28:26 + |
+==+
approx:
debian-11-bullseye-snapshot.debian.org
https://snapshot.debian.org/archive/debian/20191016T00Z/
sources.list:
# snapshot
deb [check-valid-until=no]
http://192.168.178.25:/debian-11-bullseye-snapshot.debian.org/ unstable main
deb-src [check-valid-until=no]
http://192.168.178.25:/debian-11-bullseye-snapshot.debian.org/ unstable main
deb [check-valid-until=no]
http://192.168.178.25:/debian-11-bullseye-debug-snapshot.debian.org/
unstable-debug main
# Unstable amd64 qemu VM as of date 2019-10-16
apt update
apt dist-upgrade
apt install systemd-coredump binutils sysdig
# dpkg -l | grep -E "sysdig|0.26.4-1"
ii sysdig0.26.4-1 amd64
system-level exploration and troubleshooting tool
ii sysdig-dkms 0.26.4-1 all
system-level exploration and troubleshooting tool - kernel source
##
# for lib in `ldd /usr/bin/sysdig | grep -v -E
"linux-vdso.so.1|/lib64/ld-linux-x86-64.so.2" | awk '{print $3}'`; do echo
x $lib; nm -D $lib; done | grep -E "x|_ZN4grpc13ClientContextC1Ev"
...
x /lib/x86_64-linux-gnu/libgrpc++_unsecure.so.1
00026b60 T _ZN4grpc13ClientContextC1Ev
x /lib/x86_64-linux-gnu/libprotobuf.so.17
...
# dpkg -S /usr/lib/x86_64-linux-gnu/libgrpc++_unsecure.so.1
libgrpc++1:amd64: /usr/lib/x86_64-linux-gnu/libgrpc++_unsecure.so.1
# dpkg -l | grep -E "libgrpc|1.16.1-1+b1"
ii libgrpc++1:amd64 1.16.1-1+b1 amd64
high performance general RPC framework
ii libgrpc6:amd641.16.1-1+b1 amd64
high performance general RPC framework
##
wget
https://snapshot.debian.org/archive/debian/20191119T213110Z/pool/main/g/grpc/libgrpc%2B%2B1_1.16.1-1%2Bb2_amd64.deb
wget
https://snapshot.debian.org/archive/debian/20191119T213110Z/pool/main/g/grpc/libgrpc6_1.16.1-1%2Bb2_amd64.deb
dpkg -i *_1.16.1-1+b2_*
# nm -D /lib/x86_64-linux-gnu/libgrpc++_unsecure.so.1 | grep
_ZN4grpc13ClientContextC1Ev
00026b70 T _ZN4grpc13ClientContextC1Ev
##
wget
https://snapshot.debian.org/archive/debian/20200220T030240Z/pool/main/g/grpc/libgrpc%2B%2B1_1.16.1-1%2Bb3_amd64.deb
wget
https://snapshot.debian.org/archive/debian/20181203T153211Z/pool/main/g/grpc/libgrpc6_1.16.1-1_amd64.deb
dpkg -i --force-depends *_1.16.1-1+b3_*
# nm -D /lib/x86_64-linux-gnu/libgrpc++_unsecure.so.1 | grep
_ZN4grpc13ClientContextC1Ev
00026b80 T _ZN4grpc13ClientContextC1Ev
##
wget
https://snapshot.debian.org/archive/debian/20181206T103113Z/pool/main/g/grpc/libgrpc%2B%2B1_1.17.0-1_amd64.deb
wget
https://snapshot.debian.org/archive/debian/20181206T103113Z/pool/main/g/grpc/libgrpc7_1.17.0-1_amd64.deb
dpkg -i --force-depends *_1.17.0-1_*
# nm -D /lib/x86_64-linux-gnu/libgrpc++_unsecure.so.1 | grep
_ZN4grpc13ClientContextC1Ev
00032da0 T _ZN4grpc13ClientContextC1Ev
##
wget
https://snapshot.debian.org/archive/debian/20181217T091644Z/pool/main/g/grpc/libgrpc%2B%2B1_1.17.2-1_amd64.deb
wget
https://snapshot.debian.org/archive/debian/20181217T091644Z/pool/main/g/grpc/libgrpc7_1.17.2-1_amd64.deb
dpkg -i --force-depends *_1.17.2-1_*
# nm -D /lib/x86_64-linux-gnu/libgrpc++_unsecure.so.1 | grep
_ZN4grpc13ClientContextC1Ev
00032da0 T _ZN4grpc13ClientContextC1Ev
##
grpc 1.22.0-1, not available for amd64
##
wget
https://snapshot.debian.org/archive/debian/20190811T045655Z/pool/main/g/grpc/libgrpc%2B%2B1_1.22.0-2_amd64.deb
wget
https://snapshot.debian.org/archive/debian/20190811T045655Z/pool/main/g/grpc/libgrpc7_1.22.0-2_amd64.deb
dpkg -i --force-depends *_1.22.0-2_*
# nm -D /lib/x86_64-
Bug#955747: libgl1-mesa-dri: all GL programms crash on startup
Hello Felix Rublack, I do not know if the maintainer are able to reproduce this issue, but instead or additional to the strace a backtrace of the crash might help them. The easiest way might be to install systemd-coredump and look at "journalctl -e" after a crash. More info in [1]. (Even better with debug symbols installed.) Nevertheless the segfault lines in dmesg lead to following locations in iris_dri.so: mpv/vo: function iris_resource_bo called from function stream_state: https://sources.debian.org/src/mesa/20.0.2-1/src/gallium/drivers/iris/iris_resource.h/#L290 https://sources.debian.org/src/mesa/20.0.2-1/src/gallium/drivers/iris/iris_blorp.c/#L60 until L63 vlc: glxgears: function GEN9_3DSTATE_VERTEX_ELEMENTS_pack called from iris_blorp_exec: file src/intel/genxml/gen9_pack.h, line 6901. (unfortunately a generated file?) maybe related to https://sources.debian.org/src/mesa/20.0.2-1/src/intel/blorp/blorp_genX_exec.h/#L550 Kind regards, Bernhard [1] https://wiki.debian.org/HowToGetABacktrace From submitter: [ 37.001269] mpv/vo[1739]: segfault at a0 ip 7fe5d34a62a8 sp 7fe5e6092de0 error 4 in iris_dri.so[7fe5d2a8d000+d2e000] [ 37.001276] Code: 44 24 18 48 c7 44 24 10 00 00 00 00 48 c7 44 24 18 00 00 00 00 50 4c 8d 4c 24 18 e8 e2 a4 b6 ff 48 8b 44 24 18 31 d2 48 89 ef <4c> 8b b0 a0 00 00 00 4c 89 f6 e8 09 94 fd ff 48 8b bd 28 01 00 00 [ 46.41] vlc[1778]: segfault at 24 ip 7fcc272a4c06 sp 7fcbf9e01c50 error 6 in iris_dri.so[7fcc2688b000+d2e000] [ 46.420006] Code: 7e 30 44 01 ff 81 ff ff ff 00 00 0f 87 ab 17 00 00 49 01 c7 4c 89 7e 38 48 85 c0 0f 84 2c 02 00 00 83 ea 01 81 ca 00 00 09 78 <89> 10 48 8d 50 04 45 85 ed 74 74 41 8d 75 ff 48 8d 74 f0 0c 66 0f [ 57.343120] glxgears[1785]: segfault at 24 ip 7f4a1467ec06 sp 7ffd2389b2f0 error 6 in iris_dri.so[7f4a13c65000+d2e000] [ 57.343126] Code: 7e 30 44 01 ff 81 ff ff ff 00 00 0f 87 ab 17 00 00 49 01 c7 4c 89 7e 38 48 85 c0 0f 84 2c 02 00 00 83 ea 01 81 ca 00 00 09 78 <89> 10 48 8d 50 04 45 85 ed 74 74 41 8d 75 ff 48 8d 74 f0 0c 66 0f https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash "error 4" == 0: no page found, 0: read access, 1: user-mode access "error 6" == 0: no page found, 1: write access, 1: user-mode access echo -n "find /b ..., ..., 0x" && \ > echo "44 24 18 48 c7 44 24 10 00 00 00 00 48 c7 44 24 18 00 00 00 00 50 4c 8d > 4c 24 18 e8 e2 a4 b6 ff 48 8b 44 24 18 31 d2 48 89 ef <4c> 8b b0 a0 00 00 00 > 4c 89 f6 e8 09 94 fd ff 48 8b bd 28 01 00 00" \ > | sed 's/[<>]//g' | sed 's/ /, 0x/g' find /b ..., ..., 0x44, 0x24, 0x18, 0x48, 0xc7, 0x44, 0x24, 0x10, 0x00, 0x00, 0x00, 0x00, 0x48, 0xc7, 0x44, 0x24, 0x18, 0x00, 0x00, 0x00, 0x00, 0x50, 0x4c, 0x8d, 0x4c, 0x24, 0x18, 0xe8, 0xe2, 0xa4, 0xb6, 0xff, 0x48, 0x8b, 0x44, 0x24, 0x18, 0x31, 0xd2, 0x48, 0x89, 0xef, 0x4c, 0x8b, 0xb0, 0xa0, 0x00, 0x00, 0x00, 0x4c, 0x89, 0xf6, 0xe8, 0x09, 0x94, 0xfd, 0xff, 0x48, 0x8b, 0xbd, 0x28, 0x01, 0x00, 0x00 $ echo -n "find /b ..., ..., 0x" && \ > echo "7e 30 44 01 ff 81 ff ff ff 00 00 0f 87 ab 17 00 00 49 01 c7 4c 89 7e 38 > 48 85 c0 0f 84 2c 02 00 00 83 ea 01 81 ca 00 00 09 78 <89> 10 48 8d 50 04 45 > 85 ed 74 74 41 8d 75 ff 48 8d 74 f0 0c 66 0f" \ > | sed 's/[<>]//g' | sed 's/ /, 0x/g' find /b ..., ..., 0x7e, 0x30, 0x44, 0x01, 0xff, 0x81, 0xff, 0xff, 0xff, 0x00, 0x00, 0x0f, 0x87, 0xab, 0x17, 0x00, 0x00, 0x49, 0x01, 0xc7, 0x4c, 0x89, 0x7e, 0x38, 0x48, 0x85, 0xc0, 0x0f, 0x84, 0x2c, 0x02, 0x00, 0x00, 0x83, 0xea, 0x01, 0x81, 0xca, 0x00, 0x00, 0x09, 0x78, 0x89, 0x10, 0x48, 0x8d, 0x50, 0x04, 0x45, 0x85, 0xed, 0x74, 0x74, 0x41, 0x8d, 0x75, 0xff, 0x48, 0x8d, 0x74, 0xf0, 0x0c, 0x66, 0x0f # Unstable amd64 qemu VM 2020-04-04 apt update apt dist-upgrade apt install systemd-coredump sddm xserver-xorg openbox xterm gdb mesa-utils mesa-utils-dbgsym libgl1-mesa-dri-dbgsym gdb -q set width 0 set pagination off file /usr/bin/glxgears b main set environment LD_PRELOAD=/usr/lib/x86_64-linux-gnu/dri/iris_dri.so run dele 1 info share find ... b * (... + 42) info b $ gdb -q (gdb) set width 0 (gdb) set pagination off (gdb) file /usr/bin/glxgears Reading symbols from /usr/bin/glxgears... Reading symbols from /usr/lib/debug/.build-id/40/dc623a2c150d26c9229676fba7f45a49aed7d7.debug... (gdb) b main Breakpoint 1 at 0x2410: file glxgears.c, line 723. (gdb) set environment LD_PRELOAD=/usr/lib/x86_64-linux-gnu/dri/iris_dri.so (gdb) run Starting program: /usr/bin/glxgears [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Breakpoint 1, main (argc=1, argv=0x7fffe608) at glxgears.c:723 723 glxgears.c: Datei oder Verzeichnis nicht gefunden. (gdb) dele 1 (gdb) info share FromTo Syms
Bug#955206: freeradius: Daemon has write privilege to configuration
Am 03.04.20 um 15:10 schrieb wf...@niif.hu: Hi, > "Debian Bug Tracking System" writes: > >> - set ReadOnlyDirectories to the configuration (Closes: #955206) > > Well, not very transparent or general, but certainly address my main > concern. However, the file ownerships still send the wrong message to > me. Could you please explain why the configuration files are owned by > the freerad user? To be honest I have no idea, this was way before my time. I think it was introduced here in 3.0.12+dfsg-2, shortly before Stretch https://salsa.debian.org/debian/freeradius/-/commit/42abc545ac8cdf376582ef81701f8db1ab0c3511#bee60e2d25c9ef61ebd4c5d27fecf8ab0a79dd6b I'm open to changing that, but I currently lack the time to properly test a migration path. If you have a tested patch, feel free to reopen and attach it. Bernhard
Bug#955543: Freeradius - Not working sysvinit script
Control: fixed -1 3.0.20+dfsg-1 Am 02.04.20 um 11:44 schrieb Jan Korbel: Hi Jan, > We have a problem with freeradius init script after upgrade to > up-to-date Deb10 with sysvinit. It is not possible to reload > configuration or stop daemon. Thanks for the report. This has already been fixed in unstable. You can pull in that version via buster-backports as well. I'll have a look at fixing it with an upload to stable, but right now I don't have a Radius server on stable so I can't really test. Bernhard
Bug#955407: linux-image-4.19.0-8-amd64: "Uhhuh. NMI received for unknown reason" on AMD Ryzen
Dear Maintainer, I observed such logging, too. My system is similar to the submitters one. Found two occourences in still available kern.log* files. (See attached file.) One was most probably related to a "GPU fault" 25 seconds before, running 4.19.0-8-amd64/4.19.98-1. The other was while not being at the idling system, running 5.4.0-0.bpo.3-amd64/5.4.13-1~bpo10+1. No negative consequence found at that time. Kind regards, Bernhard # LANG=C lscpu ... CPU family: 23 Model: 1 Model name: AMD Ryzen 7 1700 Eight-Core Processor Stepping:1 ... # (zcat kern.log.4.gz kern.log.3.gz kern.log.2.gz; cat kern.log.1 kern.log) | grep -E "NMI received|Linux version" -A3 Mar 7 00:10:29 rechner kernel: [0.00] Linux version 4.19.0-8-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.98-1 (2020-01-26) ... Mar 7 00:10:29 rechner kernel: [0.00] DMI: System manufacturer System Product Name/PRIME B350M-A, BIOS 4801 04/25/2019 ... Mar 7 00:13:49 rechner kernel: [ 205.788363] amdgpu :08:00.0: GPU fault detected: 147 0x0c304401 for process SOTTR.exe pid 3426 thread SOTTR.exe:cs0 pid 3448 Mar 7 00:13:49 rechner kernel: [ 205.788370] amdgpu :08:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x0FF22786 Mar 7 00:13:49 rechner kernel: [ 205.788373] amdgpu :08:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0E044001 Mar 7 00:13:49 rechner kernel: [ 205.788378] amdgpu :08:00.0: VM fault (0x01, vmid 7, pasid 32782) at page 267528070, read from 'TC1' (0x54433100) (68) ... Mar 7 00:13:49 rechner kernel: [ 205.788463] amdgpu :08:00.0: VM fault (0x01, vmid 7, pasid 32782) at page 142747517, read from 'TC1' (0x54433100) (68) Mar 7 00:13:59 rechner kernel: [ 215.998608] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=25858, emitted seq=25860 Mar 7 00:13:59 rechner kernel: [ 215.998615] [drm] GPU recovery disabled. Mar 7 00:14:14 rechner kernel: [ 230.580910] Uhhuh. NMI received for unknown reason 2d on CPU 7. Mar 7 00:14:14 rechner kernel: [ 230.580911] Do you have a strange power saving mode enabled? Mar 7 00:14:14 rechner kernel: [ 230.580914] Dazed and confused, but trying to continue Mar 7 00:15:17 rechner kernel: [ 294.139939] sysrq: SysRq : Keyboard mode set to system default Mar 7 00:15:20 rechner kernel: [ 296.891922] sysrq: SysRq : Terminate All Tasks (attempt to test Shadow of the Tomb Raider Trial via Steam, kernel crash dump available, at least the "GPU fault" was reproducible.) -- Mar 26 10:00:52 rechner kernel: [0.00] Linux version 5.4.0-0.bpo.3-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 5.4.13-1~bpo10+1 (2020-02-07) ... Mar 26 10:00:52 rechner kernel: [0.00] DMI: System manufacturer System Product Name/PRIME B350M-A, BIOS 4801 04/25/2019 ... Mar 29 07:27:08 rechner kernel: [246383.312487] Uhhuh. NMI received for unknown reason 3c on CPU 6. Mar 29 07:27:08 rechner kernel: [246383.312488] Do you have a strange power saving mode enabled? Mar 29 07:27:08 rechner kernel: [246383.312489] Dazed and confused, but trying to continue Mar 29 07:35:37 rechner kernel: [246892.656398] Process accounting resumed (system was at this time idle, no negative consequences recognized, system could be shutdown later without problems.)
Bug#562625: rovclock: Floating point exception on ATI Mobility Radeon HD 4570
Hello,
tries to find a way to underclock the gpu of an HP elitebook 8460p
with a radeon HD 6470M, because it does not handle well the 3d
requirements of a current plasma desktop and leads to the laptop
turning just off. (Turning off the compositor as a workaround.)
So "rovclock -i" leads on that system to the same exception.
This is just for the record as there might not be any
update for this package.
Kind regards,
Bernhard
(gdb) bt
#0 0x55acfe349488 in round_div (den=, num=)
at rovclock.c:178
#1 pll_info (rovclock=0x7ffc745acac0) at rovclock.c:256
#2 0x55acfe348e0c in main (argc=2, argv=0x7ffc745acc38) at rovclock.c:463
https://sources.debian.org/src/rovclock/0.6e-7/rovclock.c/#L178
https://sources.debian.org/src/rovclock/0.6e-7/rovclock.c/#L256
# rovclock -i
Radeon overclock 0.6e by Hasw (h...@hasw.net)
Found ATI card on 01:00, device id: 0x6760
I/O base address: 0x4000
Video BIOS shadow found @ 0xc
Invalid reference clock from BIOS: 0.0 MHz
Memory size: 0 kB
Memory channels: 1, CD,CH only: 0
tRcdRD: 3
tRcdWR: 1
tRP: 3
tRAS: 6
tRRD: 1
tR2W-CL: 1
tWR: 1
tW2R: 0
tW2Rsb: 0
tR2R: 1
tRFC: 13
tWL(0.5): 0
tCAS: 0
tCMD: 0
tSTR: 0
Gleitkomma-Ausnahme (Speicherabzug geschrieben)
dmesg:
[ 357.622976] traps: rovclock[1975] trap divide error ip:55acfe349488
sp:7ffc745acaa0 error:0 in rovclock[55acfe348000+3000]
journalctl -e
# coredumpctl list
TIMEPID UID GID SIG COREFILE EXE
Mon 2020-03-30 15:29:40 CEST 1975 0 0 8 present /usr/sbin/rovclock
# coredumpctl gdb
PID: 1975 (rovclock)
UID: 0 (root)
GID: 0 (root)
Signal: 8 (FPE)
Timestamp: Mon 2020-03-30 15:29:40 CEST (1min 39s ago)
Command Line: rovclock -i
Executable: /usr/sbin/rovclock
Control Group: /user.slice/user-1000.slice/session-5.scope
Unit: session-5.scope
Slice: user-1000.slice
Session: 5
Owner UID: 1000 (benutzer)
Boot ID: bff2520b59914f03b61e4827890a413a
Machine ID: c6f75e824dc44bdaaa07b94b9f66a5b3
Hostname: hpelitebook
Storage:
/var/lib/systemd/coredump/core.rovclock.0.bff2520b59914f03b61e4827890a413a.1975.158557498000.lz4
Message: Process 1975 (rovclock) of user 0 dumped core.
Stack trace of thread 1975:
#0 0x55acfe349488 n/a (rovclock)
#1 0x55acfe348e0c n/a (rovclock)
#2 0x7fd888b2c09b __libc_start_main (libc.so.6)
#3 0x55acfe348f7a n/a (rovclock)
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/rovclock...(no debugging symbols found)...done.
[New LWP 1975]
Core was generated by `rovclock -i'.
Program terminated with signal SIGFPE, Arithmetic exception.
#0 0x55acfe349488 in ?? ()
(gdb) bt
#0 0x55acfe349488 in ?? ()
#1 0x55acfe348e0c in ?? ()
#2 0x7fd888b2c09b in __libc_start_main (main=0x55acfe348c90, argc=2,
argv=0x7ffc745acc38, init=, fini=,
rtld_fini=, stack_end=0x7ffc745acc28) at ../csu/libc-start.c:308
#3 0x55acfe348f7a in ?? ()
# With rovclock-dbgsym installed
Core was generated by `rovclock -i'.
Program terminated with signal SIGFPE, Arithmetic exception.
#0 0x55acfe349488 in round_div (den=, num=)
at rovclock.c:178
178 rovclock.c: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0 0x55acfe349488 in round_div (den=, num=)
at rovclock.c:178
#1 pll_info (rovclock=0x7ffc745acac0) at rovclock.c:256
#2 0x55acfe348e0c in main (argc=2, argv=0x7ffc745acc38) at rovclock.c:463
https://sources.debian.org/src/rovclock/0.6e-7/rovclock.c/#L178
https://sources.debian.org/src/rovclock/0.6e-7/rovclock.c/#L256
# strace -f rovclock -i
execve("/usr/sbin/rovclock", ["rovclock", "-i"], 0x7ffe27b59230 /* 11 vars */)
= 0
brk(NULL) = 0x56284fd6d000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (Datei oder Verzeichnis
nicht gefunden)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=119455, ...}) = 0
mmap(NULL,
Bug#954856: Please add option to install signed grub bootloader
Hello Cyril My system don't start in case of Secure Boot is enabled. In Debian Wiki: https://wiki.debian.org/SecureBoot The package grub-efi-amd64-signed is not installed. This is a recommended package. But this package is necessary for Secure Boot. If i install a standard Debian installation, my system boot with Secure Boot. With a standard Debian installation, the recommended packages will be installed also. Please let me know, if you need further informations. Best regards Bernhard Am Samstag, den 28.03.2020, 21:51 +0100 schrieb Cyril Brulebois: > Hallo wieder, > > Bernhard (2020-03-28): > > Hello Cyril > > > > Thank you for feedback. > > Attached, there is the Syslog. > > Thanks. > > Then I think I'm not sure your bug report is correct: > > Mar 20 08:07:18 in-target: Paketlisten werden gelesen... > Mar 20 08:07:18 in-target: > Mar 20 08:07:18 in-target: Abhängigkeitsbaum wird aufgebaut > Mar 20 08:07:18 in-target: > Mar 20 08:07:18 in-target: Statusinformationen werden eingelesen > Mar 20 08:07:18 in-target: > Mar 20 08:07:18 in-target: Die folgenden zusätzlichen Pakete werden > installiert: > Mar 20 08:07:18 in-target: grub-efi-amd64-bin grub2-common > Mar 20 08:07:18 in-target: Empfohlene Pakete: > Mar 20 08:07:18 in-target: grub-efi-amd64-signed > Mar 20 08:07:18 in-target: Die folgenden NEUEN Pakete werden installiert: > Mar 20 08:07:18 in-target: grub-efi-amd64 grub-efi-amd64-bin > grub2-common > Mar 20 08:07:18 in-target: 0 aktualisiert, 3 neu installiert, 0 zu > entfernen und 0 nicht aktualisiert. > Mar 20 08:07:18 in-target: Es müssen 1.243 kB an Archiven heruntergeladen > werden. > Mar 20 08:07:18 in-target: Nach dieser Operation werden 9.393 kB > Plattenplatz zusätzlich benutzt. > Mar 20 08:07:18 in-target: Holen:1 http://192.168.178.2/debian > buster/main amd64 grub2-common amd64 2.02+dfsg1-20 [538 kB] > Mar 20 08:07:18 in-target: Holen:2 http://192.168.178.2/debian > buster/main amd64 grub-efi-amd64-bin amd64 2.02+dfsg1-20 [665 kB > […] > Mar 20 08:07:25 grub-installer: info: Additionally installing shim-signed > to go with grub-efi-amd64 > Mar 20 08:07:25 in-target: Paketlisten werden gelesen... > Mar 20 08:07:25 in-target: > Mar 20 08:07:25 in-target: Abhängigkeitsbaum wird aufgebaut > Mar 20 08:07:25 in-target: > Mar 20 08:07:25 in-target: Statusinformationen werden eingelesen > Mar 20 08:07:25 in-target: > Mar 20 08:07:25 in-target: Die folgenden zusätzlichen Pakete werden > installiert: > Mar 20 08:07:25 in-target: mokutil shim-helpers-amd64-signed > shim-signed-common shim-unsigned > Mar 20 08:07:25 in-target: Empfohlene Pakete: > Mar 20 08:07:25 in-target: secureboot-db > Mar 20 08:07:25 in-target: Die folgenden NEUEN Pakete werden installiert: > Mar 20 08:07:25 in-target: mokutil shim-helpers-amd64-signed > shim-signed shim-signed-common > Mar 20 08:07:25 in-target: shim-unsigned > Mar 20 08:07:25 in-target: 0 aktualisiert, 5 neu installiert, 0 zu > entfernen und 0 nicht aktualisiert. > Mar 20 08:07:25 in-target: Es müssen 1.380 kB an Archiven heruntergeladen > werden. > Mar 20 08:07:25 in-target: Nach dieser Operation werden 7.743 kB > Plattenplatz zusätzlich benutzt. > Mar 20 08:07:25 in-target: Holen:1 http://192.168.178.2/debian > buster/main amd64 mokutil amd64 0.3.0+1538710437.fb6250f-1 [22,6 kB] > Mar 20 08:07:25 in-target: Holen:2 http://192.168.178.2/debian > buster/main amd64 shim-unsigned amd64 15+1533136590.3beb971-7 [579 kB] > Mar 20 08:07:25 in-target: Holen:3 http://192.168.178.2/debian > buster/main amd64 shim-helpers-amd64-signed amd64 1+15+1533136590.3beb971+7 > [431 kB] > Mar 20 08:07:25 in-target: Holen:4 http://192.168.178.2/debian > buster/main amd64 shim-signed-common all 1.33+15+1533136590.3beb971-7 [13,3 > kB] > Mar 20 08:07:25 in-target: Holen:5 http://192.168.178.2/debian > buster/main amd64 shim-signed amd64 1.33+15+1533136590.3beb971-7 [335 kB] > > so you should have all needed bits to have Secure Boot up and running. > > See > https://debamax.com/blog/2019/04/19/an-overview-of-secure-boot-in-debian/ > for some overview on Debian vs. Secure Boot, including bits about GRUB > packages. > > > Cheers, signature.asc Description: This is a digitally signed message part
Bug#955134: kodi-bin-dbgsym: Does not contain debug information for kodi-x11
Package: kodi-bin-dbgsym Version: 2:18.6+dfsg1-1 Severity: normal Dear Maintainer, I attempted to add line information to bug 954782. Unfortunately I found that kodi-bin-dbgsym does not contain the debug information for the kodi-x11 binary. It does just contain debug information for kodi-xrandr and libdvdnav-x86_64-linux.so. Kind regards, Bernhard -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/12 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kodi-bin-dbgsym depends on: ii kodi-bin 2:18.6+dfsg1-1 kodi-bin-dbgsym recommends no packages. kodi-bin-dbgsym suggests no packages. -- no debconf information
Bug#954950: dislocker reports memory access error / segfault after call
Hello Michael, that is great news, just two points I want to mention: If you want to forward information to certain people, please send email to both, the bugs address and the person, e.g. use "reply all" in your mail client. And if you get e.g. "/lib/libdislocker.so.0.7" in your backtrace instead of a real source code line, then you may try to add additional dbgsym packages like in this case libdislocker0.7-dbgsym. And repeat the coredumpctl step, then it should provide better information. But not necessary now as you found the issue already. Kind regards, Bernhard
Bug#954739: gimp: GIMP crashed with a fatal error: fatal error: Segmentation fault
> #6 0x5614726b3f04 in gimp_param_spec_layer_id () > #7 0x5614725cea67 in gimp_pdb_compat_param_spec () > #8 0x5614725db487 in gimp_plug_in_handle_message () Hello Andre, I think this is the same thing as #953880, #953854, #953794. Please upgrade the gimp package to version 2.10.14-3 which should fix it. Kind regards, Bernhard
Bug#954901: ghostscript: runtime error: malloc(): invalid size (unsorted)
Dear Maintainer, I tried to collect some more information and might have found something. The allocator aborts at the backtrace below. A valgrind run points to the same function txt_add_fragment. There is seems that in line 2121 the allocation takes place with 12 bytes total, then a memset is done with 12 bytes. But in line 2126 the memcpy is done with 24 bytes. This is because allocation is done with penum->TextBufferIndex == 3, but the memcpy uses penum->text.size == 6. (For the given input file.) The same pattern in lines 2134 to 2139. But I have no clue if the variables are the right ones, or contain wrong values. It might be related to this upstream bug, which touches the same lines: https://bugs.ghostscript.com/show_bug.cgi?id=701877 Kind regards, Bernhard https://sources.debian.org/src/ghostscript/9.52%7Edfsg-1/devices/vector/gdevtxtw.c/#L2121 https://git.ghostscript.com/?p=ghostpdl.git;a=blob;f=devices/vector/gdevtxtw.c;h=87f9355d8771e1fa546b4eb687ae4078ef2abdff;hb=HEAD#l2121 2121 penum->text_state->Widths = (float *)gs_malloc(tdev->memory->stable_memory, 2122 penum->TextBufferIndex, sizeof(float), "txtwrite alloc widths array"); 2123 if (!penum->text_state->Widths) 2124 return gs_note_error(gs_error_VMerror); 2125 memset(penum->text_state->Widths, 0x00, penum->TextBufferIndex * sizeof(float)); 2126 memcpy(penum->text_state->Widths, penum->Widths, penum->text.size * sizeof(float)); (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x7fb706bae55b in __GI_abort () at abort.c:79 #2 0x7fb706c06ff8 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7fb706d13f3e "%s\n") at ../sysdeps/posix/libc_fatal.c:181 #3 0x7fb706c0e39a in malloc_printerr (str=str@entry=0x7fb706d16010 "malloc(): invalid size (unsorted)") at malloc.c:5339 #4 0x7fb706c11304 in _int_malloc (av=av@entry=0x7fb706d45b80 , bytes=bytes@entry=62) at malloc.c:3736 #5 0x7fb706c12a74 in __GI___libc_malloc (bytes=bytes@entry=62) at malloc.c:3058 #6 0x7fb7070a3445 in gs_heap_alloc_bytes (mem=0x5600c40c5c40, size=14, cname=0x7fb7072389c8 "txtwrite alloc sorted text buffer") at ./base/gsmalloc.c:191 #7 0x7fb706fe88e1 in txt_add_fragment (penum=0x5600c45abea8, tdev=) at ./devices/vector/gdevtxtw.c:2141 #8 textw_text_process (pte=0x5600c45abea8) at ./devices/vector/gdevtxtw.c:2241 #9 0x7fb70717b8a0 in op_show_continue (i_ctx_p=0x5600c40f9778) at ./psi/zchar.c:690 #10 op_show_continue (i_ctx_p=0x5600c40f9778) at ./psi/zchar.c:685 #11 0x7fb70715d739 in interp (perror_object=, pref=, pi_ctx_p=) at ./psi/interp.c:1300 #12 gs_call_interp (pi_ctx_p=pi_ctx_p@entry=0x5600c40c6590, pref=pref@entry=0x775a4350, user_errors=user_errors@entry=1, pexit_code=pexit_code@entry=0x775a43cc, perror_object=) at ./psi/interp.c:520 #13 0x7fb70715ec7a in gs_interpret (pi_ctx_p=pi_ctx_p@entry=0x5600c40c6590, pref=pref@entry=0x775a4350, user_errors=user_errors@entry=1, pexit_code=pexit_code@entry=0x775a43cc, perror_object=, perror_object@entry=0x775a43d0) at ./psi/interp.c:477 #14 0x7fb70715153e in gs_main_interpret (perror_object=0x775a43d0, pexit_code=0x775a43cc, user_errors=1, pref=0x775a4350, minst=) at ./psi/imain.c:791 #15 gs_main_run_string_end (minst=minst@entry=0x5600c40c64f0, user_errors=user_errors@entry=1, pexit_code=pexit_code@entry=0x775a43cc, perror_object=perror_object@entry=0x775a43d0) at ./psi/imain.c:791 #16 0x7fb7071515d1 in gs_main_run_string_with_length (str=, length=, perror_object=0x775a43d0, pexit_code=0x775a43cc, user_errors=1, minst=0x5600c40c64f0) at ./psi/imain.c:735 #17 gs_main_run_string_with_length (minst=0x5600c40c64f0, str=0x5600c41c2720 "<6f75742e706466>.runfile", length=24, user_errors=1, pexit_code=0x775a43cc, perror_object=0x775a43d0) at ./psi/imain.c:721 #18 0x7fb7071534ef in run_string (minst=minst@entry=0x5600c40c64f0, str=str@entry=0x5600c41c2720 "<6f75742e706466>.runfile", options=options@entry=3, user_errors=user_errors@entry=1, pexit_code=0x775a43cc, pexit_code@entry=0x0, perror_object=0x775a43d0, perror_object@entry=0x0) at ./psi/imainarg.c:1119 #19 0x7fb7071537e6 in runarg (minst=minst@entry=0x5600c40c64f0, arg=arg@entry=0x775a4508 "out.pdf", post=post@entry=0x7fb70725cc5c ".runfile", options=options@entry=3, user_errors=1, pexit_code=pexit_code@entry=0x0, perror_object=0x0, pre=0x7fb70723aced "") at ./psi/imainarg.c:1088 #20 0x7fb707153904 in argproc (arg=0x775a4508 "out.pdf", minst=0x5600c40c64f0) at ./psi/imainarg.c:1010 #21 argproc (minst=0x5600c40c64f0, arg=0x775a4508 "out.pdf") at ./psi/imainarg.c:995 #22 0x7fb707155010 in gs_main_init_with_args01 (minst=minst@entry=0x5600
Bug#954935: dbgsym packages for 2:4.9.5+dfsg-5+deb10u1? (winbind crashes when queried for user)
Dear Maintainer, I tried to start looking at the given backtrace, but could not find the winbind-dbgsym packages for 2:4.9.5+dfsg-5+deb10u1 like they are availabe for 2:4.9.5+dfsg-5. At least apt did not find it in buster-proposed-updates-debug and at snapshot.debian.org they are also not listed. Is there a source known for the dbgsym packages? Kind regards, Bernhard
Bug#954950: dislocker reports memory access error / segfault after call
Hello Michael, I am not involved in packaging dislocker but might have some points. This "error 14" should mean it cannot read from memory the next instruction to execute. This makes sense as the "ip" or "RIP" has a value of 0xbb6 which is unlikely to contain program code. If it is possible to install e.g. systemd-coredump more details of any crashes are tried to be collected. I guess for this kind of crash the output of "journalctl --no-pager" migth not reveal much more useful information, but "coredump gdb", with the command "bt" at the "(gdb)" prompt, might be able to show a reasonable backtrace. This would improve if the debug symbols in package dislocker-dbgsym could be installed, too. More hints on the debug symbol repositories and this topic in general are collected in [2]. Kind regards, Bernhard [1] https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash "error 14" == 0x14 == 0n20 == 0b10100 -> user-mode access, fault was an instruction fetch [2] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols
Bug#954203: Client splash and exit after login in
Hello Gulfstream, > Thanks for your reply! My next question is How to connect the xrdp server > using remmina client? I don't find where to set the glyph cache. in the previous mentioned upstream link to the remmina bug tracker in comment [1] is written that they added such flags, but I guess the version in buster does not yet contain it. My best hint would be to check for it in the version in buster-backports, as a workaround. > ... And When will the bug be resolve? This has to be answered by the xrdp maintainers. Kind regards, Bernhard [1] https://gitlab.com/Remmina/Remmina/issues/1770#note_120907885
Bug#954856: Please add option to install signed grub bootloader
STeK Computer Inc. 8 Series/C220 Series Chipset Family > SMBus Controller [1043:18dd] > Kernel driver in use: i801_smbus > Kernel modules: i2c_i801 > 01:00.0 3D controller [0302]: NVIDIA Corporation GM107M [GeForce GTX 960M] > [10de:139b] (rev a2) > Subsystem: ASUSTeK Computer Inc. GM107M [GeForce GTX 960M] [1043:18dd] > Kernel driver in use: nouveau > Kernel modules: nouveau > 3b:00.0 Network controller [0280]: Intel Corporation Wireless 7260 > [8086:08b1] (rev bb) > Subsystem: Intel Corporation Dual Band Wireless-AC 7260 [8086:4170] > Kernel driver in use: iwlwifi > Kernel modules: iwlwifi > 3c:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5227 PCI > Express Card Reader [10ec:5227] (rev 01) > Subsystem: ASUSTeK Computer Inc. RTS5227 PCI Express Card Reader > [1043:18dd] > Kernel driver in use: rtsx_pci > Kernel modules: rtsx_pci Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect media: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: After installation in UEFI mode, everything works fine. No problems detected. One wish regarding GRUB Bootloader: Here, my preseed-file for installing GRUB: > # == > # GRUB-Installer > # == > > # Bootloader > d-i grub-installer/only_debian boolean true > d-i grub-installer/with_other_os boolean true > > # Install GRUB Bootloader to /dev/sda > d-i grub-installer/bootdev string /dev/sda If possible, please add an option for preseed-file to decide for install signed or unsigned GRUB installer. This is for Secure Boot. Currently, the signed GRUB Bootloader is not installed on my system, because the recommended packages are not installed: > d-i base-installer/install-recommends boolean false Thank you for the great work. Best regards Bernhard signature.asc Description: This is a digitally signed message part
Bug#954203: Client splash and exit after login in
Hello, this seems to be caused by xrdp using glyph cache even when the client does not advertise it. Additionally freerdp does now stricter checks. Upstream bugs are here [1]. A workaround could be to use xfreerdp like this: xfreerdp +glyph-cache /relax-order-checks /v:hostname Kind regards, Bernhard [1] https://github.com/neutrinolabs/xrdp/issues/1266 https://gitlab.com/Remmina/Remmina/issues/1770 https://github.com/FreeRDP/FreeRDP/issues/5072 https://github.com/FreeRDP/FreeRDP/issues/5207 # Unstable amd64 qemu VM 2020-03-21 apt update apt dist-upgrade apt install systemd-coredump xserver-xorg sddm openbox xrdp remmina freerdp2-x11 reboot adduser test $ dpkg -l | grep -E "remmina|rdp" ii libfreerdp-client2-2:amd64 2.0.0~git20190204.1.2693389a+dfsg1-2 amd64Free Remote Desktop Protocol library (client library) ii libfreerdp2-2:amd64 2.0.0~git20190204.1.2693389a+dfsg1-2 amd64Free Remote Desktop Protocol library (core library) ii remmina 1.4.1+dfsg-1 amd64GTK+ Remote Desktop Client ii remmina-common 1.4.1+dfsg-1 all Common files for Remmina ii remmina-plugin-rdp:amd64 1.4.1+dfsg-1 amd64RDP plugin for Remmina ii remmina-plugin-secret:amd64 1.4.1+dfsg-1 amd64Secret plugin for Remmina ii remmina-plugin-vnc:amd64 1.4.1+dfsg-1 amd64VNC plugin for Remmina ii xorgxrdp 1:0.2.12-1 amd64Remote Desktop Protocol (RDP) modules for X.org ii xrdp 0.9.12-1 amd64Remote Desktop Protocol (RDP) server export DISPLAY=:0 $ remmina Remmina plugin glibsecret (type=Secret) has registered but not yet initialized/activated. Initialization order is 2000. ** (process:730): CRITICAL **: 11:38:54.435: secret_service_load_collections_sync: assertion 'paths != NULL' failed [glibsecret] unable to get secret service: Unknown error. StatusNotifier/Appindicator support: not supported by desktop. libappindicator will try to fallback to GtkStatusIcon/xembed Warning: Remmina is running without a secret plugin. Passwords will be saved in a less secure way. (org.remmina.Remmina:730): Gtk-WARNING **: 11:38:54.612: gtk_menu_attach_to_widget(): menu already attached to GtkMenuItem [11:39:15:452] [730:764] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr [11:39:15:452] [730:764] [INFO][com.freerdp.client.common.cmdline] - loading channelEx drdynvc [11:39:15:499] [730:764] [INFO][com.freerdp.gdi] - Local framebuffer format PIXEL_FORMAT_BGRX32 [11:39:15:499] [730:764] [INFO][com.freerdp.gdi] - Remote framebuffer format PIXEL_FORMAT_BGRA32 [11:39:15:499] [730:764] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel rdpgfx [11:39:15:499] [730:764] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel disp [11:39:15:526] [730:764] [ERROR][com.freerdp.core.update] - [0x03] Cache Glyph - SERVER BUG: The support for this feature was not announced! Use /relax-order-checks to ignore [11:39:15:526] [730:764] [ERROR][com.freerdp.core.update] - order flags 03 failed [11:39:15:526] [730:764] [ERROR][com.freerdp.core.fastpath] - Fastpath update Orders [0] failed, status 0 [11:39:15:526] [730:764] [ERROR][com.freerdp.core.fastpath] - fastpath_recv_update_data: fastpath_recv_update() - -1 [11:39:15:526] [730:764] [ERROR][com.freerdp.core.fastpath] - fastpath_recv_update_data() fail [11:39:15:526] [730:764] [ERROR][com.freerdp.core.transport] - transport_check_fds: transport->ReceiveCallback() - -3 [11:39:15:526] [730:764] [ERROR][com.freerdp.core] - freerdp_check_fds() failed - 0 [11:39:15:066] [730:764] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel rdpgfx [11:39:15:066] [730:764] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel disp [11:39:15:083] [730:764] [ERROR][com.freerdp.core.update] - [0x03] Cache Glyph - SERVER BUG: The support for this feature was not announced! Use /relax-order-checks to ignore ... -> trying to connect over and over again $ xfreerdp /v:localhost [11:51:47:908] [715:716] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr [11:51:47:909] [715:716] [INFO][com.freerdp.client.x11] - No user name set. - Using login name: benutzer [11:51:47:950] [715:716] [INFO][com.freerdp.gdi] - Local framebuffer format PIXEL_FORMAT_BGRX32 [11:51:47:950] [715:716] [INFO][com.freerdp.gdi] - Remote framebuffer format PIXEL_FORMAT_RGB16 [11:51:47:986] [715:716] [INFO][com.winpr.clipboard] - initialized POSIX local file subsystem [11:51:47:991] [715:716] [ERROR][com.freerdp.core.update
Bug#953204: postgresql-11 segmentation fault
Hello, I just tried to get some more information from the second dmesg line the submitter added. I think it crashed inside function getmissingattr because tupleDesc->constr contains an invalid pointer e.g. -1 Maybe this is of any help, but still a proper backtrace or core would be better. Kind regards, Bernhard 0x5...a06 in getmissingattr at ./build/../src/backend/access/common/heaptuple.c:101 heaptuple.c: ... 84 getmissingattr(TupleDesc tupleDesc, ... 99 Assert(tupleDesc->constr->missing); 100 101 attrmiss = tupleDesc->constr->missing + (attnum - 1); 102 103 if (attrmiss->am_present) ... https://sources.debian.org/src/postgresql-11/11.7-0+deb10u1/src/backend/access/common/heaptuple.c/#L101 dmesg from submitter: [ 77.674822] postgres[879]: segfault at 55ae73423960 ip 7fd09d6741a7 sp 7ffc7e247c28 error 4 in libc-2.28.so[7fd09d53a000+148000] [ 77.680661] Code: f9 20 77 1f c5 fd 74 0f c5 fd d7 c1 85 c0 0f 85 df 00 00 00 48 83 c7 20 83 e1 1f 48 83 e7 e0 eb 36 66 90 83 e1 1f 48 83 e7 e0 fd 74 0f c5 fd d7 c1 d3 f8 85 c0 74 1b f3 0f bc c0 48 01 f8 48 [ 77.690252] postgres[884]: segfault at f ip 55ae597d1a06 sp 7ffc7e2474c0 error 4 in postgres[55ae597c5000+465000] [ 77.695474] Code: 83 c7 70 48 8d 48 01 49 39 c1 0f 84 04 01 00 00 48 89 c8 80 bf 81 00 00 00 00 74 d8 4c 8b 5e 18 48 89 c1 48 c1 e1 04 4c 01 c1 <49> 03 4b 10 80 39 00 74 c1 41 c6 04 02 00 48 8b 49 08 eb bd 66 0f --> "error 4": no page found, read access, user-mode access # Buster/stable amd64 qemu VM 2020-03-20 apt update apt dist-upgrade apt install systemd-coredump gdb postgresql postgresql-11-dbgsym # dpkg -l | grep postgres ii postgresql11+200+deb10u3 all object-relational SQL database (supported version) ii postgresql-11 11.7-0+deb10u1 amd64 object-relational SQL database, version 11 server ii postgresql-11-dbgsym 11.7-0+deb10u1 amd64 debug symbols for postgresql-11 ii postgresql-client-11 11.7-0+deb10u1 amd64 front-end programs for PostgreSQL 11 ii postgresql-client-common 200+deb10u3 all manager for multiple PostgreSQL client versions ii postgresql-common 200+deb10u3 all PostgreSQL database-cluster manager gdb -q set width 0 set pagination off file /usr/lib/postgresql/11/bin/postgres b main run dele 1 generate-core-file /tmp/core kill y q # https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash gdb -q set width 0 set pagination off file /usr/lib/postgresql/11/bin/postgres core /tmp/core info target ... Local exec file: `/usr/lib/postgresql/11/bin/postgres', file type elf64-x86-64. Entry point: 0x5560ae40 ... 0x55609d30 - 0x55a6c25e is .text ... echo -n "find /b ..., ..., 0x" && \ echo "83 c7 70 48 8d 48 01 49 39 c1 0f 84 04 01 00 00 48 89 c8 80 bf 81 00 00 00 00 74 d8 4c 8b 5e 18 48 89 c1 48 c1 e1 04 4c 01 c1 <49> 03 4b 10 80 39 00 74 c1 41 c6 04 02 00 48 8b 49 08 eb bd 66 0f" \ | sed 's/[<>]//g' | sed 's/ /, 0x/g' (gdb) find /b 0x55609d30, 0x55a6c25e, 0x83, 0xc7, 0x70, 0x48, 0x8d, 0x48, 0x01, 0x49, 0x39, 0xc1, 0x0f, 0x84, 0x04, 0x01, 0x00, 0x00, 0x48, 0x89, 0xc8, 0x80, 0xbf, 0x81, 0x00, 0x00, 0x00, 0x00, 0x74, 0xd8, 0x4c, 0x8b, 0x5e, 0x18, 0x48, 0x89, 0xc1, 0x48, 0xc1, 0xe1, 0x04, 0x4c, 0x01, 0xc1, 0x49, 0x03, 0x4b, 0x10, 0x80, 0x39, 0x00, 0x74, 0xc1, 0x41, 0xc6, 0x04, 0x02, 0x00, 0x48, 0x8b, 0x49, 0x08, 0xeb, 0xbd, 0x66, 0x0f 0x556149dc 1 pattern found. (gdb) b * (0x556149dc + 42) Breakpoint 1 at 0x55614a06: file ./build/../src/backend/access/common/heaptuple.c, line 101. (gdb) info b Num Type Disp Enb AddressWhat 1 breakpoint keep y 0x55614a06 in getmissingattr at ./build/../src/backend/access/common/heaptuple.c:101 (gdb) disassemble /r heap_deform_tuple Dump of assembler code for function heap_deform_tuple: 0x556147c0 <+0>: 55 push %rbp ... 0x556149db <+539>: 48 83 c7 70 add$0x70,%rdi 0x556149df <+543>: 48 8d 48 01 lea0x1(%rax),%rcx 0x556149e3 <+547>: 49 39 c1cmp%rax,%r9 0x556149e6 <+550>: 0f 84 04 01 00 00 je 0x55614af0 0x556149ec <+556>: 48 89 c8mov%rcx,%rax 0x556149ef <+559>: 80 bf 81 00 00 00 00cmpb $0x0,0x81(%rdi) 0x556149f6 <+566>: 74 d8 je 0x556149d0 0x556149f8 <+568>: 4c 8b 5e 18 mov0x18(%rsi),%r11 0x556149fc <+572>: 48 89 c1
Bug#954266: qemu-system-x86: graphical-mode monitor doesn't work
Hello, tried to collect some more details. Found that the failure started with the migration of these packages into testing: libvte-2.91-0 libvte-2.91-common (0.60.0-2) The monitor worked before with 0.58.3-1. Kind regards, Bernhard # Bullseye/testing amd64 qemu VM 2020-03-20 apt update apt dist-upgrade apt install systemd-coredump sddm xserver-xorg openbox xterm qemu-system export DISPLAY=:0 qemu-system-x86_64 (qemu,outside) sendkey ctrl-alt-2 # dpkg -l | grep 1:4.2-3 ii qemu-system-common 1:4.2-3 amd64 QEMU full system emulation binaries (common files) ii qemu-system-data 1:4.2-3 all QEMU full system emulation (data files) ii qemu-system-gui 1:4.2-3 amd64 QEMU full system emulation binaries (user interface and audio support) ii qemu-system-misc 1:4.2-3 amd64 QEMU full system emulation binaries (miscellaneous) ii qemu-system-x86 1:4.2-3 amd64 QEMU full system emulation binaries (x86) ii qemu-utils 1:4.2-3 amd64 QEMU utilities wget https://snapshot.debian.org/archive/debian/20191026T211939Z/pool/main/q/qemu/qemu-system-common_4.1-1%2Bb4_amd64.deb wget https://snapshot.debian.org/archive/debian/20190827T150849Z/pool/main/q/qemu/qemu-system-data_4.1-1_all.deb wget https://snapshot.debian.org/archive/debian/20191026T211939Z/pool/main/q/qemu/qemu-system-gui_4.1-1%2Bb4_amd64.deb wget https://snapshot.debian.org/archive/debian/20191026T211939Z/pool/main/q/qemu/qemu-system-misc_4.1-1%2Bb4_amd64.deb wget https://snapshot.debian.org/archive/debian/20191026T211939Z/pool/main/q/qemu/qemu-system-x86_4.1-1%2Bb4_amd64.deb wget https://snapshot.debian.org/archive/debian/20191026T211939Z/pool/main/q/qemu/qemu-utils_4.1-1%2Bb4_amd64.deb apt install libbluetooth3 dpkg -i *.deb -> already here wget https://snapshot.debian.org/archive/debian/20190528T165330Z/pool/main/q/qemu/qemu-system-common_3.1%2Bdfsg-8_amd64.deb wget https://snapshot.debian.org/archive/debian/20190528T101728Z/pool/main/q/qemu/qemu-system-data_3.1%2Bdfsg-8_all.deb wget https://snapshot.debian.org/archive/debian/20190528T165330Z/pool/main/q/qemu/qemu-system-gui_3.1%2Bdfsg-8_amd64.deb wget https://snapshot.debian.org/archive/debian/20190528T165330Z/pool/main/q/qemu/qemu-system-misc_3.1%2Bdfsg-8_amd64.deb wget https://snapshot.debian.org/archive/debian/20190528T165330Z/pool/main/q/qemu/qemu-system-x86_3.1%2Bdfsg-8_amd64.deb wget https://snapshot.debian.org/archive/debian/20190528T165330Z/pool/main/q/qemu/qemu-utils_3.1%2Bdfsg-8_amd64.deb wget https://snapshot.debian.org/archive/debian/20190831T031850Z/pool/main/n/nettle/libnettle6_3.5.1%2Breally3.4.1-1_amd64.deb wget https://snapshot.debian.org/archive/debian/20190924T204643Z/pool/main/b/brltty/libbrlapi0.6_5.6-11%2Bb1_amd64.deb wget https://snapshot.debian.org/archive/debian/20190109T223525Z/pool/main/v/virglrenderer/libvirglrenderer0_0.7.0-2_amd64.deb dpkg -i *.deb -> already here --> maybe caused by dependency ? # Buster/stable amd64 qemu VM 2020-03-20 sources.list # snapshot deb [check-valid-until=no] http://192.168.178.25:/debian-11-bullseye-snapshot.debian.org/ testing main #deb-src [check-valid-until=no] http://192.168.178.25:/debian-11-bullseye-snapshot.debian.org/ testing main #deb [check-valid-until=no] http://192.168.178.25:/debian-11-bullseye-debug-snapshot.debian.org/ testing-debug main approx: debian-11-bullseye-snapshot.debian.org https://snapshot.debian.org/archive/debian/20190801T00Z/ apt update apt dist-upgrade apt install systemd-coredump sddm xserver-xorg openbox xterm qemu-system reboot 20190801T00Z -> testing still works (qemu 1:3.1+dfsg-8) 20190901T00Z -> testing still works (qemu 1:3.1+dfsg-8) 20191001T00Z -> testing still works (qemu 1:4.1-1) 20191101T00Z -> testing still works (qemu 1:4.1-1+b2) 20191201T00Z -> testing still works (qemu 1:4.1-1+b4) 20200101T00Z -> testing still works (qemu 1:4.1-3) 20200201T00Z -> testing still works (qemu 1:4.2-1) 20200215T00Z -> testing still works (qemu 1:4.2-1) 20200301T00Z -> testing still works (qemu 1:4.2-3) 20200303T00Z -> testing still works (qemu 1:4.2-3) 20200305T00Z -> testing still works (qemu 1:4.2-3) 20200307T00Z -> testing still works (qemu 1:4.2-3) 20200309T00Z -> testing still works (qemu 1:4.2-3) 20200311T00Z -> testing still works (qemu 1:4.2-3) 20200313T00Z -> testing still works (qemu 1:4.2-3) 20200315T00Z -> testing still works (qemu 1:4.2-3) 20200316T00Z -> testing still works (qemu 1:4.2-3) apt install dconf-gsettings-backend dconf-service gpgv libdconf1 libicu63
Bug#954315: rastertopwg segfault
Hello Till, I am not the initial reporter of the issue and I cannot reproduce it, therefore cannot test the suggested change. Just tried to share my results. Kind regards, Bernhard
Bug#954315: rastertopwg segfault
Hello, the stack trace should look like this with line numbers, if it helps: 0x7...671 in __strlen_avx2 at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65 0x7...2f4 in _cups_strlcpy at string.c:739 0x5...a31 in main at rastertopwg.c:274 0x7...e09 in __libc_start_main at ../csu/libc-start.c:308 0x5...1a4 <_start+36> https://sources.debian.org/src/cups/2.3.1-11/cups/string.c/#L739 https://sources.debian.org/src/cups/2.3.1-11/filter/rastertopwg.c/#L274 Kind regards, Bernhard # From submitter: Stack trace of thread 31898: #0 0x7f7a61751671 __strlen_avx2 (libc.so.6 + 0x15e671) #1 0x7f7a618032f9 _cups_strlcpy (libcups.so.2 + 0x4d2f9) #2 0x55a058ca1a36 main (rastertopwg + 0x1a36) #3 0x7f7a61619e0b __libc_start_main (libc.so.6 + 0x26e0b) #4 0x55a058ca21aa _start (rastertopwg + 0x21aa) ### # Unstable amd64 qemu VM 2020-03-20 apt update apt dist-upgrade apt install systemd-coredump gdb cups cups-dbgsym libcups2-dbgsym reboot # dpkg -l | grep cups ii cups 2.3.1-11 amd64 Common UNIX Printing System(tm) - PPD/driver support, web interface ii cups-browsed 1.27.2-1 amd64 OpenPrinting CUPS Filters - cups-browsed ii cups-client 2.3.1-11 amd64 Common UNIX Printing System(tm) - client programs (SysV) ii cups-common 2.3.1-11 all Common UNIX Printing System(tm) - common files ii cups-core-drivers 2.3.1-11 amd64 Common UNIX Printing System(tm) - driverless printing ii cups-daemon 2.3.1-11 amd64 Common UNIX Printing System(tm) - daemon ii cups-dbgsym 2.3.1-11 amd64 debug symbols for cups ii cups-filters 1.27.2-1 amd64 OpenPrinting CUPS Filters - Main Package ii cups-filters-core-drivers 1.27.2-1 amd64 OpenPrinting CUPS Filters - Driverless printing ii cups-ipp-utils2.3.1-11 amd64 Common UNIX Printing System(tm) - IPP developer/admin utilities ii cups-ppdc 2.3.1-11 amd64 Common UNIX Printing System(tm) - PPD manipulation utilities ii cups-server-common2.3.1-11 all Common UNIX Printing System(tm) - server common files ii libcups2:amd642.3.1-11 amd64 Common UNIX Printing System(tm) - Core library ii libcups2-dbgsym:amd64 2.3.1-11 amd64 debug symbols for libcups2 ii libcupsfilters1:amd64 1.27.2-1 amd64 OpenPrinting CUPS Filters - Shared library gdb -q set width 0 set pagination off file /usr/lib/cups/filter/rastertopwg b main run dele 1 generate-core-file /tmp/core kill y q gdb -q set width 0 set pagination off file /usr/lib/cups/filter/rastertopwg core /tmp/core disassemble _start b *0x61a4 disassemble __libc_start_main b *0x77d8ee09 disassemble main b *0x5a31 disassemble _cups_strlcpy b *0x77f782f4 disassemble __strlen_avx2 b *0x77ec6671 info b 0x77ec6671 in __strlen_avx2 at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65 0x77f782f4 in _cups_strlcpy at string.c:739 0x5a31 in main at rastertopwg.c:274 0x77d8ee09 in __libc_start_main at ../csu/libc-start.c:308 0x61a4 <_start+36> 0x7...671 in __strlen_avx2 at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65 0x7...2f4 in _cups_strlcpy at string.c:739 0x5...a31 in main at rastertopwg.c:274 0x7...e09 in __libc_start_main at ../csu/libc-start.c:308 0x5...1a4 <_start+36> https://sources.debian.org/src/cups/2.3.1-11/cups/string.c/#L739 https://sources.debian.org/src/cups/2.3.1-11/filter/rastertopwg.c/#L274
Bug#954330: GIMP 2 .10 crash
Hello Valentin, this looks similar to bug #953794, #953854 or #953880. Kind regards, Bernhard
Bug#953412: apt: segfault at 0 ip 00007f024bc54e6f sp 00007ffcc6b28d40 error 4 in libapt-pkg.so.5.0.2
Hello, I tried to locate the source line of the address shown in the /var/log/messages output. But that failed but I found in the strace output that it loads for some reason two libapt-pkg.so files ... ... openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libapt-pkg.so.6.0", O_RDONLY|O_CLOEXEC) = 3 ... openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libapt-pkg.so.5.0", O_RDONLY|O_CLOEXEC) = 3 ... Just in case if that helps. Kind regards, Bernhard
Bug#914813: AXP813 configuration for BananaPi M3
Hello Vagrant > I presume this is configs/Sinovoip_BPI_M3_defconfig ? Yes. This is correct. Best regards Bernhard signature.asc Description: This is a digitally signed message part
Bug#931630: ntp: Please include patch to fix build on m68k (alignment)
On Mon, Jul 08, 2019 at 02:52:39PM +0200, John Paul Adrian Glaubitz wrote: Hi, > Due to its native alignment being 16 bits wide, m68k needs an additional > padding in the struct conf_restrict: This has supposedly been fixed in 4.2.8p14 (according to https://bugs.ntp.org/show_bug.cgi?id=3599 and I do see the diff), but the build is still failing with the same error https://buildd.debian.org/status/fetch.php?pkg=ntp=m68k=1%3A4.2.8p14%2Bdfsg-1=1583525084=0 Bernhard
Bug#914813: AXP813 configuration for BananaPi M3
Hello, I had an additional look for the possible problem with the AXP813 for BananaPi M3 in U-Boot. With help of Google, i found a patchset for U-Boot from 2016: https://lists.denx.de/pipermail/u-boot/2016-January/240259.html > +++ b/configs/Bananapi_m3_defconfig > @@ -0,0 +1,25 @@ > +CONFIG_ARM=y > +CONFIG_ARCH_SUNXI=y > +CONFIG_MACH_SUN8I_A83T=y > +CONFIG_DRAM_CLK=480 > +CONFIG_DRAM_ZQ=15355 > +CONFIG_DRAM_ODT_EN=y > +CONFIG_SYS_EXTRA_OPTIONS="DRAM_TYPE=7" > +#CONFIG_USB0_VBUS_PIN="AXP0-VBUS-ENABLE" > +#CONFIG_USB0_VBUS_DET="AXP0-VBUS-DETECT" > +CONFIG_AXP_GPIO=y > +#CONFIG_USB_MUSB_HOST=y > +CONFIG_DEFAULT_DEVICE_TREE="sun8i-a83t-bananapi-m3-v1.2" > +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > +CONFIG_SPL=y > +# CONFIG_CMD_IMLS is not set > +# CONFIG_CMD_FLASH is not set > +# CONFIG_CMD_FPGA is not set > +CONFIG_AXP_DCDC1_VOLT=3000 > +CONFIG_AXP_DCDC2_VOLT=900 > +CONFIG_AXP_DCDC3_VOLT=900 > +CONFIG_AXP_DCDC4_VOLT=0 > +CONFIG_AXP_DCDC5_VOLT=1200 > +CONFIG_AXP_ALDO2_VOLT=0 > +CONFIG_AXP_ALDO3_VOLT=0 > +CONFIG_AXP_DLDO4_VOLT=0 > -- In the Debian configuration, i found the following: > CONFIG_ARM=y > CONFIG_ARCH_SUNXI=y > CONFIG_NR_DRAM_BANKS=1 > CONFIG_SPL=y > CONFIG_MACH_SUN8I_A83T=y > CONFIG_DRAM_TYPE=7 > CONFIG_DRAM_CLK=480 > CONFIG_DRAM_ZQ=15355 > CONFIG_DRAM_ODT_EN=y > CONFIG_MMC_SUNXI_SLOT_EXTRA=2 > CONFIG_INITIAL_USB_SCAN_DELAY=500 > CONFIG_USB0_VBUS_PIN="AXP0-VBUS-ENABLE" > CONFIG_USB0_VBUS_DET="AXP0-VBUS-DETECT" > CONFIG_USB0_ID_DET="PH11" > CONFIG_USB1_VBUS_PIN="PD24" > CONFIG_AXP_GPIO=y > CONFIG_SATAPWR="PD25" > # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > CONFIG_USE_PREBOOT=y > CONFIG_CONSOLE_MUX=y > # CONFIG_SPL_DOS_PARTITION is not set > # CONFIG_SPL_EFI_PARTITION is not set > CONFIG_DEFAULT_DEVICE_TREE="sun8i-a83t-bananapi-m3" > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > CONFIG_PHY_REALTEK=y > CONFIG_SUN8I_EMAC=y > CONFIG_AXP_DCDC5_VOLT=1200 > CONFIG_AXP_DLDO3_VOLT=3300 > CONFIG_AXP_SW_ON=y > CONFIG_USB_EHCI_HCD=y > CONFIG_USB_OHCI_HCD=y > CONFIG_USB_MUSB_HOST=y > CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y Some CONFIG_AXP_... are missing in the Debian configuration. Is it possible, that these missing AXP-configs have to be added in the Debian configuration? If i can do some tests, please let me know. Thank you for the great support. Best regards Bernhard signature.asc Description: This is a digitally signed message part
Bug#952684: cups: segfault in printers.cgi when browsing finished jobs in the cups webpage
Package: cups
Version: 2.2.10-6+deb10u2
Severity: normal
Dear Maintainer,
I found today some suspicious segfault line in dmesg output and
could reproduce it every time I loaded the finished jobs of a printer
with this URL:
http://localhost:631/printers/Samsung_CLX-3180_Series?which_jobs=completed
This is the dmesg output:
kernel: printers.cgi[3587]: segfault at 0 ip 7f05a859e181 sp
7fffcf0fb678 error 4 in libc-2.28.so[7f05a8464000+148000]
kernel: Code: 84 00 00 00 00 00 0f 1f 00 31 c0 c5 f8 77 c3 66 2e 0f 1f 84
00 00 00 00 00 89 f9 48 89 fa c5 f9 ef c0 83 e1 3f 83 f9 20 77 1f fd 74 0f
c5 fd d7 c1 85 c0 0f 85 df 00 00 00 48 83 c7 20 83 e1
Unfortunately no core was collected by systemd-coredump, but
I could generate one manually by running it in gdb described in
attached file.
(gdb) bt
#0 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
#1 0x7f02ba505dae in __GI___strdup (s=0x0) at strdup.c:41
#2 0x556d4f025055 in cgiGetArray (name=name@entry=0x7fffd550ce11
"job_name", element=element@entry=0) at var.c:171
#3 0x556d4f023cdc in cgi_copy (out=out@entry=0x7f02ba63a760
<_IO_2_1_stdout_>, in=in@entry=0x556d4f068590, element=element@entry=0,
term=term@entry=125 '}', indent=indent@entry=4) at template.c:299
#4 0x556d4f0245fe in cgi_copy (out=out@entry=0x7f02ba63a760
<_IO_2_1_stdout_>, in=in@entry=0x556d4f068590, element=element@entry=0,
term=term@entry=125 '}', indent=indent@entry=2) at template.c:348
#5 0x556d4f023ee6 in cgi_copy (out=0x7f02ba63a760 <_IO_2_1_stdout_>,
in=in@entry=0x556d4f068590, element=element@entry=0, term=term@entry=0 '\000',
indent=indent@entry=0) at template.c:602
#6 0x556d4f024977 in cgiCopyTemplateLang
(tmpl=tmpl@entry=0x556d4f027091 "jobs.tmpl") at template.c:148
#7 0x556d4f02206e in cgiShowJobs (http=,
dest=0x7fffd5510ee0 "Samsung_CLX-3180_Series") at ipp-var.c:1506
#8 0x556d4f01f9e6 in show_printer (printer=0x7fffd5510ee0
"Samsung_CLX-3180_Series", http=0x556d4f06c370) at printers.c:540
#9 main () at printers.c:137
...
(gdb) up
#2 0x556d4f025055 in cgiGetArray (name=name@entry=0x7fffd550ce11
"job_name", element=element@entry=0) at var.c:171
171 return (strdup(var->values[element]));
I found an upstream change that leaves cgiGetArray
if "var->values[element]" would be a NULL value [1].
This change reached bullseye/testing already, therefore
just buster/stable would be affected [2].
But I am not sure if this is the real problem as the
file /var/spool/cups/c00208 really contains a "job-name",
but no "job_name".
My guess is the "job_name" originates from
/usr/share/cups/templates/de/jobs.tmpl.
Therefore might this be a internationalisation issue?
A package cups built with the patch in [1] makes the
finished jobs page load completely.
All print jobs show as name unknown ("Unbekannt"),
except some recent test pages.
Most regular prints are done from a kde environment e.g. okular.
So maybe this upstream patch is worth to be considered in stable?
And second, can someone confirm if this unknown name is an issue,
while the file in /var/spool/cups does contain a job-name?
When opening the kde print queue I get the job names - maybe it
is changed to unknown on purpose for security reasons?
In bullseye/testing the web page shows also unknown, even
when credentials were given before and test page is printed
from there. (Should this go into a separate bug?)
Kind regards,
Bernhard
[1]
https://github.com/apple/cups/commit/eda46e3aac94d42e4199d95befe99ff83afb098f
https://github.com/apple/cups/pull/5621
[2] https://sources.debian.org/src/cups/2.2.10-6+deb10u2/cgi-bin/var.c/#L171
https://sources.debian.org/src/cups/2.3.1-11/cgi-bin/var.c/#L173
-- System Information:
Debian Release: 10.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500,
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-7-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages cups depends on:
ii cups-client2.2.10-6+deb10u2
ii cups-common2.2.10-6+deb10u2
ii cups-core-drivers 2.2.10-6+deb10u2
ii cups-daemon2.2.10-6+deb10u2
ii cups-filters 1.21.6-5
ii cups-ppdc 2.2.10-6+deb10u2
ii cups-server-common 2.2.10-6+deb10u2
ii debconf [debconf-2.0] 1.5.71
ii ghostscript9.27~dfsg-2+deb10u3
ii libavahi-client3 0.7-4+b1
ii libavahi-common3 0.7-4+b1
ii libc6
Bug#948996: freeradius: Consider including support for collectd when compiling freeradius.
Control: block -1 by 933296 On Wed, Jan 15, 2020 at 01:59:54PM -0500, Munroe wrote: Dear Munroe, > Radsniff was introduced in the 3.x.x branch of code and when coupled > with collectd can provide statistics collection. Including this > option does add a libcollectd dependency, but seeing that freeradius > already has a dozen or so libraries it depends on, this shouldn't add > too much bloat to the package. The libcollectdclient dependency, with Recommends enabled (default) installs 200 packages including Gtk, OpenJDK, ceph etc. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933296 I don't think this is worth it. Bernhard
Bug#951866: Debian sid successfully installed at AMD-K10 desktop PC
Package: installation-reports Boot method: USB-Stick with self-made ISO image with daily build Image version: Self-made ISO image with daily build Date: 2020-02-22 Machine: Self-made Desktop PC Processor: AMD A10-5700 APU with Radeon(tm) HD Graphics Memory: 4GB Partitions: > DateisystemTyp 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf > udev devtmpfs 1584760 0 15847600% /dev > tmpfs tmpfs 320400 8843195161% /run > /dev/sda1 ext4 111556948 6820220 990269047% / > tmpfs tmpfs 1601992 12252 15897401% /dev/shm > tmpfs tmpfs 5120 4 51161% /run/lock > tmpfs tmpfs 1601992 0 16019920% /sys/fs/cgroup > tmpfs tmpfs 320396 603203361% /run/user/1000 Output of lspci -knn (or lspci -nn): > 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h > (Models 10h-1fh) Processor Root Complex [1022:1410] > Subsystem: ASUSTeK Computer Inc. Family 15h (Models 10h-1fh) Processor > Root Complex [1043:8526] > 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. > [AMD/ATI] Trinity [Radeon HD 7660D] [1002:9901] > Subsystem: ASUSTeK Computer Inc. Trinity [Radeon HD 7660D] [1043:8526] > Kernel driver in use: radeon > Kernel modules: radeon > 00:01.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Trinity > HDMI Audio Controller [1002:9902] > Subsystem: ASUSTeK Computer Inc. Trinity HDMI Audio Controller > [1043:8526] > Kernel driver in use: snd_hda_intel > Kernel modules: snd_hda_intel > 00:10.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB > XHCI Controller [1022:7812] (rev 03) > Subsystem: ASUSTeK Computer Inc. FCH USB XHCI Controller [1043:8527] > Kernel driver in use: xhci_hcd > Kernel modules: xhci_pci > 00:10.1 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB > XHCI Controller [1022:7812] (rev 03) > Subsystem: ASUSTeK Computer Inc. FCH USB XHCI Controller [1043:8527] > Kernel driver in use: xhci_hcd > Kernel modules: xhci_pci > 00:11.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] FCH SATA > Controller [AHCI mode] [1022:7801] (rev 40) > Subsystem: ASUSTeK Computer Inc. FCH SATA Controller [AHCI mode] > [1043:8527] > Kernel driver in use: ahci > Kernel modules: ahci > 00:12.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB > OHCI Controller [1022:7807] (rev 11) > Subsystem: ASUSTeK Computer Inc. FCH USB OHCI Controller [1043:8527] > Kernel driver in use: ohci-pci > Kernel modules: ohci_pci > 00:12.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB > EHCI Controller [1022:7808] (rev 11) > Subsystem: ASUSTeK Computer Inc. FCH USB EHCI Controller [1043:8527] > Kernel driver in use: ehci-pci > Kernel modules: ehci_pci > 00:13.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB > OHCI Controller [1022:7807] (rev 11) > Subsystem: ASUSTeK Computer Inc. FCH USB OHCI Controller [1043:8527] > Kernel driver in use: ohci-pci > Kernel modules: ohci_pci > 00:13.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB > EHCI Controller [1022:7808] (rev 11) > Subsystem: ASUSTeK Computer Inc. FCH USB EHCI Controller [1043:8527] > Kernel driver in use: ehci-pci > Kernel modules: ehci_pci > 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller > [1022:780b] (rev 14) > Subsystem: ASUSTeK Computer Inc. FCH SMBus Controller [1043:8527] > Kernel driver in use: piix4_smbus > Kernel modules: i2c_piix4, sp5100_tco > 00:14.2 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] FCH Azalia > Controller [1022:780d] (rev 01) > Subsystem: ASUSTeK Computer Inc. F2A85-M Series [1043:8444] > Kernel driver in use: snd_hda_intel > Kernel modules: snd_hda_intel > 00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge > [1022:780e] (rev 11) > Subsystem: ASUSTeK Computer Inc. FCH LPC Bridge [1043:8527] > 00:14.4 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] FCH PCI Bridge > [1022:780f] (rev 40) > 00:15.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Hudson PCI to > PCI bridge (PCIE port 0) [1022:43a0] > Kernel driver in use: pcieport > 00:15.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Hudson PCI to > PCI bridge (PCIE port 1) [1022:43a1] > Kernel driver in use: pcieport > 00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h > (Models 10h-1fh) Processor Function 0 [1022:1400] > 00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h > (Models 10h-1fh) Processor Function 1 [1022:1401] > 00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h > (Models
Bug#914813: Test with current daily
Hello, I did a test again. Within installer, there is no ethernet card detected. Attached, there is the complete Log from U-Boot to start of the installer. I assume, there is something wrong with the AXP-regulator. There is the message some times: >> sun8i-a83t-r-pinctrl 1f02c00.pinctrl: 1f02c00.pinctrl supply vcc-pl not >> found, using dummy regulator << If i can do some tests, please let me know. Thank you for the great support. Best regards Bernhard U-Boot SPL 2020.01+dfsg-2 (Feb 13 2020 - 06:29:38 +) DRAM: 2048 MiB Trying to boot from MMC1 U-Boot 2020.01+dfsg-2 (Feb 13 2020 - 06:29:38 +) Allwinner Technology CPU: Allwinner A83T (SUN8I 1673) Model: Banana Pi BPI-M3 DRAM: 2 GiB MMC: Device 'mmc@1c11000': seq 1 is in use by 'mmc@1c1' mmc@1c0f000: 0, mmc@1c1: 2, mmc@1c11000: 1 Loading Environment from FAT... Unable to use mmc 1:0... In:serial Out: serial Err: serial Net: phy interface7 eth0: ethernet@1c3 starting USB... Bus usb@1c19000: No host cable detected: Port not available. Bus usb@1c1a000: USB EHCI 1.00 scanning bus usb@1c1a000 for devices... Device NOT ready Request Sense returned 02 3A 00 3 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 2 1 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot.scr 1575 bytes read in 3 ms (512.7 KiB/s) ## Executing script at 4310 Mainline u-boot / new-style environment detected. 4559360 bytes read in 445 ms (9.8 MiB/s) 23505 bytes read in 16 ms (1.4 MiB/s) 23787656 bytes read in 2317 ms (9.8 MiB/s) Booting the Debian installer... ## Flattened Device Tree blob at 4300 Booting using the fdt blob at 0x4300 Loading Ramdisk to 4895, end 49fff888 ... OK Loading Device Tree to 48947000, end 4894fbd0 ... OK Starting kernel ... 0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 5.4.0-4-armmp (debian-ker...@lists.debian.org) (gcc version 9.2.1 20200203 (Debian 9.2.1-28)) #1 SMP Debian 5.4.19-1 (2020-02-13) [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d [0.00] CPU: div instructions available: patching division code [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] OF: fdt: Machine model: Banana Pi BPI-M3 [0.00] Memory policy: Data cache writealloc [0.00] efi: Getting EFI parameters from FDT: [0.00] efi: UEFI not found. [0.00] cma: Reserved 16 MiB at 0xbf00 [0.00] percpu: Embedded 21 pages/cpu s53388 r8192 d24436 u86016 [0.00] Built 1 zonelists, mobility grouping on. Total pages: 521984 [0.00] Kernel command line: console=ttyS0,115200 [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear) [0.00] mem auto-init: stack:off, heap alloc:off, heap free:off [0.00] Memory: 2015548K/2097152K available (9216K kernel code, 1175K rwdata, 3012K rodata, 2048K init, 321K bss, 65220K reserved, 16384K cma-reserved, 1294336K highmem) [0.00] random: get_random_u32 called from __kmem_cache_create+0x48/0x514 with crng_init=0 [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1 [0.00] ftrace: allocating 35195 entries in 69 pages [0.00] rcu: Hierarchical RCU implementation. [0.00] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies. [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 [0.00] arch_timer: cp15 timer(s) running at 24.00MHz (virt). [0.00] clocksource: arch_sys_counter: mask: 0xff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns [0.10] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns [0.25] Switching to timer-based delay loop, resolution 41ns [0.001303] clocksource: timer: mask: 0x max_cycles: 0x, max_idle_ns: 79635851949 ns [0.002827] Console: colour dummy device 80x30 [0.002921] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=96000) [0.002939] pid_max: default: 32768 minimum: 301 [0.003228] LSM: Security Framework initializing [0.003363] Yama: disabled by default; enable with sysctl kernel.yama.* [0.003561] AppArmor: AppArmor initialized [0.003577] TOMOYO Linux initialized [0.003702] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, linear) [0.003726] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes, linear) [0.005689] CPU: Testing write buffer coherency: ok [0.006540] /cpus/cpu@0 missing clock-frequency property [0.006573] /cpus/cpu@1 missing clock-frequency property [0.006593] /cpus/cpu@2 missing clock-frequency property [0.006613] /cpus/cpu@3 missi
Bug#951565: freerdp2-x11: does not work at all, immediately exits, against xrdp server (rdesktop works)
Hi Thorsten, On Tue, Feb 18, 2020 at 07:18:23AM +0100, Thorsten Glaser wrote: > tglase@tglase-nb:~ $ xfreerdp /v:tglase-edge > > .. > [07:15:08:628] [29233:29234] [INFO][com.winpr.clipboard] - initialized POSIX > local file subsystem > [07:15:08:744] [29233:29234] [ERROR][com.freerdp.core.update] - [0x03] Cache > Glyph - SERVER BUG: The support for this feature was not announced! Use > /relax-order-checks to ignore > [07:15:08:745] [29233:29234] [INFO][com.freerdp.client.common] - Network > disconnect! > [07:15:08:745] [29233:29234] [ERROR][com.freerdp.client.x11] - Failed to > check FreeRDP file descriptor > .. > > I also tried xfreerdp /size:1000x768 /v:tglase-edge but that > does not change anything. FreeRDP does strict protocol level checks per default since a while. xrdp does use the glyph cache without announcing/negotiating it - this causes xfreerdp to close the connection. Give the options /relax-order-checks (as the error above indicates) and +glyph-cache a try. As reference also See: https://github.com/neutrinolabs/xrdp/issues/1229 and https://github.com/neutrinolabs/xrdp/issues/1266 Best regards, Bernhard
Bug#951468: symlinks: segfault when symlink is /..
Dear Maintainer,
I tried to debug this issue.
(gdb) bt
#0 tidy_path (path=0x55f0c81ea140 "/../") at symlinks.c:96
#1 0x55f0c7fe6908 in fix_symlink (my_dev=2049, path=0x55f0c81ec1e0
"/tmp/tmp.tlVVwIgOZQ/mylink") at symlinks.c:185
#2 0x55f0c7fe6e81 in dirwalk (pathlen=, dev=2049,
path=0x55f0c81ec1e0 "/tmp/tmp.tlVVwIgOZQ/mylink") at symlinks.c:290
#3 0x55f0c7fe5f1d in main (argc=, argv=0x7ffd5d3596f0)
at symlinks.c:376
I guess I found a buffer underrun in following lines:
76 static int tidy_path (char *path)
...
91 while ((p = strstr(path,"/../")) != NULL) {
92 s = p+3;
93 for (p--; p != path; p--) if (*p == '/') break;
In line 93 p equals path already but is decremented before the
condition 'p != path' is checked the first time.
Therefore this loop is just ended when the first '/' is found
before the begin of the path variable, which is "luckily" in our
case in the .rodata section of the executable, to that we want
to write in line 96.
This modification makes symlinks not crash and shows plausible output:
- for (p--; p != path; p--) if (*p == '/') break;
+ for (p--; p > path; p--) if (*p == '/') break;
Kind regards,
Bernhard
# Buster/stable amd64 qemu VM 2020-02-16
apt update
apt dist-upgrade
apt install systemd-coredump mc fakeroot symlinks gdb symlinks-dbgsym
apt build-dep symlinks
mkdir /home/benutzer/source/symlinks/orig -p
cd/home/benutzer/source/symlinks/orig
apt source symlinks
cd
cat < reproduce.sh
#! /usr/bin/env sh
MYTMP=\$(mktemp -d)
ln -s /.. \$MYTMP/mylink
symlinks \$MYTMP
EOF
chmod +x reproduce.sh
./reproduce.sh
journalctl --no-pager
coredumpctl list
coredumpctl gdb 1443
set width 0
set pagination off
directory /home/benutzer/source/symlinks/orig/symlinks-1.4
bt
###
###
###
benutzer@debian:~$ ./reproduce.sh
Segmentation fault (core dumped)
root@debian:~# journalctl --no-pager
...
Feb 17 23:49:17 debian kernel: symlinks[1443]: segfault at 55f0c81e70ed ip
55f0c7fe675a sp 7ffd5d359360 error 7 in symlinks[55f0c7fe5000+3000]
Feb 17 23:49:17 debian kernel: Code: 1d 0f 1f 80 00 00 00 00 80 3a 2f 74 11 48
83 ea 01 48 39 d5 75 f2 48 89 ea 80 3a 2f 75 29 31 c9 0f b6 74 08 03 bb 01 00
00 00 <40> 88 34 0a 48 83 c1 01 40 84 f6 75 e9 4c 89 e6 48 89 ef e8 0e f6
Feb 17 23:49:17 debian systemd[1]: Created slice
system-systemd\x2dcoredump.slice.
Feb 17 23:49:17 debian systemd[1]: Started Process Core Dump (PID 1444/UID 0).
Feb 17 23:49:17 debian systemd-coredump[1445]: Process 1443 (symlinks) of user
1000 dumped core.
Stack trace of thread 1443:
#0 0x55f0c7fe675a n/a
(symlinks)
#1 0x55f0c7fe6908 n/a
(symlinks)
#2 0x55f0c7fe6e81 n/a
(symlinks)
#3 0x55f0c7fe5f1d n/a
(symlinks)
#4 0x7fea02a9f09b
__libc_start_main (libc.so.6)
#5 0x55f0c7fe61da n/a
(symlinks)
Feb 17 23:49:17 debian systemd[1]: systemd-coredump@0-1444-0.service: Succeeded.
https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash
error 7 == 0b111
* bit 0 ==1: protection fault
* bit 1 ==1: write access
* bit 2 ==1: user-mode access
root@debian:~# coredumpctl list
TIMEPID UID GID SIG COREFILE EXE
Mon 2020-02-17 23:49:17 CET1443 1000 1000 11 present /usr/bin/symlinks
root@debian:~# coredumpctl gdb 1443
PID: 1443 (symlinks)
UID: 1000 (benutzer)
GID: 1000 (benutzer)
Signal: 11 (SEGV)
Timestamp: Mon 2020-02-17 23:49:17 CET (1min 25s ago)
Command Line: symlinks /tmp/tmp.tlVVwIgOZQ
Executable: /usr/bin/symlinks
Control Group: /user.slice/user-1000.slice/session-3.scope
Unit: session-3.scope
Slice: user-1000.slice
Session: 3
Owner UID: 1000 (benutzer)
Boot ID: 2d5d5576a57947a7aad042da5f907289
Machine ID: 33f18f39d2a9438eb75b0ed52848afcd
Hostname: debian
Storage:
/var/lib/systemd/coredump/core.symlinks.1000.2d5d5576a57947a7aad042da5f907289.1443.158197975700.lz4
Message: Process 1443 (symlinks) of user 1000 dumped core.
Stack trace of thread 1443:
#0 0x55f0c7fe675a n/a (symlinks)
#1 0x55f0c7fe6908 n/a (symlinks)
#2 0x55f0c7fe6e81 n/a (symlinks)
#3 0x55f0c7fe5f1d n/a (symlinks)
#4 0x7fea02a9f09b __libc_start_main (libc.so.6)
Bug#951412: proftpd-basic: segfault when logging in through sftp
Hello Tomas, Am 16.02.20 um 17:30 schrieb Tomas Janousek: > So unless that palloc tries to allocate way more memory than it should, > I don't think that's the problem. Unfortunately that allocation seems just "sizeof(pr_response_t)", so I guess it is not an unusual big allocation. Kind regards, Bernhard
Bug#951412: proftpd-basic: segfault when logging in through sftp
Dear Maintainer, I just tried to reconstruct the line informations from a running process with an attached gdb and installed dbgsym package. 0x7f373b3ad458 in __memset_sse2_unaligned at ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:120 0x55d7e2f68a64 in pcalloc at pool.c:620 0x55d7e2f8c778 in pr_response_add at response.c:281 0x7f373ab45822 in handle_userauth_req at auth.c:1502 0x7f373ab2de69 in sftp_ssh2_packet_handle at packet.c:1608 0x7f373ab29f12 in sftp_cmd_loop at mod_sftp.c:302 0x55d7e2f65222 in fork_server at main.c:1481 0x55d7e2f65acd in daemon_loop at main.c:1718 0x55d7e2f639bf in standalone_main at main.c:1903 0x7f373b32f09b in __libc_start_main () at ../csu/libc-start.c:308 0x55d7e2f63fca in _start () at main.c:2332 https://sources.debian.org/src/proftpd-dfsg/1.3.6-4+deb10u3/src/pool.c/#L620 https://sources.debian.org/src/proftpd-dfsg/1.3.6-4+deb10u3/src/response.c/#L281 Could the call to palloc just before have failed to allocate memory? Kind regards, Bernhard
Bug#950535: iptables-restore segfaults on nat table
Dear Maintainer,
I tried to collect some more information and got
the following backtrace with the restore command
from the submitter.
It looks like "expr->ops" contains a null pointer
that gets dereferenced.
Unfortunately I still see the same crash after
upgrading to the versions in backports in my test VM.
Also this crash is still visible in a minimal
Bullseye/testing VM.
Kind regards,
Bernhard
(gdb) bt
#0 0x7fd480466793 in nftnl_expr_build_payload (nlh=0x7fd47fc7a178,
expr=0x55fe70704f40) at expr.c:210
#1 0x7fd480461783 in nftnl_rule_nlmsg_build_payload (nlh=0x7fd47fc7a178,
r=0x55fe70705650) at rule.c:320
#2 0x55fe6e793c66 in nft_compat_rule_batch_add (h=,
type=, flags=, seq=,
rule=) at nft.c:2579
#3 0x55fe6e79493e in nft_action (h=0x7fff14b33560, action=0) at nft.c:2673
#4 0x55fe6e790555 in xtables_restore_parse (h=h@entry=0x7fff14b33560,
p=p@entry=0x7fff14b33540, cb=cb@entry=0x55fe6e7b8140 ,
argc=argc@entry=1, argv=argv@entry=0x7fff14b336e8) at xtables-restore.c:143
#5 0x55fe6e790f90 in xtables_restore_main (family=2, progname=, argc=1, argv=0x7fff14b336e8) at xtables-restore.c:474
#6 0x7fd47fcf709b in __libc_start_main (main=0x55fe6e78bfb0 ,
argc=1, argv=0x7fff14b336e8, init=, fini=,
rtld_fini=, stack_end=0x7fff14b336d8) at ../csu/libc-start.c:308
#7 0x55fe6e78bfea in _start ()
(gdb) print expr
$3 = (struct nftnl_expr *) 0x55fe70704f40
(gdb) print expr->ops
$4 = (struct expr_ops *) 0x0
(gdb) list expr.c:210
205
206 void nftnl_expr_build_payload(struct nlmsghdr *nlh, struct nftnl_expr
*expr)
207 {
208 struct nlattr *nest;
209
210 mnl_attr_put_strz(nlh, NFTA_EXPR_NAME, expr->ops->name);
211
212 if (!expr->ops->build)
213 return;
214
https://sources.debian.org/src/libnftnl/1.1.2-2/src/expr.c/#L210
# Buster/stable amd64 qemu VM 2020-02-11
apt update
apt dist-upgrade
apt install systemd-coredump mc git fakeroot strace gdb iptables-dbgsym
libnftnl11-dbgsym
apt build-dep iptables libnftnl11
mkdir /home/benutzer/source/libnftnl11/orig -p
cd/home/benutzer/source/libnftnl11/orig
apt source libnftnl11
cd
mkdir /home/benutzer/source/iptables/orig -p
cd/home/benutzer/source/iptables/orig
apt source iptables
cd
mkdir /home/benutzer/source/iptables/git -p
cd/home/benutzer/source/iptables/git
git clone git://git.netfilter.org/iptables
cd
iptables-restore < *nat
> -F PREROUTING
> -A PREROUTING -i eth0 -p tcp --dport 22 -j REDIRECT --to-ports 1194
> -F PREROUTING
> -F POSTROUTING
> COMMIT
> EOF
Speicherzugriffsfehler (Speicherabzug geschrieben)
# journalctl --no-pager
Feb 11 13:34:26 debian kernel: iptables-restor[1104]: segfault at 0 ip
7fd480466793 sp 7fff14b30530 error 4 in
libnftnl.so.11.0.0[7fd48045b000+17000]
Feb 11 13:34:26 debian kernel: Code: 0c 25 28 00 00 00 75 05 48 83 c4 18 c3 e8
b5 4a ff ff 0f 1f 44 00 00 41 54 55 48 89 fd 53 48 8b 46 18 48 89 f3 be 01 00
00 00 <48> 8b 10 e8 b5 51 ff ff 48 8b 43 18 48 83 78 30 00 74 32 48 89 ef
Feb 11 13:34:26 debian systemd[1]: Created slice
system-systemd\x2dcoredump.slice.
Feb 11 13:34:26 debian systemd[1]: Started Process Core Dump (PID 1105/UID 0).
Feb 11 13:34:26 debian systemd-coredump[1106]: Process 1104 (iptables-restor)
of user 0 dumped core.
Stack trace of thread 1104:
#0 0x7fd480466793 n/a
(libnftnl.so.11)
#1 0x7fd480461783
nftnl_rule_nlmsg_build_payload (libnftnl.so.11)
#2 0x55fe6e79493e n/a
(xtables-nft-multi)
#3 0x55fe6e790555 n/a
(xtables-nft-multi)
#4 0x55fe6e790f90 n/a
(xtables-nft-multi)
#5 0x7fd47fcf709b
__libc_start_main (libc.so.6)
#6 0x55fe6e78bfea n/a
(xtables-nft-multi)
Feb 11 13:34:26 debian systemd[1]: systemd-coredump@0-1105-0.service: Succeeded.
root@debian:~# coredumpctl list
TIMEPID UID GID SIG COREFILE EXE
Tue 2020-02-11 13:34:26 CET1104 0 0 11 present
/usr/sbin/xtables-nft-multi
root@debian:~# coredumpctl gdb 1104
PID: 1104 (iptables-restor)
UID: 0 (root)
GID: 0 (root)
Signal: 11 (SEGV)
Timestamp: Tue 2020-02-11 13:34:26 CET (2min 44s ago)
Command Line: iptables-restore
Executable: /usr/sbin/xtables-nft-multi
Control Group: /user.slice/user-1000.slice/session-1.scope
Unit: session-1.scope
Slice: user-1000.slice
Session: 1
Owner UID: 1000 (benutzer)
Boot ID: 07b3a6dc70ab428eb2a3fb217276c015
Machine ID:
Bug#950669: cups-browsed: segfault at 0 ip 00000000f79ffb5b sp 00000000fffd3828 error 4 in libc-2.29.so
Hello Thorsten, Am 06.02.20 um 19:19 schrieb Thorsten Glaser: > On Thu, 6 Feb 2020, Bernhard Übelacker wrote: > >> Hello Thorsten, >> getting the source of such an address is possible, even with ASLR, >> if the library versions are known and dbgsyms are available, >> like in attached file. > > This is great. Do you mind writing this up and posting it somewhere > so people can link and bookmark it? Perhaps even in a place aggregated > on Planet Debian? I made an attempt in [1], hopefully my english is not too bad... >> It looks like a null pointer is given to strncasecmp_l. >> >> But you are right, this information might still not be very useful, >> because the location is in libc - if it would be in cups-browsed it >> would be more useful. > > Yeah, at least a backtrace… sorry I can’t be more helpful. Maybe a core could be collected with one of the three core-dump-handler providing packages installed in [2]? Kind regards, Bernhard [1] https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash [2] https://wiki.debian.org/HowToGetABacktrace#Core_dump
Bug#949710: /usr/bin/plasmashell: segfaults sporadically but only when using app dropdown menu
Hello Sarah, I am sorry, but the given information might not be enough for the maintainers to solve the crash. Usually when a segfault happens in 'dmesg' output should appear two lines about this event. Maybe you could forward these to the report too. If it is possible to install systemd-coredump a backtrace would be automatically added to the journal, which could be viewed by 'journalctl --no-pager'. 'coredumpctl gdb' could also show these information and if the package gdb is also installed a '(gdb)' prompt should appear, where the command 'thread apply all bt full' should provide detailed information where the crash happened. This information would be much better if the package plasma-workspace-dbgsym and maybe some for shared libraries get installed from the repository described here [1]. (If output gets too much pages, maybe attach as file.) Kind regards Bernhard [1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols
Bug#950669: cups-browsed: segfault at 0 ip 00000000f79ffb5b sp 00000000fffd3828 error 4 in libc-2.29.so
Hello Thorsten,
getting the source of such an address is possible, even with ASLR,
if the library versions are known and dbgsyms are available,
like in attached file.
It looks like a null pointer is given to strncasecmp_l.
But you are right, this information might still not be very useful,
because the location is in libc - if it would be in cups-browsed it
would be more useful.
Kind regards,
Bernhard
# From submitter:
cups-browsed[20400]: segfault at 0 ip f79ffb5b sp fffd3828
error 4 in libc-2.29.so[f78d2000+145000]
Code: 66 0f 6f 25 37 7c 03 00 66 0f 6f 2d 3f 7c 03 00 66 0f 6f 35 47 7c 03 00
83 f9 30 0f 87 8e 00 00 00 83 f8 30 0f 87 85 00 00 00 0f 6f 0f f3 0f 6f 16
66 0f 6f f9 66 44 0f 6f c5 66 44 0f 6f ca
/*
* Page fault error code bits:
*
* bit 0 ==0: no page found 1: protection fault
* bit 1 ==0: read access 1: write access
* bit 2 ==0: kernel-mode access 1: user-mode access
* bit 3 == 1: use of reserved bit detected
* bit 4 == 1: fault was an instruction fetch
* bit 5 == 1: protection keys block access
*/
enum x86_pf_error_code {
PF_PROT = 1 << 0,
PF_WRITE= 1 << 1,
PF_USER = 1 << 2,
PF_RSVD = 1 << 3,
PF_INSTR= 1 << 4,
PF_PK = 1 << 5,
};
arch/x86/mm/fault.c:
printk("%s%s[%d]: segfault at %lx ip %px sp %px error %lx",
"error 4" == 0x4 == 0b100
bit 0 == 0: no page found
bit 1 == 0: read access
bit 2 == 1: user-mode access
bit 3 == 0:
bit 4 == 0:
bit 5 == 0:
##
# Unstable amd64 qemu VM with x32 userland 2020-02-06
apt update
apt dist-upgrade
apt install systemd-coredump gdb cups-browsed cups-browsed-dbgsym
dpkg -l | grep -i libc6
dpkg -l | grep 2.29-10
wget
https://snapshot.debian.org/archive/debian-ports/20200111T150052Z/pool-x32/main/g/glibc/libc6_2.29-9_x32.deb
wget
https://snapshot.debian.org/archive/debian-ports/20200111T150052Z/pool-x32/main/g/glibc/libc6-dbg_2.29-9_x32.deb
wget
https://snapshot.debian.org/archive/debian-ports/20200111T150052Z/pool-x32/main/g/glibc/libc-bin_2.29-9_x32.deb
wget
https://snapshot.debian.org/archive/debian/20200111T032041Z/pool/main/g/glibc/libc-l10n_2.29-9_all.deb
wget
https://snapshot.debian.org/archive/debian/20200111T032041Z/pool/main/g/glibc/locales_2.29-9_all.deb
dpkg -i "*_2.29-9_*"
gdb -q
file /sbin/cups-browsed
b main
run
generate-core /tmp/core
kill
y
q
gdb -q | grep "libc\."
file /sbin/cups-browsed
core /tmp/core
set width 0
set pagination off
info share
q
# 0xf7920320 0xf7a634db Yes /lib/x86_64-linux-gnux32/libc.so.6
echo -n "find /b ..., ..., 0x" && \
{
echo "66 0f 6f 25 37 7c 03 00 66 0f 6f 2d 3f 7c 03 00 66 0f 6f 35 47 7c 03
00 83 f9 30 0f 87 8e 00 00 00 83 f8 30 0f 87 85 00 00 00 0f 6f 0f f3 0f 6f
16 66 0f 6f f9 66 44 0f 6f c5 66 44 0f 6f ca"
} | sed 's/[<>]//g' | sed 's/ /, 0x/g'
# find /b ..., ..., 0x66, 0x0f, 0x6f, 0x25, 0x37, 0x7c, 0x03, 0x00, 0x66,
0x0f, 0x6f, 0x2d, 0x3f, 0x7c, 0x03, 0x00, 0x66, 0x0f, 0x6f, 0x35, 0x47, 0x7c,
0x03, 0x00, 0x83, 0xf9, 0x30, 0x0f, 0x87, 0x8e, 0x00, 0x00, 0x00, 0x83, 0xf8,
0x30, 0x0f, 0x87, 0x85, 0x00, 0x00, 0x00, 0xf3, 0x0f, 0x6f, 0x0f, 0xf3, 0x0f,
0x6f, 0x16, 0x66, 0x0f, 0x6f, 0xf9, 0x66, 0x44, 0x0f, 0x6f, 0xc5, 0x66, 0x44,
0x0f, 0x6f, 0xca
gdb -q
file /sbin/cups-browsed
core /tmp/core
set width 0
set pagination off
find /b 0xf7920320, 0xf7a634db, 0x66, 0x0f, 0x6f, 0x25, 0x37, 0x7c, 0x03, 0x00,
0x66, 0x0f, 0x6f, 0x2d, 0x3f, 0x7c, 0x03, 0x00, 0x66, 0x0f, 0x6f, 0x35, 0x47,
0x7c, 0x03, 0x00, 0x83, 0xf9, 0x30, 0x0f, 0x87, 0x8e, 0x00, 0x00, 0x00, 0x83,
0xf8, 0x30, 0x0f, 0x87, 0x85, 0x00, 0x00, 0x00, 0xf3, 0x0f, 0x6f, 0x0f, 0xf3,
0x0f, 0x6f, 0x16, 0x66, 0x0f, 0x6f, 0xf9, 0x66, 0x44, 0x0f, 0x6f, 0xc5, 0x66,
0x44, 0x0f, 0x6f, 0xca
disassemble /r 0xf7a4db31, 0xf7a4db31 + 62
b * (0xf7a4db31 + 42)
info b
benutzer@debian:~$ gdb -q
(gdb) file /sbin/cups-browsed
Reading symbols from /sbin/cups-browsed...
Reading symbols from
/usr/lib/debug/.build-id/30/1088ae63113870879be52401bc26cac176081b.debug...
(gdb) core /tmp/core
[New LWP 4218]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnux32/libthread_db.so.1".
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
...
(gdb) set width 0
(gdb) set pagination off
(gdb) find /b 0xf7920320, 0xf7a634db, 0x66, 0x0f, 0x6f, 0x25, 0x37, 0x7c, 0x03,
0x00, 0x66, 0x0f, 0x6f, 0x2d, 0x3f, 0x7c, 0x03, 0x00, 0x66, 0x0f, 0x6f, 0x35,
0x47, 0x7c, 0x03, 0x00, 0x83, 0xf9, 0x30, 0x0f, 0x87, 0x8e, 0x00, 0x00, 0x00,
0x83, 0xf8, 0x30, 0x0f, 0x87, 0x85, 0x00, 0x00,
Bug#942055: ghostscript in buster partly broken on armel?
Hello Jonas, thanks for taking time for this bug. Am 05.02.20 um 11:02 schrieb Jonas Smedegaard: > Hi Alexander, > > Quoting Alexander Reichle-Schmehl (2020-02-05 08:45:05) >> Am 2020-02-04 22:09, schrieb Jonas Smedegaard: >> >>> Most notable change between 9.22 and 9.24 - and also applied to >>> various degree in security updates - was a security fix affecting >>> interpretation of Postscript code. >> >> Maybe a stupid question, but does that fix work? I'm just wondering, >> if the firx triggers a problem on one arm but not on amd64, is it >> working? > > Fair question. > > Ghostscript is (mainly) a Postscript interpreter. > > To investigate if the cause for this issue is a) Ghostscript > _interpreting_ differently on arm than on amd64, or a tool further back > in the chain _producing_ different code for Ghostscript to interpret, it > seems to me that we need someone to isolate the actual code fed into > Ghostscript. > > I maintain the Ghostscript package, but am not skilled in the various > tools using Ghostscript. It seems more sensible to me to first > investigate toolchain problems further back in the chain, where (I > assume) it is better known how to isolate the data forwarded down the > chain. I guess this is what I did in previous message 33 ? There I attached file foomatic-9RyCd0 which is fed by cups into ghostscript. I have put the ghostscript command line parameter also in message 33. This file, seems to be just a PDF, is interpreted by ghostscript at amd64 without issue. But gives the message "Can't handle format 4" at an armv5tel/armel (real hardware, QNAP, Feroceon 88FR131). And even worse it might manifests just on armv5tel/armel, in my qemu armv7/armel VM it works without problems too. Therefore I guess you are right and this is not an issue of ghostscript, but could be compiler related. I continued testing and a package "9.25~dfsg-7" compiled in an unstable chroot as of date 2017-12-07 produces a working package. But a package "9.25~dfsg-7" built inside a unstable chroot as of date 2018-01-01 crashes in gx_filter_edgebuffer, like current version in buster 9.27~dfsg-2+deb10u3 with "-dDEBUG" set. Therefore I guess this could be related to the switch from gcc-7 7.2.0-16 to gcc-7 7.2.0-18 in that time frame. (The -18 raised the baseline to armv5te.) That would at least explain why the stretch stable update packages do not show the problem (e.g. 9.26a~dfsg-0+deb9u6), as they should be built with stretch's gcc-6. But without pointing to an exact instruction or function I cannot prove it. So are there any hints how to further debug ghostscript in that regard? Kind regards, Bernhard
Bug#942055: ghostscript in buster partly broken on armel?
Control: fixed -1 9.26a~dfsg-0+deb9u6 Control: fixed -1 9.26a~dfsg-0+deb9u1 Control: fixed -1 9.25~dfsg-0+deb9u1 Control: found -1 9.27~dfsg-3.1 Control: found -1 9.27~dfsg-3 Control: found -1 9.26a~dfsg-2 Control: found -1 9.26a~dfsg-1 Control: found -1 9.26~dfsg-2 Control: found -1 9.26~dfsg-1 Control: found -1 9.25~dfsg-7 Control: found -1 9.25~dfsg-2 Control: found -1 9.24~~rc2~dfsg-1 Control: fixed -1 9.22~dfsg-1 Control: fixed -1 9.21~dfsg-1 Control: fixed -1 9.20~dfsg-3.2 Hello, tried to get a little further. The last version from sid that did not show this error was 9.22~dfsg-1. All other good version seem to be created as security updates, where I cannot find the build logs. Kind regards, Bernhard
Bug#948287: bash: *** stack smashing detected *** ( SIGABRT crash )
Control: reassign -1 libc6 2.29-9 Control: affects -1 bash Dear Maintainer, reassigning to get hold of libc6 maintainer about the issue of incompatible tunables indices between libc6 versions. Therefore applications could crash when libc is from previous package version, then a package update gets installed, and then libpthread is from new version is loaded. Kind regards, Bernhard
Bug#950537: lxterminal: wrong default PATH for superuser
Hello Jan, please leave the bugs email in the recipients or cc list to have all information attached to the bug e.g. by using "reply all". Nice to hear it works. You can close a bug by just changing the email recipient from '950...@bugs.debian.org' to '950537-d...@bugs.debian.org'. Kind regards, Bernhard Am 03.02.20 um 15:55 schrieb Schweik Josef: > Well, you are quite correct, "su -" is working fine! > ... > > Thanks. Jan > > Please, how can I close this bug report? > >
Bug#950537: lxterminal: wrong default PATH for superuser
Hello Jan, your issue might originate not from the terminal but from su itself. This might be an interesting read: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904988#20 But in short, is instead of 'su' using 'su -' working for you like expected? Kind regards, Bernhard
Bug#948708: Further information
Dear Maintainer, I found this upstream bug report [1]. The SIGILL causing instruction seems to consist just of four zeros. [2] The instruction before is [3]. Version 68.4.2esr-1 in unstable does not show this crash. Kind regards, Bernhard [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1609535 [2] (gdb) disassemble /r 0x7da711f0-60,0x7da711f0+60 ... 0x7da711ec: 1f 20 03 d5 nop => 0x7da711f0 :00 00 00 00 .inst 0x ; undefined 0x7da711f4 :85 ff ff 17 b 0x7da71008 0x7da711f8: 00 00 00 00 .inst 0x ; undefined ... [3] 1: x/i $pc => 0xf2ab9004: b 0xf2ab91f0 (gdb) stepi 0xf2ab91f0 in ?? () from /usr/lib/firefox-esr/libxul.so 1: x/i $pc => 0xf2ab91f0: .inst 0x ; undefined #0 0xf2ab9004 in nsCommandLine::EnumerateHandlers (this=this@entry=0xe75edaf0, aCallback=aCallback@entry=0xf2ab77d0 , aClosure=aClosure@entry=0x0) at ./build-browser/dist/include/nsCOMPtr.h:331 https://sources.debian.org/src/firefox-esr/68.4.2esr-1/xpcom/base/nsCOMPtr.h/#L331 https://sources.debian.org/src/firefox-esr/68.4.2esr-1/xpcom/base/nsCOMPtr.h/#L91
Bug#949952: tilix does not start on arm64 (maybe libunwind related)
Hello Birger Schacht, I tried to get some more information from this issue. To be sure where your tilix aborts you would need to install gdb and at least tilix-dbgsym [1] and run it this way: gdb -q -ex 'set pagination off' -ex run -ex bt -ex detach -ex quit --args tilix Then I guess you see an backtrace like this: (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0xf690aea8 in __GI_abort () at abort.c:79 #2 0xf6b3f544 in _d_throw_exception () from /lib/aarch64-linux-gnu/libdruntime-ldc-shared.so.88 #3 0xaac73528 in _D3std9exception__T7bailOutHTC9ExceptionZQwFNaNfAyamMAxaZv (line=, msg=..., file=...) at /usr/lib/ldc/aarch64-linux-gnu/include/d/std/exception.d:516 #4 _D3std9exception__T7enforceZ__TQmTbZQrFNaNfbLAxaAyamZb (value=, msg=..., file=..., line=) at /usr/lib/ldc/aarch64-linux-gnu/include/d/std/exception.d:436 #5 0xf6e44610 in std.process.environment.opIndex(scope const(char)[]) () from /lib/aarch64-linux-gnu/libphobos2-ldc-shared.so.88 #6 0xaac2874c in D main (args=...) at app.d:127 After looking at the source [2] I assume this might not be fatal and the program not be aborted. You might be able to confirm if this workaround works for you too, by starting with this LD_PRELOAD: LD_PRELOAD=/lib/aarch64-linux-gnu/libgcc_s.so.1 tilix This might be related to exceptions in libunwind.so.8. There exists a similar ticket which is also related to exception handling with the same workaround [3]. Unfortunately there was not yet much response from libunwind downstream or upstream. Kind regards, Bernhard [1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols [2] https://sources.debian.org/src/tilix/1.9.3-4/source/app.d/#L127 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932499 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923962 https://github.com/libunwind/libunwind/issues/129 # Bullseye/testing arm64 qemu VM 2020-02-01 apt update apt dist-upgrade apt install systemd-coredump psmisc net-tools strace gdb tilix tilix-dbgsym libphobos2-ldc-shared88-dbgsym libgtkd-3-0-dbgsym libsecret-1-0 xserver-xephyr x11vnc tigervnc-standalone-server xterm openbox # Even without DISPLAY set tilix coredumpctl list journalctl --no-pager coredumpctl gdb 2251 set width 0 set pagination off bt apt install libsecret-1-0 gdb -q --args tilix ### $ tilix dwarfeh(363) fatal error Aborted (core dumped) # coredumpctl list TIMEPID UID GID SIG COREFILE EXE Sat 2020-02-01 01:05:31 CET2251 1000 1000 6 present /usr/bin/tilix Feb 01 01:05:29 debian systemd[1]: Started Process Core Dump (PID 2252/UID 0). Feb 01 01:05:31 debian systemd-coredump[2253]: Process 2251 (tilix) of user 1000 dumped core. Stack trace of thread 2251: #0 0x9440db88 raise (libc.so.6 + 0x35b88) #1 0x943fbea8 abort (libc.so.6 + 0x23ea8) #2 0x94630544 _d_throw_exception (libdruntime-ldc-shared.so.88 + 0xbd544) #3 0x956b43d0 _D4gtkd6Loader6Linker11loadLibraryFAyaZv (libgtkd-3.so.0 + 0x9ec3d0) #4 0xcb23872c n/a (tilix + 0x17b72c) #5 0x94638b34 _D2rt5minfo13rt_moduleCtorUZ14__foreachbody1MFKSQBu19sections_elf_shared3DSOZi (libdruntime-ldc-shared.so.88 + 0xc5b34) #6 0x94639d8c _D2rt19sections_elf_shared3DSO7opApplyFMDFKSQBqQBqQyZiZi (libdruntime-ldc-shared.so.88 + 0xc6d8c) #7 0x9462f7fc rt_init (libdruntime-ldc-shared.so.88 + 0xbc7fc) #8 0x9462fd80 _D2rt6dmain212_d_run_main2UAAamPUQgZiZ6runAllMFZv (libdruntime-ldc-shared.so.88 + 0xbcd80) #9 0x9462fbb8 _d_run_main2 (libdruntime-ldc-shared.so.88 + 0xbcbb8) #10 0x9462fa5c _d_run_main (libdruntime-ldc-shared.so.88 + 0xbca5c) #11 0x943fc2ec __libc_start_main (libc.so.6 + 0x242ec) #12 0xcb2385ec n/a (tilix + 0x17b5ec) #13 0xcb2385ec n/a (tilix + 0x17b5ec) Feb 01 01:05:31 debian systemd[1]: systemd-coredump@0-2252-0.service: Succeeded. # coredumpctl gdb 2251 PID: 2251 (tilix) UID: 1000 (benutzer) GID: 1000 (benutzer) Signal: 6 (ABRT) Timestamp: Sat
Bug#948288: gnome-shell reproducibly crashes on boot, and the boot process gets stuck
Hello Md Ayquassar, Am 31.01.20 um 02:23 schrieb Md Ayquassar: > Second, is a reassignment to some Mesa package required? I guess mesa maintainer would have more insight if that function pointer is allowed to be NULL, there possibly yes. I wonder if the content of /var/log/Xorg.0.log* would reveal some more error messages? Just for a workaround, does giving nomodeset on the kernel prompt a different result? > Third, is there anything else I can do as a user to help the developers > to bugfix this? Bug at line 1017 is strange: if there is a NULL > dereference there, there should also probably be one in line 1016 unless > someone has a deterministic concurrent access to that data. > https://sources.debian.org/src/mesa/18.3.6-2/src/egl/drivers/dri2/egl_dri2.c/#L1017 I assume line 1017, 1018 and 1019 are one statement, therefore gdb shows 1017. Further I think the function pointer "dri2_dpy->dri2->allocateBuffer" contains the NULL, therefore the "ip " in your dmesg output. A "regular" segfault should still show a sane instruction pointer value. Kind regards, Bernhard
Bug#948288: gnome-shell reproducibly crashes on boot, and the boot process gets stuck
Hello Md Ayquassar, sorry, I did not recognize that you seem to have a usrmerge'd system. Then I get following backtraces from your core dump, with and without debug symbols. It looks like a function pointer gets called unconditionally, while containing NULL. Seems to be graphics driver related. Kind regards, Bernhard https://sources.debian.org/src/mesa/18.3.6-2/src/egl/drivers/dri2/egl_dri2.c/#L1017 (gdb) bt #0 0x in ?? () #1 0xaf7d2c74 in ?? () from /lib/i386-linux-gnu/libEGL_mesa.so.0 #2 0xaf7d755e in ?? () from /lib/i386-linux-gnu/libEGL_mesa.so.0 #3 0xade2d004 in ?? () from /usr/lib/i386-linux-gnu/dri/radeon_dri.so #4 0xade2d812 in ?? () from /usr/lib/i386-linux-gnu/dri/radeon_dri.so #5 0xade9232f in ?? () from /usr/lib/i386-linux-gnu/dri/radeon_dri.so #6 0xaf7d29ba in ?? () from /lib/i386-linux-gnu/libEGL_mesa.so.0 #7 0xaf7c061c in eglMakeCurrent () from /lib/i386-linux-gnu/libEGL_mesa.so.0 #8 0xb4cd8b58 in ?? () from /lib/i386-linux-gnu/libEGL.so.1 #9 0xb674a1bd in _cogl_winsys_egl_make_current () from /usr/lib/i386-linux-gnu/mutter/libmutter-cogl-3.so #10 0xb6d8f1f6 in ?? () from /lib/i386-linux-gnu/libmutter-3.so.0 #11 0xb6ceaca4 in meta_renderer_rebuild_views () from /lib/i386-linux-gnu/libmutter-3.so.0 #12 0xb6d920fa in meta_stage_native_rebuild_views () from /lib/i386-linux-gnu/libmutter-3.so.0 #13 0xb6d83ba7 in ?? () from /lib/i386-linux-gnu/libmutter-3.so.0 #14 0xb6ccf11a in ?? () from /lib/i386-linux-gnu/libmutter-3.so.0 #15 0xb6ccff40 in ?? () from /lib/i386-linux-gnu/libmutter-3.so.0 #16 0xb6d83f98 in ?? () from /lib/i386-linux-gnu/libmutter-3.so.0 #17 0xb6cd053a in meta_clutter_init () from /lib/i386-linux-gnu/libmutter-3.so.0 #18 0xb6d20323 in meta_init () from /lib/i386-linux-gnu/libmutter-3.so.0 #19 0x004ad53d in ?? () #20 0xb6aa2b41 in __libc_start_main (main=0x4ad430, argc=1, argv=0xbff2c2a4, init=0x4adfa0, fini=0x4ae000, rtld_fini=0xb7f97520 <_dl_fini>, stack_end=0xbff2c29c) at ../csu/libc-start.c:308 #21 0x004ad8d1 in ?? () (gdb) Core was generated by `/usr/bin/gnome-shell'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x in ?? () [Current thread is 1 (Thread 0xb1f2eb80 (LWP 899))] (gdb) set width 0 (gdb) set pagination off (gdb) bt #0 0x in ?? () #1 0xaf7d2c74 in dri2_egl_surface_alloc_local_buffer (dri2_surf=0x1b8e9f0, att=9, format=32) at ../src/egl/drivers/dri2/egl_dri2.c:1017 #2 0xaf7d755e in dri2_drm_get_buffers_with_format (driDrawable=0x1b73580, width=0x1b73598, height=0x1b7359c, attachments=0xbff2bb04, count=2, out_count=0xbff2baf8, loaderPrivate=0x1b8e9f0) at ../src/egl/drivers/dri2/platform_drm.c:344 #3 0xade2d004 in radeon_update_renderbuffers (context=0x19e7d60, drawable=0x1b73580, front_only=0 '\000') at ../src/mesa/drivers/dri/radeon/radeon_common_context.c:421 #4 0xade2d812 in radeonMakeCurrent (driContextPriv=0x19e7d60, driDrawPriv=0x1b73580, driReadPriv=0x1b73580) at ../src/mesa/drivers/dri/radeon/radeon_common_context.c:616 #5 0xade9232f in driBindContext (pcp=0x19e7d60, pdp=0x1b73580, prp=0x1b73580) at ../src/mesa/drivers/dri/common/dri_util.c:579 #6 0xaf7d29ba in dri2_make_current (drv=0x19e5120, disp=0x19e49c0, dsurf=0x1b8e9f0, rsurf=0x1b8e9f0, ctx=) at ../src/egl/drivers/dri2/egl_dri2.c:1516 #7 0xaf7c061c in eglMakeCurrent (dpy=0x19e49c0, draw=0x1b8e9f0, read=0x1b8e9f0, ctx=0x19fe5c0) at ../src/egl/main/eglapi.c:860 #8 0xb4cd8b58 in InternalMakeCurrentVendor (dpy=0x19e3dd0, draw=draw@entry=0x1b8e9f0, read=0x1b8e9f0, read@entry=0x19c3310, context=0x19fe5c0, apiState=0x19fe360, vendor=) at ../../../src/EGL/libegl.c:861 #9 0xb4cd9606 in eglMakeCurrent (dpy=, draw=, read=0x1b8e9f0, context=0x19fe5c0) at ../../../src/EGL/libegl.c:727 #10 0xb674a1bd in _cogl_winsys_egl_make_current (display=0x19ca4d8, draw=0x1b8e9f0, read=0x1b8e9f0, context=0x19fe5c0) at winsys/cogl-winsys-egl.c:300 #11 0xb6d8f1f6 in meta_renderer_native_create_view (renderer=0x19c8610, logical_monitor=0x19bbf20) at backends/native/meta-renderer-native.c:2949 #12 0xb6ceaca4 in meta_renderer_create_view (logical_monitor=, renderer=0x19c8610) at ./backends/meta-renderer.h:36 #13 meta_renderer_rebuild_views (renderer=0x19c8610) at backends/meta-renderer.c:73 #14 0xb6d920fa in meta_stage_native_rebuild_views (stage_native=0x19c2470) at backends/native/meta-stage-native.c:141 #15 0xb6d83ba7 in meta_backend_native_update_screen_size (backend=0x19a48b8, width=1024, height=768) at backends/native/meta-backend-native.c:493 #16 0xb6ccf11a in meta_backend_sync_screen_size (backend=backend@entry=0x19a48b8) at backends/meta-backend-private.h:52 #17 0xb6ccff40 in meta_backend_real_post_init (backend=0x19a48b8) at backends/meta-backend.c:442 #18 0xb6d83f98 in meta_backend_native_post_init (backend=0x19a48b8) at ./backends/meta-backend-private.h:52 #19 0xb6cd053a in meta_backend_post_init (backend=) at backends/meta-backend-private.h:52 #20 meta_clutter_init () at backends/meta-backend.c:12
Bug#924507: ksplashqml: hits its hard timeout of 30 seconds
Control: found -1 plasma-workspace/4:5.14.5.1-5 Dear Maintainer, I found today another device affected by this issue. It got switched a few days ago from stable to current testing. It shows the same 30 second splash screen. A package build with the given patch did show the splash just 14 seconds. plasma-workspace version 5.15 or later contain this patch and should much less likely show this issue. Kind regards, Bernhard
Bug#950175: grub-common: Grub delays 23 seconds to show the menu.
Package: grub-common
Version: 2.04-5
Severity: wishlist
Dear Maintainer,
I noticed some moths ago a delay between Grub gets
started ("Welcome to GRUB!") and Grub shows the menu.
I switched a few days ago from stable to Bullseye/testing
at this device and tried to find out where this 23 seconds
delay is coming from.
After some tests I found that /etc/grub.d/05_debian_theme
is convinced that the root partition is readable by Grub.
Unfortunately this is not the case, as root is on a micro-sd card,
just boot is on the internal MMC. Also the EFI shell did
not recognize the partition table of that micro-sd, as far as I see.
The "search" command below takes these 23 seconds.
As a workaround I copied grub-16x9.png from
/usr/share/desktop-base/futureprototype-theme/grub
to /boot/grub/ and did "update-grub".
Now the delay is gone and the background image is shown by Grub.
I wonder why the background image is not
copied to the boot partition by default?
Kind regards,
Bernhard
-- /boot/grub/grub.cfg:
...
### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod ext2
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root ...
else
...
-- System Information:
Debian Release: bullseye/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages grub-common depends on:
ii gettext-base0.19.8.1-10
ii libc6 2.29-9
ii libdevmapper1.02.1 2:1.02.167-1
ii libefiboot1 37-2
ii libefivar1 37-2
ii libfreetype62.10.1-2
ii libfuse22.9.9-2
ii liblzma55.2.4-1+b1
Versions of packages grub-common recommends:
ii os-prober 1.77
Versions of packages grub-common suggests:
ii console-setup 1.194
ii desktop-base 10.0.3
pn grub-emu
pn multiboot-doc
pn xorriso
-- no debconf information
Bug#948287: bash: *** stack smashing detected *** ( SIGABRT crash )
Dear Maintainer,
today I received this stack smashing also in one of my VMs.
I could reproduce the isse when ever a bash is started
while 2.29-7 got started and left open.
Then in a different shell the packages get upgraded,
especially glibc packages to version 2.29-9.
Then get back to the opened shell before and I could good
reproduce it by "dpkg-deb -x g".
As far as I could follow it, then libpthread-2.29.so gets loaded,
but the version 2.29-9 while libc-2.29.so is still 2.29-7.
Then the stack canary from __pthread_tunables_init gets overwritten here:
Old value = 898596864
New value = 0
__GI___tunable_get_val (id=, valp=,
callback=) at dl-tunables.c:393
393 dl-tunables.c: Datei oder Verzeichnis nicht gefunden.
1: x/i $pc
=> 0x7f42d1904cc3 <__GI___tunable_get_val+99>: jmp0x7f42d1904c8d
<__GI___tunable_get_val+45>
(gdb) bt
#0 __GI___tunable_get_val (id=, valp=,
callback=) at dl-tunables.c:393
#1 0x7f42d137206a in __pthread_tunables_init () at
pthread_mutex_conf.c:43
#2 0x7f42d1364bdd in __pthread_initialize_minimal_internal () at
nptl-init.c:437
#3 0x7f42d1364009 in _init () at ../sysdeps/x86_64/crti.S:74
#4 0x in ?? ()
https://sources.debian.org/src/glibc/2.29-9/nptl/pthread_mutex_conf.c/#L43
(gdb) print (int)glibc_pthread_mutex_spin_count
$6 = 23
(gdb) print tunable_list[23]
$7 = {name = 0x7f42d190ecc3 "glibc.malloc.tcache_max", type = {type_code =
TUNABLE_TYPE_SIZE_T, min = 0, max = -1}, val = {numval = 0, strval = 0x0},
initialized = false, security_level = TUNABLE_SECLEVEL_SXID_ERASE, env_alias =
0x0}
(gdb) print tunable_list[22]
$8 = {name = 0x7f42d19112b0 "glibc.pthread.mutex_spin_count", type =
{type_code = TUNABLE_TYPE_INT_32, min = 0, max = 32767}, val = {numval = 100,
strval = 0x64 }, initialized =
false, security_level = TUNABLE_SECLEVEL_SXID_ERASE, env_alias = 0x0}
It looks like between 2.29-7 and 2.29-9 the position in
the tunable_list array shifted and now libpthread accesses
element 23 while there is a different, bigger sized value
which leads to overwriting the stack canary.
I guess the question now is if this is a supported szenario?
If yes this bug needs to be handled by glibc maintainers?
A workaround in bash could be to make sure to have
libpthread loaded at startup, that way also holding
the same (outdated) version in memory.
Kind regards,
Bernhard
# Bullseye/testing amd64 qemu VM 2020-01-29
apt update
apt dist-upgrade
apt install systemd-coredump mc fakeroot
apt build-dep grub-efi-ia32
# not yet rebooted
benutzer@debian:~/deb$ dpkg-dev -x gr*** stack smashing detected ***:
terminated
Connection to 127.0.254.63 closed.
root@debian:~# journalctl --no-pager
-- Logs begin at Wed 2020-01-29 15:24:56 CET, end at Wed 2020-01-29 15:29:14
CET. --
Jan 29 15:24:56 debian kernel: Linux version 5.3.0-3-amd64
(debian-ker...@lists.debian.org) (gcc version 9.2.1 20191130 (Debian 9.2.1-21))
#1 SMP Debian 5.3.15-1 (2019-12-07)
...
Jan 29 15:29:14 debian systemd-coredump[23763]: Process 1008 (bash) of user
1000 dumped core.
Stack trace of thread 1008:
#0 0x7f7060d8b081 n/a
(/usr/lib/x86_64-linux-gnu/libc-2.29.so (deleted) + 0x3a081)
#1 0x7f7060e5b81d n/a
(/usr/lib/x86_64-linux-gnu/libc-2.29.so (deleted) + 0x10a81d)
Jan 29 15:29:14 debian systemd[1]: systemd-coredump@0-23762-0.service:
Succeeded.
root@debian:~# coredumpctl list
TIMEPID UID GID SIG COREFILE EXE
Wed 2020-01-29 15:29:14 CET1008 1000 1000 6 present /usr/bin/bash
root@debian:~# coredumpctl gdb 1008
PID: 1008 (bash)
UID: 1000 (benutzer)
GID: 1000 (benutzer)
Signal: 6 (ABRT)
Timestamp: Wed 2020-01-29 15:29:14 CET (4min 0s ago)
Command Line: -bash
Executable: /usr/bin/bash
Control Group: /user.slice/user-1000.slice/session-3.scope
Unit: session-3.scope
Slice: user-1000.slice
Session: 3
Owner UID: 1000 (benutzer)
Boot ID: 40d7405f80194b29af2d13741d10b59a
Machine ID: 33f18f39d2a9438eb75b0ed52848afcd
Hostname: debian
Storage:
/var/lib/systemd/coredump/core.bash.1000.40d7405f80194b29af2d13741d10b59a.1008.1580308154.lz4
Message: Process 1008 (bash) of user 1000 dumped core.
Stack trace of thread 1008:
#0 0x7f7060d8b081 n/a
(/usr/lib/x86_64-linux-gnu/libc-2.29.so (deleted) + 0x3a081)
#1 0x7f7060e5b81d n/a
(/usr/lib/x86_64-linux-gnu/libc-2.29.so (deleted) + 0x10a81d)
GNU gdb (Debian 8.3.1-1) 8.3.1
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version
Bug#945814: audacity: various segfaults of audacity on startup
Control: reassign -1 zynaddsubfx-dssi 3.0.3-1 Control: affects -1 + audacity Hello Tjeerd, > Thanks for coming back, I'm not in a hurry... > > The problem is that I can not trigger specific bugs (they seem to happen > somewhat random). So a made some more valgrinds: valgrind.dat Because the error des not manifest each run in the same location this might be thread related e.g. two threads are working on the same memory. > I had zynaddsubfx installed to try it out and see if I like it, but did > not uninstall after the tries (sufficient diskspace luxury). I could > uninstall zynadd, zynsaddsubfx and zynaddsubfx-dssi, the data package is > depended on by the lmms-common package. I tried to install some more lv2 plugins and bridges and after enabling all in audacity I got the shared library loaded libzynaddsubfx_dssi.so by just starting audacity - but still cannot reproduce a crash. (Details attached.) > And audacity runs without crashing (thanks for the hint) but still gives > a lot of debug output: audacity_debug.dat Most of the remaining output seems gui related - seems to be harmless. > So at least the the source of all evil is now clear... and the bug > "resolved". Do you have contact with the zynaddsubfx devs and file a bug > there? Devs amongst each other might talk clearer? Otherwise I'm happy > to do it. It might not be that clear - depending on e.g. libzynaddsubfx_dssi.so is intended to work multi threaded ... When I did run audacity in my test environment I get some "Possible data race" with valgrind's helgrind tool. At least it might be related to some plugins, either direct or via some bridges, therefore I hope it is ok to reassign. Bringing the issue upstream might also not be a bad idea. Kind regards, Bernhard # Buster/stable amd64 qemu VM 2020-01-27 apt update apt dist-upgrade apt install systemd-coredump xserver-xorg sddm openbox xterm mc strace valgrind gdb audacity jackd2 lmms zynadd zynaddsubfx-dssi liblv2dynparamhost1-1 naspro-bridges audacity-dbgsym libstdc++6-8-dbg zynaddsubfx-dssi-dbgsym naspro-bridges-dbgsym libjack-jackd2-0-dbgsym libwxbase3.0-0v5-dbgsym libportaudio2-dbgsym libnabrit-dbg liblilv-0-0-dbgsym reboot # dpkg -l | grep -i -E "audacity|jack|zynaddsubfx|lmms" ii audacity 2.2.2-1+b1 amd64 fast, cross-platform audio editor ii audacity-data 2.2.2-1 all fast, cross-platform audio editor (data) ii audacity-dbgsym2.2.2-1+b1 amd64 debug symbols for audacity ii jackd 5+nmu1 all JACK Audio Connection Kit (default server package) ii jackd2 1.9.12~dfsg-2amd64 JACK Audio Connection Kit (server and example clients) ii jackd2-firewire1.9.12~dfsg-2amd64 JACK Audio Connection Kit (FFADO and FreeBoB backends) ii libjack-jackd2-0:amd64 1.9.12~dfsg-2amd64 JACK Audio Connection Kit (libraries) ii libjack-jackd2-0-dbgsym:amd64 1.9.12~dfsg-2amd64 debug symbols for libjack-jackd2-0 ii lmms 1.1.3-8.1amd64 Linux Multimedia Studio ii lmms-common1.1.3-8.1all Linux Multimedia Studio - common files ii qjackctl 0.5.0-1 amd64 User interface for controlling the JACK sound server ii zynadd 1+git.20100609+dfsg0-4 amd64 ZynAddSubFX engines converted to LV2 plugin format ii zynaddsubfx3.0.3-1 amd64 Realtime software synthesizer for Linux ii zynaddsubfx-data 3.0.3-1 all Realtime software synthesizer for Linux (data) ii zynaddsubfx-dssi 3.0.3-1 amd64 dssi plugin of zynaddsubfx ii zynaddsubfx-dssi-dbgsym3.0.3-1 amd64 debug symbols for zynaddsubfx-dssi export LANG=C export DISPLAY=:0 qjackctl # Start audacity # Select all new plugins and enable # Close gdb -q set width 0 set pagination off set breakpoint pending on file /usr/bin/audacity break _ZN3zyn10MiddleWare4tickEv run break _ZN3zyn4Bank9addtobankEiNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES6_ cont break free cont generate /home/benutzer/core (gdb) bt #0 __GI___libc_free (mem=0x5652b0c0) at malloc.c:3083 #1 0x7fffe9511f3d in zyn::Bank::addtobank(int, std::__cxx11::basic_string, std::allocator >, std::__cxx11::basic_string, std::allocator >) () from /usr/lib/dssi/libzynaddsubfx_dssi.so #2 0x7fffe95138a1 in zyn::Bank::loadbank(std::__cxx11::basic_string, std::allocator >) () from /usr/l
Bug#945814: Fwd: Bug#945814: audacity: various segfaults of audacity on startup
Hello Tjeerd, sorry for the delay. I would have expected more output from catchsegv. I guess the first valgrind run would have been better placed in an attachement too. The file audacity_coredumps.log points to libzynaddsubfx_dssi.so that belongs to package zynaddsubfx-dssi. That seems to be involved in the crash at least. I guess this package is installed on purpose on your system? If not uninstalling could be a workaround. As I just tried to help triaging this issue and being not involved in packaging I have not enough knowledge how to setup a system to get this file loaded by audacity. Therefore probably you could add what needs to be done from a fresh installed system to reach a setup similar to yours. And please add the output of following: dpkg -l | grep -i -E "audacity|jack|zynaddsubfx" Kind regards, Bernhard Backtrace from audacity_coredumps.log what it should look like with debug symbols installed: Stack trace of thread 11485: #0 0x7f94d6a507bb __GI_raise (libc.so.6) #1 0x7f94d6a3b535 __GI_abort (libc.so.6) #2 0x7f94d6a92508 __libc_message (libc.so.6) #3 0x7f94d6a98c1a malloc_printerr (libc.so.6) #4 0x7f94d6a9a5d7 _int_free (libc.so.6) #5 0x7f94cacf6f3d in __gnu_cxx::new_allocator::deallocate(char*, unsigned long) at /usr/include/c++/7/ext/new_allocator.h:125 in zyn::Bank::addtobank(int, std::__cxx11::basic_string, std::allocator >, std::__cxx11::basic_string, std::allocator >) #6 0x7f94cacf88a1 in zyn::Bank::loadbank(std::__cxx11::basic_string, std::allocator >) at ./src/Misc/Bank.cpp:267 #7 0x7f94cad4029c in zyn::MiddleWareImpl::loadPendingBank(int, zyn::Bank&) at ./src/Misc/MiddleWare.cpp:477 #8 0x7f94cade20ea in std::function::operator()(char const*, rtosc::RtData&) const at /usr/include/c++/7/bits/std_function.h:706 in rtosc::Ports::dispatch(char const*, rtosc::RtData&, bool) #9 0x7f94cad42959 in zyn::MiddleWareImpl::bToUhandle(char const*) at ./src/Misc/MiddleWare.cpp:1905 #10 0x7f94cad42cbf in zyn::MiddleWareImpl::tick() at ./src/Misc/MiddleWare.cpp:698 #11 0x7f94cacf43fd in DSSIaudiooutputoperator() at ./src/Output/DSSIaudiooutput.cpp:635 #12 0x7f94d6e32b2f n/a (libstdc++.so.6) #13 0x7f94d6f0efa3 in start_thread (arg=) at pthread_create.c:486 #14 0x7f94d6b124cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 https://sources.debian.org/src/zynaddsubfx/3.0.3-1/src/Misc/Bank.cpp/#L506 https://sources.debian.org/src/zynaddsubfx/3.0.3-1/src/Misc/Bank.cpp/#L267
Bug#948626: kicad: Closing pcbnew hangs main kicad process
Hello Paul, > That was my first thought; as explained in my initial bug report: >>> If run from the terminal there is no printed output of any kind. Sorry I missed that one. >> Otherwise maybe it is related to the used desktop environment, >> if xorg or wayland is in use > > I'm using xorg and the xfce desktop. > >> or the used project - do >> you observe this behaviour if you just open one >> of the templates? > > I observe it for any project, any template; even just opening "pcbnew" > as a standalone program on a blank project then immediately trying to > close it again. I guess then I could not help any more. Maybe the Maintainer have some other hints. One thing that could help the maintainer still would be the first time question if one wants to use hardware accelleration. Did you enable it? Seems to be stored there: $ grep canvas_type .config/kicad/pcbnew canvas_type=1 (When switched on seems to be "=1", switched off to be "=2", but not completely sure about it.) And maybe which graphics driver do you use? As far as I see the pcbnew window when started from kicad lives in the parents process. Now this process happens to run __run_exit_handlers. This makes me think for some reason the main function is left. Does your CPU support the rr debugger [1]? With that one could try to debug reverse from the point of failure. Kind regards, Bernhard [1] https://github.com/mozilla/rr https://packages.debian.org/bullseye/rr
Bug#949631: linux-image-4.19.0-7-amd64: refcount_t: underflow; use-after-free. Followed by: list_del corruption. next->prev should be
Dear Maintainer, crash happened again today when stopping a qemu VM with the quit command at the qemu prompt. Found the "refcount_t: underflow" already once at 2020-01-07, but there the system could continue to run more than a day. All occourences are with: [0.00] Linux version 4.19.0-7-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.87-1 (2019-12-03) Kind regards, Bernhard [0.00] Linux version 4.19.0-7-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.87-1 (2019-12-03) [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-7-amd64 root=UUID=64e985dd-8bd3-4051-82a4-a01577abbed4 ro crashkernel=384M-:128M [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format. [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0fff] reserved [0.00] BIOS-e820: [mem 0x1000-0x0008] usable [0.00] BIOS-e820: [mem 0x0009-0x00090fff] type 20 [0.00] BIOS-e820: [mem 0x00091000-0x0009] usable [0.00] BIOS-e820: [mem 0x000a-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x09e0] usable [0.00] BIOS-e820: [mem 0x09e1-0x09ff] reserved [0.00] BIOS-e820: [mem 0x0a00-0x0a1f] usable [0.00] BIOS-e820: [mem 0x0a20-0x0a20afff] ACPI NVS [0.00] BIOS-e820: [mem 0x0a20b000-0x0aff] usable [0.00] BIOS-e820: [mem 0x0b00-0x0b01] reserved [0.00] BIOS-e820: [mem 0x0b02-0xd18acfff] usable [0.00] BIOS-e820: [mem 0xd18ad000-0xd18d9fff] ACPI data [0.00] BIOS-e820: [mem 0xd18da000-0xda732fff] usable [0.00] BIOS-e820: [mem 0xda733000-0xda898fff] reserved [0.00] BIOS-e820: [mem 0xda899000-0xda8b9fff] ACPI data [0.00] BIOS-e820: [mem 0xda8ba000-0xdacc2fff] usable [0.00] BIOS-e820: [mem 0xdacc3000-0xdad87fff] ACPI NVS [0.00] BIOS-e820: [mem 0xdad88000-0xdbaa3fff] reserved [0.00] BIOS-e820: [mem 0xdbaa4000-0xdbb44fff] type 20 [0.00] BIOS-e820: [mem 0xdbb45000-0xddff] usable [0.00] BIOS-e820: [mem 0xde00-0xdfff] reserved [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfd10-0xfd1f] reserved [0.00] BIOS-e820: [mem 0xfea0-0xfea0] reserved [0.00] BIOS-e820: [mem 0xfeb8-0xfec01fff] reserved [0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved [0.00] BIOS-e820: [mem 0xfec3-0xfec30fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved [0.00] BIOS-e820: [mem 0xfed4-0xfed44fff] reserved [0.00] BIOS-e820: [mem 0xfed8-0xfed8] reserved [0.00] BIOS-e820: [mem 0xfedc2000-0xfedc] reserved [0.00] BIOS-e820: [mem 0xfedd4000-0xfedd5fff] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfeef] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00041f37] usable [0.00] NX (Execute Disable) protection: active [0.00] efi: EFI v2.60 by American Megatrends [0.00] efi: ACPI 2.0=0xd18ad000 ACPI=0xd18ad000 SMBIOS=0xdba12000 SMBIOS 3.0=0xdba11000 ESRT=0xd8841a98 MEMATTR=0xd80dc018 [0.00] secureboot: Secure boot could not be determined (mode 0) [0.00] SMBIOS 3.1.1 present. [0.00] DMI: System manufacturer System Product Name/PRIME B350M-A, BIOS 4801 04/25/2019 [0.00] tsc: Fast TSC calibration failed [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] last_pfn = 0x41f380 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B write-through [0.00] C-D uncachable [0.00] E-F write-protect [0.00]
Bug#948876: kodi: FTBFS: something segfaults
Dear Maintainer, a short addition. I got some help that AddressSanitizer and Valgrind could be squeezed to delay returning previously free'd addresses from the allocator. Then both tools point to the mentioned first allocation directly. Kind regards, Bernhard AddressSanitizer: export ASAN_OPTIONS=quarantine_size_mb=1000 Valgrind: --freelist-vol=100 Result with unmodified Debian binaries: valgrind --tool=memcheck --track-origins=yes --num-callers=100 --freelist-vol=100 fontforge -script /home/benutzer/source/kodi/try1/kodi-17.6+dfsg1/debian/mergefonts.ff /usr/share/fonts/truetype/droid/DroidSansFallbackFull.ttf /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf /home/benutzer/source/kodi/try1/kodi-17.6+dfsg1/media/Fonts/arial.ttf The glyph named Omega is mapped to U+03A9. But its name indicates it should be mapped to U+2126. ==74312== Invalid read of size 8 ==74312==at 0x55F6B69: gv_len (tottfgpos.c:3838) ==74312==by 0x5601DC9: ttf_math_dump_glyphvariant (tottfgpos.c:3979) ==74312==by 0x5601DC9: otf_dump_math (tottfgpos.c:4139) ==74312==by 0x56134C9: initATTables (tottf.c:5316) ==74312==by 0x5615006: initTables (tottf.c:5792) ==74312==by 0x561552A: _WriteTTFFont (tottf.c:6143) ==74312==by 0x5615A49: WriteTTFFont (tottf.c:6171) ==74312==by 0x54F5413: _DoSave (savefont.c:845) ==74312==by 0x54F7DCF: GenerateScript (savefont.c:1269) ==74312==by 0x55103FB: bGenerate (scripting.c:2061) ==74312==by 0x5512F0A: docall (scripting.c:9632) ==74312==by 0x551359D: handlename (scripting.c:9745) ==74312==by 0x55147B2: term (scripting.c:9983) ==74312==by 0x5514B37: mul (scripting.c:10128) ==74312==by 0x5514D4D: add (scripting.c:10174) ==74312==by 0x55150B8: comp (scripting.c:10249) ==74312==by 0x5515340: _and (scripting.c:10293) ==74312==by 0x55154E2: _or (scripting.c:10325) ==74312==by 0x55154E2: assign (scripting.c:10358) ==74312==by 0x55122FC: expr (scripting.c:10436) ==74312==by 0x55122FC: ff_statement (scripting.c:10649) ==74312==by 0x5516110: ProcessNativeScript (scripting.c:10796) ==74312==by 0x5516744: _CheckIsScript (scripting.c:10890) ==74312==by 0x5516744: CheckIsScript (scripting.c:10927) ==74312==by 0x4A165B8: fontforge_main (startui.c:1099) ==74312==by 0x4C13BBA: (below main) (libc-start.c:308) ==74312== Address 0x8f6e3600 is 0 bytes inside a block of size 40 free'd ==74312==at 0x48379AB: free (vg_replace_malloc.c:540) ==74312==by 0x55C7B19: SplineCharFreeContents (splineutil.c:5963) ==74312==by 0x55C7B7D: SplineCharFree (splineutil.c:5974) ==74312==by 0x55C7B7D: SplineCharFree (splineutil.c:5970) ==74312==by 0x55CA66D: SplineFontFree (splineutil.c:6535) ==74312==by 0x55CA66D: SplineFontFree (splineutil.c:6491) ==74312==by 0x542E147: _MergeFont (fvfonts.c:1161) ==74312==by 0x542E147: __MergeFont (fvfonts.c:1179) ==74312==by 0x542E147: MergeFont (fvfonts.c:1261) ==74312==by 0x5512F0A: docall (scripting.c:9632) ==74312==by 0x551359D: handlename (scripting.c:9745) ==74312==by 0x55147B2: term (scripting.c:9983) ==74312==by 0x5514B37: mul (scripting.c:10128) ==74312==by 0x5514D4D: add (scripting.c:10174) ==74312==by 0x55150B8: comp (scripting.c:10249) ==74312==by 0x5515340: _and (scripting.c:10293) ==74312==by 0x55154E2: _or (scripting.c:10325) ==74312==by 0x55154E2: assign (scripting.c:10358) ==74312==by 0x55122FC: expr (scripting.c:10436) ==74312==by 0x55122FC: ff_statement (scripting.c:10649) ==74312==by 0x5516110: ProcessNativeScript (scripting.c:10796) ==74312==by 0x5516744: _CheckIsScript (scripting.c:10890) ==74312==by 0x5516744: CheckIsScript (scripting.c:10927) ==74312==by 0x4A165B8: fontforge_main (startui.c:1099) ==74312==by 0x4C13BBA: (below main) (libc-start.c:308) ==74312== Block was alloc'd at ==74312==at 0x4838B65: calloc (vg_replace_malloc.c:762) ==74312==by 0x5486A1B: ttf_math_read_gvtable (parsettfatt.c:5317) ==74312==by 0x5491113: ttf_math_read_variants (parsettfatt.c:5473) ==74312==by 0x5491113: _otf_read_math (parsettfatt.c:5515) ==74312==by 0x5491113: _otf_read_math (parsettfatt.c:5493) ==74312==by 0x54A87D4: readttf (parsettf.c:5673) ==74312==by 0x54A87D4: _SFReadTTF (parsettf.c:6327) ==74312==by 0x556808E: _ReadSplineFont (splinefont.c:1141) ==74312==by 0x5569238: LoadSplineFont (splinefont.c:1379) ==74312==by 0x550B0E2: bMergeFonts (scripting.c:5600) ==74312==by 0x5512F0A: docall (scripting.c:9632) ==74312==by 0x551359D: handlename (scripting.c:9745) ==74312==by 0x55147B2: term (scripting.c:9983) ==74312==by 0x5514B37: mul (scripting.c:10128) ==74312==by 0x5514D4D: add (scripting.c:10174) ==74312==by 0x55150B8: comp (scripting.c:10249) ==74312==by 0x5515340: _and (scripting.c:10293) ==74312==by 0x55154E2: _or (scripting.c:10325) ==74312==by 0x55154E2: assign (scripting.c:10358) ==74312
Bug#943398: linux-perf-5.2: perf report segmentation fault
Control: forwarded -1 https://marc.info/?l=linux-kernel=157973791626377=2 Control: tags -1 + upstream Hello Salvatore, thanks for the link. I tried to get in contact with upstream. Kind regards, Bernhard https://www.spinics.net/lists/kernel/msg3384013.html https://marc.info/?l=linux-kernel=157973791626377=2
Bug#948876: kodi: FTBFS: something segfaults
Dear Maintainer, I tried to look into this issue without being involved in packaging fontforge. I found it most reproducible when building with "-fsanitize=address", and then always failing on accessing the same address. [1] As far as I see this is what happens: - Address 0x6048a210 gets returned by the allocator [2], and stored in "sf->glyphs[49391]->vert_variants". - Memory gets freed below SplineFontFree while still stored below "sf->..." [3]. - Address 0x6048a210 gets returned a second time. This is returned as the previous allocation by AddressSanitizer [1]. - And freed again. - The first pointer gets further copied around (See attached file.) - Now in gv_len this address is again accessed and causes the crash. [1] (Is there a way to force AddressSanitizer to return unique memory addresses?) The line numbers of the AddressSanitizer outputs do not completely match because of some added fprintf's. A temporary workaround could be to disable the call to SplineFontFree in _MergeFont. Then no crash happens. Kind regards, Bernhard [1] ==111281==ERROR: AddressSanitizer: heap-use-after-free on address 0x6048a210 at pc 0x7fc246fb1ea9 bp 0x7fff40ed9800 sp 0x7fff40ed97f8 READ of size 8 at 0x6048a210 thread T0 #0 0x7fc246fb1ea8 in gv_len ./fontforge/tottfgpos.c:3838 #1 0x7fc246fcce1f in ttf_math_dump_glyphvariant ./fontforge/tottfgpos.c:3979 #2 0x7fc246fcce1f in otf_dump_math ./fontforge/tottfgpos.c:4139 #3 0x7fc246fff7f0 in initATTables ./fontforge/tottf.c:5316 #4 0x7fc24700297e in initTables ./fontforge/tottf.c:5792 #5 0x7fc247003737 in _WriteTTFFont ./fontforge/tottf.c:6143 #6 0x7fc2470040b1 in WriteTTFFont ./fontforge/tottf.c:6171 #7 0x7fc246d09d1b in _DoSave ./fontforge/savefont.c:845 #8 0x7fc246d0ec2b in GenerateScript ./fontforge/savefont.c:1269 #9 0x7fc246d5d592 in bGenerate ./fontforge/scripting.c:2061 #10 0x7fc246d63b7d in docall ./fontforge/scripting.c:9632 #11 0x7fc246d64be1 in handlename ./fontforge/scripting.c:9745 #12 0x7fc246d67aa1 in term ./fontforge/scripting.c:9983 #13 0x7fc246d684fb in mul ./fontforge/scripting.c:10128 #14 0x7fc246d68a0b in add ./fontforge/scripting.c:10174 #15 0x7fc246d6943c in comp ./fontforge/scripting.c:10249 #16 0x7fc246d69b10 in _and ./fontforge/scripting.c:10293 #17 0x7fc246d6a04a in _or ./fontforge/scripting.c:10325 #18 0x7fc246d6a04a in assign ./fontforge/scripting.c:10358 #19 0x7fc246d620d9 in expr ./fontforge/scripting.c:10436 #20 0x7fc246d620d9 in ff_statement ./fontforge/scripting.c:10649 #21 0x7fc246d6bddd in ProcessNativeScript ./fontforge/scripting.c:10796 #22 0x7fc246d6c944 in _CheckIsScript ./fontforge/scripting.c:10890 #23 0x7fc246d6c944 in CheckIsScript ./fontforge/scripting.c:10927 #24 0x7fc2477c8643 in fontforge_main ./fontforgeexe/startnoui.c:122 #25 0x7fc24762cbba in __libc_start_main ../csu/libc-start.c:308 #26 0x5568a79b80c9 in _start (/home/benutzer/source/libfontforge3/try2/fontforge-20190801~dfsg/debian/fontforge-nox/usr/bin/fontforge+0x10c9) 0x6048a210 is located 0 bytes inside of 35-byte region [0x6048a210,0x6048a233) freed by thread T0 here: #0 0x7fc2478d4277 in __interceptor_free (/lib/x86_64-linux-gnu/libasan.so.5+0x107277) #1 0x7fc246fe6564 in dumpglyph ./fontforge/tottf.c:1331 previously allocated by thread T0 here: #0 0x7fc2478d4628 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x107628) #1 0x7fc246fe6336 in dumpglyph ./fontforge/tottf.c:1316 [2] # Alloction 1 (gdb) print gv $1 = (struct glyphvariants *) 0x6048a210 (gdb) bt #0 0x769adb01 in ttf_math_read_gvtable (ttf=ttf@entry=0x6160002bfb80, info=info@entry=0x7fffc3c0, start=, justinuse=justinuse@entry=git_normal, basesc=basesc@entry=0x613002af2800, isv=isv@entry=1) at ././fontforge/parsettfatt.c:5318 #1 0x769c7653 in ttf_math_read_variants (justinuse=git_normal, start=47440, info=0x7fffc3c0, ttf=0x6160002bfb80) at ././fontforge/parsettfatt.c:5474 #2 0x769c7653 in _otf_read_math (justinuse=git_normal, info=, ttf=0x6160002bfb80) at ././fontforge/parsettfatt.c:5518 #3 0x769c7653 in _otf_read_math (ttf=0x6160002bfb80, info=, justinuse=git_normal) at ././fontforge/parsettfatt.c:5496 #4 0x76a08515 in readttf (filename=, info=, ttf=0x6020004fd210) at ././fontforge/parsettf.c:5673 #5 0x76a08515 in _SFReadTTF (ttf=ttf@entry=0x6160002bfb80, flags=flags@entry=0, openflags=openflags@entry=(unknown: 0), filename=filename@entry=0x60470690 "/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf", chosenname=chosenname@entry=0x0, fd=fd@entry=0x0) at ././fontforge/parsettf.c:6327 #6 0x76c08d80 in _ReadSplineFont (file=, file@entry=0x0, filename=filename@entry=0x60470650 "/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf", openflags=openflags@entry=(unknown: 0)) at ././fontforge
Bug#943398: linux-perf-5.2: perf report segmentation fault
Hello Salvatore, > Can you report the issue directly upstream? Will do, but I am not sure exactly to where. I found the MAINTAINERS file and I guess if there is no "B:" line it has to be reported to the "L:" list ? Kind regards, Bernhard https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS#n12936
Bug#949257: xserver-xorg-core: Segmentation fault w/ 1.20.7
Hello Jamie Heilman, I just tried to retrieve some line information from the backtrace. Unfortunately I could not match the addresses with the binary from the debian repository. Was this backtrace by any chance built with a local rebuild of the xserver-xorg-core package? Kind regards, Bernhard
Bug#948288: gnome-shell reproducibly crashes on boot, and the boot process gets stuck
Hello Md Ayquassar, could you please additionally run following and attach the output to this bug: reportbug --template gnome-shell I am asking because trying to open the coredump shows following warning inside a minimal uptodate Buster/stable VM, which could point to a incompatibility of some used shared libraries: warning: Could not load shared library symbols for 120 libraries, e.g. /lib/i386-linux-gnu/libgio-2.0.so.0. Kind regards, Bernhard
Bug#693587: bind9: stop resolving
On Wed, Dec 11, 2019 at 12:54:23AM +0100, Marco d'Itri wrote: > Control: forwarded -1 https://gitlab.isc.org/isc-projects/bind9/issues/1483 > > On Nov 24, Ondřej Surý wrote: > > > could you please fill an upstream issue? > Done. > > I will also add that I have found a workaround: sending SIGSTOP to named > before suspend and SIGCONT a few seconds after resume. Upstream recommended this: ---snip--- This will almost certainly be the result of packet loss immediately after resume causing named to retry without EDNS (and DO=1) in a attempt to get a response. The subsequent responses fail validation as they do not contain DNSSEC records. This behaviour was done to work around badly configured firewalls that dropped EDNS or EDNS with DO=1 or EDNS with DO=1 and DNS COOKIE options present (different levels of breakage). Falling back to plain DNS on packet loss was changed in post DNS flag day releases and BIND 9.14 does not retry with differing flags on packet loss. I would recommend upgrading to BIND 9.14. ---snip--- Since we finally have 9.15 in experimental, could you please try this and give feedback? Thanks, Bernhard
Bug#948388: navit: fails to connect to gpsd
Hello Bernd, I could further isolate the cmake failing issue. It starts failing when the package qtbase5-dev is installed. This gets installed as build dependency for libgps26. A workaround would be to temporarily uninstall qtbase5-dev. Maybe better would be to add following to navit to allow building while qtbase5-dev is installed. Building that way produces equal .deb packages. Kind regards, Bernhard --- navit-0.5.3+dfsg.1.orig/debian/rules2018-09-01 12:16:52.0 +0200 +++ navit-0.5.3+dfsg.1/debian/rules2020-01-15 23:57:58.840074000 +0100 @@ -75,6 +75,9 @@ CMAKEFLAGS += -Dsupport/shapefile=TRUE # Enable libspeechd CMAKEFLAGS += -Dspeech/speech_dispatcher=TRUE +# Disable Qt explicitly to allow building while qtbase5-dev is installed +CMAKEFLAGS += -DDISABLE_QT=TRUE + # Avoid floating point calculation for armel ifeq ($(DEB_HOST_ARCH), armel) CMAKEFLAGS += -DAVOID_FLOAT=TRUE
Bug#948388: navit: fails to connect to gpsd
Hello Bernd, my navit know-how is also limited, but I remebered I saw this while having build-deps of navit and libgps installed. Below are the packages which got installed additionally in a minimal test VM on top of navit's build-deps. If there are just build-deps's of navit installed the build runs fine until the compile error given in message 18. For this I made this (to be checked) change: -priv->fix_time = data->fix.time; +priv->fix_time = data->fix.time.tv_sec; Kind regards, Bernhard apt build-dep libgps26 asciidoc asciidoc-base asciidoc-common bc dh-apparmor dh-buildinfo dh-exec dh-python docbook-xml docbook-xsl libbluetooth-dev libbluetooth3 libdouble-conversion3 libegl-dev libegl-mesa0 libegl1 libevdev2 libgbm1 libgudev-1.0-0 libinput-bin libinput10 libmtdev1 libncurses-dev libpython3-all-dbg libpython3-all-dev libpython3-dbg libpython3-dev libpython3.7-dbg libpython3.7-dev libpython3.8 libpython3.8-dbg libpython3.8-dev libpython3.8-minimal libpython3.8-stdlib libqt5concurrent5 libqt5core5a libqt5dbus5 libqt5gui5 libqt5network5 libqt5printsupport5 libqt5sql5 libqt5test5 libqt5widgets5 libqt5xml5 libusb-1.0-0-dev libvulkan-dev libvulkan1 libwacom-common libwacom2 libwayland-client0 libwayland-server0 libxcb-icccm4 libxcb-image0 libxcb-keysyms1 libxcb-randr0 libxcb-render-util0 libxcb-shape0 libxcb-util0 libxcb-xfixes0 libxcb-xinerama0 libxcb-xinput0 libxcb-xkb1 libxkbcommon-x11-0 libxkbcommon0 libxslt1.1 makedev pps-tools python3-all python3-all-dbg python3-all-dev python3-dbg python3-dev python3.7-dbg python3.7-dev python3.8 python3.8-dbg python3.8-dev python3.8-minimal qt5-qmake qt5-qmake-bin qtbase5-dev qtbase5-dev-tools qtchooser scons sgml-base sgml-data xml-core xsltproc
Bug#942081: utox: segfault on setting proxy settings
Control: found -1 0.17.0-1 Dear Maintainer, I tried to collect some more information and could reproduce the issue. I guess the interesting thread is not that with the main function. Instead it is that thread with the tox_kill / __GI_abort. There I think that tox_kill in libtoxcore2 is reached while not completely shut down, therefore aborts in this LOGGER_ASSERT. Unfortunately that message was not printed on stderr/out. There exists upstream issue [1] based on this bug, with a workaround mentioned. This issue can already be seen in Buster/stable too. Kind regards, Bernhard (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x7f6209ebb535 in __GI_abort () at abort.c:79 #2 0x7f620ad3385a in tox_kill (tox=tox@entry=0x7f61c4000d50) at ./toxcore/tox.c:578 #3 0x560b734da5a1 in toxcore_thread (UNUSED_args=) at ./src/tox.c:572 #4 0x7f620aa52fb7 in start_thread (arg=) at pthread_create.c:486 #5 0x7f6209f902df in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 (gdb) #2 0x7f620ad3385a in tox_kill (tox=tox@entry=0x7f61c4000d50) at ./toxcore/tox.c:578 578 LOGGER_ASSERT(m->log, m->msi_packet == nullptr, "Attempted to kill tox while toxav is still alive"); (gdb) print m->msi_packet $1 = (m_msi_packet_cb *) 0x7f620ad389b0 https://sources.debian.org/src/libtoxcore/0.2.10-1/toxcore/tox.c/#L578 https://sources.debian.org/src/utox/0.17.1-1/src/tox.c/#L572 [1] https://github.com/uTox/uTox/issues/1376 # Bullseye/testing amd64 qemu VM 2020-01-14 apt update apt dist-upgrade apt install systemd-coredump xserver-xorg sddm openbox xterm fakeroot gdb utox utox-dbgsym libtoxcore2-dbgsym apt build-dep utox reboot mkdir /home/benutzer/source/utox/orig -p cd/home/benutzer/source/utox/orig apt source utox cd mkdir /home/benutzer/source/libtoxcore/orig -p cd/home/benutzer/source/libtoxcore/orig apt source libtoxcore cd export LANG=C export DISPLAY=:0 utox coredumpctl list coredumpctl gdb 696 set width 0 set pagination off directory /home/benutzer/source/libtoxcore/orig/libtoxcore-0.2.10 directory /home/benutzer/source/utox/orig/utox-0.17.1 ## benutzer@debian:~$ utox Settings: Unable to parse utox_save.ini. Settings: Unable to open utox_save. Settings: Unable to load uTox settings. Use defaults. XLib Tray:Incoming tray window event (28) XLib tray:Reached end of function, this is bad juju! Aborted (core dumped) root@debian:~# coredumpctl list TIMEPID UID GID SIG COREFILE EXE Tue 2020-01-14 23:33:51 CET 696 1000 1000 6 present /usr/bin/utox root@debian:~# coredumpctl gdb 696 PID: 696 (utox) UID: 1000 (benutzer) GID: 1000 (benutzer) Signal: 6 (ABRT) Timestamp: Tue 2020-01-14 23:33:50 CET (1min 9s ago) Command Line: utox Executable: /usr/bin/utox Control Group: /user.slice/user-1000.slice/session-7.scope Unit: session-7.scope Slice: user-1000.slice Session: 7 Owner UID: 1000 (benutzer) Boot ID: 7b7aab6c8d274a96b162737e6c652404 Machine ID: 33f18f39d2a9438eb75b0ed52848afcd Hostname: debian Storage: /var/lib/systemd/coredump/core.utox.1000.7b7aab6c8d274a96b162737e6c652404.696.1579041230.lz4 Message: Process 696 (utox) of user 1000 dumped core. Stack trace of thread 711: #0 0x7f6209ed0081 __GI_raise (libc.so.6 + 0x3a081) #1 0x7f6209ebb535 __GI_abort (libc.so.6 + 0x25535) #2 0x7f620ad3385a tox_kill (libtoxcore.so.2 + 0x2c85a) #3 0x560b734da5a1 toxcore_thread (utox + 0x2b5a1) #4 0x7f620aa52fb7 start_thread (libpthread.so.0 + 0x8fb7) #5 0x7f6209f902df __clone (libc.so.6 + 0xfa2df) Stack trace of thread 708: #0 0x7f620aa58db5 futex_wait_cancelable (libpthread.so.0 + 0xedb5) #1 0x7f620597403b n/a (swrast_dri.so + 0x18203b) #2 0x7f6205973eb7 n/a (swrast_dri.so + 0x181eb7) #3 0x7f620aa52fb7 start_thread (libpthread.so.0 + 0x8fb7) #4 0x7f6209f902df __clone (libc.so.6 + 0xfa2df) Stack trace of thread 702: #0 0x7f620aa58db5 futex_wait_cancelable (libpthread.so.0 + 0xedb5) #1 0x7f620597403b n/a (swrast_dri.so + 0x18203b) #2 0x7f6205973eb7 n/a (swrast_dri.so + 0x181eb7) #3 0x7f620aa52fb7 start_thread (libpthread.so.0 + 0x8fb7) #4 0x7f6209f902df __clone (libc.so.6 + 0xfa2df) Stack trace of thread 700: #0 0x7f620aa58db5 futex_wait_cancelable (libpthread.so.0 + 0xedb5) #1 0x7f620597403b n/a (swras
Bug#945814: Fwd: Bug#945814: audacity: various segfaults of audacity on startup
Sorry, forget the right email. Forwarded Message Betreff: Re: Bug#945814: audacity: various segfaults of audacity on startup Datum: Tue, 14 Jan 2020 11:46:06 +0100 Von: Bernhard Übelacker An: 945...@bugs.debian.org Hello Tjeerd, If this issue still exists on your system, you might try to rename $HOME/.audacity-data to test if it depends on some settings stored there. If it still crashes then you might start it by following and forward the output: $ catchsegv audacity Better would be if you could install the packages: systemd-coredump gdb valgrind audacity-dbgsym The last one is in a different repository described here [1]. Then some more information should appear after a crash in 'journalctl --no-pager'. Also running audacity by following could give some pointer: $ valgrind audacity Kind regards, Bernhard [1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols
Bug#945814: audacity: various segfaults of audacity on startup
Hello Tjeerd, If this issue still exists on your system, you might try to rename $HOME/.audacity-data to test if it depends on some settings stored there. If it still crashes then you might start it by following and forward the output: $ catchsegv audacity Better would be if you could install the packages: systemd-coredump gdb valgrind audacity-dbgsym The last one is in a different repository described here [1]. Then some more information should appear after a crash in 'journalctl --no-pager'. Also running audacity by following could give some pointer: $ valgrind audacity Kind regards, Bernhard [1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols
Bug#942410: gnome-settings-daemon: gsd-housekeeping crashes
Dear Maintainer, hello Benjamin, the core seems at least related to the "Too many open files" lines. Unfortunately I cannot get the whole backtrace (see below). The crash seems to be the same as already reported in #851498, which got forwarded to upstream in [1]. I guess in "Gnome - Settings - Privacy - Purge Trash & Temoprary Files", by default "Automatically purge Temporary Files" is off, so this might not show up by default. There is another upstream issue about the "Permission denied" messages in [2], Ubuntu downstream in [3], Fedora [4]. For the missing files - got the partition mounted to e.g. /tmp/fsa/20191015-204501-00010385-00 ? If then gsd-housekeeping walks there and finds old files in that directory would it might delete them? Kind regards, Bernhard #851498 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851498 [1] https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues/345 [2] https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues/26 [3] https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1745666 [4] https://bugzilla.redhat.com/show_bug.cgi?id=1563445 (gdb) bt #0 0x7f3bde066c75 in _g_log_abort (breakpoint=1) at ../../../glib/gmessages.c:554 #1 0x7f3bde067d0d in g_log_default_handler (log_domain=log_domain@entry=0x7f3bde0ac00e "GLib", log_level=log_level@entry=6, message=message@entry=0x56301f465d60 "Creating pipes for GWakeup: Too many open files", unused_data=unused_data@entry=0x0) at ../../../glib/gmessages.c:3111 #2 0x7f3bde067f5f in g_logv (log_domain=0x7f3bde0ac00e "GLib", log_level=G_LOG_LEVEL_ERROR, format=, args=args@entry=0x7ffdb8b33f20) at ../../../glib/gmessages.c:1350 #3 0x7f3bde06814f in g_log (log_domain=log_domain@entry=0x7f3bde0ac00e "GLib", log_level=log_level@entry=G_LOG_LEVEL_ERROR, format=format@entry=0x7f3bde10f1d8 "Creating pipes for GWakeup: %s") at ../../../glib/gmessages.c:1413 #4 0x7f3bde0a6a4a in g_wakeup_new () at ../../../glib/gwakeup.c:161 #5 0x7f3bde05e703 in g_main_context_new () at ../../../glib/gmain.c:656 #6 0x7f3bde27ecd6 in g_dbus_connection_send_message_with_reply_sync (connection=connection@entry=0x56301f366070 [GDBusConnection], message=message@entry=0x7f3bcc006450 [GDBusMessage], flags=flags@entry=G_DBUS_SEND_MESSAGE_FLAGS_NONE, timeout_msec=timeout_msec@entry=-1, out_serial=out_serial@entry=0x0, cancellable=cancellable@entry=0x0, error=0x7ffdb8b34100) at ../../../gio/gdbusconnection.c:2129 #7 0x7f3bde27f11f in g_dbus_connection_call_sync_internal (connection=0x56301f366070 [GDBusConnection], bus_name=bus_name@entry=0x56301f58c5f0 ":1.27", object_path=0x56301f43acf0 "/org/gtk/vfs/metadata", interface_name=interface_name@entry=0x56301f3b6f40 "org.gtk.vfs.Metadata", method_name=method_name@entry=0x7f3bdc333e16 "GetTreeFromDevice", parameters=parameters@entry=0x7f3bc008ec10, reply_type=0x56301f591aa0, flags=G_DBUS_CALL_FLAGS_NONE, timeout_msec=-1, fd_list=0x0, out_fd_list=0x0, cancellable=0x0, error=0x7ffdb8b342e0) at ../../../gio/gdbusconnection.c:5941 #8 0x7f3bde281605 in g_dbus_connection_call_with_unix_fd_list_sync (connection=, bus_name=bus_name@entry=0x56301f58c5f0 ":1.27", object_path=, interface_name=interface_name@entry=0x56301f3b6f40 "org.gtk.vfs.Metadata", method_name=method_name@entry=0x7f3bdc333e16 "GetTreeFromDevice", parameters=parameters@entry=0x7f3bc008ec10, reply_type=0x56301f591aa0, flags=G_DBUS_CALL_FLAGS_NONE, timeout_msec=-1, fd_list=0x0, out_fd_list=0x0, cancellable=0x0, error=0x7ffdb8b342e0) at ../../../gio/gdbusconnection.c:6290 #9 0x7f3bde28b809 in g_dbus_proxy_call_sync_internal (proxy=0x56301f36b4b0 [GVfsMetadataProxy], method_name=method_name@entry=0x7f3bdc333e16 "GetTreeFromDevice", parameters=parameters@entry=0x7f3bc008ec10, flags=flags@entry=G_DBUS_CALL_FLAGS_NONE, timeout_msec=timeout_msec@entry=-1, fd_list=fd_list@entry=0x0, out_fd_list=0x0, cancellable=0x0, error=0x7ffdb8b342e0) at ../../../gio/gdbusproxy.c:2870 #10 0x7f3bde28cc74 in g_dbus_proxy_call_sync (proxy=, method_name=method_name@entry=0x7f3bdc333e16 "GetTreeFromDevice", parameters=parameters@entry=0x7f3bc008ec10, flags=flags@entry=G_DBUS_CALL_FLAGS_NONE, timeout_msec=timeout_msec@entry=-1, cancellable=cancellable@entry=0x0, error=0x7ffdb8b342e0) at ../../../gio/gdbusproxy.c:3062 #11 0x7f3bdc32aaf8 in gvfs_metadata_call_get_tree_from_device_sync (proxy=0x56301f36b4b0, arg_major=arg_major@entry=8, arg_minor=, out_tree=out_tree@entry=0x7ffdb8b342d8, cancellable=cancellable@entry=0x0, error=error@entry=0x7ffdb8b342e0) at metadata/metadata-dbus.c:969 #12 0x7f3bdc32f636 in get_tree_for_device (cache=0x56301f65b850, cache=0x56301f65b850, device=2052) at /usr/include/x86_64-linux-gnu/sys/sysmacros.h:41 #13 0x7f3bdc32f636 i
Bug#948760: berusky2: Compile without warnings
Hello Asher, hello Markus, sorry, I wasn't aware of that patch being applied at Salsa as there was no more activity in 944431, so I thought it went through unnoticed. Sorry for the noise. Kind regards, Bernhard
Bug#930563: Can not start freecad
Hello Gulfstream, On Mon, 17 Jun 2019 11:17:48 +0800 (GMT+08:00) wg...@china.com wrote: > > I have install the proprietary nvidia drivers and it runs well. > Another user reported the same error and he had installed the nvidia driver by their installer. He could solve the issue by uninstalling it and installing by the Debian nvidia-driver package. Have you by any chance also used the nvidia installer in the first place? Kind regards, Bernhard
Bug#943398: linux-perf-5.2: perf report segmentation fault
Dear Maintainer,
I could reproduce using linux-perf-5.2 and it is
also visible in linux-perf-5.4 5.4.8-1,
by just pressing enter.
The crash happens because in line 3172
function hist_browser__selected_entry returns
browser->he_selection, which is at this time a
null pointer.
This null pointer gets dereferenced to
access the res_samples member.
Upstream seems to have fixed other occourences [1]
of browser->he_selection being null, but this is
already contained in 5.4 while a crash still happens.
Kind regards,
Bernhard
Program received signal SIGSEGV, Segmentation fault.
(rr) bt
#0 perf_evsel__hists_browse (evsel=0x55e794ebcb40,
nr_events=nr_events@entry=1, helpline=helpline@entry=0x55e794f7c040 "Tip:
System-wide collection from all CPUs: perf record -a",
left_exits=left_exits@entry=false, hbt=hbt@entry=0x0, min_pcnt=,
env=env@entry=0x55e794eb54f0, warn_lost_event=true,
annotation_opts=0x7ffcc3063dc8) at ui/browsers/hists.c:3170
#1 0x55e79385cce9 in perf_evlist__tui_browse_hists
(evlist=evlist@entry=0x55e794ebc0c0, help=help@entry=0x55e794f7c040 "Tip:
System-wide collection from all CPUs: perf record -a", hbt=hbt@entry=0x0,
min_pcnt=, env=env@entry=0x55e794eb54f0,
warn_lost_event=warn_lost_event@entry=true,
annotation_opts=annotation_opts@entry=0x7ffcc3063dc8) at
ui/browsers/hists.c:3422
#2 0x55e7936f1ece in report__browse_hists (rep=0x7ffcc3063c30) at
builtin-report.c:585
#3 __cmd_report (rep=0x7ffcc3063c30) at builtin-report.c:930
#4 cmd_report (argc=, argv=) at
builtin-report.c:1475
#5 0x55e79375b823 in run_builtin (p=0x55e793a9ef90 , argc=2,
argv=0x7ffcc30661f0) at perf.c:312
#6 0x55e7936d6a2c in handle_internal_command (argv=,
argc=) at perf.c:364
#7 run_argv (argcp=, argv=) at perf.c:408
#8 main (argc=2, argv=0x7ffcc30661f0) at perf.c:538
https://sources.debian.org/src/linux/5.4.8-1/tools/perf/ui/browsers/hists.c/#L2217
2217 static struct hist_entry *hist_browser__selected_entry(struct
hist_browser *browser)
2218 {
2219return browser->he_selection;
2220 }
https://sources.debian.org/src/linux/5.4.8-1/tools/perf/ui/browsers/hists.c/#L3170
3170nr_options += add_res_sample_opt(browser,
[nr_options],
3171 [nr_options],
3172
hist_browser__selected_entry(browser)->res_samples,
3173 evsel, A_NORMAL);
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/tools/perf/ui/browsers/hists.c?id=ceb75476db1617a88cc29b09839acacb69aa076e
# Bullseye/testing amd64 qemu VM 2020-01-13
apt update
apt dist-upgrade
apt install systemd-coredump mc colorized-logs gdb rr linux-perf-5.4
linux-perf-5.4-dbgsym
perf record ls
perf report perf.data
# Press enter
###
# 5.2.17-1+b1
wget
https://snapshot.debian.org/archive/debian/20191006T205801Z/pool/main/l/linux/linux-perf-5.2_5.2.17-1%2Bb1_amd64.deb
wget
https://snapshot.debian.org/archive/debian/20191006T205801Z/pool/main/l/linux/linux-image-5.2.0-3-amd64-unsigned_5.2.17-1%2Bb1_amd64.deb
wget
https://snapshot.debian.org/archive/debian-debug/20191006T210740Z/pool/main/l/linux/linux-perf-5.2-dbgsym_5.2.17-1%2Bb1_amd64.deb
dpkg -i linux-image-5.2.0-3-amd64-unsigned_5.2.17-1+b1_amd64.deb
linux-perf-5.2_5.2.17-1+b1_amd64.deb
reboot
root@debian:~# uname -a
Linux debian 5.2.0-3-amd64 #1 SMP Debian 5.2.17-1 (2019-10-06) x86_64 GNU/Linux
root@debian:~# perf record ls
...
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0,009 MB perf.data (2 samples) ]
root@debian:~# perf report perf.data
perf: Speicherzugriffsfehler
backtrace
perf_5.2(+0x322d14)[0x5631251b2d14]
/lib/x86_64-linux-gnu/libc.so.6(+0x3a0ff)[0x7f88ec6ee0ff]
perf_5.2(+0x32021e)[0x5631251b021e]
perf_5.2(+0x3211c8)[0x5631251b11c8]
perf_5.2(+0x1bb4f5)[0x56312504b4f5]
perf_5.2(+0x222072)[0x5631250b2072]
perf_5.2(+0x1a0a13)[0x563125030a13]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea)[0x7f88ec6dabba]
perf_5.2(+0x1a0c69)[0x563125030c69]
root@debian:~# gdb -q --args perf_5.2 report perf.data
Reading symbols from perf_5.2...
(No debugging symbols found in perf_5.2)
(gdb) set width 0
(gdb) set pagination off
(gdb) run
...
rogram received signal SIGSEGV, Segmentation fault.
0x5587421e in ?? ()
(gdb) bt
#0 0x5587421e in ?? ()
#1 0x558751c9 in ?? ()
#2 0x5570f4f6 in ?? ()
#3 0x55776073 in ?? ()
#4 0x556f4a14 in ?? ()
#5 0x7758abbb in __libc_start_main (main=0x556f43b0, argc=3,
argv=0x7fffecf8, init=, fini=,
rtld_fini=, stack_end=0x7fffece8) at ../csu/libc-start.c:308
#6 0x556f4c6a in ?? ()
(gdb) generate-core /root/core-perf_5.2
warning: target file /proc/800/cmdline contained unexpected null characters
Saved corefile /root/core-perf_5.2
r
Bug#930563: Can not start freecad
Hello Jean-Luc, thanks for your information. Please use the reply-to-all button to have the information forwarded to the bug report. Am 08.01.20 um 17:21 schrieb Jean-Luc Lacroix: > Hallo Bernhard, > > My system only has a single GPU (Nvidia GTX 970, see attached config) > installed on a robust tower powered by a i7-4790K with plenty of RAM. > > It must be package related as the package (Stretch) was running without > any issue. > > Attached my config. > > Cheers > > Jean-Luc Find below the information of libGLdispatch.so.0 from a Buster VM, without any nvidia drivers. There exists the _glapi_tls_Current symbol. After installing the package nvidia-driver the files and links libGLdispatch.so.0* and libOpenGL.so.0* were unchanged. Therefore the question, where does your libGLdispatch.so.0 come from? How did you install the nvidia driver - by the Debian package or did you use the installer from NVidia? Kind regards, Bernhard # Buster stable without nvidia-drivre installed: benutzer@debian:~$ nm -D /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 | grep tls D _glapi_tls_Current benutzer@debian:~$ ls -la /usr/lib/x86_64-linux-gnu/libGLdispatch.so* /usr/lib/x86_64-linux-gnu/libOpenGL.so.0* lrwxrwxrwx 1 root root 22 Aug 10 2018 /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 -> libGLdispatch.so.0.0.0 -rw-r--r-- 1 root root 637384 Aug 10 2018 /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0.0.0 lrwxrwxrwx 1 root root 18 Aug 10 2018 /usr/lib/x86_64-linux-gnu/libOpenGL.so.0 -> libOpenGL.so.0.0.0 -rw-r--r-- 1 root root 194880 Aug 10 2018 /usr/lib/x86_64-linux-gnu/libOpenGL.so.0.0.0 benutzer@debian:~$ dpkg -S /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 libglvnd0:amd64: /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 benutzer@debian:~$ dpkg -S /usr/lib/x86_64-linux-gnu/libOpenGL.so.0 libopengl0:amd64: /usr/lib/x86_64-linux-gnu/libOpenGL.so.0 benutzer@debian:~$ dpkg -l | grep -E "libglvnd0|libopengl0" ii libglvnd0:amd64 1.1.0-1 amd64Vendor neutral GL dispatch library ii libopengl0:amd64 1.1.0-1 amd64Vendor neutral GL dispatch library -- OpenGL support
Bug#948626: kicad: Closing pcbnew hangs main kicad process
Hello Paul, in that case I guess kicad is really trying to leave the process for some reason. That reason is maybe written to stdout. Therefore maybe you can run kicad from a terminal and attach its output. Probably that could give any hints. Otherwise maybe it is related to the used desktop environment, if xorg or wayland is in use, or the used project - do you observe this behaviour if you just open one of the templates? Kind regards, Bernhard
Bug#948760: berusky2: Compile without warnings
Hello Asher, maybe you want to incorporate the changes given here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944431#31 Unfortunately I was too late there. Then the call to e.g. SetThreadPriority would not needed to get commented out, and the "-O0" fix in #944431 could be removed again, I guess. Kind regards, Bernhard
Bug#316549: time-daemon pseudopackage
Control: affects -1 src:ntp Am 13.01.20 um 02:02 schrieb Michael Biebl: Hi Michael, On Fri, 1 Jul 2005 13:49:45 -0400 Justin Pryzby wrote: Package: chrony, ntp Severity: normal Only openntpd provides, conflicts, replaces: time-daemon. Seems all NTP clients (ntpsec, chrony, openntpd) aside from ntp itself have Conflict/Replaces/Provides: time-daemon nowadays to prevent multiple implementations being installed and enabled at the same time. This is a common mechanism defined in policy [1] It's kinda annyoing that they all have to special case ntp and must declare explicit Conflicts against ntp. Would be great if you can reconsider this and consider adding Conflict/Replaces/Provides: time-daemon to ntp Hrm, I wasn't involved in this discussion. Right now I don't see a major blocker. There are a few packages that need time sync and only depend on ntp without time-daemon (bwctl-server, lava, openstack-cloud-services, openstack-compute-nodes), we should probably file bugs against them if they only need some timekeeping facility. I remember that some time ago some monitoring solutions also depended on ntp to use and parse the output of ntpq or ntpdc, possibly on remote servers. I only see hobbit-plugins doing that right now, and only using Suggests. Unless I find a major issue I'll do this in the next upload. Bernhard
Bug#948543: gnome-logs: Unable to start gnome-logs due to Segmentation fault
Dear Maintainer, I could reproduce this issue. Upstream fixed this crash with this upstream commit: https://gitlab.gnome.org/GNOME/gnome-logs/commit/7d0062a4ab36d457b74fe17b8d494570d4a0334b A package build with this patch applied still crashes, which got fixed in this upstream commit: https://gitlab.gnome.org/GNOME/gnome-logs/commit/86ae341d6837e7b6b36bd8e0c65be0211ef37eba With both patches applied it does not crash (and shows no logs as expected as non-root user). Both patches seem to be already contained in gnome-logs 3.34.0-1 currently in testing, therefore this issue should just affect Buster or older. Kind regards, Bernhard (gdb) bt #0 0x55a9d5e79b4f in gl_journal_update_latest_timestamp (journal=0x55a9d6de69e0) at ../src/gl-journal.c:98 #1 gl_journal_get_boot_time (journal=0x55a9d6de69e0, boot_match=0x0) at ../src/gl-journal.c:127 #2 0x55a9d5e7b4c9 in gl_journal_model_get_boot_time (model=, boot_match=) at ../src/gl-journal-model.c:1158 #3 0x55a9d5e756b0 in gl_event_view_list_get_boot_time (view=view@entry=0x55a9d6ce53c0, boot_match=) at ../src/gl-eventviewlist.c:402 #4 0x55a9d5e7d721 in on_category_list_changed (list=, pspec=, user_data=) at ../src/gl-window.c:252 #5 0x7f2ddab5fc8d in g_closure_invoke (closure=0x55a9d70b8ba0, return_value=0x0, n_param_values=2, param_values=0x7ffec12b7ee0, invocation_hint=0x7ffec12b7e60) at ../../../gobject/gclosure.c:810 ... #57 0x55a9d5e7155c in main (argc=1, argv=0x7ffec12b9858) at ../src/gl-main.c:39 (gdb) # Buster/stable amd64 qemu VM 2020-01-12 apt update apt dist-upgrade apt install systemd-coredump gnome apt build-dep gnome-logs mkdir /home/benutzer/source/gnome-logs/orig -p cd/home/benutzer/source/gnome-logs/orig apt source gnome-logs cd benutzer@debian:~$ export DISPLAY=:0 benutzer@debian:~$ gnome-logs ** (gnome-logs:3016): WARNING **: 19:13:04.073: Error retrieving the sender timestamps: Die angeforderte Adresse kann nicht zugewiesen werden Speicherzugriffsfehler (Speicherabzug geschrieben) dmesg: [ 121.990363] gnome-logs[3016]: segfault at 17fff8 ip 55a9d5e79b4f sp 7ffec12b7cc0 error 4 in gnome-logs[55a9d5e7+e000] [ 121.990370] Code: 43 18 48 8b 3b 48 89 e6 8b 50 08 48 8b 00 83 ea 01 48 8d 14 52 4c 8d 24 d0 e8 4d 6b ff ff 85 c0 0f 88 fd 00 00 00 48 8b 04 24 <49> 39 44 24 10 0f 82 8e 00 00 00 48 8b 3b e8 5e 70 ff ff 85 c0 0f root@debian:~# coredumpctl list TIMEPID UID GID SIG COREFILE EXE Sun 2020-01-12 19:13:04 CET3016 1000 1000 11 present /usr/bin/gnome-logs root@debian:~# coredumpctl gdb 3016 PID: 3016 (gnome-logs) UID: 1000 (benutzer) GID: 1000 (benutzer) Signal: 11 (SEGV) Timestamp: Sun 2020-01-12 19:13:04 CET (1min 13s ago) Command Line: gnome-logs Executable: /usr/bin/gnome-logs Control Group: /user.slice/user-1000.slice/session-5.scope Unit: session-5.scope Slice: user-1000.slice Session: 5 Owner UID: 1000 (benutzer) Boot ID: 31e1a4dac60f43c3b142249a971244a8 Machine ID: 33f18f39d2a9438eb75b0ed52848afcd Hostname: debian Storage: /var/lib/systemd/coredump/core.gnome-logs.1000.31e1a4dac60f43c3b142249a971244a8.3016.157885278400.lz4 Message: Process 3016 (gnome-logs) of user 1000 dumped core. Stack trace of thread 3016: #0 0x55a9d5e79b4f n/a (gnome-logs) #1 0x55a9d5e7d721 n/a (gnome-logs) #2 0x7f2ddab5fc8d g_closure_invoke (libgobject-2.0.so.0) #3 0x7f2ddab73365 n/a (libgobject-2.0.so.0) #4 0x7f2ddab7c2be g_signal_emit_valist (libgobject-2.0.so.0) #5 0x7f2ddab7c97f g_signal_emit (libgobject-2.0.so.0) #6 0x7f2ddab64364 n/a (libgobject-2.0.so.0) #7 0x7f2ddab66921 g_object_notify_by_pspec (libgobject-2.0.so.0) #8 0x55a9d5e72691 n/a (gnome-logs) #9 0x7f2ddab5fc8d g_closure_invoke (libgobject-2.0.so.0) #10 0x7f2ddab73365 n/a (libgobject-2.0.so.0) #11 0x7f2ddab7c2be g_signal_emit_valist (libgobject-2.0.so.0) #12 0x7f2ddab7c97f g_signal_emit (libgobject-2.0.so.0) #13 0x7f2dda56f735 n/a (libgtk-3.so.0) #14 0x7f2dda573192 n/a (libgtk-3.so.0) #15 0x7f2dda573280 n/a (libgtk-3.so.0) #16 0x7f2dd9aa38ee ffi_call_unix64 (libffi.so.6) #17 0x7f2dd9aa32bf ffi_call (libffi.so.6) #18 0x7f2ddab60906 g_cclosure_marshal_generic_va (libgobject-2.0.so.0) #19 0x7f2ddab5fec6 n/a (libgobject-2.0.so.0) #20 0x7f2ddab7c38d g_signal_emit_valist (libgobject-2.0.so.0) #21 0x7f2ddab7c97f g_signal_emit (libgobject-2.0.so.0)
Bug#941930: smbclient: protocol negotiation failed: NT_STATUS_INVALID_PARAMETER_MIX with maxprotocol=NT1
Hello luca, this bug might be related: https://bugs.debian.org/948671 Kind regards, Bernhard
Bug#948671: libsmbclient: mounting a share from Windows XP fails on timeout
Hello Горбешко Богдан, I am not involved in packaging samba but tried to get some more details. Currently smblcient fails with that message: $ smbclient --user=testuser --ip-address=127.0.0.1 //testhost/C testtest Unable to initialize messaging context protocol negotiation failed: NT_STATUS_IO_TIMEOUT This seems to be due to smbclient sending out a SMB2 tcp message, which is not responded to by Windows XP. Therefore you could specify max-protocol at the command line which fails that way (seems to come from the windows side): $ smbclient --user=testuser --ip-address=127.0.0.1 --max-protocol=NT1 //testhost/C testtest Unable to initialize messaging context protocol negotiation failed: NT_STATUS_INVALID_PARAMETER_MIX This behaviour started at upstream following commit and is contained in samba-4.11.0rc1 and later. https://git.samba.org/?p=samba.git;a=commitdiff;h=3264b1f317d6c603cc72eb2a150fe244c47aa3ac Therefore smbclient could be convinced to connect by: $ smbclient --user=testuser --ip-address=127.0.0.1 --option='client min protocol = CORE' //testhost/C testtest Or setting 'client min protocol = CORE' globally in /etc/samba/smb.conf. Bug https://bugs.debian.org/941930 seems to be about the same issue. Kind regards, Bernhard
Bug#948626: kicad: Closing pcbnew hangs main kicad process
Hello Paul, I am not involved in packaging kicad or wxwidgets, just trying to collect some more information. Could you recheck - could it be that this pid 309563 was still running from a previous kicad session and your hanging kicad was another, newer process? Because, I guess, the __run_exit_handlers should just run at process exit. The last line in your backtrace point to this line, with a loop which would fit into the picture: https://sources.debian.org/src/wxwidgets3.0/3.0.4+dfsg-15/src/common/object.cpp/#L177 When you are in gdb and try to leave the current function by "finish", do you get again to the debugger prompt, or is it causing already the 100% CPU usage again? Kind regards, Bernhard
Bug#948584: libc6: Mounting nfsv4-export from my NAS there is a segfault in libc
Dear Maintainer, I could reproduce the crash now in an minimal unstable VM with the given config and the command line from the coredumpctl output. It seems that the function conf_parse_line is not prepared for missing quotation marks for the argument in the section head [1]. Therefore, if quotes are ommitted, the variable arg gets not filled, and therefore the cb->arg contains then a null pointer [2], that leads given to strcasecmp to the crash. @Miriam: I guess the crash should go away if change the config like following? - [ Server mirunas.mirulan.net ] - [ MountPoint /media/MiruNAS/Medienwerkstatt ] + [ Server "mirunas.mirulan.net" ] + [ MountPoint "/media/MiruNAS/Medienwerkstatt" ] Kind regards, Bernhard [1] https://sources.debian.org/src/nfs-utils/1:1.3.4-2.5/support/nfs/conffile.c/#L274 [2] https://sources.debian.org/src/nfs-utils/1:1.3.4-2.5/support/nfs/conffile.c/#L582
Bug#948584: libc6: Mounting nfsv4-export from my NAS there is a segfault in libc
Hello Miriam, thanks for the backtraces, just the one from "coredumctl gdb" is enough. Have you by any chance a file "/etc/nfsmount.conf" at this system? If there are no secrets inside, could you attach that too? Kind regards, Bernhard
Bug#948598: mingw-w64-i686-dev: non-conforming snprintf function in case of truncation
Hello Vincent, I tried to find some more details about this issue. In the regular case the resulting exe seems to link to msvcrt.dll!_vsnprintf: $ i686-w64-mingw32-objdump --private-headers test.c.exe DLL Name: msvcrt.dll vma: Hint/Ord Member-Name Bound-To 63e8 766 _vsnprintf Under wine we then get to that location: #0 0x7eb514d6 in MSVCRT_vsnprintf (str=0x65fe64 "", len=3, format=0x40400b "abcdef", valist=0x65fe5c "+\026@") at /home/benutzer/wine/wine-git/wine-git/dlls/msvcrt/wcs.c:686 The resulting executables are showing the same output in wine and windows. In the posix case it seems the snprintf implementation is not taken from any dll, instead it is contained inside the executable, therefore supplied by the compiler? Microsoft states [1], that they switched in VS2015 snprintf to be C99 compliant, wouldn't therefore snprintf in msvcrt.dll not compliant? Is this issue in the end that mingw should link to newer c-library by default? Kind regards, Bernhard [1] https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=vs-2019
Bug#948584: libc6: Mounting nfsv4-export from my NAS there is a segfault in libc
Hello Miriam, if possible, you could install the additional package systemd-coredump. Then in the output of 'journalctl --no-pager' at the bottom should the known 'segfault at' line appear. This and the following lines at that time would be of interest. This would get better if the additional nfs-common-dbgsym could be installed [1] (from a separate repo). If additonal to the above steps the package gdb is installed, 'coredumpctl gdb' with the command 'bt full' at the gdb prompt would yield even better information. Kind regards, Bernhard [1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols
Bug#948588: libmtp9: segfault in libmtp.so.9.4.0
Dear Maintainer,
the given code from dmesg points to this function:
LIBMTP_GetPartialObject at libmtp.c:9070
The related code [1] looks like function LIBMTP_Get_Filemetadata
returns a null pointer which get dereferenced unconditionally
in line 9070.
This part of the function seems unchanged upstream [2].
Kind regards,
Bernhard
[1] https://sources.debian.org/src/libmtp/1.1.16-2/src/libmtp.c/#L9070
9067 LIBMTP_file_t *mtpfile = LIBMTP_Get_Filemetadata(device, id);
9068
9069 /* Some devices do not like reading over the end and hang instead
of progressing */
9070 if (offset >= mtpfile->filesize) {
[2] https://sourceforge.net/p/libmtp/code/ci/master/tree/src/libmtp.c#l9084
From Submitter:
[ 6707.977374] pool[8766]: segfault at 18 ip 7f6b6a6262ee sp
7f6b49ffaac0 error 4 in libmtp.so.9.4.0[7f6b6a618000+2a000]
[ 6707.977385] Code: d7 41 56 41 89 f6 41 55 4d 89 c5 41 54 4d 89 cc 55 48 89
fd 53 48 83 ec 18 48 8b 5f 08 89 4c 24 0c e8 96 23 ff ff 8b 4c 24 0c <48> 8b 50
18 4c 39 fa 0f 86 15 01 00 00 89 c8 89 d6 4c 01 f8 44 29
0 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8
9 20 1 2 3 4 5 6 7 8 9 30 1 2 3 4 5 6 7 8 9 40 1 42
###
# Unstable amd64 qemu VM 2020-01-10
apt update
apt dist-upgrade
apt install systemd-coredump xserver-xorg sddm openbox xterm gdb rhythmbox
libmtp9-dbgsym
export DISPLAY=:0
gdb -q --args rhythmbox
set width 0
set pagination off
run
Ctrl-C
(gdb) info share
FromTo Syms Read Shared Object Library
...
0x7fffe10c9870 0x7fffe10f2e20 Yes
/lib/x86_64-linux-gnu/libmtp.so.9
...
(gdb) find /b 0x7fffe10c9870, 0x7fffe10f2e20, 0xd7, 0x41, 0x56, 0x41,
0x89, 0xf6, 0x41, 0x55, 0x4d, 0x89, 0xc5, 0x41, 0x54, 0x4d, 0x89, 0xcc, 0x55,
0x48, 0x89, 0xfd, 0x53, 0x48, 0x83, 0xec, 0x18, 0x48, 0x8b, 0x5f, 0x08, 0x89,
0x4c, 0x24, 0x0c, 0xe8, 0x96, 0x23, 0xff, 0xff, 0x8b, 0x4c, 0x24, 0x0c, 0x48,
0x8b, 0x50, 0x18, 0x4c, 0x39, 0xfa, 0x0f, 0x86, 0x15, 0x01, 0x00, 0x00, 0x89,
0xc8, 0x89, 0xd6, 0x4c, 0x01, 0xf8, 0x44, 0x29
0x7fffe10d72c4
1 pattern found.
(gdb) b *(0x7fffe10d72c4 + 42)
Breakpoint 2 at 0x7fffe10d72ee: file libmtp.c, line 9070.
(gdb) info b
Num Type Disp Enb AddressWhat
2 breakpoint keep y 0x7fffe10d72ee in LIBMTP_GetPartialObject
at libmtp.c:9070
(gdb) disassemble LIBMTP_GetPartialObject
Dump of assembler code for function LIBMTP_GetPartialObject:
0x7fffe10d72c0 <+0>: push %r15
0x7fffe10d72c2 <+2>: mov%rdx,%r15
0x7fffe10d72c5 <+5>: push %r14
0x7fffe10d72c7 <+7>: mov%esi,%r14d
0x7fffe10d72ca <+10>:push %r13
0x7fffe10d72cc <+12>:mov%r8,%r13
0x7fffe10d72cf <+15>:push %r12
0x7fffe10d72d1 <+17>:mov%r9,%r12
0x7fffe10d72d4 <+20>:push %rbp
0x7fffe10d72d5 <+21>:mov%rdi,%rbp
0x7fffe10d72d8 <+24>:push %rbx
0x7fffe10d72d9 <+25>:sub$0x18,%rsp
0x7fffe10d72dd <+29>:mov0x8(%rdi),%rbx
0x7fffe10d72e1 <+33>:mov%ecx,0xc(%rsp)
0x7fffe10d72e5 <+37>:callq 0x7fffe10c9680
0x7fffe10d72ea <+42>:mov0xc(%rsp),%ecx
0x7fffe10d72ee <+46>:mov0x18(%rax),%rdx
<<<<<<<
0x7fffe10d72f2 <+50>:cmp%r15,%rdx
...
0x7fffe10d744a <+394>: jmp0x7fffe10d73d9
End of assembler dump.
Debian: https://sources.debian.org/src/libmtp/1.1.16-2/src/libmtp.c/#L9070
9067 LIBMTP_file_t *mtpfile = LIBMTP_Get_Filemetadata(device, id);
9068
9069 /* Some devices do not like reading over the end and hang instead of
progressing */
9070 if (offset >= mtpfile->filesize) {
Upstream:
https://sourceforge.net/p/libmtp/code/ci/master/tree/src/libmtp.c#l9084
Bug#948442: gdm3: Unable to enable Orca
Hello Boris, I am not involved in packaging gdm or orca but tried to get more information. I added also the a11y tag in the hope to get the attention of the right people. I tested inside a minimal VM with the gnome package installed. In the gdm3 login screen I also got no reaction from the Ctrl-Alt-s shortcut, neither in Wayland or Xorg mode. Your second command did not work for me, I adjusted it and prepended a shell before the eval: $ sudo -u Debian-gdm bash -c 'eval $(dbus-launch) ; export DBUS_SESSION_BUS_ADDRESS DBUS_SESSION_BUS_PID ; GSETTINGS_BACKEND=dconf gsettings set org.gnome.desktop.a11y.applications screen-reader-enabled true' This seems to modify the setting but does not immediately activate orca - just after a reboot speech output worked. I guess this happens because of using another dbus process. When using the already running dbus it seemed to work immediately: $ sudo -u Debian-gdm bash -c 'export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$(id -u "Debian-gdm")/bus; GSETTINGS_BACKEND=dconf gsettings set org.gnome.desktop.a11y.applications screen-reader-enabled true' The Debian Wiki has also a shell before the eval command. And uses instead of sudo the su command, which from a regular user requires the not existing password for Debian-gdm. The Wiki does also not mention the requirement of a reboot. https://wiki.debian.org/accessibility#gdm_accessibility I guess if this "activation" command could be hidden in a short-named helper script would be helpful. Kind regards, Bernhard
Bug#948491: centengine crashes regulary
Dear Maintainer,
I guess I found the issue here.
It looks like centengine is crashing with an unmodified
default configuration after 60 minutes running.
By changing "retention_update_interval" from 60 to 1 this could
be lowered to 1 minute.
Further it looks like having null pointers in "custom_variables"
member is not unusual.
But because 'dump::customvariables' receives the 'obj' by reference,
the compiler removes in an optimized build the null check,
I guess because it assumes that a reference has to be valid by definition.
Attached patch changes the argument by reference to a pointer.
A package build with that patch checks like expected for null and
leaves the function.
Upstream seems to have changed obj.custom_variables to a container type,
which might therefore not suffer from this problem anymore.
Kind regards,
Bernhard
(gdb) print obj.custom_variables
$3 = (customvariablesmember_struct *) 0x0
https://sources.debian.org/src/centreon-engine/18.10.0-4/src/retention/dump.cc/#L127
(gdb) list 121,133
121 std::ostream& dump::customvariables(
122 std::ostream& os,
123 customvariablesmember_struct const& obj) {
124 for (customvariablesmember const* member();
125member;
126member = member->next)
127 if (member->variable_name)
128 os << "_" << member->variable_name << "="
129 << member->has_been_modified << ","
130 << (member->variable_value ? member->variable_value : "")
131 << "\n";
132 return (os);
133 }
https://sources.debian.org/src/centreon-engine/18.10.0-4/src/retention/dump.cc/#L454
(gdb) list 389,455
389 std::ostream& dump::service(std::ostream& os, service_struct const&
obj) {
...
454 dump::customvariables(os, *obj.custom_variables);
455 os << "}\n";
(gdb) bt
#0 com::centreon::engine::retention::dump::customvariables (os=..., obj=...)
at ./src/retention/dump.cc:127
#1 0x559743899013 in com::centreon::engine::retention::dump::host (os=...,
obj=...) at ./src/retention/dump.cc:264
#2 0x55974389a62b in com::centreon::engine::retention::dump::hosts
(os=...) at ./src/retention/dump.cc:278
#3 com::centreon::engine::retention::dump::save (path=...) at
./src/retention/dump.cc:359
#4 0x55974386126b in _exec_event_retention_save (event=) at
./src/events/timed_event.cc:176
#5 0x559743860b5d in handle_timed_event (event=event@entry=0x559744b5ea90)
at ./src/events/timed_event.cc:752
#6 0x55974385becb in com::centreon::engine::events::loop::_dispatching
(this=0x559744b396a0) at ./src/events/loop.cc:233
#7 0x55974385c9e9 in com::centreon::engine::events::loop::run
(this=0x559744b396a0) at ./src/events/loop.cc:90
#8 0x559743784774 in main (argc=, argv=) at
./src/main.cc:410
Unmodified Debian: || With
patch applied:
...7c0 <+0>: push %r14 || ...530
<+0>: push %r14
...7c2 <+2>: lea0x290a5(%rip),%r14# 0x5597438c086e ||
...7c9 <+9>: push %r13 || ...532
<+2>: push %r13
...7cb <+11>:push %r12 || ...534
<+4>: push %r12
...7cd <+13>:push %rbp || ...536
<+6>: push %rbp
...7ce <+14>:mov%rdi,%rbp || ...537
<+7>: mov%rdi,%rbp
...7d1 <+17>:push %rbx || ...53a
<+10>:push %rbx
|| ...53b
<+11>:test %rsi,%rsi <<< null check
|| ...53e
<+14>:je 0x560648b46630 <...customvariables...+256><<< jump
...7d2 <+18>:mov%rsi,%rbx || ...544
<+20>:mov%rsi,%rbx
...7d5 <+21>:jmpq 0x559743897868 <...customvariables...+168> ||
...
... ||
...
...868 <+168>: cmpq $0x0,(%rbx) <<< crash||
...
... || ...630
<+256>: pop%rbx
|| ...631
<+257>: mov%rbp,%rax
