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 3 or later
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/lib/dssi/libzynaddsubfx_dssi.so #3 0x7fffe955b29c in ?? () from
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] MTRR variable
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)
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/splinefont.c:1141 #7 0x76c0a3ac in ReadSplineFont
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#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 (swrast_dri.so + 0x18203b)
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 in meta_lookup_cache_lookup_path (cache=cache@entry=0x56301f65b850, filename=filename@entry=0x7f3bd01919f0
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
root@debian:~# dpkg -i
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#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) #22
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
|| ...634
<+260>: pop%rbp
|| ...635
<+261>: pop%r12
|| ...637
<+263>: pop%r13
...639
<+265>: pop%r14
...63b
<+267>: retq
Description: Change argument by reference to pointer to avoid crash
GCC seems to expect always valid references, therefore removes
in optimized builds null checks of references.
Author: Bernhard Übelacker
Bug-Debian: https://bugs.debian.org/948491
Bug: https://github.com/centreon/centreon-engine/issues/338
Forwarded: no
Last-Update: 2020-01-10
--- centreon-engine-18.10.0.orig/inc/com/centreon/engine/retention/dump.hh
+++ centreon-engine-18.10.0/inc/com/centreon/engine/retention/dump.hh
@@ -39,7 +39,7 @@ namespace retention {
std::ostream& comments(std::ostream& os);
std::ostream& contact(std::ostream& os, contact_struct const& obj);
std::ostream& contacts(std::ostream& os);
-std::ostream& customvariables(std::ostream& os, customvariablesmember_struct const& obj);
+std::ostream& customvariables(std::ostream& os, customvariablesmember_struct const* obj);
std::ostream& downtime(std::ostream& os, scheduled_downtime_struct const& obj);
std::ostream& downtimes(std::ostream& os);
std::ostream& header(std::ostream& os);
--- centreon-engine-18.10.0.orig/src/retention/dump.cc
+++ centreon-engine-18.10.0/src/retention/dump.cc
@@ -92,7 +92,7 @@ std::ostream& dump::contact(std::ostream
"modified_service_attributes=" << (obj.modified_service_attributes & ~config->retained_contact_service_attribute_mask()) << "\n"
"service_notification_period=" << (obj.service_notification_period ? obj.service_notification_period : "") << "\n"
"service_notifications_enabled=" << obj.service_notifications_enabled << "\n";
- dump::customvariables(os, *obj.custom_variables);
+ dump::customvariables(os, obj.custom_variables);
os << "}\n";
return (os);
}
@@ -120,8 +120,8 @@ std::ostream& dump::contacts(std::ostrea
*/
std::ostream& dump::customvariables(
std::ostream& os,
-customvariablesmember_struct const& obj) {
- for (customvariablesmember const* member();
+customvariablesmember_struct const* obj) {
+ for (customvariablesmember const* member = obj;
member;
member = member->next)
if (member->variable_name)
@@ -261,7 +261,7 @@ std::ostream& dump::host(std::ostream& o
os << (x > 0 ? "," : "") << obj.state_history[(x + obj.state_history_index) % MAX_STATE_HISTORY_ENTRIES];
os << "\n";
- dump::customvariables(os, *obj.custom_variables);
+ dump::customvariables(os, obj.custom_variables);
os << "}\n";
return (os);
}
@@ -451,7 +451,7 @@ std::ostream& dump::service(std::ostream
os << (x > 0 ? "," : "") << obj.state_history[(x + obj.state_history_index) % MAX_STATE_HISTORY_ENTRIES];
os << "\n";
- dump::customvariables(os, *obj.custom_variables);
+ dump::customvariables(os, obj.custom_variables);
os << "}\n";
return (os);
}
Bug#948491: centengine crashes regulary
Hello Pascal, now I see one thing that would be even better: coredumpctl gdb info reg thread apply all bt full Sorry for not saying this sooner. Kind regards, Bernhard
Bug#948491: centengine crashes regulary
Am 09.01.20 um 22:18 schrieb Pascal Vibet - ADACIS: > @Bernhard : I install 'systemd-coredump' and 'centreon-engine-dbgsym' > packages. I restart centengine. What information do you need? When > centengine process crashes ? Or i run a program in same time ? What do > you want me to do? Great. Just wait for the next crash and then look at the end of the command "journalctl --no-pager". There should be a line with the known 'segfault at'. This line and the following at nearly the same time would be interesting, if you could forward them to this bug? Kind regards, Bernhard
Bug#948287: bash: *** stack smashing detected *** ( SIGABRT crash )
Am 09.01.20 um 17:56 schrieb crvi c: > I am using the same bash / gnome-terminal as part of my daily work. The > crash was random and it is not consistently reproducible. I have a > couple of bash core files, if that would be of any help. Ok, I see - had hoped it to be better reproducible. In my tests I found that the function in question get executed if I do for example "ls /" and tab. Could be the crashing cases are related to absolute paths? Otherwise you could try to run it by valgrind e.g. like following: valgrind --tool=memcheck--trace-children=no --child-silent-after-fork=yes bash valgrind --tool=exp-sgcheck --trace-children=no --child-silent-after-fork=yes bash Another approach could be, if CPU support is given, to use a timetravel debugger like rr to record bash executions and replay a crashing one to find out where the stack canary got overwritten. Unfortunately a core did alreay run over the interesting instruction changing that stack canary, will therefore not of so much use. Maybe just if the stack would be overwritten with some recognizable values ... Kind regards, Bernhard
Bug#920772: kdeinit5 crashing at MTP transfer to android device.
Dear Maintainer, I got today the same crash as the submitter. It happened short after disconnecting one android device, connecting another and opening/retrying the MTP connection. This upstream bug looks related: https://bugs.kde.org/show_bug.cgi?id=415693 (Seems to be also from buster due to address offsets.) This line seems to call member getDevice even when there is no object: 102 LIBMTP_mtpdevice_t *device = deviceCache->get(pathItems.at(0))->getDevice(); https://sources.debian.org/src/kio-extras/4:18.08.3-1/mtp/kio_mtp.cpp/#L102 This line got removed upstream in this commit: https://cgit.kde.org/kio-extras.git/commit/mtp/kio_mtp.cpp?id=aaa1edbb74c4fb01affbde7b79bb45d3a9b61f83 Which points to this task and among others this bug: https://phabricator.kde.org/T9390 https://bugs.kde.org/show_bug.cgi?id=396527 Because the offending line and function removed, current testing 4:19.08.1-1 might be have this bug fixed. One upstream mentions that Nautilus was working find, this might be a workaround, as I guess MTP with KDE will stay kind of fragile in Buster. Kind regards, Bernhard Without debug symbols: [KCrash Handler] #6 0x7f9b372b417a in ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/mtp.so #7 0x7f9b372b9457 in ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/mtp.so #8 0x7f9b372bd65b in ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/mtp.so #9 0x7f9b3272f39f in KIO::SlaveBase::dispatch(int, QByteArray const&) () from /usr/lib/x86_64-linux-gnu/libKF5KIOCore.so.5 #10 0x7f9b3272f876 in KIO::SlaveBase::dispatchLoop() () from /usr/lib/x86_64-linux-gnu/libKF5KIOCore.so.5 #11 0x7f9b372be7fd in kdemain () from /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/mtp.so #12 0x556b97c3fe1c in ?? () #13 0x556b97c40eea in ?? () #14 0x556b97c418fb in ?? () #15 0x556b97c3c645 in ?? () #16 0x7f9b3646b09b in __libc_start_main (main=0x556b97c3bc70, argc=5, argv=0x7ffc69537f98, init=, fini=, rtld_fini=, stack_end=0x7ffc69537f88) at ../csu/libc-start.c:308 #17 0x556b97c3d2ca in ?? () [Inferior 1 (process 2264) detached] With debug symbols: Thread 1 (Thread 0x7f9b32b26780 (LWP 2264)): [KCrash Handler] #6 CachedDevice::getDevice (this=0x0) at ./mtp/devicecache.cpp:64 #7 0x7f9b372b9457 in MTPSlave::getPath (this=0x7ffc695377b0, path=...) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qlist.h:115 #8 0x7f9b372bd65b in MTPSlave::fileSystemFreeSpace (this=0x7ffc695377b0, url=...) at ./mtp/kio_mtp.cpp:946 #9 0x7f9b3272f39f in KIO::SlaveBase::dispatch(int, QByteArray const&) () from /usr/lib/x86_64-linux-gnu/libKF5KIOCore.so.5 #10 0x7f9b3272f876 in KIO::SlaveBase::dispatchLoop() () from /usr/lib/x86_64-linux-gnu/libKF5KIOCore.so.5 #11 0x7f9b372be7fd in kdemain (argc=, argv=) at ./mtp/kio_mtp.cpp:56 #12 0x556b97c3fe1c in launch (argc=4, _name=0x556b993ab398 "/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/mtp.so", args=, cwd=, envc=0, envs=, reset_env=false, tty=0x0, avoid_loops=false, startup_id_str=0x556b97c43187 "0") at ./src/kdeinit/kinit.cpp:706 #13 0x556b97c40eea in handle_launcher_request (sock=8, who=) at ./src/kdeinit/kinit.cpp:1146 #14 0x556b97c418fb in handle_requests (waitForPid=0) at ./src/kdeinit/kinit.cpp:1339 #15 0x556b97c3c645 in main (argc=5, argv=) at ./src/kdeinit/kinit.cpp:1785 [Inferior 1 (process 2264) detached] -- 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_WARN, 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 kio-extras depends on: ii kio5.54.1-1 ii kio-extras-data4:18.08.3-1 ii libc6 2.28-10 ii libgcc11:8.3.0-6 ii libkf5activities5 5.54.0-1 ii libkf5archive5 5.54.0-1 ii libkf5bookmarks5 5.54.0-1 ii libkf5codecs5 5.54.0-1 ii libkf5configcore5 5.54.0-1+deb10u1 ii libkf5configgui5 5.54.0-1+deb10u1 ii libkf5configwidgets5 5.54.0-1 ii libkf5coreaddons5 5.54.0-1 ii libkf5dbusaddons5 5.54.0-1 ii libkf5dnssd5 5.54.0-1 ii libkf5guiaddons5 5.54.0-1 ii libkf5i18n55.54.0-1 ii libkf5iconthemes5 5.54.0-1 ii libkf5khtml5 5.54.0-1 ii libkf5kiocore5 5.54.1-1 ii libkf5kiofilewidgets5 5.54.1-1 ii libkf5kiowidgets5 5.54.1-1 ii libkf5parts5 5.54.0-1 ii libkf5pty5 5.54.0-1 ii libkf5service-bin 5.54.0-1 ii libkf5service5 5.54.0-1 ii libkf5solid5 5.54.0-1 ii
Bug#948287: bash: *** stack smashing detected *** ( SIGABRT crash )
Am 09.01.20 um 17:05 schrieb crvi c: > gdb -q -batch -command ~/gdb-cmds.bash.txt --args bash > Function "__pthread_tunables_init" not defined. > Breakpoint 1 (__pthread_tunables_init) pending. > [Detaching after fork from child process 37973] Sorry, wasn't clear about that. The prompt then shown should belong to the bash being debugged, have tried to trigger the crash in that prompt again? Kind regards, Bernhard
Bug#948491: centengine crashes regulary
Dear Maintainer, I just tried to get some more info from the dmesg line, which seems to point to: file ./src/retention/dump.cc, line 127. [1] @Pascal: More information could maybe retrieved from the journal if 'systemd-coredump' could be installed, even better if additionally package 'centreon-engine-dbgsym' would be installed [1]. Kind regards, Bernhard [1] https://sources.debian.org/src/centreon-engine/18.10.0-4/src/retention/dump.cc/#L127 [2] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols dmesg submitter: [ 5321.507438] centengine[26832]: segfault at 0 ip 55c4d2403868 sp 7ffd605fa390 error 4 in centengine[55c4d22e+134000] [ 5321.507456] Code: 89 c2 4c 89 ee 4c 89 e7 e8 35 d0 ed ff ba 01 00 00 00 48 8d 35 03 94 01 00 4c 89 e7 e8 21 d0 ed ff 48 8b 5b 18 48 85 db 74 58 <48> 83 3b 00 74 f1 ba 01 00 00 00 48 8d 35 07 9a 01 00 48 89 ef e8 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 # Buster/stable amd64 qemu VM 2020-01-09 apt update apt dist-upgrade apt install systemd-coredump gdb centreon-engine centreon-engine-dbgsym gdb -q --args /usr/sbin/centengine set width 0 set pagination off b main run dele 1 (gdb) info target ... Local exec file: `/usr/sbin/centengine', file type elf64-x86-64. ... 0x555ef050 - 0x55721701 is .text ... (gdb) find /b 0x555ef050, 0x55721701, 0x89, 0xc2, 0x4c, 0x89, 0xee, 0x4c, 0x89, 0xe7, 0xe8, 0x35, 0xd0, 0xed, 0xff, 0xba, 0x01, 0x00, 0x00, 0x00, 0x48, 0x8d, 0x35, 0x03, 0x94, 0x01, 0x00, 0x4c, 0x89, 0xe7, 0xe8, 0x21, 0xd0, 0xed, 0xff, 0x48, 0x8b, 0x5b, 0x18, 0x48, 0x85, 0xdb, 0x74, 0x58, 0x48, 0x83, 0x3b, 0x00, 0x74, 0xf1, 0xba, 0x01, 0x00, 0x00, 0x00, 0x48, 0x8d, 0x35, 0x07, 0x9a, 0x01, 0x00, 0x48, 0x89, 0xef, 0xe8 0x5571183e 1 pattern found. (gdb) b *(0x5571183e + 42) Breakpoint 3 at 0x55711868: file ./src/retention/dump.cc, line 127. (gdb) info b Num Type Disp Enb AddressWhat 3 breakpoint keep y 0x55711868 in com::centreon::engine::retention::dump::customvariables(std::ostream&, customvariablesmember_struct const&) at ./src/retention/dump.cc:127 89 c2 4c 89 ee 4c 89 e7 e8 35 d0 ed ff ba 01 00 00 00 48 8d 35 03 94 01 00 4c 89 e7 e8 21 d0 ed ff 48 8b 5b 18 48 85 db 74 58 <48> 83 3b 00 74 f1 ba 01 00 00 00 48 8d 35 07 9a 01 00 48 89 ef e8 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 2 0x89, 0xc2, 0x4c, 0x89, 0xee, 0x4c, 0x89, 0xe7, 0xe8, 0x35, 0xd0, 0xed, 0xff, 0xba, 0x01, 0x00, 0x00, 0x00, 0x48, 0x8d, 0x35, 0x03, 0x94, 0x01, 0x00, 0x4c, 0x89, 0xe7, 0xe8, 0x21, 0xd0, 0xed, 0xff, 0x48, 0x8b, 0x5b, 0x18, 0x48, 0x85, 0xdb, 0x74, 0x58, 0x48, 0x83, 0x3b, 0x00, 0x74, 0xf1, 0xba, 0x01, 0x00, 0x00, 0x00, 0x48, 0x8d, 0x35, 0x07, 0x9a, 0x01, 0x00, 0x48, 0x89, 0xef, 0xe8 (gdb) disassemble /r 0x5571183e,0x5571183e+62 Dump of assembler code from 0x5571183e to 0x5571187c: 0x5571183e :89 c2 mov %eax,%edx 0x55711840 :4c 89 eemov %r13,%rsi 0x55711843 :4c 89 e7mov %r12,%rdi 0x55711846 :e8 35 d0 ed ff callq 0x555ee880 <_ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l@plt> 0x5571184b :ba 01 00 00 00 mov $0x1,%edx 0x55711850 :48 8d 35 03 94 01 00lea 0x19403(%rip),%rsi# 0x5572ac5a 0x55711857 :4c 89 e7mov %r12,%rdi 0x5571185a :e8 21 d0 ed ff callq 0x555ee880 <_ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l@plt> 0x5571185f :48 8b 5b 18 mov 0x18(%rbx),%rbx 0x55711863 :48 85 dbtest %rbx,%rbx 0x55711866 :74 58 je 0x557118c0 >> 0x55711868 >> > customvariablesmember_struct const&)+168>:48 83 3b 00 >> cmpq $0x0,(%rbx) 0x5571186c :74 f1 je 0x5571185f 0x5571186e :ba 01 00 00 00 mov $0x1,%edx 0x55711873 :48 8d 35 07 9a 01 00lea 0x19a07(%rip),%rsi# 0x5572b281 0x5571187a :48 89 efmov %rbp,%rdi End of assembler dump. root@debian:~# dpkg -l | grep centreon ii centreon-engine 18.10.0-4 amd64 Network, system, applicative supervision and monitoring - engine ii centreon-engine-dbgsym18.10.0-4 amd64 debug symbols for centreon-engine ii libcentreon-clib
Bug#930563: Can not start freecad
Hello Gulfstream, hello Jean-Luc, this report got opened mentioning a "Thinkpad P1". Reading through some pages about that device, it looks like it contains some "hybrid graphics". Maybe you both could confirm that your devices have such "hybrid graphics", and if yes, maybe you could give some more information of both graphic devices and how the switching between them is configured? (I don't have such a device accessible.) Kind regards, Bernhard
Bug#948388: navit: fails to connect to gpsd
Sorry, forgot to attach details.
# Bullseye/testing amd64 qemu VM 2020-01-08
apt update
apt dist-upgrade
apt install systemd-coredump xserver-xorg sddm openbox xterm net-tools mc
fakeroot gdb navit navit-dbgsym libgps25-dbgsym
apt build-dep navit
reboot
mkdir /home/benutzer/source/libgps25/orig -p
cd/home/benutzer/source/libgps25/orig
apt source libgps25
cd
mkdir /home/benutzer/source/navit/orig -p
cd/home/benutzer/source/navit/orig
apt source navit
cd
systemctl start gpsd.service
export DISPLAY=:0
gdb -q --args navit
set width 0
set pagination off
set breakpoint pending on
directory /home/benutzer/source/libgps25/orig/gpsd-3.20
directory /home/benutzer/source/navit/orig/navit-0.5.3+dfsg.1/navit/vehicle/gpsd
b gps_open
run
print gpsdata
print sizeof(*gpsdata)
print sizeof(struct gps_data_t)
up
print priv->gps
print sizeof(*priv->gps)
print sizeof(struct gps_data_t)
down
set logging file /tmp/libgps25-ptype-struct-gps_data_t.txt
set logging on
ptype /o struct gps_data_t
set logging off
up
set logging file /tmp/navit-ptype-struct-gps_data_t.txt
set logging on
ptype /o struct gps_data_t
set logging off
benutzer@debian:~$ gdb -q --args navit
Reading symbols from navit...
Reading symbols from
/usr/lib/debug/.build-id/ad/4c802fbe455074f8a5eb217f3ade9bddb73bd5.debug...
(gdb) set width 0
(gdb) set pagination off
(gdb) set breakpoint pending on
(gdb) directory /home/benutzer/source/libgps25/orig/gpsd-3.20
Source directories searched:
/home/benutzer/source/libgps25/orig/gpsd-3.20:$cdir:$cwd
(gdb) directory
/home/benutzer/source/navit/orig/navit-0.5.3+dfsg.1/navit/vehicle/gpsd
Source directories searched:
/home/benutzer/source/navit/orig/navit-0.5.3+dfsg.1/navit/vehicle/gpsd:/home/benutzer/source/libgps25/orig/gpsd-3.20:$cdir:$cwd
(gdb) b gps_open
Function "gps_open" not defined.
Breakpoint 1 (gps_open) pending.
(gdb) run
Starting program: /usr/bin/navit
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, gps_open (host=host@entry=0x556bc137 "localhost", port=0x0,
gpsdata=0x556d4a50) at libgps_core.c:73
73 if (!gpsdata)
(gdb) print gpsdata
$1 = (struct gps_data_t *) 0x556d4a50
(gdb) print sizeof(*gpsdata)
$2 = 24008
(gdb) print sizeof(struct gps_data_t)
$3 = 24008
(gdb) up
#1 0x756555c3 in vehicle_gpsd_try_open
(priv=priv@entry=0x5568f510) at ./navit/vehicle/gpsd/vehicle_gpsd.c:225
warning: Source file is more recent than executable.
225 if (gps_open(source + 7, port, priv->gps)) {
(gdb) print priv->gps
$4 = (struct gps_data_t *) 0x556d4a50
(gdb) print sizeof(*priv->gps)
$5 = 20800
(gdb) print sizeof(struct gps_data_t)
$6 = 20800
(gdb)
benutzer@debian:~$ diff -ty /tmp/libgps25-ptype-struct-gps_data_t.txt
/tmp/navit-ptype-struct-gps_data_t.txt | head -n 20
/* offset| size */ type = struct gps_data_t {/* offset
| size */ type = struct gps_data_t {
/*0 | 8 */gps_mask_t set; /*0
| 8 */gps_mask_t set;
/*8 |16 */timespec_t online; | /*8
| 8 */timestamp_t online;
/* 24 | 4 */socket_t gps_fd; | /* 16
| 4 */socket_t gps_fd;
/* XXX 4-byte hole */ /* XXX
4-byte hole */
/* 32 | 360 */struct gps_fix_t { | /* 24
| 256 */struct gps_fix_t {
/* 32 |16 */timespec_t time; | /* 24
| 8 */timestamp_t time;
/* 48 | 4 */int mode;| /* 32
| 4 */int mode;
/* XXX 4-byte hole */ | /* XXX
4-byte hole */
/* 56 | 8 */double ept; | /* 40
| 8 */double ept;
/* 64 | 8 */double latitude; | /* 48
| 8 */double latitude;
/* 72 | 8 */double epy; | /* 56
| 8 */double epy;
/* 80 | 8 */double longitude;| /* 64
| 8 */double longitude;
/* 88 | 8 */double epx; | /* 72
| 8 */double epx;
/* 96 | 8 */double altitude; | /* 80
| 8 */double altitude;
/* 104 | 8 */double altHAE; | /* 88
| 8 */double epv;
/* 112 | 8 */double altMSL; | /* 96
| 8 */double track;
/* 120 | 8 */double epv; | /* 104
| 8 */double epd;
/* 128 | 8 */double track;| /* 112
| 8 */double speed;
/* 136 |
Bug#948388: navit: fails to connect to gpsd
Dear Maintainer,
I tried to gather some more information to this issue and
found below difference [1] [2] in sizes of struct gps_data_t,
by inspecting a running process in different stack frames.
Also I found that the current navit 0.5.3+dfsg.1-2+b1 was
built against libgps-dev 3.19-2 [6].
The current libgps-dev 3.20-1 seems to have added members
to struct gps_data_t [4] [7].
Additionally the timespec_t members differ in size.
Unfortunately I was not able to rebuild navit in a
minimal bullseye VM because of this error [5].
Therefore I guess ABI got broken
between libgps25 3.19-3 and 3.20-1?
When repeating the test with libgps25 3.19-3 [8] installed,
the struct sizes match and no differenences in
gdb's ptype output exist.
Kind regards,
Bernhard
[1]
Breakpoint 1, gps_open (host=host@entry=0x556bc137 "localhost", port=0x0,
gpsdata=0x556d4a50) at libgps_core.c:73
73 if (!gpsdata)
(gdb) print sizeof(struct gps_data_t)
$3 = 24008
[2]
#1 0x756555c3 in vehicle_gpsd_try_open
(priv=priv@entry=0x5568f510) at ./navit/vehicle/gpsd/vehicle_gpsd.c:225
225 if (gps_open(source + 7, port, priv->gps)) {
(gdb) print sizeof(struct gps_data_t)
$6 = 20800
$ diff -ty /tmp/libgps25-ptype-struct-gps_data_t.txt
/tmp/navit-ptype-struct-gps_data_t.txt | head -n 20
/* offset| size */ type = struct gps_data_t {/* offset
| size */ type = struct gps_data_t {
/*0 | 8 */gps_mask_t set; /*0
| 8 */gps_mask_t set;
/*8 |16 */timespec_t online; | /*8
| 8 */timestamp_t online; <<< [3] different size
/* 24 | 4 */socket_t gps_fd; | /* 16
| 4 */socket_t gps_fd;
/* XXX 4-byte hole */ /* XXX
4-byte hole */
...
/* 96 | 8 */double altitude; | /* 80
| 8 */double altitude;
/* 104 | 8 */double altHAE; | /* 88
| 8 */double epv; <<< [4] new member
...
[5]
<>/navit/vehicle/gpsd/vehicle_gpsd.c: In function
‘vehicle_gpsd_callback’:
<>/navit/vehicle/gpsd/vehicle_gpsd.c:177:26: error: incompatible
types when assigning to type ‘time_t’ {aka ‘long int’} from type ‘timespec_t’
{aka ‘struct timespec’}
177 | priv->fix_time = data->fix.time;
| ^~~~
[6]
https://buildd.debian.org/status/fetch.php?pkg=navit=amd64=0.5.3%2Bdfsg.1-2%2Bb1=1571055435=0
[7]
https://sources.debian.org/src/gpsd/3.19-2%7Ebpo10+1/gps.h/#L97
https://sources.debian.org/src/gpsd/3.20-1/gps.h/#L123
[8]
https://snapshot.debian.org/package/gpsd/3.19-3/
Bug#948380: GIMP crash with floating point exception on image save.
Dear Maintainer, when comparing with a process while having debug symbols installed, I guess the given backtrace would translate to something like below. Therefore I guess this crash is the same as described in #929113. Unfortunately I could not find a matching appearance of function gimp_projection_chunk_render_iteration. Additionally upstream has highly modified this file already. Therefore, if this is reproducable, running with installed debug symbol packages "gimp-dbgsym libglib2.0-0-dbgsym libgimp2.0-dbgsym" [1] and an attached gdb, issuing at the crash the commands 'info reg' and 'thread apply all bt full' could give some more insight. Kind regards, Bernhard Submitter: | Reconstructed: [0x7f05c7726e27] libgimpbase-2.0.so.0(gimp_stack_trace_print+0x397) | 0x7fc6d8ca8e27 in gimp_stack_trace_print () from /lib/libgimpbase-2.0.so.0 [0x56063cab94a0] gimp-2.10(+0xd14a0)| 0x55b3604154a0 in gimp_eek () at errors.c:377 [0x56063cab98d8] gimp-2.10(+0xd18d8)| 0x55b3604158d8 in gimp_fatal_error () at errors.c:234 [0x56063caba037] gimp-2.10(+0xd2037)| 0x55b360416037 in gimp_sigfatal_handler (sig_num=8) at signals.c:165 [0x7f05c6a2e730] libpthread.so.0(+0x12730) | [0x56063ce2b97f] gimp-2.10(+0x44397f) | 0x55b36078797f in gimp_projection_chunk_render_iteration () at gimpprojection.c:1416 [0x56063ce2bc28] gimp-2.10(+0x443c28) | 0x55b360787c28 in gimp_projection_chunk_render_callback () at gimpprojection.c:857 [0x7f05c6c12dd8] libglib-2.0.so.0(g_main_context_dispatch+0x158)| 0x7fc6d8194dd8 in g_main_dispatch () at ../../../glib/gmain.c:3182 [0x7f05c6c131c8] libglib-2.0.so.0(+0x4e1c8) | 0x7fc6d81951c8 in g_main_context_iterate () at ../../../glib/gmain.c:3920 [0x7f05c6c134c2] libglib-2.0.so.0(g_main_loop_run+0xb2) | 0x7fc6d81954c2 in g_main_loop_run () at ../../../glib/gmain.c:4116 [0x56063cab8cb7] gimp-2.10(app_run+0x357) | 0x55b360414cb7 in app_run () at app.c:440 [0x56063cab85b5] gimp-2.10(main+0x395) | 0x55b3604145b5 in main () at main.c:524 [0x7f05c687d09b] libc.so.6(__libc_start_main+0xeb) | 0x7fc6d7dff09b in __libc_start_main () at ../csu/libc-start.c:308 [0x56063cab873a] gimp-2.10(_start+0x2a) | 0x55b36041473a in _start () [1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols # Buster/stable amd64 qemu VM 2020-01-08 apt update apt dist-upgrade apt install systemd-coredump xserver-xorg sddm openbox xterm binutils gdb gimp gimp-dbgsym libglib2.0-0-dbgsym libgimp2.0-dbgsym gdb -q --pid $(pidof gimp-2.10 set width 0 set pagination off set backtrace past-main Submitter: | Reconstructed: [0x7f05c7726e27] libgimpbase-2.0.so.0(gimp_stack_trace_print+0x397) | 0x7fc6d8ca8e27 in gimp_stack_trace_print () from /lib/libgimpbase-2.0.so.0 [0x56063cab94a0] gimp-2.10(+0xd14a0)| 0x55b3604154a0 in gimp_eek () at errors.c:377 [0x56063cab98d8] gimp-2.10(+0xd18d8)| 0x55b3604158d8 in gimp_fatal_error () at errors.c:234 [0x56063caba037] gimp-2.10(+0xd2037)| 0x55b360416037 in gimp_sigfatal_handler (sig_num=8) at signals.c:165 [0x7f05c6a2e730] libpthread.so.0(+0x12730) | [0x56063ce2b97f] gimp-2.10(+0x44397f) | 0x55b36078797f in gimp_projection_chunk_render_iteration () at gimpprojection.c:1416 [0x56063ce2bc28] gimp-2.10(+0x443c28) | 0x55b360787c28 in gimp_projection_chunk_render_callback () at gimpprojection.c:857 [0x7f05c6c12dd8] libglib-2.0.so.0(g_main_context_dispatch+0x158)| 0x7fc6d8194dd8 in g_main_dispatch () at ../../../glib/gmain.c:3182 [0x7f05c6c131c8] libglib-2.0.so.0(+0x4e1c8) | 0x7fc6d81951c8 in g_main_context_iterate () at ../../../glib/gmain.c:3920 [0x7f05c6c134c2] libglib-2.0.so.0(g_main_loop_run+0xb2) | 0x7fc6d81954c2 in g_main_loop_run () at ../../../glib/gmain.c:4116 [0x56063cab8cb7] gimp-2.10(app_run+0x357) | 0x55b360414cb7 in app_run () at app.c:440 [0x56063cab85b5] gimp-2.10(main+0x395) | 0x55b3604145b5 in main () at main.c:524 [0x7f05c687d09b] libc.so.6(__libc_start_main+0xeb) | 0x7fc6d7dff09b in __libc_start_main () at ../csu/libc-start.c:308 [0x56063cab873a] gimp-2.10(_start+0x2a) | 0x55b36041473a in _start () benutzer@debian:~$ addr2line --exe=/lib/x86_64-linux-gnu/libpthread.so.0
Bug#948346: xdm gets killed, but only on sunday, on the first startup (code=killed, signal=USR2)
Dear Maintainer,
I could reproduce the issue in a minimal bullseye VM.
>From my observations I guess the USR2 signal is sent
by logrotate:
/etc/logrotate.d/xdm:
kill -s USR2 $(cat /var/run/xdm.pid); \
If I read [1] right, then USR2 has a default action of
process termination. Therefore is my guess that log rotation
is started/finishes too fast and the USR2 signal is sent
before xdm replaced the default with its own signal handler.
With a package built with the following line moved near
the top of the main function I could no more
reproduce the issue:
(void) Signal (SIGUSR2, ReopenLogFileNotify);
Kind regards,
Bernhard
[1]
https://unix.stackexchange.com/questions/38589/why-does-sigusr1-cause-process-to-be-terminated
# Bullseye/testing amd64 qemu VM 2020-01-08
apt update
apt dist-upgrade
apt install systemd-coredump mc fakeroot xserver-xorg xdm openbox xterm
apt build-dep xdm
mkdir /home/benutzer/source/xdm/orig -p
cd/home/benutzer/source/xdm/orig
apt source xdm
cd
timedatectl set-ntp false
timedatectl set-time "2020-01-11 23:59:00"
reboot
# stay in grub menu two minutes
journalctl --no-pager
Jan 12 00:00:11 debian systemd[1]: xdm.service: Main process exited,
code=killed, status=12/USR2
Jan 12 00:00:11 debian systemd[1]: xdm.service: Failed with result 'signal'.
journalctl -u xdm
-- Logs begin at Sun 2020-01-12 00:00:11 CET, end at Sun 2020-01-12 00:00:27
CET. --
Jan 12 00:00:11 debian systemd[1]: Starting X-Window Display Manager...
Jan 12 00:00:11 debian systemd[1]: Started X-Window Display Manager.
Jan 12 00:00:11 debian systemd[1]: xdm.service: Main process exited,
code=killed, status=12/USR2
Jan 12 00:00:11 debian systemd[1]: xdm.service: Failed with result 'signal'.
systemctl status xdm
● xdm.service - X-Window Display Manager
Loaded: loaded (/lib/systemd/system/xdm.service; indirect; vendor preset:
enabled)
Active: failed (Result: signal) since Sun 2020-01-12 00:00:11 CET; 2min 0s
ago
Process: 491 ExecStartPre=/bin/sh -c [ "$(cat
/etc/X11/default-display-manager 2>/dev/null)" = "/usr/bin/xdm" ] (code=exited,
status=0/SUCCESS)
Process: 499 ExecStart=/usr/bin/xdm -nodaemon (code=killed, signal=USR2)
Main PID: 499 (code=killed, signal=USR2)
Jan 12 00:00:11 debian systemd[1]: Starting X-Window Display Manager...
Jan 12 00:00:11 debian systemd[1]: Started X-Window Display Manager.
Jan 12 00:00:11 debian systemd[1]: xdm.service: Main process exited,
code=killed, status=12/USR2
Jan 12 00:00:11 debian systemd[1]: xdm.service: Failed with result 'signal'.
ls -lisah /var/log/xdm.log*
3933400 -rw-r--r-- 1 root root0 Jan 12 00:00 /var/log/xdm.log
393269 4,0K -rw-r--r-- 1 root root 1,4K Jan 12 00:00 /var/log/xdm.log.1
root@debian:~# journalctl -u xdm
-- Logs begin at Sun 2020-01-19 00:00:12 CET, end at Sun 2020-01-19 00:00:21
CET. --
Jan 19 00:00:12 debian systemd[1]: Starting X-Window Display Manager...
Jan 19 00:00:12 debian systemd[1]: Started X-Window Display Manager.
Jan 19 00:00:12 debian systemd[1]: xdm.service: Main process exited,
code=killed, status=12/USR2
Jan 19 00:00:13 debian systemd[1]: xdm.service: Failed with result 'signal'.
root@debian:~# ls -lisah /var/log/xdm.log*
3932690 -rw-r--r-- 1 root root0 Jan 19 00:00 /var/log/xdm.log
393340 12K -rw-r--r-- 1 root root 8,5K Jan 19 00:00 /var/log/xdm.log.1
393359 4,0K -rw-r--r-- 1 root root 274 Jan 11 23:59 /var/log/xdm.log.2.gz
root@debian:~# cat /etc/logrotate.d/xdm
/var/log/xdm.log {
weekly
rotate 52
compress
delaycompress
notifempty
missingok
postrotate
if [ -r /var/run/xdm.pid ]; then \
kill -s USR2 $(cat /var/run/xdm.pid); \
fi
endscript
}
# vim:set ai et sts=4 sw=4 tw=80:
#
watch -n0.01 kill -s USR2 \$\(cat /var/run/xdm.pid\)
systemctl stop xdm
rm /var/run/xdm.pid
systemctl start xdm
--> similar result, xdm is not able to start
Bug#948287: bash: *** stack smashing detected *** ( SIGABRT crash )
Hello crvi c, could you please add an example command that you want to have completed? And if you have changed the environment GLIBC_TUNABLES, to which value? Otherwise a gdb session driven by the two commands below could maybe point to the exact location where the overwriting takes place, if watchpoint 5 is reached, and we assume that __pthread_tunables_init is just called once... Kind regards, Bernhard cat < /tmp/gdb-cmd.txt set width 0 set pagination off display/i \$pc set breakpoint pending on b __pthread_tunables_init run dele 1 b * (__pthread_tunables_init+30) cont dele 2 disassemble __pthread_tunables_init, __pthread_tunables_init+70 print/x \$rax print/x \$rsp + 0x8 print/x *(long*) \$2 bt b * (__pthread_tunables_init+37) cont dele 3 print/x *(long*) \$2 b * (__pthread_tunables_init+56) watch *(long*) \$2 cont info b bt full disa 4 disa 5 cont bt quit EOF gdb -q -batch -command /tmp/gdb-cmd.txt --args bash
Bug#948288: gnome-shell reproducibly crashes on boot, and the boot process gets stuck
Hello Md Ayquassar, I am not involved in packaging gnome-shell, but may have some pointers to gather some more informations for the maintainer. You could try to install the package systemd-coredump. That way the output of 'journalctl --no-pager' should give some information where the crash happened below the line "segfault at". Additionally that output would be a lot more helpful if you could install the debug symbol package gnome-shell-dbgsym before the process crashes. This package comes from a separate repository described in following link: https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols Kind regards, Bernhard
Bug#941051: cryptsetup: luksFormat crash with benbi IV generator and LUKS2 integrity option(s)
Dear Maintainer, I rebuilt a linux-image package with the patch applied and the submitters' cryptsetup command finished without visible error to me. (console output and dmesg in second half of attached file.) Due to my limited knowledge of cryptsetup I guess Jerad could better judge if the resulting device is working properly afterwards. Kind regards, Bernhard # Unstable amd64 qemu VM 2020-01-06 apt-mark hold kmod libkmod2 #Bug 948257 apt update apt dist-upgrade fdisk /dev/sdb mkfs.ext4 /dev/sdX1 mkdir /home/benutzer/source mount /dev/sdb1 /home/benutzer/source chown benutzer:benutzer /home/benutzer/source apt install linux-image-5.4.0-2-amd64-unsigned systemd-coredump mc htop strace cryptsetup fakeroot apt build-dep linux-image-5.4.0-2-amd64-unsigned dpkg --purge linux-image-5.3.0-3-amd64 linux-image-5.4.0-1-amd64 linux-image-amd64 linux-image-5.4.0-2-amd64-unsigned mkdir /home/benutzer/source/linux-image-5.4.0-2-amd64-unsigned/orig -p cd/home/benutzer/source/linux-image-5.4.0-2-amd64-unsigned/orig apt source linux-image-5.4.0-2-amd64-unsigned cd # 1. Without patch cd /home/benutzer/source/linux-image-5.4.0-2-amd64-unsigned cp orig try1 -a cd try1/linux-5.4.8 fakeroot debian/rules source sed -i 's@debian/bin/buildcheck.py @-debian/bin/buildcheck.py @g' debian/rules.real time fakeroot make -j`nproc` -f debian/rules.gen binary-arch_amd64_none_amd64 ~ 1h ~25 GB dpkg -i /home/benutzer/source/linux-image-5.4.0-2-amd64-unsigned/try1/linux-image-5.4.0-2-amd64-unsigned_5.4.8-1_amd64.deb reboot truncate -s 400M /tmp/test losetup /dev/loop0 /tmp/test export LANG=C cryptsetup luksFormat \ --cipher=twofish-xts-benbi \ --hash=sha512 \ --verify-passphrase \ --key-size=512 \ --use-random \ --type=luks2 \ --pbkdf=argon2id \ --pbkdf-memory=1048576 \ --pbkdf-parallel=4 \ --pbkdf-force-iterations=5 \ --integrity=hmac-sha256 \ --integrity-no-journal \ --sector-size=4096 \ /dev/loop0 losetup -d /dev/loop0 rm /tmp/test [Mo Jan 6 20:08:28 2020] loop: module loaded [Mo Jan 6 20:08:36 2020] device-mapper: uevent: version 1.0.3 [Mo Jan 6 20:08:36 2020] device-mapper: ioctl: 4.41.0-ioctl (2019-09-16) initialised: dm-de...@redhat.com [Mo Jan 6 20:08:36 2020] NET: Registered protocol family 38 [Mo Jan 6 20:08:36 2020] cryptd: max_cpu_qlen set to 1000 [Mo Jan 6 20:08:36 2020] CPU feature 'AVX registers' is not supported. [Mo Jan 6 20:08:36 2020] xor: measuring software checksum speed [Mo Jan 6 20:08:36 2020]prefetch64-sse: 17846.000 MB/sec [Mo Jan 6 20:08:36 2020]generic_sse: 16337.000 MB/sec [Mo Jan 6 20:08:36 2020] xor: using function: prefetch64-sse (17846.000 MB/sec) [Mo Jan 6 20:08:36 2020] async_tx: api initialized (async) [Mo Jan 6 20:08:38 2020] alg: No test for authenc(hmac(sha256),xts(twofish)) (authenc(hmac(sha256-generic),xts(ecb-twofish-3way))) [Mo Jan 6 20:08:38 2020] device-mapper: table: 254:1: crypt: Error creating IV [Mo Jan 6 20:08:38 2020] device-mapper: ioctl: error adding target to table [Mo Jan 6 20:09:50 2020] BUG: unable to handle page fault for address: 00400024 [Mo Jan 6 20:09:50 2020] #PF: supervisor read access in kernel mode [Mo Jan 6 20:09:50 2020] #PF: error_code(0x) - not-present page [Mo Jan 6 20:09:50 2020] PGD 0 P4D 0 [Mo Jan 6 20:09:50 2020] Oops: [#1] SMP NOPTI [Mo Jan 6 20:09:50 2020] CPU: 4 PID: 665 Comm: cryptsetup Tainted: G E 5.4.0-2-amd64 #1 Debian 5.4.8-1 [Mo Jan 6 20:09:50 2020] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 [Mo Jan 6 20:09:50 2020] RIP: 0010:crypt_iv_benbi_ctr+0x18/0x60 [dm_crypt] # 2. With patch cd /home/benutzer/source/linux-image-5.4.0-2-amd64-unsigned cp orig try2 -a cd try2/linux-5.4.8 fakeroot debian/rules source sed -i 's@debian/bin/buildcheck.py @-debian/bin/buildcheck.py @g' debian/rules.real wget "https://git.kernel.org/pub/scm/linux/kernel/git/mbroz/linux.git/patch/?id=c3563cd7350dff811543cbc275547a7f878a6c3a; -O ../c3563cd7350dff811543cbc275547a7f878a6c3a.patch patch -p1 < ../c3563cd7350dff811543cbc275547a7f878a6c3a.patch time fakeroot make -j`nproc` -f debian/rules.gen binary-arch_amd64_none_amd64 real61m33,973s user240m28,026s sys 33m8,348s du -sh . 25G . dpkg -i /home/benutzer/source/linux-image-5.4.0-2-amd64-unsigned/try2/linux-image-5.4.0-2-amd64-unsigned_5.4.8-1_amd64.deb reboot truncate -s 400M /tmp/test losetup /dev/loop0 /tmp/test export LANG=C cryptsetup luksFormat \ --cipher=twofish-xts-benbi \ --hash=sha512 \ --verify-passphrase \ --key-size=512 \ --use-random \ --type=luks2 \ --pbkdf=argon2id \ --pbkdf-memory=1048576 \ --pbkdf-parallel=4 \ --pbkdf-force-iterations=5 \ --integrity=hmac-sha256 \ --integrity-no-journal \
Bug#948268: Crashes after startup
Dear Maintainer, just as a side note, a similar bug was submitted against the basilisk2 package. https://bugs.debian.org/922323 Another user of slirp is qemu, which had some changes in that area, which seems to have evolved into this library: https://gitlab.freedesktop.org/slirp/libslirp https://gitlab.freedesktop.org/slirp/libslirp/blob/master/src/ip.h#L214 Kind regards, Bernhard
Bug#941051: cryptsetup: luksFormat crash with benbi IV generator and LUKS2 integrity option(s)
Hello Milan, thanks for the fast response - I currently try to build a package with your patch, but I guess this could take some time... And I don't know what the usual approach is, but the original reporter is probably Jerad? (@Jerad maybe you could confirm your issue is the same that I was seeing in dmesg?) I hope the build finishes and I can report back then. Kind regards, Bernhard
Bug#941051: cryptsetup: luksFormat crash with benbi IV generator and LUKS2 integrity option(s)
Dear Maintainer, I just tried to reproduce the issue, but always got a kernel oops instead of a usermode exception. Therefore I guess this issue might be reassigned to src:linux? By further looking it seems that in crypto_tfm_alg_blocksize the __crt_alg member is dereferenced unconditionally while containing a null pointer. This could be reproduced in a minimal VM running stable with 4.19.0-6-amd64 or unstable with 5.4.0-1-amd64. Kind regards, Bernhard [Sa Jan 4 17:08:33 2020] alg: No test for authenc(hmac(sha256),xts(twofish)) (authenc(hmac(sha256-generic),xts(ecb-twofish-3way))) [Sa Jan 4 17:08:33 2020] BUG: kernel NULL pointer dereference, address: 0028 [Sa Jan 4 17:08:33 2020] #PF: supervisor read access in kernel mode [Sa Jan 4 17:08:33 2020] #PF: error_code(0x) - not-present page [Sa Jan 4 17:08:33 2020] PGD 0 P4D 0 [Sa Jan 4 17:08:33 2020] Oops: [#1] SMP NOPTI [Sa Jan 4 17:08:33 2020] CPU: 7 PID: 4875 Comm: cryptsetup Not tainted 5.4.0-1-amd64 #1 Debian 5.4.6-1 [Sa Jan 4 17:08:33 2020] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 [Sa Jan 4 17:08:33 2020] RIP: 0010:crypt_iv_benbi_ctr+0x18/0x60 [dm_crypt] [Sa Jan 4 17:08:33 2020] Code: 00 00 00 b9 ff ff ff ff 0f bd 8f b0 00 00 00 d3 e8 c3 66 66 66 66 90 48 8b 87 a8 00 00 00 b9 ff ff ff ff 48 8b 00 48 8b 40 60 <8b> 50 24 b8 01 00 00 00 0f bd ca d3 e0 39 d0 75 15 83 f9 09 7f 1e # Buster/stable amd64 qemu VM 2020-01-04 apt update apt dist-upgrade apt install systemd-coredump cryptsetup truncate -s 400M /tmp/test losetup /dev/loop0 /tmp/test export LANG=C cryptsetup luksFormat \ --cipher=twofish-xts-benbi \ --hash=sha512 \ --verify-passphrase \ --key-size=512 \ --use-random \ --type=luks2 \ --pbkdf=argon2id \ --pbkdf-memory=1048576 \ --pbkdf-parallel=4 \ --pbkdf-force-iterations=5 \ --integrity=hmac-sha256 \ --integrity-no-journal \ --sector-size=4096 \ /dev/loop0 losetup -d /dev/loop0 rm /tmp/test ## ## root@debian:~# truncate -s 400M /tmp/test root@debian:~# losetup /dev/loop0 /tmp/test root@debian:~# export LANG=C root@debian:~# cryptsetup luksFormat \ > --cipher=twofish-xts-benbi \ > --hash=sha512 \ > --verify-passphrase \ > --key-size=512 \ > --use-random \ > --type=luks2 \ > --pbkdf=argon2id \ > --pbkdf-memory=1048576 \ > --pbkdf-parallel=4 \ > --pbkdf-force-iterations=5 \ > --integrity=hmac-sha256 \ > --integrity-no-journal \ > --sector-size=4096 \ > /dev/loop0 WARNING! This will overwrite data on /dev/loop0 irrevocably. Are you sure? (Type uppercase yes): YES Enter passphrase for /dev/loop0: Verify passphrase: System is out of entropy while generating volume key. Please move mouse or type some text in another window to gather some random events. Generating key (25% done). Generating key (25% done). Generating key (25% done). Generating key (68% done). Generating key (100% done). Wiping device to initialize integrity checksum. You can interrupt this by pressing CTRL+c (rest of not wiped device will contain invalid checksum). Segmentation fault root@debian:~# dmesg ... [ 72.932437] alg: No test for authenc(hmac(sha256),xts(twofish)) (authenc(hmac(sha256-generic),xts(ecb-twofish-avx))) [ 72.932657] general protection fault: [#1] SMP PTI [ 72.932718] CPU: 2 PID: 463 Comm: cryptsetup Not tainted 4.19.0-6-amd64 #1 Debian 4.19.67-2+deb10u2 [ 72.932771] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 [ 72.932821] RIP: 0010:crypt_iv_benbi_ctr+0x18/0x60 [dm_crypt] [ 72.932854] Code: 00 00 00 b9 ff ff ff ff 0f bd 8f c0 00 00 00 d3 e8 c3 66 66 66 66 90 48 8b 87 b8 00 00 00 b9 ff ff ff ff 48 8b 00 48 8b 40 60 <8b> 50 24 b8 01 00 00 00 0f bd ca d3 e0 39 d0 75 15 83 f9 09 7f 1e [ 72.932956] RSP: 0018:c0874098fbb8 EFLAGS: 00010286 [ 72.932987] RAX: 19e7f52c35158f78 RBX: 9b0cb6fd7800 RCX: [ 72.933024] RDX: RSI: c08740956040 RDI: 9b0cb6fd7800 [ 72.933061] RBP: 9b0cb6fd7800 R08: 70da9754 R09: [ 72.933099] R10: 4020ca8d R11: 0027 R12: c08740956040 [ 72.933136] R13: 0010 R14: 9b0cbb3c4480 R15: 9b0cb4918188 [ 72.933200] FS: 7fae4dc9ed00() GS:9b0cbcb0() knlGS: [ 72.933241] CS: 0010 DS: ES: CR0: 80050033 [ 72.933272] CR2: 7ffe60090e18 CR3: b4c26004 CR4: 00060ee0 [ 72.933314] Call Trace: [ 72.933345] crypt_ctr+0x806/0x122e [dm_crypt] [ 72.933386] dm_table_add_target+0x17d/0x360 [dm_mod] [ 72.933422] table_load+0x122/0x2e0 [dm_mod] [ 72.933453] ? dev_status+0x40/0x40 [dm_mod] [ 72.933481] ctl_ioctl+0x1af/0x3f0 [dm_mod] [ 72.933512] dm_ctl_ioctl+0xa/0x10 [dm_mod] [ 72.933546] do_vfs_ioctl+0xa4/0x630 [ 72.933577] ?
Bug#947902: midori: Crash upon clearing URL
Short addition: upstream changed that line urlbar.vala:109 in commit [1]. A locally built package including that patch did not crash for me. Kind regards, Bernhard [1] https://github.com/midori-browser/core/commit/525f76c68fdde8a2d974c6975d9cc5ebe0cd594b
Bug#947902: midori: Crash upon clearing URL
Dear Maintainer,
I tried to reproduce it also on amd64 and found it
crashing at the following location.
My knowledge of vala is limited, but is here the member
"suggestion_row.item.database" not yet set, but already accessed?
Kind regards,
Bernhard
Thread 1 received signal SIGSEGV, Segmentation fault.
midori_database_get_readonly (self=0x0) at ./core/database.vala:202
202 public bool readonly { get; construct set; default = false; }
(rr) bt
#0 0x7f3978c8c830 in midori_database_get_readonly (self=0x0) at
./core/database.vala:202
#1 0x7f3978ca26e5 in midori_urlbar_real_key_press_event
(base=0x561ecad38360 [MidoriUrlbar], event=) at
./core/urlbar.vala:109
#2 0x7f3973fee274 in _gtk_marshal_BOOLEAN__BOXEDv (closure=0x561ecaa80110,
return_value=0x7ffce21e8e40, instance=, args=,
marshal_data=, n_params=,
param_types=0x561ecaa80140) at ../../../../gtk/gtkmarshalers.c:129
#3 0x7f39788b1dd0 in _g_closure_invoke_va (closure=0x561ecaa80110,
return_value=0x7ffce21e8e40, instance=0x561ecad38360, args=0x7ffce21e8f10,
n_params=1, param_types=0x561ecaa80140) at ../../../gobject/gclosure.c:873
#4 0x7f39788cdd74 in g_signal_emit_valist (instance=0x561ecad38360,
signal_id=, detail=0, var_args=var_args@entry=0x7ffce21e8f10) at
../../../gobject/gsignal.c:3300
#5 0x7f39788ce97f in g_signal_emit
(instance=instance@entry=0x561ecad38360, signal_id=,
detail=detail@entry=0) at ../../../gobject/gsignal.c:3447
#6 0x7f3973f9c324 in gtk_widget_event_internal
(widget=widget@entry=0x561ecad38360 [MidoriUrlbar],
event=event@entry=0x561ecaff7010) at ../../../../gtk/gtkwidget.c:7744
#7 0x7f3973f9e43a in gtk_widget_event (widget=widget@entry=0x561ecad38360
[MidoriUrlbar], event=event@entry=0x561ecaff7010) at
../../../../gtk/gtkwidget.c:7314
#8 0x7f3973fbc91b in gtk_window_propagate_key_event
(window=window@entry=0x561ecad064d0 [MidoriBrowser],
event=event@entry=0x561ecaff7010) at ../../../../gtk/gtkwindow.c:8198
#9 0x7f3978c8387a in midori_browser_real_key_press_event
(base=0x561ecad064d0 [MidoriBrowser], event=0x561ecaff7010) at
./core/browser.vala:395
#10 0x7f3973fee274 in _gtk_marshal_BOOLEAN__BOXEDv (closure=0x561ecaa80110,
return_value=0x7ffce21e9230, instance=, args=,
marshal_data=, n_params=,
param_types=0x561ecaa80140) at ../../../../gtk/gtkmarshalers.c:129
#11 0x7f39788b1ec6 in _g_closure_invoke_va (closure=0x561ecaa80110,
return_value=0x7ffce21e9230, instance=0x561ecad064d0, args=0x7ffce21e9300,
n_params=1, param_types=0x561ecaa80140) at ../../../gobject/gclosure.c:873
#12 0x7f39788cdd74 in g_signal_emit_valist (instance=0x561ecad064d0,
signal_id=, detail=0, var_args=var_args@entry=0x7ffce21e9300) at
../../../gobject/gsignal.c:3300
#13 0x7f39788ce97f in g_signal_emit
(instance=instance@entry=0x561ecad064d0, signal_id=,
detail=detail@entry=0) at ../../../gobject/gsignal.c:3447
#14 0x7f3973f9c324 in gtk_widget_event_internal (widget=0x561ecad064d0
[MidoriBrowser], event=0x561ecaff7010) at ../../../../gtk/gtkwidget.c:7744
#15 0x7f3973e5ca3f in propagate_event (widget=0x561ecaa54660 [GtkPopover],
event=0x561ecaff7010, captured=, topmost=0x0) at
../../../../gtk/gtkmain.c:2685
#16 0x7f3973e5ea83 in gtk_main_do_event (event=0x561ecaff7010) at
../../../../gtk/gtkmain.c:1915
#17 0x7f3973e5ea83 in gtk_main_do_event (event=) at
../../../../gtk/gtkmain.c:1685
#18 0x7f3973b60465 in _gdk_event_emit (event=event@entry=0x561ecaff7010) at
../../../../gdk/gdkevents.c:73
#19 0x7f3973b91112 in gdk_event_source_dispatch (source=,
callback=, user_data=) at
../../../../../gdk/x11/gdkeventsource.c:367
#20 0x7f39787cdf2e in g_main_dispatch (context=0x561ecaa0aac0) at
../../../glib/gmain.c:3182
#21 0x7f39787cdf2e in g_main_context_dispatch
(context=context@entry=0x561ecaa0aac0) at ../../../glib/gmain.c:3847
#22 0x7f39787ce1c8 in g_main_context_iterate
(context=context@entry=0x561ecaa0aac0, block=block@entry=1,
dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:3920
#23 0x7f39787ce25c in g_main_context_iteration
(context=context@entry=0x561ecaa0aac0, may_block=may_block@entry=1) at
../../../glib/gmain.c:3981
#24 0x7f39789c2a2d in g_application_run (application=0x561ecaa090f0
[MidoriApp], argc=, argv=0x7ffce21e9778) at
../../../gio/gapplication.c:2470
#25 0x561ec941e18e in _vala_main (args=0x7ffce21e9778, args_length1=1) at
./core/main.vala:14
#26 0x7f397375b09b in __libc_start_main (main=0x561ec941e070 ,
argc=1, argv=0x7ffce21e9778, init=, fini=,
rtld_fini=, stack_end=0x7ffce21e9768) at ../csu/libc-start.c:308
#27 0x561ec941e0aa in _start () at ./core/main.vala:12
...
(rr) reverse-stepi
0x7f3978ca26e0 in midori_urlbar_real_key_press_event (base=0x561ecad38360
[MidoriUrlbar], event=) at ./core/urlbar.vala:109
109 if (suggestion_row != null &&
!suggestion_row.item.database.readonly) {
# Buster/stable amd64 qemu VM 2020-01-04
apt
Bug#942214: thunar/nautilus crash navigate directory "cifs mounted" containing opened libreoffice writer file
Hello David, I guess the package "thunar-dbgsym gdb" are installed on your system, but could you please recheck if packages "libglib2.0-0-dbgsym libgtk-3-0-dbgsym" are really installed, too? Kind regards, Bernhard
Bug#947928: rdesktop crash with segmentation error
Hello Antonio, thanks for your comprehensive investigation. I was not aware that rdesktop did not yet have a dbgsym package, have opened bug #948126 for this. And unfortunately if the backtrace in catchsegv ommits function names, its output is just of help when using the debian binary with a dbgsym package available. However, your nice backtraces made the Maintainer already solve the issue, I guess. Kind regards, Bernhard
Bug#948126: rdesktop: Enable dbgsym packages by not stripping binary
Package: rdesktop Version: 1.9.0-1 Severity: normal Dear Maintainer, attempting to support triaging another rdesktop bug I found there does not yet exist a dbgsym package. I tried to find out why and guess this is caused by the strip command done in the Makefile. As stripping would be done by debhelper while packaging, I guess simplifying 80_handle_nostrip_option.patch to following would do: -STRIP = @STRIP@ +STRIP=/bin/true 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-1-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 rdesktop depends on: ii libasound21.1.9-1 ii libc6 2.29-7 ii libgmp10 2:6.1.2+dfsg-4 ii libgnutls30 3.6.11.1-2 ii libgssapi-krb5-2 1.17-6 ii libhogweed5 3.5.1+really3.5.1-2 ii libnettle73.5.1+really3.5.1-2 ii libpcsclite1 1.8.26-1 ii libtasn1-64.15.0-2 ii libx11-6 2:1.6.8-1 ii libxcursor1 1:1.2.0-2 ii libxrandr22:1.5.1-1 rdesktop recommends no packages. Versions of packages rdesktop suggests: pn pcscd -- no debconf information
Bug#947928: rdesktop crash with segmentation error
Hello Antonio, could you please add to which windows version you were trying to connect. Maybe you could also try to start it that way: catchsegv rdesktop ... Even better would be if you could install debug symbols like described in [1] and systemd-coredump. Then after an application crashed you should receive a backtrace at the end of this command: journalctl --no-pager [1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols Kind regards, Bernhard
Bug#948026: GIMP 2.10.8-2 still fails to open EPS files;
Short addition: this upstream issue seems to match better: https://gitlab.gnome.org/GNOME/gimp/issues/3630 Which got fixed in branches master and gimp-2-10 by these upstream commits: https://gitlab.gnome.org/GNOME/gimp/commit/bbcc7ca5f55e62404bd69bf2e5b198039ad3f568 https://gitlab.gnome.org/GNOME/gimp/commit/2f2067a5aacae176f5aaf828e15bd4463879062a Kind regards, Bernhard
Bug#948026: GIMP 2.10.8-2 still fails to open EPS files;
Control: tags -1 + patch upstream
Dear Maintainer,
I tried to have a look at this crash and I guess I found the reason.
The plugin calls into libgs.so.9 by gsapi_new_instance/psapi_new_instance.
Unfortunately the instance pointer is given to that function
uninitialized. But documentation states that it has to be NULL [1].
Building a gimp package with attached patch makes the import
not crash any longer.
Upstream seems to track this issue in [2].
Kind regards,
Bernhard
[1] https://www.ghostscript.com/doc/current/API.htm#new_instance
[2] https://gitlab.gnome.org/GNOME/gimp/issues/3636
Thread 1 "file-ps" received signal SIGSEGV, Segmentation fault.
gs_lib_ctx_init (ctx=ctx@entry=0x7fea95643559 <__libc_read+89>,
mem=mem@entry=0x559c0c831c00) at ./base/gslibctx.c:175
175 gx_monitor_enter((gx_monitor_t *)(pio->core->monitor));
(gdb) bt
#0 0x7fea95999ab8 in gs_lib_ctx_init (ctx=ctx@entry=0x7fea95643559
<__libc_read+89>, mem=mem@entry=0x559c0c831c00) at ./base/gslibctx.c:175
#1 0x7fea959956b1 in gs_malloc_init_with_context (ctx=0x7fea95643559
<__libc_read+89>) at ./base/gsmalloc.c:597
#2 0x7fea95a45622 in psapi_new_instance (pinstance=0x7ffd709dfe88,
caller_handle=0x0) at ./psi/psapi.c:92
#3 0x559c0c2774ca in ps_open (filename=0x559c0c61b8e0
"/usr/share/doc/hp2xx/hp-tests/pages.2.eps", llx=,
lly=, urx=, ury=,
is_epsf=0x7ffd709e0304, loadopt=0x559c0c281080 ) at file-ps.c:1760
#4 0x559c0c278074 in load_image (filename=0x559c0c61b8e0
"/usr/share/doc/hp2xx/hp-tests/pages.2.eps", error=0x7ffd709e03f8) at
file-ps.c:1077
#5 0x559c0c27958c in run (name=, nparams=,
param=0x559c0c61bf70, nreturn_vals=0x7ffd709e0484, return_vals=)
at file-ps.c:847
#6 0x7fea96f3560c in gimp_proc_run (proc_run=) at
gimp.c:2439
#7 0x7fea96f3560c in gimp_loop () at gimp.c:2264
#8 0x7fea96f3560c in gimp_main (info=, argc=, argv=) at gimp.c:671
#9 0x7fea9549309b in __libc_start_main (main=0x559c0c274b80 ,
argc=6, argv=0x7ffd709e0688, init=, fini=,
rtld_fini=, stack_end=0x7ffd709e0678) at ../csu/libc-start.c:308
#10 0x559c0c274bca in _start () at file-ps.c:589
Description: Avoid crash in gsapi_new_instance by initializing instance pointer
Ghostscript documentation requires the handle pointer to be initialized
which is given to gsapi_new_instance.
https://www.ghostscript.com/doc/current/API.htm#new_instance
Author: Bernhard Ãbelacker
Bug: https://gitlab.gnome.org/GNOME/gimp/issues/3636
Bug-Debian: https://bugs.debian.org/948026
Forwarded: no
Last-Update: 2020-01-03
--- gimp-2.10.8.orig/plug-ins/common/file-ps.c
+++ gimp-2.10.8/plug-ins/common/file-ps.c
@@ -1757,6 +1757,7 @@ ps_open (const gchar *filename,
}
#endif
+ instance = NULL;
code = gsapi_new_instance (, NULL);
if (code == 0) {
code = gsapi_init_with_args (instance, cmdA->len - 1, pcmdA);
# Buster/stable amd64 qemu VM 2020-01-03
apt update
apt dist-upgrade
apt install systemd-coredump xserver-xorg sddm openbox xterm psmisc mc strace
gdb gdbserver gimp hp2xx gimp-dbgsym libgimp2.0-dbgsym ghostscript-dbg
apt build-dep gimp
mkdir /home/benutzer/source/gimp/orig -p
cd/home/benutzer/source/gimp/orig
apt source gimp
cd
mkdir /home/benutzer/source/ghostscript/orig -p
cd/home/benutzer/source/ghostscript/orig
apt source ghostscript
cd
export DISPLAY=:0
export LANG=C
# ulimit -c unlimited
# unfortunately somehow disables gimp the core dump production ...
# mv /usr/lib/gimp/2.0/plug-ins/file-ps/file-ps /file-ps.real
# (echo "#\!/bin/sh"; echo "exec /usr/bin/gdbserver localhost:5
/file-ps.real") > /usr/lib/gimp/2.0/plug-ins/file-ps/file-ps
# chmod +x /usr/lib/gimp/2.0/plug-ins/file-ps/file-ps
# gimp /usr/share/doc/hp2xx/hp-tests/pages.2.eps
# gdb -q
# target remote localhost:5
# does not work too
# gdb -q --args gimp /usr/share/doc/hp2xx/hp-tests/pages.2.eps
# set width 0
# set pagination off
# set follow-fork-mode child
# run
# not working too
benutzer@debian:~$ gimp --stack-trace-mode=always
/usr/share/doc/hp2xx/hp-tests/pages.2.eps
(gimp:10927): Gtk-WARNING **: 23:12:08.841: Unable to locate theme engine in
module_path: "pixmap",
...
gimp_device_info_set_device: trying to set GdkDevice 'VirtualPS/2 VMware
VMMouse' on GimpDeviceInfo which already has a device
(file-ps:10952): Gtk-WARNING **: 23:12:10.118: Unable to locate theme engine in
module_path: "pixmap",
...
/usr/lib/gimp/2.0/plug-ins/file-ps/file-ps: fatal error: Segmentation fault
26 ../sysdeps/unix/sysv/linux/read.c: No such file or directory.
# Stack traces obtained from PID 10952 - Thread 10952 #
[New LWP 10953]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
__libc_read (nbytes=256, buf=0x7ffe3ce3cbd0, fd=9) at
../sysdeps/unix/sysv/linux/read.c:26
Id Target Id Frame
* 1Thread 0x7f2d19c0b0c0 (LWP 10952) "file-ps" __libc_read (nbytes=256,
Bug#946420: kpat is spamming with error messages
Control: notfound -1 4:18.04.1-1 Control: found -1 4:19.08.1-1 Control: tags -1 unreproducible moreinfo Hello Hans, I tried to reproduce inside a minimal plasma testing VM. But I could not see a noticeable amount of messages in .xsession_errors while playing kpat. If this is still visible on your system then some more information could help. - Which game have you played inside kpat? - Some example lines of the messages in .xsession_errors Kind regards, Bernhard
Bug#946499: eog crashes with 'BadAlloc (insufficient resources for operation)' on large image
Dear Maintainer, I tried to reproduce this issue. And as far as I see eog/cairo tries to allocate a pixmap from the xserver in the size of the image file - in this case 44351x3013 pixel. Unfortunately the xserver has a hard limit for such pixmap sizes: Thread 1 "Xorg" hit Breakpoint 4, ProcShmCreatePixmap (client=0x55b5f312cc50) at ../../../../Xext/shm.c:1085 1085if (width > 32767 || height > 32767) 1086return BadAlloc; Would wayland behave better in that regard? Otherwise eog/cairo would need to allocate that pixmap some other way. This issue reported against gtkmm seems to match: https://gitlab.gnome.org/GNOME/gtkmm/issues/54 Complete backtraces with debug symbols in attached file of eog and xserver. Could remember I saw such a rejection from the xserver already in (not strictly related): https://bugs.debian.org/858045 Kind regards, Bernhard # Buster/testing amd64 qemu VM 2019-12-31 apt update apt dist-upgrade apt install systemd-coredump mc xserver-xorg sddm openbox xterm imagemagick graphicsmagick gimp gdb eog eog-dbgsym libglib2.0-0-dbgsym libgtk-3-0-dbgsym libcairo2-dbgsym libxext6-dbg libx11-6-dbgsym xserver-xorg-core-dbgsym apt build-dep xserver-xorg-core reboot mkdir /home/benutzer/source/xserver-xorg-core/orig -p cd/home/benutzer/source/xserver-xorg-core/orig apt source xserver-xorg-core cd benutzer@debian:~$ convert -size 44351x3013 xc:white white.jpg convert-im6.q16: width or height exceeds limit `white' @ error/cache.c/OpenPixelCache/3911. convert-im6.q16: no images defined `white.jpg' @ error/convert.c/ConvertImageCommand/3258. # Created with gimp benutzer@debian:~$ identify 44351x3013.jpg 44351x3013.jpg JPEG 44351x3013 44351x3013+0+0 8-bit sRGB 1.49679MiB 0.000u 0:00.000 benutzer@debian:~$ file 44351x3013.jpg 44351x3013.jpg: JPEG image data, JFIF standard 1.01, resolution (DPI), density 300x300, segment length 16, comment: "Created with GIMP", progressive, precision 8, 44351x3013, components 3 export DISPLAY=:0 benutzer@debian:~$ eog 44351x3013.jpg (eog:661): Gdk-ERROR **: 14:05:22.547: The program 'eog' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAlloc (insufficient resources for operation)'. (Details: serial 1315 error_code 11 request_code 130 (MIT-SHM) minor_code 5) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the GDK_SYNCHRONIZE environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Trace/Breakpoint ausgelöst (Speicherabzug geschrieben) [ 43.663846] traps: eog[661] trap int3 ip:7fc4abeebdb5 sp:7ffc7facd730 error:0 in libglib-2.0.so.0.6200.3[7fc4abeb2000+8] Dez 31 14:05:22 debian systemd[1]: Started Process Core Dump (PID 687/UID 0). Dez 31 14:05:29 debian systemd-coredump[688]: Core file was truncated to 2147483648 bytes. Dez 31 14:05:35 debian systemd-coredump[688]: Process 661 (eog) of user 1000 dumped core. Stack trace of thread 661: #0 0x7fc4abeebdb5 n/a (n/a + 0x0) Dez 31 14:05:35 debian systemd[1]: systemd-coredump@0-687-0.service: Succeeded. benutzer@debian:~$ GDK_SYNCHRONIZE=1 gdb -q --args eog 44351x3013.jpg Reading symbols from eog... (No debugging symbols found in eog) (gdb) run Starting program: /usr/bin/eog 44351x3013.jpg [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x72391700 (LWP 1012)] [New Thread 0x71b90700 (LWP 1013)] [New Thread 0x7138f700 (LWP 1014)] [New Thread 0x70b24700 (LWP 1015)] [New Thread 0x7fffe3fff700 (LWP 1016)] (eog:1008): Gdk-ERROR **: 14:10:12.498: The program 'eog' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAlloc (insufficient resources for operation)'. (Details: serial 2438 error_code 11 request_code 130 (MIT-SHM) minor_code 5) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the GDK_SYNCHRONIZE environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Thread 1 "eog" received signal SIGTRAP, Trace/breakpoint trap. 0x77c4bdb5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 (gdb) bt #0 0x77c4bdb5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #1 0x77c4e6bc in g_log_writer_default () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x77c4c9e7 in
Bug#947159: hardinfo segfaults when running benchmarks
Dear Maintainer,
the given backtrace should look like below with debug symbols installed.
For some reason it looks like the strchr at line 281 returns a null pointer.
Kind regards,
Bernhard
(gdb) bt no-filter
#0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
#1 0x76fc4dae in __GI___strdup (s=0x1 ) at strdup.c:41
#2 0x7471f5b4 in bench_result_benchmarkconf (section, key, values) at
./modules/benchmark/bench_results.c:281
#3 0x7471fa4d in __benchmark_include_results (r, benchmark,
order_type) at ./modules/benchmark.c:373
#4 0x7471fd8a in benchmark_include_results (benchmark, result) at
./modules/benchmark.c:408
#5 callback_bfsh () at ./modules/benchmark/benches.c:33
...
(gdb) display/i $pc
1: x/i $pc
=> 0x76fd5206 <__strlen_sse2+38>: movdqu (%rax),%xmm4
(gdb) list bench_results.c:281
276 b->legacy = 1;
277
278 /* old old format has prefix before cpu name (ex: 4x
Pentium...) */
279 nx = nx_prefix(key);
280 if (nx > 0) {
281 b->machine->cpu_name = strdup(strchr(key, 'x') + 1);
282 b->machine->threads = nx;
283 } else {
284 b->machine->cpu_name = strdup(key);
285 b->machine->threads = 1;
Bug#947237: gnome-software: Crashes on click over any software icon
Dear Maintainer, the given valgrind backtrace should translate to something like below (which did not crash for me). The crashing instruction tries to read memory pointed by register $rdi, that held in my test the address in parameters "v" / "key" / "name". So I assume for some reason this register $rdi and parameter "v" / "key" / "name" contain a null pointer leading to the crash seen by definetti. Kind regards, Bernhard (gdb) bt #0 0x77df6e20 in g_str_hash (v=0x7fffdc38d780) at ../../../glib/ghash.c:2324 #1 0x77df5eff in g_hash_table_lookup_node (hash_return, key=0x7fffdc38d780, hash_table) at ../../../glib/ghash.c:473 #2 0x77df5eff in g_hash_table_lookup (hash_table, key=key@entry=0x7fffdc38d780) at ../../../glib/ghash.c:1509 #3 0x708f9389 in store_snap_cache_lookup (need_details, name=0x7fffdc38d780 "notepad-plus-plus", plugin) at ../plugins/snap/gs-plugin-snap.c:204 #4 0x708f9389 in get_store_snap (plugin, name=0x7fffdc38d780 "notepad-plus-plus", need_details, cancellable, error) at ../plugins/snap/gs-plugin-snap.c:520 #5 0x708f9d2d in gs_plugin_add_alternates (plugin, app, list, cancellable, error) at ../plugins/snap/gs-plugin-snap.c:592 #6 0x555cca3f in gs_plugin_loader_call_vfunc (helper, plugin, app, app@entry, list, list@entry, refine_flags, refine_flags@entry, cancellable, error) at ../lib/gs-plugin-loader.c:651 #7 0x555ccc62 in gs_plugin_loader_run_results (helper, cancellable, error) at ../lib/gs-plugin-loader.c:1084 #8 0x555cdac5 in gs_plugin_loader_process_thread_cb (task, object, task_data, cancellable) at ../lib/gs-plugin-loader.c:3040 #9 0x77c92bae in g_task_thread_pool_thread (thread_data, pool_data) at ../../../gio/gtask.c:1410 #10 0x77e31404 in g_thread_pool_thread_proxy (data) at ../../../glib/gthreadpool.c:308 #11 0x77e30d0d in g_thread_proxy (data) at ../../../glib/gthread.c:805 #12 0x76fcdfb7 in start_thread (arg) at pthread_create.c:486 #13 0x76eff2df in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 (gdb) display/i $pc 2: x/i $pc => 0x77df6e20 : movsbl (%rdi),%eax (gdb) print/x $rdi $5 = 0x7fffdc38d780
Bug#947400: hkl FTBFS on arm64: sirius segfaults
Dear Maintainer, I tried to have a look and might have found something. The crash happens because coroutine_stack_init returns NULL. This is because of a buffer size check. Building a package with doubled "DEFAULT_STATE_SIZE" went through without crash (just tested on aarch64). However, I am unfamiliar with that package, therefore cannot estimate other consequences of that change. Kind regards, Bernhard (gdb) bt #0 0xe0e16e30 in generator_new_ (fn=fn@entry=0xe0e18ed8 , retsize=48, retsize@entry=40) at generator/generator.c:36 #1 0xe0e194c0 in trajectory_gen (tconfig=...) at hkl2.c:250 #2 0xe0e19574 in Trajectory_solve (tconfig=..., gconfig=..., sconfig=..., move=1) at hkl2.c:292 #3 0xe0e18168 in main_1 () at sirius.c:161 #4 0xe0dee47c in main () at sirius.c:246 # Buster aarch64 qemu VM 2019-12-28 (running at a raspberry 3) apt update apt dist-upgrade apt install systemd-coredump fakeroot htop git gdb apt build-dep hkl mkdir /home/benutzer/source/hkl/orig -p cd/home/benutzer/source/hkl/orig apt source hkl cd cd/home/benutzer/source/hkl cp orig try1 -a cd try1/hkl-5.0.0.2569 script -a "../dpkg-buildpackage_$(date +%Y-%m-%d_%H-%M-%S).log" -c "dpkg-buildpackage" dmesg journalctl --no-pager coredumpctl list coredumpctl gdb 9919 set width 0 set pagination off bt display/i $pc info reg make[4]: Entering directory '/home/benutzer/source/hkl/try1/hkl-5.0.0.2569/Documentation/figures' gcc -DHAVE_CONFIG_H -I. -I../.. -Wextra -D_DEFAULT_SOURCE -I../.. -I../../hkl -I/usr/include/glib-2.0 -I/usr/lib/aarch64-linux-gnu/glib-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/aarch64-linux-gnu/glib-2.0/include -I/usr/include -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/home/benutzer/source/hkl/try1/hkl-5.0.0.2569=. -fstack-protector-strong -Wformat -Werror=format-security -c -o sirius.o sirius.c sirius.c:244:1: warning: return type defaults to ‘int’ [-Wimplicit-int] 244 | main(void) | ^~~~ /bin/bash ../../libtool --tag=CC --mode=link gcc -g -O2 -fdebug-prefix-map=/home/benutzer/source/hkl/try1/hkl-5.0.0.2569=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,--whole-archive,../../hkl/.libs/libhkl.a,--no-whole-archive -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -o sirius sirius.o ../../hkl/libhkl.la ../../hkl/api2/libhkl2.la -lglib-2.0 -lgobject-2.0 -lglib-2.0 -L/usr/lib/aarch64-linux-gnu -lgsl -lgslcblas -lm -lyaml libtool: link: gcc -g -O2 -fdebug-prefix-map=/home/benutzer/source/hkl/try1/hkl-5.0.0.2569=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,--whole-archive -Wl,../../hkl/.libs/libhkl.a -Wl,--no-whole-archive -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,--as-needed -o .libs/sirius sirius.o ../../hkl/.libs/libhkl.so ../../hkl/api2/.libs/libhkl2.a -lgobject-2.0 -lglib-2.0 -L/usr/lib/aarch64-linux-gnu -lgsl -lgslcblas -lm -lyaml cd . && ./sirius make[4]: *** [Makefile:739: sirius-stamp] Segmentation fault (core dumped) make[4]: Leaving directory '/home/benutzer/source/hkl/try1/hkl-5.0.0.2569/Documentation/figures' make[3]: *** [Makefile:459: all-recursive] Error 1 make[3]: Leaving directory '/home/benutzer/source/hkl/try1/hkl-5.0.0.2569/Documentation' make[2]: *** [Makefile:559: all-recursive] Error 1 make[2]: Leaving directory '/home/benutzer/source/hkl/try1/hkl-5.0.0.2569' make[1]: *** [Makefile:443: all] Error 2 make[1]: Leaving directory '/home/benutzer/source/hkl/try1/hkl-5.0.0.2569' dh_auto_build: make -j4 returned exit code 2 make: *** [debian/rules:10: build] Error 255 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 Script done, file is ../dpkg-buildpackage_2019-12-28_15-26-39.log root@debian:~# journalctl --no-pager ... Dec 28 15:36:32 debian systemd[1]: Started Process Core Dump (PID 9933/UID 0). Dec 28 15:36:34 debian systemd-coredump[9934]: Process 9919 (sirius) of user 1000 dumped core. Stack trace of thread 9919: #0 0xe0e16e30 n/a (/home/benutzer/source/hkl/try1/hkl-5.0.0.2569/Documentation/figures/.libs/sirius + 0x40e30) #1 0xe0e16e28 n/a (/home/benutzer/source/hkl/try1/hkl-5.0.0.2569/Documentation/figures/.libs/sirius + 0x40e28) #2 0xe0e194c0 n/a (/home/benutzer/source/hkl/try1/hkl-5.0.0.2569/Documentation/figures/.libs/sirius + 0x434c0) #3 0xe0e19574 n/a (/home/benutzer/source/hkl/try1/hkl-5.0.0.2569/Documentation/figures/.libs/sirius + 0x43574) #4 0xe0e18168 n/a (/home/benutzer/source/hkl/try1/hkl-5.0.0.2569/Documentation/figures/.libs/sirius + 0x42168) #5 0xe0dee47c n/a
Bug#946940: lshw crashes with floating point exception
Control: tags -1 + fixed-upstream patch Dear Maintainer, upstream fixed this issue in git by following commit: https://ezix.org/src/pkg/lshw/commit/89b3b6b9ed03f22ca98954712db5a90acf2c6755 Kind regards, Bernhard
Bug#946940: lshw crashes with floating point exception
Control: tags -1 + upstream Control: forwarded -1 https://www.ezix.org/project/ticket/755 Dear Maintainer, I tried to forward this issue upstream, where it is tracked in this bug report: https://www.ezix.org/project/ticket/755 Hope it is ok to set this bug to forwarded. Kind regards, Bernhard
Bug#946940: lshw crashes with floating point exception
Hello Dave, I am not involved in packaging lshw, just looking at some random crash bug reports. First, when reporting crashes that line from dmesg is most of the time not sufficient. Therefore a simple way to retrieve some more information could be to run it by 'catchsegv lshw'. Better woudl be if it is possible to install something like systemd-coredump. That way a backtrace should be printed to 'journalctl --no-pager'. And even better would be to install additionally matching dbgsym packages e.g. lshw-dbgsym. Therefore another package repository is needed to be activated. More details in [1]. But as lshw is small enough, I guess I found something. The instruction offset in combination with the 'divide error' points to this line: (gdb) list fat.cc:220 227 cluster_count /= vs.sectors_per_cluster; Could you confirm to have a FAT partition attached to the system? Maybe a damaged or ancient one, maybe a floppy? If vs.sectors_per_cluster would be 0 the crash would happen exactly like you experienced it. (gdb) bt #0 0x555f2e73 in scan_fat (n=..., id=...) at fat.cc:237 #1 0x555edea4 in detect_fat (n=..., s=...) at volumes.cc:513 #2 0x555eb895 in scan_volume (n=..., s=...) at volumes.cc:1075 #3 0x555e4115 in detect_dosmap (s=..., n=...) at partitions.cc:1197 #4 0x555e0e96 in scan_partitions (n=...) at partitions.cc:1386 #5 0x555cb00a in scan_disk (n=...) at disk.cc:79 #6 0x555c81d5 in scan_sg (n=...) at scsi.cc:762 #7 0x555c9e75 in scan_scsi (n=...) at scsi.cc:909 #8 0x5558bffd in scan_system (system=...) at main.cc:134 #9 0x5557a50c in main (argc=, argv=) at lshw.cc:247 Kind regards, Bernhard P.S.: You compiled upstream package lshw-B.02.18.tar.gz and experienced a crash. I guess that one is fixed in upstream git in the last commit to usb.cc, which is unrelated to the above issue. More details at the bottom of attached file. [1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols # Bullseye/testing amd64 qemu VM 2019-12-18 apt update apt dist-upgrade apt install systemd-coredump parted dosfstools binutils mc gdb lshw lshw-dbgsym apt build-dep lshw mkdir /home/benutzer/source/lshw/orig -p cd/home/benutzer/source/lshw/orig apt source lshw cd reboot #objdump --disassemble /usr/bin/lshw | grep e73: gdb -q -ex 'set width 0' -ex 'set pagination off' -ex 'b main' -ex 'run' -ex 'generate-core-file core' -ex 'kill' -ex 'quit' --args /usr/bin/lshw root@debian:~# gdb -q -ex 'set width 0' -ex 'set pagination off' -ex 'info target' -ex 'quit' /usr/bin/lshw --core core | grep -E "is .text$" 80 lshw.cc: Datei oder Verzeichnis nicht gefunden. 0x55563a40 - 0x555f4071 is .text root@debian:~# gdb -q -ex 'set width 0' -ex 'set pagination off' -ex 'disassemble 0x55563a40,0x555f4071' -ex 'quit' /usr/bin/lshw --core core | grep " 0x.e73" 80 lshw.cc: Datei oder Verzeichnis nicht gefunden. 0x55565e73 :add $0x10,%rbx 0x55567e73 , std::allocator > >&)+-223165>: callq 0x55563400 <_ZdlPv@plt> 0x5556ee73 :callq 0x55563400 <_ZdlPv@plt> 0x5556fe73 :je 0x5556fe7a 0x55572e73 :je 0x55572e7a 0x55573e73 , std::allocator >)+-418717>: mov%rbp,%rdi 0x5557be73 : cmp$0x5,%esi 0x5557ce73 , std::allocator > const&)+83>: mov%rbx,%rdi 0x5557de73 , std::allocator > const&)+179>: je 0x5557df30 , std::allocator > const&)+368> 0x5558ae73 >::operator=(std::vector > const&)+35>: mov(%rsi),%rbx 0x5558de73 : test %r14b,%r14b 0x5558fe73 :mov $0x16,%edx 0x55593e73 :nopl 0x0(%rax,%rax,1) 0x5559ae73 :je 0x5559899e 0x5559be73 :mov0x5b0(%rsp),%rdi 0x555aae73 > > >, std::_Select1st > > > >, std::less, std::allocator > > > > >::_M_erase(std::_Rb_tree_node > > > >*)+35>:mov 0x30(%rbp),%rbx 0x555abe73 : lea0x10(%rbx),%rax 0x555aee73 :push %rbp 0x555b0e73 : mov%r15,%rdi 0x555b3e73 : add$0x1,%rbx 0x555b6e73 : callq 0x55563400 <_ZdlPv@plt> 0x555bce73 : mov 0xe8(%rsp),%rdx 0x555c3e73 : movb $0x0,0x26(%rsp) 0x555c8e73 : rep stos %rax,%es:(%rdi) 0x555cbe73 : mov%rbx,%r9 0x555cee73 : callq 0x55581940 , std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&)> 0x555cfe73 :mov%r13,0x1e0(%rsp) 0x555d4e73 , std::allocator >, std::__cxx11::basic_string, std::allocator >, std::_Identity, std::allocator > >, std::less, std::allocator > >, std::allocator, std::allocator > >
Bug#946699: wine: Lotus Notes 6.5 font drop down list corrupt after upgrade to buster
Hello Wolfgang, could you please count how many true type fonts you have installed, e.g. by 'find /usr/share/fonts/truetype -iname "*.ttf" | wc -l'. Because in a minimal test environment the application started to behave strange after that number went over ~1250. That test was done with these debian packages and problem started after the latter: ttf-mscorefonts-installer fonts-noto-extra When moving half of the files out of the directory /usr/share/fonts/truetype/noto (to e.g. /root) the application could work, also when swapping the halfes of that directory. If staying just a little above 1250 then the font list got scrambled like in your first picture. With all fonts it is getting more likely to just hang or receive the message: Sorry, an uncorrectable error has occurred. LookupHandle: null handle Press ENTER to abort the application. I assume you have the package fonts-noto-extra installed, but could you try to uninstall it, if no other packages depend on it and the fonts are not needed otherwise. This package alone has 1224 TTF files. If this can be confirmed I guess this is just an application bug and wine can not do much about it. This links seem to describe a similar issue [1] with newer versions of the application. Kind regards, Bernhard [1] http://blog.nashcom.de/nashcomblog.nsf/dx/notes-910-standard-client-issues-in-combination-wth-libreoffice-6-installed-fonts-noto.htm?opendocument https://atnotes.de/index.php?topic=62177.20 # Buster/stable i386 qemu VM 2019-12-17 # + contrib apt update apt dist-upgrade apt install systemd-coredump xserver-xorg sddm openbox xterm mc valgrind wine wine32-dbgsym libwine-dbgsym libfreetype6-dbgsym ttf-mscorefonts-installer fonts-noto-extra apt install fonts-noto-extra reboot benutzer@debian:~$ wine --version wine-4.0 (Debian 4.0-2) export DISPLAY=:0 wine wineboot wine c53d7na-win-all-clients-r65.exe cd .wine/drive_c/Program\ Files/lotus/notes/ wine notes.exe script -c "valgrind --num-callers=30 --trace-children=yes --vex-iropt-register-updates=allregs-at-mem-access --error-limit=no wine notes.exe; xterm" -a "/home/benutzer/wine_$(date +%Y-%m-%d_%H-%M-%S).log" script -c "WINEDEBUG=+pid,+tid,+timestamp,+font,+seh wine notes.exe; xterm" -a "/home/benutzer/wine_$(date +%Y-%m-%d_%H-%M-%S).log" winedbg info proc attach 0x29 wineserver -k find /usr/share/fonts/truetype -iname "*.ttf" | wc -l 1310
Bug#939846: xymon: xymonnet segfaults (and completely stops working) if any URL to check is IPv6-only
Dear Maintainer,
I just tried to reproduce the crash but did not get it.
Maybe some more details of the configuration details of
host.cfg and DNS server setup could help,
because in my test I never reached with my IPv6 config
the faulting instruction.
At least the instruction, at that address where the segfault is received,
leads to the assumption that hent->h_addr_list is not a valid pointer
for some reason.
A workaround could be to check if the DNS result is IPv4.
I guess following could achieve this:
dns.c:119:
- if (status == ARES_SUCCESS) {
+ if (status == ARES_SUCCESS && hent->h_addrtype == AF_INET &&
hent->h_addr_list) {
But more insight could maybe give someone experiencing the crash
by forwarding the output of following in the dns_simple_callback frame:
print *hent
x/1gx *(hent->h_addr_list)
x/4ub *(hent->h_addr_list)
And maybe a 'bt full' should contain a part of the UDP response.
Kind regards,
Bernhard
(gdb) disassemble /m dns_simple_callback
Dump of assembler code for function dns_simple_callback:
111 {
0x55569ab0 <+0>: push %r13
0x55569ab2 <+2>: push %r12
0x55569ab4 <+4>: mov%rcx,%r13
# store address of hent into $r13
0x55569ab7 <+7>: push %rbp
0x55569ab8 <+8>: push %rbx
0x55569ab9 <+9>: mov%rdi,%rbx
0x55569abc <+12>:mov%esi,%ebp
0x55569abe <+14>:sub$0x28,%rsp
0x55569ac5 <+21>:mov%fs:0x28,%rax
0x55569ace <+30>:mov%rax,0x18(%rsp)
0x55569ad3 <+35>:xor%eax,%eax
112 struct dnsitem_t *dnsc = (dnsitem_t *)arg;
113 struct timespec etime;
114
115 getntimer();
0x55569ac2 <+18>:mov%rsp,%rdi
0x55569ad5 <+37>:callq 0x5556c030
116 tvdiff(>resolvetime, , >resolvetime);
0x55569ada <+42>:lea0x20(%rbx),%rdi
0x55569ade <+46>:mov%rsp,%rsi
0x55569ae1 <+49>:mov%rdi,%rdx
0x55569ae4 <+52>:callq 0x55578790
117 pending_dns_count--;
0x55569ae9 <+57>:subl $0x1,0x2287d8(%rip)#
0x557922c8
118
119 if (status == ARES_SUCCESS) {
0x55569af0 <+64>:test %ebp,%ebp
0x55569af2 <+66>:jne0x55569b30
120 memcpy(>addr, *(hent->h_addr_list),
sizeof(dnsc->addr));
0x55569af4 <+68>:mov0x18(%r13),%rax
# store address hent->h_addr_list points to into
$rax
121 dbgprintf("Got DNS result for host %s : %s\n",
dnsc->name, inet_ntoa(dnsc->addr));
0x55569af8 <+72>:mov0x228dc2(%rip),%edx#
0x557928c0
0x55569afe <+78>:mov(%rax),%rax
0x55569b01 <+81>:test %edx,%edx
=> 0x55569b03 <+83>:mov(%rax),%edi
# store address pointed to by hent->h_addr into $edi
0x55569b08 <+88>:jne0x55569b88
(gdb) print/x $r13
$27 = 0x557bd4d0
(gdb) print hent
$28 = (struct hostent *) 0x557bd4d0
(gdb) x/1xg $r13 + 0x18
0x557bd4e8: 0x557a8560
(gdb) print hent->h_addr_list
$32 = (char **) 0x557a8560
(gdb) x/1xg hent->h_addr_list
0x557a8560: 0x557a8220
(gdb) print/x $rax
$33 = 0x557a8220
(gdb) x/4ub *(hent->h_addr_list)
0x557a8220: 192 168 240 240
Bug#946699: wine: Lotus Notes 6.5 font drop down list corrupt after upgrade to buster
Hello Wolfgang, Am 16.12.19 um 18:18 schrieb Wolfgang Rosner: > -8<--- > script: Ungültige Option > -- Try 'script --help' for more information. > -8<--- Sorry, there was a -a too much inside the quotation marks. > I get a log file of 13 MB in Size. > Notes displays its splash screen, but then finishes. > I found many fonts not displayed in notes, but no single trace of those > corrupt font names listed in the Notes client. Found also nothing obvious in the output, but maybe to be expected when the point showing the dropdown was not reached. > May I suspect that the sheer number of fonts may cause some kind of > index overrun in 20 year old Lotus Notes? Maybe one plausible explanation. >> /home/user/wine-4.20/wine notepad.exe > But to my impression, this only keeps binaries in sync, not prefixes, > not fonts. >> export WINEPREFIX=/home/user/wine-prefix-for-test > But how can I set up a pristine wineprefix with pristine minimal font > configuration, matching the version in test? > > Sorry, I know, that's a question for the wine forum. > Or gidf before. Both combined should create a wine-prefix populated by the self-built wine, I guess. Oh and what I forgot in my last email - to properly separate things, you could create a different system user. Grüße in den Nachbarlandkreis :-) Bernhard
Bug#946699: wine: Lotus Notes 6.5 font drop down list corrupt after upgrade to buster
Hello Wolfgang, Am 16.12.19 um 11:42 schrieb Wolfgang Rosner: > Hi Bernhard, > > Thanks for the debug instructions. > > I'll go to try them, maybe the next weekend. > > Notes is an essential tool of my daily work, so extended trials block > me from productive offfice work for some hours, since I don't have a > separate testing environment. > > I managed to finish builds of wine 1.8.7 ( --without-freetype) and > wine-4.21 on my box. Next step is to figure out how I could set up a > different sandbox style testing not only for the binaries, but also the > prefix skeletons and the fonts. So haven't done 'make install' yet. Normally it should be possible to run wine from the build directory, therefore should not be needed to install it. E.g.: /home/user/wine-4.20/wine notepad.exe > One thing on my suspicion list may be broken version contingencies in > the wine prefixes and/or the font installation in use. > Anytime I run a prefix with a different wine version > I get some window mentioning sth. like "registry upgrade". > Would be glad to have a clue what's going on there. If wine detects a change in wine version a prefix was run last time and now, it tries to update that prefix. Therefore, if you have important applications in your prefix, I would suggest to minimize the wine version changes to that prefix. If you want to just test something you can use WINEPREFIX for a different wine environment, e.g.: export WINEPREFIX=/home/user/wine-prefix-for-test > I know the bug list is not the proper place for help questions, but a > hint where to find those issues explained would nevertheless help > to speed up the process of bug fixing. Do you mean something like these: https://bugs.winehq.org/ https://forums.winehq.org/ > Regarding trial installation sources: > 20 years back in "good old" IBM times they were quite relaxed with > public availability of installation sources for trial purposes. > This seems to have changed, as I found in a search for a more recent > notes version. So I don't dare to make one publicly available. > > It's a 125 MB exe file, What is the name of that file? Kind regards, Bernhard
Bug#942737: libapache2-mod-gnutls: mod_gnutls consumes 100% cpu
Dear Maintainer, tried to reconstruct the given backtrace with debug symbols in a gdb session and came to following, maybe it could be of some help. (Still a proper backtrace with dbgsym packages installed would be better.) Kind regards, Bernhard Reconstructed: #0 0x7f78b4cfb92f in gnutls_assert_val_int at ../../lib/errors.h:139 from libgnutls.so.30 #1 0x7f78b4cfdf7c in _gnutls_recv_int at ../../lib/record.c:1773 from libgnutls.so.30 in gnutls_record_recv at ../../lib/record.c:2281 #2 0x7f78b4e90f38 in gnutls_io_input_read at gnutls_io.c:246 from mod_gnutls.so #3 0x7f78b4e91ad2 in gnutls_io_input_getline at gnutls_io.c:342 from mod_gnutls.so in mgs_filter_input at gnutls_io.c:595 in ap_get_brigade at util_filter.c:553 #4 0x55c220cd08e1 in ap_rgetline_core at protocol.c:246 #5 0x55c220cd336c in read_request_line at protocol.c:682 in ap_read_request at protocol.c:1322 #6 0x55c220cfe7a8 in ap_process_http_sync_connection at http_core.c:192 #7 0x55c220cf38b0 in ap_run_process_connection at connection.c:42 in ap_process_connection at connection.c:219 #8 0x7f78b3bd23df in child_main at prefork.c:615 from mod_mpm_prefork.so #9 0x7f78b3bd26d4 in make_child at prefork.c:717 from mod_mpm_prefork.so #10 0x7f78b3bd272f in startup_children at prefork.c:735 from mod_mpm_prefork.so #11 0x7f78b3bd32f3 in prefork_run at prefork.c:897 from mod_mpm_prefork.so #12 0x55c220ccc67e in ap_run_mpm at mpm_common.c:94 #13 0x55c220cc4f57 in main at main.c:819
Bug#946699: wine: Lotus Notes 6.5 font drop down list corrupt after upgrade to buster
Hello Wolfgang, I am not involved in packaging wine in debian, but may have some hints. Unfortunately I could not find any download for a trial version, is there one known? Otherwise this can just be debugged by users having access to that software. Then a file containing some more output could be of some help. E.g. start from a terminal the application similar to this: cd "/home/user/.wine/drive_c/path/to/application" script -c "WINEDEBUG=+pid,+tid,+timestamp,+font wine 'application.exe'" -a "-a ~/wine_$(date +%Y-%m-%d_%H-%M-%S).log" Such a file should contain all API calls to windows font functions, maybe that would already show something. As you tested already WineHQ packages too, and these showed the same error you might also go ahead an open an upstream bug there. (If you do so please send here the bug number too.) Kind regards, Bernhard
Bug#946714: gimp: GIMP crashed with a fatal error when a was editing an image
Hello Jesús, > Version: 2.10.12-0.1~mx19+1 Could not find a dbgsym package for that gimp version. Is your system a MX Linux installation or a plain Debian? At least in the first case, I guess, the MX Linux forums can give better support. And if the crash is reproducible it would help if you could describe in detail the steps leading to the crash. Kind regards, Bernhard
Bug#943335: aeolus throws std::bad_alloc on first launch
Dear Maintainer, I tried to have a look at this issue. I got this also on amd64 [2]. It looks like this is related to aeolus requesting its memory never getting swapped out. [1] Without this line a process does not give this fault. But there is a "max locked memory" of 65536 kbytes in place (ulimit -a). Unfortunately aeolus need this limit at least raised to 85000 kbytes. I tested to raise this limit by doing following changes: /etc/security/limits.conf *- memlock 10 /etc/pam.d/common-session session required pam_limits.so Kind regards, Bernhard [1] main.cc:195 if (mlockall (MCL_CURRENT | MCL_FUTURE)) fprintf (stderr, "Warning: memory lock failed.\n"); [2] (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x7f185578f535 in __GI_abort () at abort.c:79 #2 0x7f1855b57983 in __gnu_cxx::__verbose_terminate_handler () at ../../../../src/libstdc++-v3/libsupc++/vterminate.cc:95 #3 0x7f1855b5d8c6 in __cxxabiv1::__terminate (handler=) at ../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:47 #4 0x7f1855b5d901 in std::terminate () at ../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:57 #5 0x7f1855b5db34 in __cxxabiv1::__cxa_throw (obj=, tinfo=0x7f1855c40690 , dest=0x7f1855b5be60 ) at ../../../../src/libstdc++-v3/libsupc++/eh_throw.cc:95 #6 0x7f1855b5e01c in operator new (sz=sz@entry=13004) at /build/gcc-8-Ev0Tjh/gcc-8-8.3.0/build/x86_64-linux-gnu/libstdc++-v3/include/bits/exception.h:63 #7 0x7f1855b5e075 in operator new[] (sz=sz@entry=13004) at ../../../../src/libstdc++-v3/libsupc++/new_opv.cc:32 #8 0x561c3ea56477 in Pipewave::genwave (this=this@entry=0x7f18526c44a8, D=D@entry=0x7f1854328010, n=, fsamp=fsamp@entry=48000, fpipe=) at rankwave.cc:225 #9 0x561c3ea5771b in Rankwave::gen_waves (this=0x7f1854269010, D=0x7f1854328010, fsamp=48000, fbase=263.181396, scale=0x561c3ec5e2e0 ) at rankwave.cc:414 #10 0x561c3ea5015c in Slave::thr_main (this=0x561c40190d00) at slave.cc:53 #11 0x7f1855f9ba3a in P_thread_entry_point (arg=) at p_thread.cc:38 #12 0x7f1855c5dfa3 in start_thread (arg=) at pthread_create.c:486 #13 0x7f18558664cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Bug#946641: stops: Mark stops as 'Multi-Arch: foreign'
Hello Daniel, Am 12.12.19 um 18:27 schrieb Daniel James: > Hi Bernhard, >> Marking stops as 'Multi-Arch: foreign' should make >> that installation possible. > > The package 'stops' contains binary instrument data, which as far as I > know, is uniquely created by the undocumented and well-hidden instrument > editor feature in aeolus (hold down Ctrl then left-mouse-click on any > stop in the aeolus GUI to open the instrument editor). > > This instrument data works fine when copied to Debian systems running > other arches (I have tested amd64 -> armhf). That's great to hear, as far as I understand you, the package does not contain architecture dependent data, so the proposed change should be no problem. Kind regards, Bernhard
Bug#946639: iwd 1.2-1 is crashing making WiFi access impossible
Control: tags -1 + upstream fixed-upstream patch Dear Maintainer, I tried to have a look at this crash and I guess I found something. The "Code:" sequence points to src/scan.c:1706. There it seems like variable sr got a null pointer and therefore the assignment crashes. (gdb) list src/scan.c:1700,src/scan.c:1710 1700case NL80211_CMD_TRIGGER_SCAN: 1701if (active_scan) 1702sc->state = SCAN_STATE_ACTIVE; 1703else 1704sc->state = SCAN_STATE_PASSIVE; 1705 1706sr->start_time_tsf = start_time_tsf; 1707 1708break; 1709 1710case NL80211_CMD_SCAN_ABORTED: Upstream git [1] has a fix committed. Kind regards, Bernhard https://git.kernel.org/pub/scm/network/wireless/iwd.git/commit/src/scan.c?id=d2556a48b7d65eb670fb0ce20e3f929bf9839a20
Bug#946639: iwd 1.2-1 is crashing making WiFi access impossible
(Forgot to attach some more debugging details.)
From submitter
Dec 12 09:40:11 lambda kernel: [55486.381334] iwd[202645]: segfault at 38 ip
55b1995e2056 sp 7ffc966c5360 error 6 in iwd[55b1995c4000+84000]
Dec 12 09:40:11 lambda kernel: [55486.381374] Code: 48 83 c4 20 e9 58 fe ff ff
0f 1f 00 3c 21 0f 85 70 ff ff ff 31 c0 80 7c 24 10 00 0f 95 c0 83 c0 01 41 89
47 08 48 8b 44 24 18 <49> 89 46 38 e9 51 ff ff ff 90 41 8b 77 08 85 f6 0f 84 44
ff ff ff
/*
* 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 6" == 0x6 == 0b110
bit 0 == 0: no page found
bit 1 == 1: write access
bit 2 == 1: user-mode access
bit 3 == 0:
bit 4 == 0:
bit 5 == 0:
#
# Bullseye/testing amd64 qemu VM 2019-12-12
apt update
apt dist-upgrade
apt install systemd-coredump mc gdb iwd iwd-dbgsym
apt build-dep iwd
mkdir /home/benutzer/source/iwd/orig -p
cd/home/benutzer/source/iwd/orig
apt source iwd
cd
gdb -q --args /usr/libexec/iwd
set width 0
set pagination off
directory /home/benutzer/source/iwd/orig/iwd-1.2
b main
run
dele 1
(gdb) info target
...
0xe830 - 0x555e1001 is .text
...
(gdb) find /b 0xe830, 0x555e1001, 0x48, 0x83, 0xc4, 0x20,
0xe9, 0x58, 0xfe, 0xff, 0xff, 0x0f, 0x1f, 0x00, 0x3c, 0x21, 0x0f, 0x85, 0x70,
0xff, 0xff, 0xff, 0x31, 0xc0, 0x80, 0x7c, 0x24, 0x10, 0x00, 0x0f, 0x95, 0xc0,
0x83, 0xc0, 0x01, 0x41, 0x89, 0x47, 0x08, 0x48, 0x8b, 0x44, 0x24, 0x18, 0x49,
0x89, 0x46, 0x38, 0xe9, 0x51, 0xff, 0xff, 0xff, 0x90, 0x41, 0x8b, 0x77, 0x08,
0x85, 0xf6, 0x0f, 0x84, 0x44, 0xff, 0xff, 0xff
0x5557c02c
1 pattern found.
(gdb) b *0x5557c02c+42
Breakpoint 2 at 0x5557c056: file src/scan.c, line 1706.
(gdb) info b
Num Type Disp Enb AddressWhat
2 breakpoint keep y 0x5557c056 in scan_notify at
src/scan.c:1706
(gdb) disassemble /r scan_notify
Dump of assembler code for function scan_notify:
0x5557be50 <+0>: 41 57 push %r15
...
0x5557c027 <+471>: e8 d4 ae 03 00 callq 0x555b6f00
0x5557c02c <+476>: 48 83 c4 20 add$0x20,%rsp
0x5557c030 <+480>: e9 58 fe ff ff jmpq 0x5557be8d
0x5557c035 <+485>: 0f 1f 00nopl (%rax)
0x5557c038 <+488>: 3c 21 cmp$0x21,%al
0x5557c03a <+490>: 0f 85 70 ff ff ff jne0x5557bfb0
0x5557c040 <+496>: 31 c0 xor%eax,%eax
0x5557c042 <+498>: 80 7c 24 10 00 cmpb $0x0,0x10(%rsp)
0x5557c047 <+503>: 0f 95 c0setne %al
0x5557c04a <+506>: 83 c0 01add$0x1,%eax
0x5557c04d <+509>: 41 89 47 08 mov%eax,0x8(%r15)
0x5557c051 <+513>: 48 8b 44 24 18 mov0x18(%rsp),%rax
0x5557c056 <+518>: 49 89 46 38 mov%rax,0x38(%r14)
<
0x5557c05a <+522>: e9 51 ff ff ff jmpq 0x5557bfb0
0x5557c05f <+527>: 90 nop
0x5557c060 <+528>: 41 8b 77 08 mov0x8(%r15),%esi
0x5557c064 <+532>: 85 f6 test %esi,%esi
0x5557c066 <+534>: 0f 84 44 ff ff ff je 0x5557bfb0
0x5557c06c <+540>: 41 0f b6 47 58 movzbl 0x58(%r15),%eax
...
0x5557c2ff <+1199>: e8 4c 1f fe ff callq 0xe250
<__stack_chk_fail@plt>
End of assembler dump.
(gdb) list src/scan.c:1700,src/scan.c:1710
1700case NL80211_CMD_TRIGGER_SCAN:
1701if (active_scan)
1702sc->state = SCAN_STATE_ACTIVE;
1703else
1704sc->state = SCAN_STATE_PASSIVE;
1705
1706sr->start_time_tsf = start_time_tsf;
1707
1708break;
1709
1710case NL80211_CMD_SCAN_ABORTED:
(gdb) ptype struct scan_request
type = struct scan_request {
Bug#946641: stops: Mark stops as 'Multi-Arch: foreign'
Package: stops Version: 0.3.0-2 Severity: wishlist Dear Maintainer, I was trying to look at 943335, tried to look at it with the rr debugger which is in the archive just for amd64. Therefore tried to install aeolus:i386 which required a package stops:i386. Marking stops as 'Multi-Arch: foreign' should make that installation possible. Kind regards, Bernhard -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/4 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 stops depends on no packages. Versions of packages stops recommends: ii aeolus 0.9.5-1 stops suggests no packages. -- no debconf information
Bug#942257: phonon-backend-gstreamer: Cannot upgrade phonon-backend-gstreamer-common to 4:4.9.1-2, this package requires 4:4.9.1-1
Control: tags -1 - upstream Hello Felix, maybe the information from following bug is relevant in this case too. https://bugs.debian.org/942860 Kind regards, Bernhard
Bug#942860: 942860: phonon: no functional current backend
Hello Karl, I am not involved in the packaging of phonon, but still a few questions. Have you any Qt4 applications installed? Because src:phonon in version 4:4.10.3-2 was the last version that built the Qt4 parts. Since src:phonon 4:4.10.3-3 just the Qt5 packages get build anymore. And therefore I guess phonon and phonon-backend got replaced by phonon4qt5 and phonon4qt5-backend some time ago. Maybe there should exist a transitional package for upgrading phonon to phonon4qt5? Kind regards, Bernhard
Bug#944017: libsoxr: autopkgtest regression: segmentation fault
Hello Adrian, hello Paul, I could reproduce the issue in a minimal revertable Unstable qemu VM with this command: /usr/bin/autopkgtest libsoxr -- null As far as I see the test is called this way: src/debian/tests/inst-check src/inst-check src/inst-check-soxr $gen# line 43, generates test data $tmp/3-options-input-fn # line 43, run test In the end it runs: dd if=/dev/urandom count=1000 | /tmp/tmp.bQI47Dtfhv/4-split-channels 7 6 2 2 3 Unfortunately the "inst-check" runs just in the autopkgtest, but not at build time. All debugging attempts led me to the location below. And the lines soxr.c:664 and soxr.c:786 point to the fix-unaligned-access.patch introduced in bug #942746. When a packages are installed without this patch the autopkgtest gets not segfault. Kind regards, Bernhard Thread 1 received signal SIGTRAP, Trace/breakpoint trap. 0x0485210a in lsx_rint16_clip_dither_f (seed0=0x4c51500, n=6735, src=0x4ca4270, dest0=0x4c241a0) at ./src/rint-clip.h:67 67 DO_16; (gdb) bt #0 0x0485210a in lsx_rint16_clip_dither_f (seed0=0x4c51500, n=6735, src=0x4ca4270, dest0=0x4c241a0) at ./src/rint-clip.h:67 #1 _soxr_interleave_f (data_type=, dest0=0x4c241a0, src=, n=6735, ch=1, seed=0x4c51500) at ./src/data-io.c:213 #2 0x0484d60f in soxr_output_1ch (p=p@entry=0x4c513e0, i=0, dest=dest@entry=0x4c24100, len=, len@entry=6923, separated=separated@entry=true) at ./src/soxr.c:664 #3 0x0484d8cc in soxr_process._omp_fn.0 () at ./src/soxr.c:786 #4 0x04bcaa42 in GOMP_parallel (fn=0x484d830 , data=0x1fff000800, num_threads=4, flags=0) at ../../../src/libgomp/parallel.c:171 #5 0x0484ef78 in soxr_process (p=0x4c513e0, in=0x4c24150, ilen0=, idone0=0x0, out=0x4c24100, olen=6923, odone0=0x1fff0008a8) at ./src/soxr.c:781 #6 0x00109fd8 in main (n=0, arg=0x1fff000b28) at 4-split-channels.c:142 # Unstable amd64 qemu VM 2019-12-12 apt update apt dist-upgrade apt install systemd-coredump mc autopkgtest quilt gdb rr valgrind libgomp1-dbgsym libsoxr0-dbgsym apt build-dep libsoxr ## root@debian:~# autopkgtest libsoxr -- null ... /tmp/tmp.LScD5ODKNY/3-options-input-fn no error; 0 clips; I/O: no error (cr32s) Segmentation fault (core dumped) autopkgtest [00:22:20]: test inst-check: ---] autopkgtest [00:22:21]: test inst-check: - - - - - - - - - - results - - - - - - - - - - inst-check FAIL non-zero exit status 139 autopkgtest [00:22:21]: test inst-check: - - - - - - - - - - stderr - - - - - - - - - - Segmentation fault (core dumped) ... root@debian:~# coredumpctl list TIMEPID UID GID SIG COREFILE EXE Thu 2019-12-12 00:22:20 CET2744 0 0 11 present /tmp/tmp.LScD5ODKNY/4-split-channels root@debian:~# journalctl --no-pager Dez 12 00:22:20 debian kernel: 4-split-channel[2745]: segfault at 0 ip 7f17b31ec10a sp 7f17b2e79c50 error 6 in libsoxr.so.0.1.2[7f17b31e7000+28000] Dez 12 00:22:20 debian kernel: Code: d0 48 89 94 24 d0 00 00 00 49 c1 e8 06 41 83 e0 1f 44 29 c7 f2 0f 2a c7 f2 0f 59 c1 f2 0f 58 c2 f2 0f 11 44 24 08 dd 44 24 08 <41> df 1e 48 89 c7 66 0f ef c0 66 0f ef d2 49 89 d0 48 c1 ef 09 49 Dez 12 00:22:20 debian systemd[1]: Created slice system-systemd\x2dcoredump.slice. Dez 12 00:22:20 debian systemd[1]: Started Process Core Dump (PID 2756/UID 0). Dez 12 00:22:20 debian su[2651]: pam_unix(su:session): session closed for user root Dez 12 00:22:20 debian systemd-coredump[2757]: Process 2744 (4-split-channel) of user 0 dumped core. Stack trace of thread 2745: #0 0x7f17b31ec10a n/a (libsoxr.so.0 + 0x910a) #1 0x7f17b31e760f n/a (libsoxr.so.0 + 0x460f) #2 0x7f17b31e78cc n/a (libsoxr.so.0 + 0x48cc) #3 0x7f17b2ec0946 n/a (libgomp.so.1 + 0x1a946) #4 0x7f17b2e88fb7 start_thread (libpthread.so.0 + 0x8fb7) #5 0x7f17b311d2df __clone (libc.so.6 + 0xfa2df) Stack trace of thread 2753: #0 0x7f17b2ec32aa n/a (libgomp.so.1 + 0x1d2aa) #1 0x7f17b2ec0952 n/a (libgomp.so.1 + 0x1a952) #2 0x7f17b2e88fb7 start_thread (libpthread.so.0 + 0x8fb7) #3 0x7f17b311d2df __clone (libc.so.6 + 0xfa2df)
Bug#946606: libc-bin: catchsegv does not handle backtraces with parentheses
Dear Maintainer,
sorry, did attempt to output the build-id unconditionally,
fixed in attached patch version.
Kind regards,
Bernhard
>From 0a4a73d4eeaa45acdbeb6ea8fea878e134cbc11b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?=
Date: Wed, 11 Dec 2019 19:56:39 +0100
Subject: Make catchsegv work again after format changed and add build-ids.
https://sourceware.org/bugzilla/show_bug.cgi?id=21830
---
debug/backtracesymsfd.c | 32 +-
debug/catchsegv.sh | 50 -
2 files changed, 70 insertions(+), 12 deletions(-)
diff --git a/debug/backtracesymsfd.c b/debug/backtracesymsfd.c
index 5751d62f..9bc058fb 100644
--- a/debug/backtracesymsfd.c
+++ b/debug/backtracesymsfd.c
@@ -35,13 +35,14 @@
void
__backtrace_symbols_fd (void *const *array, int size, int fd)
{
- struct iovec iov[9];
+ struct iovec iov[12];
int cnt;
for (cnt = 0; cnt < size; ++cnt)
{
char buf[WORD_WIDTH];
char buf2[WORD_WIDTH];
+ char buf3[WORD_WIDTH];
Dl_info info;
struct link_map *map;
size_t last = 0;
@@ -96,6 +97,35 @@ __backtrace_symbols_fd (void *const *array, int size, int fd)
- (char *) iov[last].iov_base);
++last;
+ /* Even when we have a symbol name, print the file offset to
+ make processing in addr2line possible. */
+ if (info.dli_sname != NULL)
+ {
+ iov[last].iov_base = (void *) ",";
+ iov[last].iov_len = 1;
+ ++last;
+
+ if (array[cnt] >= (void *) map->l_addr)
+ {
+ iov[last].iov_base = (void *) "+0x";
+ diff = array[cnt] - (void *) map->l_addr;
+ }
+ else
+ {
+ iov[last].iov_base = (void *) "-0x";
+ diff = (void *) map->l_addr - array[cnt];
+ }
+ iov[last].iov_len = 3;
+ ++last;
+
+ iov[last].iov_base = _itoa_word ((unsigned long int) diff,
+ [WORD_WIDTH], 16, 0);
+ iov[last].iov_len = ([WORD_WIDTH]
+ - (char *) iov[last].iov_base);
+ ++last;
+
+ }
+
iov[last].iov_base = (void *) ")";
iov[last].iov_len = 1;
++last;
diff --git a/debug/catchsegv.sh b/debug/catchsegv.sh
index 245c100f..fd6a232a 100755
--- a/debug/catchsegv.sh
+++ b/debug/catchsegv.sh
@@ -52,6 +52,7 @@ Written by Ulrich Drepper.'
fi
segv_output=`mktemp ${TMPDIR:-/tmp}/segv_output.XX` || exit
+used_libs=`mktemp ${TMPDIR:-/tmp}/used_libs.XX` || exit
# Redirect stderr to avoid termination message from shell.
(exec 3>&2 2>/dev/null
@@ -87,21 +88,48 @@ if test -s "$segv_output"; then
sed '/Backtrace/q' "$segv_output"
sed '1,/Backtrace/d' "$segv_output" |
(while read line; do
- line=`echo $line | sed "s@^$prog\\(\\[.*\\)@\1@"`
case "$line" in
- \[*) addr=`echo "$line" | sed 's/^\[\(.*\)\]$/\1/'`
- complete=`addr2line -f -e "$prog" $addr 2>/dev/null`
- if test $? -eq 0; then
- echo "`echo "$complete"|sed 'N;s/\(.*\)\n\(.*\)/\2(\1)/;'`$line"
- else
- echo "$line"
- fi
- ;;
- *) echo "$line"
- ;;
+ *\(*\)\[*\])
+ lib=`echo $line | sed "s@^\(.*\)(\(.*\))\[\(.*\)\]\\$@\1@"`
+ offs=`echo $line | sed "s@^\(.*\)(\(.*\))\[\(.*\)\]\\$@\2@"`
+ addr=`echo $line | sed "s@^\(.*\)(\(.*\))\[\(.*\)\]\\$@\3@"`
+ func=""
+ case "$offs" in
+ *,*) func=`echo $offs | sed "s@\(.*\),\(.*\)\\$@\1,@"`
+offs=`echo $offs | sed "s@\(.*\),\(.*\)\\$@\2@"`
+;;
+ esac
+ case "$offs" in
+ +*) case "$prog" in
+ */$lib)
+ lib="$prog"
+ ;;
+ esac
+ complete=`addr2line -p -i -f -e "$lib" $offs 2>/dev/null`
+ if test $? -eq 0; then
+ echo " [$addr] $complete $lib($func$offs)"
+ else
+ echo " $line"
+ fi
+ ;;
+ *) echo " $line"
+ ;;
+ esac
+ echo "$lib" >> "$used_libs"
+ ;;
+*) echo "$line"
+ ;;
esac
done)
+ objdumptest=`objdump --version 2>/dev/null`
+ if test $? -eq 0; then
+echo "\nBuild-IDs:"
+sort -u "$used_libs" | while read lib; do
+ objdump -s -j .note.gnu.build-id "$lib"
+done
+ fi
fi
rm -f "$segv_output"
+rm -f "$used_libs"
exit $exval
--
2.24.0
Bug#946606: libc-bin: catchsegv does not handle backtraces with parentheses
Dear Maintainer,
while I was at it, I attempted to change the output to
deliver the before mentioned information for addr2line too.
Attached is a improved patch, that would now output following:
Backtrace:
[0x55f317f9175b] main at
/usr/share/doc/libsoxr-dev/examples/3-options-input-fn.c:79 (discriminator 4)
/tmp/tmp.sSrfzsTKpn/3-options-input-fn(+0x175b)
[0x7fd67920fbbb] __libc_start_main at
/root/source/glibc/try1/glibc-2.29/csu/../csu/libc-start.c:342
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb,+0x26bbb)
[0x55f317f911ba] _start at ??:? /tmp/tmp.sSrfzsTKpn/3-options-input-fn(+0x11ba)
At the end there is another small change to add the build-ids
of the in the backtrace involved binaries to the output.
Kind regards,
Bernhard
>From cb1fdbd4e5a7fbeb1de27b72a7945a0b4789d251 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?=
Date: Wed, 11 Dec 2019 19:56:39 +0100
Subject: Make catchsegv work again after format changed and add build-ids.
https://sourceware.org/bugzilla/show_bug.cgi?id=21830
---
debug/backtracesymsfd.c | 32 +-
debug/catchsegv.sh | 51 -
2 files changed, 71 insertions(+), 12 deletions(-)
diff --git a/debug/backtracesymsfd.c b/debug/backtracesymsfd.c
index 5751d62f..9bc058fb 100644
--- a/debug/backtracesymsfd.c
+++ b/debug/backtracesymsfd.c
@@ -35,13 +35,14 @@
void
__backtrace_symbols_fd (void *const *array, int size, int fd)
{
- struct iovec iov[9];
+ struct iovec iov[12];
int cnt;
for (cnt = 0; cnt < size; ++cnt)
{
char buf[WORD_WIDTH];
char buf2[WORD_WIDTH];
+ char buf3[WORD_WIDTH];
Dl_info info;
struct link_map *map;
size_t last = 0;
@@ -96,6 +97,35 @@ __backtrace_symbols_fd (void *const *array, int size, int fd)
- (char *) iov[last].iov_base);
++last;
+ /* Even when we have a symbol name, print the file offset to
+ make processing in addr2line possible. */
+ if (info.dli_sname != NULL)
+ {
+ iov[last].iov_base = (void *) ",";
+ iov[last].iov_len = 1;
+ ++last;
+
+ if (array[cnt] >= (void *) map->l_addr)
+ {
+ iov[last].iov_base = (void *) "+0x";
+ diff = array[cnt] - (void *) map->l_addr;
+ }
+ else
+ {
+ iov[last].iov_base = (void *) "-0x";
+ diff = (void *) map->l_addr - array[cnt];
+ }
+ iov[last].iov_len = 3;
+ ++last;
+
+ iov[last].iov_base = _itoa_word ((unsigned long int) diff,
+ [WORD_WIDTH], 16, 0);
+ iov[last].iov_len = ([WORD_WIDTH]
+ - (char *) iov[last].iov_base);
+ ++last;
+
+ }
+
iov[last].iov_base = (void *) ")";
iov[last].iov_len = 1;
++last;
diff --git a/debug/catchsegv.sh b/debug/catchsegv.sh
index 245c100f..8d8a38f0 100755
--- a/debug/catchsegv.sh
+++ b/debug/catchsegv.sh
@@ -52,6 +52,7 @@ Written by Ulrich Drepper.'
fi
segv_output=`mktemp ${TMPDIR:-/tmp}/segv_output.XX` || exit
+used_libs=`mktemp ${TMPDIR:-/tmp}/used_libs.XX` || exit
# Redirect stderr to avoid termination message from shell.
(exec 3>&2 2>/dev/null
@@ -87,21 +88,49 @@ if test -s "$segv_output"; then
sed '/Backtrace/q' "$segv_output"
sed '1,/Backtrace/d' "$segv_output" |
(while read line; do
- line=`echo $line | sed "s@^$prog\\(\\[.*\\)@\1@"`
case "$line" in
- \[*) addr=`echo "$line" | sed 's/^\[\(.*\)\]$/\1/'`
- complete=`addr2line -f -e "$prog" $addr 2>/dev/null`
- if test $? -eq 0; then
- echo "`echo "$complete"|sed 'N;s/\(.*\)\n\(.*\)/\2(\1)/;'`$line"
- else
- echo "$line"
- fi
- ;;
- *) echo "$line"
- ;;
+ *\(*\)\[*\])
+ lib=`echo $line | sed "s@^\(.*\)(\(.*\))\[\(.*\)\]\\$@\1@"`
+ offs=`echo $line | sed "s@^\(.*\)(\(.*\))\[\(.*\)\]\\$@\2@"`
+ addr=`echo $line | sed "s@^\(.*\)(\(.*\))\[\(.*\)\]\\$@\3@"`
+ func=""
+ case "$offs" in
+ *,*) func=`echo $offs | sed "s@\(.*\),\(.*\)\\$@\1,@"`
+offs=`echo $offs | sed "s@\(.*\),\(.*\)\\$@\2@"`
+;;
+ esac
+ case "$offs" in
+ +*) case "$prog" in
+ */$lib)
+ lib="$prog"
+ ;;
+ esac
+ complete=`addr2line -p -i -f -e "$lib" $offs 2>/dev/null`
+ if test $? -eq 0; then
+ echo " [$addr] $complete $lib($func$offs)"
+ else
+ echo " $line"
+ fi
+ ;;
+ *) echo " $line"
+ ;;
+ esac
+ echo "$lib" >> "$used_libs"
+ ;;
+*) echo "$line"
+ ;;
esac
done)
fi
rm -f "$segv_output"
+objdumptest=`objdump --version 2>/dev/null`
+if test $? -eq 0; then
+ echo "\nBuild-IDs:"
+ sort -u /tmp/used_libs.kUDu9V | while read lib; do
+objdump -s -j .note.gnu.build-id "$lib"
+ done
+fi
+rm
Bug#946606: libc-bin: catchsegv does not handle backtraces with parentheses
Package: libc-bin Version: 2.29-3 Severity: wishlist Tags: upstream patch Dear Maintainer, since upstream commit in 2012 [1] the function __backtrace_symbols_fd seems to outputs in one of this formats: program(+)[] program(function+)[] Therefore the /usr/bin/catchsegv cannot find the backtrace lines and produces less useful outputs (see below) There exists an upstream bug about the issue [2]. Attached patch is an attempt to parse the offset instead of the address, which seems now less important due to ASLR. Known symbols are currently written by __backtrace_symbols_fd as such with the offset in relation to the function instead of the library section. To get for these also sourcefile and line information either __backtrace_symbols_fd needs to be changed to output the library section offset to the backtrace too, or addr2line (binutils) needs a change to lookup the symbol and calculate from there, but both would be different issues. What do you think? Kind regards, Bernhard Current: Backtrace: /tmp/tmp.sSrfzsTKpn/3-options-input-fn(+0x175b)[0x557275eb775b] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f4f8194ebbb] /tmp/tmp.sSrfzsTKpn/3-options-input-fn(+0x11ba)[0x557275eb71ba] With proposed changes: Backtrace: [0x5578ceb0575b] main at /usr/share/doc/libsoxr-dev/examples/3-options-input-fn.c:79 (discriminator 4) /tmp/tmp.sSrfzsTKpn/3-options-input-fn(+0x175b) /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7fcf5f243bbb] [0x5578ceb051ba] _start at ??:? /tmp/tmp.sSrfzsTKpn/3-options-input-fn(+0x11ba) [1] https://sourceware.org/git/?p=glibc.git;a=commit;h=1d6c3d237d10606121c959b9bd2ae722f79ea899 [2] https://sourceware.org/bugzilla/show_bug.cgi?id=21830 -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'proposed-updates-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-2-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 libc-bin depends on: ii libc6 2.29-3 Versions of packages libc-bin recommends: ii manpages 5.04-1 libc-bin suggests no packages. -- no debconf information >From fca03cd9af5ffaea1e4968fa27a7b28ee80903ef Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= Date: Wed, 11 Dec 2019 19:56:39 +0100 Subject: Make catchsegv work again after format changed. https://sourceware.org/bugzilla/show_bug.cgi?id=21830 --- debug/catchsegv.sh | 34 +++--- 1 file changed, 23 insertions(+), 11 deletions(-) diff --git a/debug/catchsegv.sh b/debug/catchsegv.sh index 245c100f..da87122c 100755 --- a/debug/catchsegv.sh +++ b/debug/catchsegv.sh @@ -87,18 +87,30 @@ if test -s "$segv_output"; then sed '/Backtrace/q' "$segv_output" sed '1,/Backtrace/d' "$segv_output" | (while read line; do - line=`echo $line | sed "s@^$prog\\(\\[.*\\)@\1@"` case "$line" in - \[*) addr=`echo "$line" | sed 's/^\[\(.*\)\]$/\1/'` - complete=`addr2line -f -e "$prog" $addr 2>/dev/null` - if test $? -eq 0; then - echo "`echo "$complete"|sed 'N;s/\(.*\)\n\(.*\)/\2(\1)/;'`$line" - else - echo "$line" - fi - ;; - *) echo "$line" - ;; + *\(*\)\[*\]) + lib=`echo $line | sed "s@^\(.*\)(\(.*\))\[\(.*\)\]\\$@\1@"` + offs=`echo $line | sed "s@^\(.*\)(\(.*\))\[\(.*\)\]\\$@\2@"` + addr=`echo $line | sed "s@^\(.*\)(\(.*\))\[\(.*\)\]\\$@\3@"` + case "$offs" in + +*) case "$prog" in + */$lib) + lib="$prog" + ;; + esac + complete=`addr2line -p -i -f -e "$lib" $offs 2>/dev/null` + if test $? -eq 0; then + echo " [$addr] $complete $lib($offs)" + else + echo " $line" + fi + ;; + *) echo " $line" +;; + esac + ;; +*) echo "$line" + ;; esac done) fi -- 2.24.0
Bug#944205: spacefm: 100% cpu when creating files/folders
Hello Jack Barns, I am not involved in packaging spacefm, but just tried to reproduce the issue. "Unfortunately" for my test it did not freeze. If you still can reproduce it, maybe you can execute following command while a single spacefm process is in the system and hangs: script -a "spacefm-gdb_$(date +%Y-%m-%d_%H-%M-%S).txt" -c "ps -C spacefm -mo %cpu,pid,tid,user,args; gdb -q --pid $(pidof spacefm) -ex 'set width 0' -ex 'set pagination off' -ex 'thread apply all bt full' -ex 'detach' -ex 'quit'" This should generate a file spacefm-gdb*.txt which could be forwarded to this bug. Even better if the dbgsym packages could be installed before, like described in [1]. spacefm-dbgsym libgtk2.0-0-dbgsym libglib2.0-0-dbgsym Kind regards, Bernhard [1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols
Bug#942214: thunar/nautilus crash navigate directory "cifs mounted" containing opened libreoffice writer file
Hello David, I fear that output is not sufficient for that type of application. Maybe you could install following packages: thunar-dbgsym gdb libglib2.0-0-dbgsym libgtk-3-0-dbgsym For this you would need to add a matching package archive like described in this link: https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols And then running following command (all in one line) and trigger the crash again. This should generate a a file thunar-gdb_*.txt that could be forwarded to this bug. script -a "thunar-gdb_$(date +%Y-%m-%d_%H-%M-%S).txt" -c "thunar -q; gdb -q -ex 'set width 0' -ex 'set pagination off' -ex 'set backtrace past-main' -ex 'run' -ex 'backtrace no-filter' -ex 'print range_start' -ex 'print range_length' -ex 'print data_length' -ex 'print data_offset' -ex 'print mask_offset' -ex 'print i' -ex 'print j' -ex 'print/x cache' -ex 'print/x cache->buffer' -ex 'print/x data' -ex 'print/x offset' -ex 'print/x len' -ex 'info share' -ex 'info reg' -ex 'thread apply all bt full' -ex 'detach' -ex 'quit' --args thunar" Kind regards, Bernhard
Bug#945443: git-svn fails with "error: git-svn died of signal 11"
base.h:390
#1 0x758e3e64 in QAtomicOps::load(std::atomic const&)
(_q_value=...) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qatomic_cxx11.h:227
#2 0x758e3e64 in QBasicAtomicInteger::load() const
(this=0x75a23280) at
/usr/include/x86_64-linux-gnu/qt5/QtCore/qbasicatomic.h:103
#3 0x758e3e64 in QtPrivate::RefCount::deref() (this=0x75a23280) at
/usr/include/x86_64-linux-gnu/qt5/QtCore/qrefcount.h:66
#4 0x758e3e64 in QString::~QString() (this=0x569742d0,
__in_chrg=) at
/usr/include/x86_64-linux-gnu/qt5/QtCore/qstring.h:1130
#5 0x758e3e64 in KAboutData::Private::~Private() (this=0x569742d0,
__in_chrg=) at ./src/lib/kaboutdata.cpp:460
#6 0x758e3e64 in KAboutData::~KAboutData() (this=0x56972700,
__in_chrg=) at ./src/lib/kaboutdata.cpp:581
#7 0x758e410d in KAboutDataRegistry::~KAboutDataRegistry()
(this=0x7595a6e0 <(anonymous
namespace)::Q_QGS_s_registry::innerFunction()::holder>, __in_chrg=) at ./src/lib/kaboutdata.cpp:1040
#8 0x758e410d in (anonymous
namespace)::Q_QGS_s_registry::Holder::~Holder() (this=0x7595a6e0
<(anonymous namespace)::Q_QGS_s_registry::innerFunction()::holder>,
__in_chrg=) at ./src/lib/kaboutdata.cpp:1040
#9 0x77c87d8c in __run_exit_handlers (status=0, listp=0x77e09718
<__exit_funcs>, run_list_atexit=run_list_atexit@entry=true,
run_dtors=run_dtors@entry=true) at exit.c:108
#10 0x77c87eba in __GI_exit (status=) at exit.c:139
#11 0x555883f6 in main (argc=, argv=,
env=) at perlmain.c:166
(gdb) kill
Kill the program being debugged? (y or n) y
[Inferior 1 (process 607) killed]
(gdb) q
cd /home/benutzer/source/libsvn1
cp orig try2 -a
cd try2/subversion-1.10.4
945443_Avoid-crash-in-__run_exit_handlers-by-using-QString-instead-of-QStringLiteral.patch
Description: Avoid crash in __run_exit_handlers by using QString instead of
QStringLiteral
If QStringLiteral is used then pointer to segments in the
shared library libsvn_auth_kwallet-1.so.1 are passed to
the KAboutData::Private object, which unfortuantely makes
no deep copy.
Later in the exit handler when the KAboutData object gets
destroyed, that pointer are again accessed and trigger the
crash.
Author: Bernhard Übelacker
Bug-Debian: https://bugs.debian.org/945443
Bug-Kde: https://bugs.kde.org/show_bug.cgi?id=407271
Bug-Arch: https://bugs.archlinux.org/task/60005
Forwarded: no
Last-Update: 2019-12-10
# dpkg-buildpackage
DEB_BUILD_OPTIONS='nocheck' dpkg-buildpackage
dpkg -i
/home/benutzer/source/libsvn1/try1/{subversion,libsvn1-dbgsym,libsvn1,libsvn-perl}_1.10.4-1+deb10u1_amd64.deb
###
https://bugs.archlinux.org/task/60005
https://bugs.kde.org/show_bug.cgi?id=407271
https://sources.debian.org/src/subversion/1.13.0-1/subversion/libsvn_auth_kwallet/kwallet.cpp/#L230
https://sources.debian.org/src/subversion/1.13.0-1/subversion/libsvn_auth_kwallet/kwallet.cpp/#L312
https://sources.debian.org/src/kcoreaddons/5.54.0-1/src/lib/kaboutdata.cpp/#L598
https://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_auth_kwallet/kwallet.cpp?view=markup#l230
https://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_auth_kwallet/kwallet.cpp?view=markup#l312
https://cgit.kde.org/kcoreaddons.git/tree/src/lib/kaboutdata.cpp#n600
Bug#945375: gnome-control-center: Segmentation fault when selecting display on secondary GPU.
Control: tags -1 + patch upstream fixed-upstream
Hello Mladen Mijatov, dear Maintainer,
the first frames would be translated by addr2line to following [1].
This looks like the crash is caused by an invalid pointer pself/self
in function cc_display_mode_dbus_is_supported_scale [112].
This pointer is retrieved by cc_display_monitor_get_mode in [399].
That led me to this upstream bug [2] which got
already fixed in [3]. Either of the upstream tags 3.34.2 or 3.35.2
contains that patch.
Kind regards,
Bernhard
[1]
#apt install systemd-coredump gnome binutils gdb gnome-control-center-dbgsym
libglib2.0-0-dbgsym libgtk-3-0-dbgsym
cat backtrace.txt | tr '()[]' ' ' | while read -ra line; do
if [[ ${line[1]:0:1} == "+" ]] ; then
if [[ ${line[0]:0:1} == "/" ]] ; then
F=${line[0]};
else
F=$(which ${line[0]});
fi;
echo ${line[2]} at $(addr2line --exe=$F ${line[1]}) from ${line[0]}
${line[1]};
else
echo ${line[2]} in ${line[1]} from ${line[0]};
fi;
done
0x56214d26c2de at
./obj-x86_64-linux-gnu/../panels/display/cc-display-config-dbus.c:112 from
gnome-control-center +0xa82de
0x56214d26c425 at
./obj-x86_64-linux-gnu/../panels/display/cc-display-config-dbus.c:1217 from
gnome-control-center +0xa8425
0x56214d269206 at
./obj-x86_64-linux-gnu/../panels/display/cc-display-settings.c:399 from
gnome-control-center +0xa5206
0x56214d269b73 in cc_display_settings_set_selected_output+0x13 from
gnome-control-center
0x56214d262970 at
./obj-x86_64-linux-gnu/../panels/display/cc-display-panel.c:733 from
gnome-control-center +0x9e970
0x56214d263780 at
./obj-x86_64-linux-gnu/../panels/display/cc-display-panel.c:546 from
gnome-control-center +0x9f780
0x7fb21bc370e6 at ../../../gobject/gclosure.c:294 from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 +0x140e6
...
[2] https://gitlab.gnome.org/GNOME/gnome-control-center/issues/675
[3]
https://gitlab.gnome.org/GNOME/gnome-control-center/commit/0fa4d11477076c9d06af218795cd8c6194fa5dff
[112]
https://sources.debian.org/src/gnome-control-center/1:3.34.1-1/panels/display/cc-display-config-dbus.c/#L112
[1217]
https://sources.debian.org/src/gnome-control-center/1:3.34.1-1/panels/display/cc-display-config-dbus.c/#L1217
[399]
https://sources.debian.org/src/gnome-control-center/1:3.34.1-1/panels/display/cc-display-settings.c/#L399
Bug#944603: Attempt to print checks crashes gnucash
Hello local10, if you still get this crash, maybe if you start it like below there would be more information about the crash. catchsegv gnome-control-center Alternatively you could install systemd-coredump and look at the end of 'journalctl --no-pager' if there is some debug information of the crash. Kind regards, Bernhard
Bug#945375: gnome-control-center: Segmentation fault when selecting display on secondary GPU.
Hello Mladen Mijatov, if you still get this crash, maybe if you start it like below there would be more information about the crash. catchsegv gnome-control-center Alternatively you could install systemd-coredump and look at the end of 'journalctl --no-pager' if there is some debug information of the crash. Kind regards, Bernhard
Bug#946405: nextcloud-desktop: Nextcloud desktop client crash when trying to enter login/password
Hello Ludovic, I tried to collect some more information from your crash dump. With debug symbols this backtrace should look like below. I guess you are running a nvidia graphics card with the nouveau drivers? As a workaround it may work if you start the client from a terminal by following: export LIBGL_ALWAYS_SOFTWARE=1 nextcloud Or maybe this: export QT_XCB_FORCE_SOFTWARE_OPENGL=1 nextcloud Maybe you can confirm my findings, and forward the output of following commands to this bug: lspci | grep VGA glxinfo | grep -i -E "GLX_MESA_query_renderer.:" -A5 Kind regards, Bernhard From submitter | Reconstructed #0 0x7fe16d9b6bde | 0x7f1811853bde #1 0x7fe16d9b6cf0 | 0x7f1811853cf0 #2 0x7fe16d9b7327 | 0x7f1811854327 #3 0x7fe166ea4840 | 0x7f180ad41840 <__restore_rt+0>: mov$0xf,%rax #4 0x7fe152142a8c | 0x7f17f754ca8c in list_del at ../src/util/list.h:91 #5 0x7fe152142c87 | 0x7f17f754cc87 in nouveau_fence_update at ../src/gallium/drivers/nouveau/nouveau_fence.c:128 #6 0x7fe152142f83 | 0x7f17f754cf83 in nouveau_fence_wait at ../src/gallium/drivers/nouveau/nouveau_fence.c:219 #7 0x7fe1523cf490 | 0x7f17f77d9490 in st_finish (st=st@entry=0x562393326c90) at ../src/mesa/state_tracker/st_cb_flush.c:69 #8 0x7fe1523cf4e0 | 0x7f17f77d94e0 in st_glFinish (ctx=) at ../src/mesa/state_tracker/st_cb_flush.c:104 #9 0x7fe166a5f156 | 0x7f180a8fc156 in QQuickWidgetPrivate::render (this=0x562392ccb0b0, needsSync=) at qquickwidget.cpp:295 #10 0x7fe166a5f2b6 | 0x7f180a8fc2b6 in QQuickWidgetPrivate::renderSceneGraph (this=0x562392ccb0b0) at qquickwidget.cpp:339 #11 0x7fe1675e509b QObject::event() | 0x7f180b48209b in QObject::event (this=this@entry=0x5623930a2130, e=e@entry=0x7ffcf1848bb0) at kernel/qobject.cpp:1232 #12 0x7fe167f7496b QWidget::event() | 0x7f180be1196b in QWidget::event (this=this@entry=0x5623930a2130, event=event@entry=0x7ffcf1848bb0) at kernel/qwidget.cpp:9353 #13 0x7fe166a62e5d QQuickWidget::event() | 0x7f180a8ffe5d in QQuickWidget::event (this=0x5623930a2130, e=0x7ffcf1848bb0) at qquickwidget.cpp:1525 #14 0x7fe17207cb50 | 0x7f1815f19b50 in QtWebEngineCore::RenderWidgetHostViewQtDelegateWidget::event(QEvent*) () from /lib/x86_64-linux-gnu/libQt5WebEngineWidgets.so.5 #15 0x7fe167f364c1 QApplicationPrivate::notify_helper() | 0x7f180bdd34c1 in QApplicationPrivate::notify_helper (this=this@entry=0x562392919dd0, receiver=receiver@entry=0x5623930a2130, e=e@entry=0x7ffcf1848bb0) at kernel/qapplication.cpp:3726 #16 0x7fe167f3d970 QApplication::notify()| 0x7f180bdda970 in QApplication::notify (this=0x7ffcf1848ef0, receiver=0x5623930a2130, e=0x7ffcf1848bb0) at kernel/qapplication.cpp:3485 #17 0x7fe1675bb4f9 QCoreApplication::notifyInternal2() | 0x7f180b4584f9 in QCoreApplication::notifyInternal2 (receiver=0x5623930a2130, event=event@entry=0x7ffcf1848bb0) at ../../include/QtCore/5.11.3/QtCore/private/../../../../../src/corelib/thread/qthread_p.h:307 | 0x7f180b4a8ba8 in QCoreApplication::sendEvent (event=0x7ffcf1848bb0, receiver=) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:234 | 0x7f180b4a8ba8 in QTimerInfoList::activateTimers (this=0x562392954560) at kernel/qtimerinfo_unix.cpp:643 | 0x7f180b4a943c in timerSourceDispatch (source=) at kernel/qeventdispatcher_glib.cpp:182 | 0x7f180b4a943c in idleTimerSourceDispatch (source=) at kernel/qeventdispatcher_glib.cpp:229 #18 0x7fe16760bba8 QTimerInfoList::activateTimers() | 0x7f180b4a8ba8 in QTimerInfoList::activateTimers (this=0x562392954560) at kernel/qtimerinfo_unix.cpp:643 #19 0x7fe16760c404 | 0x7f180b4a9404 in timerSourceDispatch (source=) at kernel/qeventdispatcher_glib.cpp:182 #20 0x7fe166ab9f2e g_main_context_dispatch | 0x7f180a956f2e in g_main_dispatch (context=0x7f17f8004ff0) at ../../../glib/gmain.c:3182 | 0x7f180a956f2e in g_main_context_dispatch (context=context@entry=0x7f17f8004ff0) at ../../../glib/gmain.c:3847 #21 0x7fe166aba1c8 | 0x7f180a9571c8 in g_main_context_iterate
Bug#945443: git-svn fails with "error: git-svn died of signal 11"
Hello Christian, if you still see this crash, maybe you could install the package systemd-coredump. If then a process crashes again some more information should be visible at the end of: journalctl --no-pager Kind regards, Bernhard
Bug#944771: GNOME Shell crashes when selecting "About" from top bar menu in Midori
Hello Andrew,
On Sun, 8 Dec 2019 15:17:45 -0500 Andrew Engelbrecht wrote:
> I was able to reproduce and to get a backtrace, which I attached to this
> email.
Your backtrace with full debug symbols should read like below [4].
This seems to point to the upstream issue [1].
Unfortunately I could not find any hint of a solution there.
Another occourence seems to be in fedora,
but also without solution [2].
At least it looks like the pointer "observer" contained in your
gnome-shell crash an invalid pointer.
The crash before in midori seems to be in webkitWebViewBaseMakeGLContextCurrent.
In my test VM I never reached that function.
> I tried clearing out the ~/.config/midori/ directory. After doing so, I
> no longer get a crash when selecting the "About" menu option.
>
> If needed, I can try to recover the bad config from backups, for the
> sake of testing future versions of Midori and GNOME Shell.
Thats maybe up to the maintainer if this is still desired,
as you found already a workaround.
Kind regards,
Bernhard
[1] https://gitlab.gnome.org/GNOME/gnome-shell/issues/365
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1642473
[3]
https://sources.debian.org/src/gnome-shell/3.30.2-11%7Edeb10u1/src/gtkactionobserver.c/#L155
(gdb) list
150 void
151 gtk_action_observer_action_removed (GtkActionObserver *observer,
152 GtkActionObservable *observable,
153 const gchar *action_name)
154 {
155 g_return_if_fail (GTK_IS_ACTION_OBSERVER (observer));
156
157 GTK_ACTION_OBSERVER_GET_IFACE (observer)
158 ->action_removed (observer, observable, action_name);
159 }
(gdb) print observer
$2 = (GtkActionObserver *) 0x562a598364c0
(gdb) print/x $rbx
$3 = 0x562a598364c0
[4]
(gdb) bt no-filters
#0 0x7fc15234e9a7 in gtk_action_observer_action_removed at
../src/gtkactionobserver.c:155
#1 0x7fc15234d206 in gtk_action_muxer_action_removed at
../src/gtkactionmuxer.c:313
#2 0x7fc15234d26f in gtk_action_muxer_action_removed_from_group at
../src/gtkactionmuxer.c:326
#3 0x7fc15234dce0 in gtk_action_muxer_remove at ../src/gtkactionmuxer.c:763
#4 0x7fc15234dd28 in gtk_action_muxer_insert at ../src/gtkactionmuxer.c:712
#5 0x7fc1534238a4 in shell_app_update_window_actions at
../src/shell-app.c:472
#6 0x7fc153432aee in update_focus_app at ../src/shell-window-tracker.c:487
#7 0x7fc1531ecc8d in g_closure_invoke at ../../../gobject/gclosure.c:810
#8 0x7fc153200365 in signal_emit_unlocked_R at
../../../gobject/gsignal.c:3635
#9 0x7fc1532092be in g_signal_emit_valist at
../../../gobject/gsignal.c:3391
#10 0x7fc15320997f in g_signal_emit at ../../../gobject/gsignal.c:3447
#11 0x7fc1531f1364 in g_object_dispatch_properties_changed at
../../../gobject/gobject.c:1088
#12 0x7fc1531f3921 in g_object_notify_by_spec_internal at
../../../gobject/gobject.c:1181
#13 g_object_notify_by_pspec at ../../../gobject/gobject.c:1291
#14 0x7fc1513258ee in ffi_call_unix64 at ../src/x86/unix64.S:76
#15 0x7fc1513252bf in ffi_call at ../src/x86/ffi64.c:525
#16 0x7fc14f8ccb2d in wl_closure_invoke at ../src/connection.c:1006
#17 0x7fc14f8c95a9 in wl_client_connection_data at
../src/wayland-server.c:420
#18 0x7fc14f8cab72 in wl_event_loop_dispatch at ../src/event-loop.c:641
#19 0x7fc1526263a7 in wayland_event_source_dispatch at
wayland/meta-wayland.c:90
#20 0x7fc15310af2e in g_main_dispatch at ../../../glib/gmain.c:3182
#21 g_main_context_dispatch at ../../../glib/gmain.c:3847
#22 0x7fc15310b1c8 in g_main_context_iterate at ../../../glib/gmain.c:3920
#23 0x7fc15310b4c2 in g_main_loop_run at ../../../glib/gmain.c:4116
#24 0x7fc1525ed06c in meta_run at core/main.c:689
#25 0x562a53f1e782 in main at ../src/main.c:501
#26 0x7fc15237a09b in __libc_start_main at ../csu/libc-start.c:308
#27 0x562a53f1e8da in _start
Bug#944771: GNOME Shell crashes when selecting "About" from top bar menu in Midori
Hello Andrew, I tried to reproduce this crash but it did not show up for me. Maybe you could install systemd-coredump, then a backtrace would be written automatically into the journal: journalctl --no-pager Kind regards, Bernhard
Bug#942214: thunar/nautilus crash navigate directory "cifs mounted" containing opened libreoffice writer file
Hello David, I tried to reproduce the issue but I did not receive a crash. There should have been two lines in the syslog - the line with "Code" would at least help to identify in which function the crash happened. Maybe you could also start thunar or nautilus from a terminal by e.g. thunar -q; catchsegv thunar or nautilus -q; catchsegv nautilus Then trigger the crash and in the terminal should be more information that would help with this issue. Kind regards, Bernhard
Bug#946242: fatal: privsep_preauth: preauth child terminated by signal 31
Am 07.12.19 um 18:20 schrieb Colin Watson: > On Sat, Dec 07, 2019 at 04:52:19PM +0100, Bernhard Übelacker wrote: >> I could reproduce the issue in a i386 qemu VM with >> a downgraded 3.16-3-686-pae kernel. >> Attached file contains a debug session. >> >> At the sysenter instruction in function shmdt >> the signal SIGSYS is received. > > Since you're building it locally already, it would be helpful if you > could follow the debugging instructions in a comment near the top of > sandbox-seccomp-filter.c (either the auditctl approach, or if that > doesn't work on such an old kernel, the ""uncomment this macro" > approach). Really I had not rebuilt it locally, just used the dbgsym packages and downloaded sources. Attached are the lines added to /var/log/audit/audit.log, after "auditctl -a task,always -F uid=0" and a failing ssh attempt. The uncomment-approach did not work for me as I received several compile errors. Kind regards, Bernhard debugging_auditctl-approach.txt.gz Description: application/gzip
Bug#946158: lightdm-gtk-greeter or libcairo2 segfault immediately after submitting password, unlocking session
Hello dinar qurbanov, I am guessing you are using Buster/stable i386? If reportbug would be used for reporting bugs, such information gets added automatically to the report. Then the "Code" in the syslog the crash most probably happened in _cairo_surface_set_error [1]. Unfortunately I doubt that information is enough for the maintainer to fix this issue. If it would be possible to install systemd-coredump, then a backtrace for each crashing app would be added to the journal, that could be of help. And I cannot judge if this could be due to bad sectors on your disk, therefore at least below the md5sums [2] of the files I got installed. Maybe you want to lookup smartctl, if your disk recorded itself some errors. Kind regards, Bernhard [1] https://sources.debian.org/src/cairo/1.16.0-4/src/cairo-surface.c/#L201 [2] # md5sum /usr/lib/i386-linux-gnu/libcairo.so.2.11600.0 273f0014984b9f43abbed04cd9e0bc0c /usr/lib/i386-linux-gnu/libcairo.so.2.11600.0 # md5sum /usr/sbin/lightdm-gtk-greeter dbfa2151ff036c85f4659358d7a5f392 /usr/sbin/lightdm-gtk-greeter # from submitter: Dec 4 14:28:08 localhost kernel: [ 5707.165413] lightdm-gtk-gre[9162]: segfault at 8 ip b73a92e4 sp bfa6f59c error 4 in libcairo.so.2.11600.0[b733d000+dd000] Dec 4 14:28:08 localhost kernel: [ 5707.165431] Code: 51 14 89 54 24 04 e9 1b e5 fa ff 8d 76 00 31 c0 c3 8d 74 26 00 90 89 d0 c3 8d b4 26 00 00 00 00 8d b6 00 00 00 00 8b 44 24 04 <8b> 40 08 c3 8d b4 26 00 00 00 00 90 8b 44 24 04 8b 40 0c c3 8d b4 ### Buster/stable i386 qemu VM 2019-12-07 apt update apt dist-ugprade apt install mc gdb lightdm-gtk-greeter lightdm-gtk-greeter-dbgsym libcairo2-dbgsym gdb -q --args lightdm-gtk-greeter set width 0 set pagination off b main run info share 0xb73f26a0 0xb74cd724 Yes /usr/lib/i386-linux-gnu/libcairo.so.2 find /b 0xb73f26a0, 0xb74cd724, 0x51, 0x14, 0x89, 0x54, 0x24, 0x04, 0xe9, 0x1b, 0xe5, 0xfa, 0xff, 0x8d, 0x76, 0x00, 0x31, 0xc0, 0xc3, 0x8d, 0x74, 0x26, 0x00, 0x90, 0x89, 0xd0, 0xc3, 0x8d, 0xb4, 0x26, 0x00, 0x00, 0x00, 0x00, 0x8d, 0xb6, 0x00, 0x00, 0x00, 0x00, 0x8b, 0x44, 0x24, 0x04, 0x8b, 0x40, 0x08, 0xc3, 0x8d, 0xb4, 0x26, 0x00, 0x00, 0x00, 0x00, 0x90, 0x8b, 0x44, 0x24, 0x04, 0x8b, 0x40, 0x0c, 0xc3, 0x8d, 0xb4 0xb745d2ba <_cairo_surface_tag+4294956810> 1 pattern found. (gdb) disassemble 0xb745d2a0,0xb745d2ba+20 Dump of assembler code from 0xb745d2a0 to 0xb745d2ce: 0xb745d2a0 <_cairo_surface_set_error+0>: mov0x8(%esp),%edx 0xb745d2a4 <_cairo_surface_set_error+4>: mov0x4(%esp),%ecx 0xb745d2a8 <_cairo_surface_set_error+8>: cmp$0x66,%edx 0xb745d2ab <_cairo_surface_set_error+11>:je 0xb745d2c8 <_cairo_surface_set_error+40> 0xb745d2ad <_cairo_surface_set_error+13>:lea-0x1(%edx),%eax 0xb745d2b0 <_cairo_surface_set_error+16>:cmp$0x29,%eax 0xb745d2b3 <_cairo_surface_set_error+19>:ja 0xb745d2d0 <_cairo_surface_set_error+48> 0xb745d2b5 <_cairo_surface_tag+-10491>: xor%eax,%eax 0xb745d2b7 <_cairo_surface_tag+-10489>: lock cmpxchg %edx,0x14(%ecx) 0xb745d2bc <_cairo_surface_set_error+28>:mov%edx,0x4(%esp) 0xb745d2c0 <_cairo_surface_set_error+32>:jmp0xb740b7e0 <_cairo_error> 0xb745d2c5 <_cairo_surface_set_error+37>:lea0x0(%esi),%esi 0xb745d2c8 <_cairo_surface_set_error+40>:xor%eax,%eax 0xb745d2ca <_cairo_surface_set_error+42>:ret 0xb745d2cb <_cairo_surface_set_error+43>:lea0x0(%esi,%eiz,1),%esi End of assembler dump. (gdb) b *0xb745d2bc Breakpoint 3 at 0xb745d2bc: file ../../../../src/cairo-surface.c, line 201. (gdb) info b Num Type Disp Enb AddressWhat 2 breakpoint keep y 0xb745d2ba in _cairo_atomic_int_cmpxchg_impl at ../../../../src/cairo-atomic-private.h:118 3 breakpoint keep y 0xb745d2bc in _cairo_surface_set_error at ../../../../src/cairo-surface.c:201 https://sources.debian.org/src/cairo/1.16.0-4/src/cairo-surface.c/#L201
Bug#946242: fatal: privsep_preauth: preauth child terminated by signal 31
Dear Maintainer, I could reproduce the issue in a i386 qemu VM with a downgraded 3.16-3-686-pae kernel. Attached file contains a debug session. At the sysenter instruction in function shmdt the signal SIGSYS is received. Kind regards, Bernhard (gdb) bt #0 shmdt (shmaddr=0xb774) at ../sysdeps/unix/sysv/linux/shmdt.c:33 #1 0xb748c35a in cleanup_shm () at ../crypto/rand/rand_unix.c:370 #2 0xb7460fb3 in OPENSSL_cleanup () at ../crypto/init.c:519 #3 OPENSSL_cleanup () at ../crypto/init.c:497 #4 0xb6fdfae0 in __run_exit_handlers (status=0, listp=0xb71883fc <__exit_funcs>, run_list_atexit=true, run_dtors=true) at exit.c:108 #5 0xb6fdfc01 in __GI_exit (status=0) at exit.c:139 #6 0xb774da25 in main (ac=, av=) at ../../sshd.c:2257 Buster/stable i386 qemu VM 2019-12-07 apt update apt dist-ugprade apt install dropbear mc gdb openssh-server-dbgsym libssl1.1-dbgsym apt build-dep openssh-server mkdir /home/benutzer/source/openssh-server/orig -p cd/home/benutzer/source/openssh-server/orig apt source openssh-server cd mkdir /home/benutzer/source/libssl1.1/orig -p cd/home/benutzer/source/libssl1.1/orig apt source libssl1.1 cd wget https://snapshot.debian.org/archive/debian/20141013T184415Z/pool/main/l/linux/linux-image-3.16-3-686-pae_3.16.5-1_i386.deb dpkg -i linux-image-3.16-3-686-pae_3.16.5-1_i386.deb reboot # to kernel 3.16 # to have another ssh available dropbear -p 80 # failed login attempt Dez 07 15:42:55 debian kernel: audit: type=1326 audit(1575729775.309:3): auid=4294967295 uid=104 gid=65534 ses=4294967295 pid=5227 comm="sshd" exe="/usr/sbin/sshd" sig=31 syscall=117 compat=0 ip=0xb76fed4c code=0x0 Dez 07 15:42:55 debian sshd[5226]: Accepted password for benutzer from 10.0.2.2 port 48382 ssh2 Dez 07 15:42:55 debian sshd[5226]: fatal: privsep_preauth: preauth child terminated by signal 31 gdb -q --pid $(pidof sshd) set width 0 set pagination off directory /home/benutzer/source/openssh-server/orig/openssh-7.9p1/debian/po directory /home/benutzer/source/libssl1.1/orig/openssl-1.1.1d/crypto b fork b shmget b shmat b shmdt set follow-fork-mode child cont bt info proc # try to ssh, wait for password prompt, not enter it yet finish info proc bt cont info proc bt cont info proc bt cont # enter password info proc bt display/i $pc root@debian:~# gdb -q --pid $(pidof sshd) Attaching to process 701 Reading symbols from /usr/sbin/sshd...Reading symbols from /usr/lib/debug/.build-id/e1/d218f3aad351129f185477cd07fa0217f1648f.debug...done. done. Reading symbols from /lib/i386-linux-gnu/libwrap.so.0...(no debugging symbols found)...done. Reading symbols from /lib/i386-linux-gnu/libaudit.so.1...(no debugging symbols found)...done. Reading symbols from /lib/i386-linux-gnu/libpam.so.0...(no debugging symbols found)...done. Reading symbols from /lib/i386-linux-gnu/libselinux.so.1...(no debugging symbols found)...done. Reading symbols from /lib/i386-linux-gnu/libsystemd.so.0...(no debugging symbols found)...done. Reading symbols from /usr/lib/i386-linux-gnu/libcrypto.so.1.1...Reading symbols from /usr/lib/debug/.build-id/fa/b89eb04abddd217b9dcbac3092b22b3316bc85.debug...done. done. Reading symbols from /lib/i386-linux-gnu/libutil.so.1...Reading symbols from /usr/lib/debug/.build-id/00/f2ffae5a7d102f8d638567d0ebbf4a50fe8909.debug...done. done. Reading symbols from /lib/i386-linux-gnu/libz.so.1...(no debugging symbols found)...done. Reading symbols from /lib/i386-linux-gnu/libcrypt.so.1...Reading symbols from /usr/lib/debug/.build-id/1a/00e365b7690f55dd90ace5de35843ce25d6b35.debug...done. done. Reading symbols from /usr/lib/i386-linux-gnu/libgssapi_krb5.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/i386-linux-gnu/libkrb5.so.3...(no debugging symbols found)...done. Reading symbols from /lib/i386-linux-gnu/libcom_err.so.2...(no debugging symbols found)...done. Reading symbols from /lib/i386-linux-gnu/libc.so.6...Reading symbols from /usr/lib/debug/.build-id/44/72898f10b8f6e536025fe764b9245186520cef.debug...done. done. Reading symbols from /lib/i386-linux-gnu/libnsl.so.1...Reading symbols from /usr/lib/debug/.build-id/e7/ef24c10b8f675406ad572c03bb03453a69670c.debug...done. done. Reading symbols from /lib/i386-linux-gnu/libcap-ng.so.0...(no debugging symbols found)...done. Reading symbols from /lib/i386-linux-gnu/libdl.so.2...Reading symbols from /usr/lib/debug/.build-id/0a/eba38648f88f71c49aff5cc91e5a696e8ba0ef.debug...done. done. Reading symbols from /lib/i386-linux-gnu/libpcre.so.3...(no debugging symbols found)...done. Reading symbols from /lib/ld-linux.so.2...Reading symbols from /usr/lib/debug/.build-id/75/c5f4b3fd81f62a7f2fea8f1c091f3aabf81693.debug...done. done. Reading symbols from /lib/i386-linux-gnu/librt.so.1...Reading symbols from /usr/lib/debug/.build-id/c4/8f25812a51319cbd05b8102b3ce4be0c89266c.debug...done. done. Reading symbols from /lib/i386-linux-gnu/liblzma.so.5...(no debugging symbols found)...done. Reading
Bug#946308: /usr/games/fs2_open: fs2_open crashes immediately (illegal instruction)
Dear Maintainer, I tried to reproduce inside a minimal Buster i386 qemu VM and received also an "Illegal instruction" message. It looks like it tries to execute an AVX instruction that my CPU should support, but is not enabled inside the VM. The usage of AVX might originate from the compiler flag "-march=native". This might be added in configure.ac, lines 149 or 163. The solution could be to just add this configure flag: -CONF_O=--bindir=/usr/games --disable-silent-rules --enable-speech +CONF_O=--bindir=/usr/games --disable-silent-rules --enable-speech --enable-generic-architecture Then these flags get used instead: -mtune=generic -mfpmath=sse -msse -msse2 Do these also violate the i386 Buster baseline? Kind regards, Bernhard (gdb) bt #0 0x005eec8f in std::vector, std::allocator > >::operator[] (this=, __n=) at /usr/include/c++/7/bits/stl_vector.h:798 #1 factor_table::resize (this=0xce84d8 , size=6) at io/keycontrol.cpp:159 #2 0x005eed94 in factor_table::factor_table (this=0xce84d8 , size=6) at io/keycontrol.cpp:112 #3 0x00448a8e in __static_initialization_and_destruction_0 (__priority=65535, __initialize_p=1) at io/keycontrol.cpp:171 #4 _GLOBAL__sub_I__ZN12factor_tableC2Ej () at io/keycontrol.cpp:2912 #5 0x00952f8b in __libc_csu_init () #6 0xb761dad3 in __libc_start_main (main=0x43c4f0 , argc=1, argv=0xbf8b8554, init=0x952f40 <__libc_csu_init>, fini=0x952fa0 <__libc_csu_fini>, rtld_fini=0xb7ef4520 <_dl_fini>, stack_end=0xbf8b854c) at ../csu/libc-start.c:264 #7 0x0046c58b in _start () (gdb) display/i $pc 1: x/i $pc => 0x5eec8f : vmovd %ebx,%xmm2 # Buster/stable i386 qemu VM 2019-12-07 # enable non-free apt update apt dist-upgrade apt install systemd-coredump xserver-xorg sddm openbox xterm mc fakeroot gdb freespace2 freespace2-dbgsym libstdc++-7-dev apt build-dep freespace2 reboot mkdir /home/benutzer/source/freespace2/orig -p cd/home/benutzer/source/freespace2/orig apt source freespace2 cd export DISPLAY=:0 /usr/games/fs2_open catchsegv /usr/games/fs2_open coredumpctl list coredumpctl gdb [PID] set width 0 set pagination off directory /home/benutzer/source/freespace2/orig/freespace2-3.7.4+repack/code bt display/i $pc ### benutzer@debian:~$ /usr/games/fs2_open Ungültiger Maschinenbefehl (Speicherabzug geschrieben) benutzer@debian:~$ catchsegv /usr/games/fs2_open Illegal instruction (core dumped) benutzer@debian:~$ /usr/games/fs2_open_DEBUG Ungültiger Maschinenbefehl (Speicherabzug geschrieben) benutzer@debian:~$ catchsegv /usr/games/fs2_open_DEBUG Illegal instruction (core dumped) ### dmesg: [ 219.663592] traps: fs2_open[883] trap invalid opcode ip:684c8f sp:bf9bce50 error:0 in fs2_open_3.7.4[4d+51a000] [ 226.887618] traps: fs2_open[891] trap invalid opcode ip:5d4c8f sp:bfbbbcc0 error:0 in fs2_open_3.7.4[42+51a000] [ 473.081117] traps: fs2_open_DEBUG[1059] trap invalid opcode ip:69bc0f sp:bfaecb20 error:0 in fs2_open_3.7.4_DEBUG[4cb000+571000] [ 502.160726] traps: fs2_open_DEBUG[1075] trap invalid opcode ip:5f1c0f sp:bfd2c050 error:0 in fs2_open_3.7.4_DEBUG[421000+571000] ### root@debian:~# coredumpctl list TIMEPID UID GID SIG COREFILE EXE Sat 2019-12-07 13:34:07 CET 883 1000 1000 4 present /usr/games/fs2_open_3.7.4 Sat 2019-12-07 13:34:15 CET 891 1000 1000 4 present /usr/games/fs2_open_3.7.4 Sat 2019-12-07 13:38:21 CET1059 1000 1000 4 present /usr/games/fs2_open_3.7.4_DEBUG Sat 2019-12-07 13:38:50 CET1075 1000 1000 4 present /usr/games/fs2_open_3.7.4_DEBUG root@debian:~# coredumpctl gdb 1140 PID: 1140 (fs2_open) UID: 1000 (benutzer) GID: 1000 (benutzer) Signal: 4 (ILL) Timestamp: Sat 2019-12-07 13:53:45 CET (6min ago) Command Line: /usr/games/fs2_open Executable: /usr/games/fs2_open_3.7.4 Control Group: /user.slice/user-1000.slice/session-6.scope Unit: session-6.scope Slice: user-1000.slice Session: 6 Owner UID: 1000 (benutzer) Boot ID: 7a7eca3571374b3ca58ef7f657194b9c Machine ID: 45f49504b47f4e5690bc479adf67aa5b Hostname: debian Storage: /var/lib/systemd/coredump/core.fs2_open.1000.7a7eca3571374b3ca58ef7f657194b9c.1140.157572322500.lz4 Message: Process 1140 (fs2_open) of user 1000 dumped core. Stack trace of thread 1140: #0 0x005eec8f _ZNSt6vectorI10SCP_vectorIjESaIS1_EEixEj (fs2_open_3.7.4) #1 0x005eed94 _ZN12factor_tableC2Ej (fs2_open_3.7.4) #2 0x00448a8e __static_initialization_and_destruction_0 (fs2_open_3.7.4) #3 0x00952f8b __libc_csu_init (fs2_open_3.7.4) #4 0xb761dad3 __libc_start_main (libc.so.6) #5 0x0046c58b _start (fs2_open_3.7.4) GNU gdb (Debian 8.2.1-2+b3) 8.2.1 Copyright (C) 2018 Free Software
