Bug#919447: [asterisk] [1329393.987739] asterisk[27758]: segfault at 10 ip 00007facf79d5233 sp 00007facc14428d0 error 4 in libiksemel.so.3.1.1[7facf79ce000+d000]

[Bernhard Übelacker]

Hello Fernando Toledo, Dear Maintainer,


On Wed, 16 Jan 2019 01:22:31 -0300 Fernando Toledo  
wrote:

> > I need help to know how to get more info/debug.

Maybe you can install a core file collector.
On stable or testing I would propose systemd-coredump,
but that is not available in jessie.
The package corekeeper sounds similar and might put
after a crash a core file somewhere below /var/crash.

That might provide some more information when opened with gdb:

gdb -q /usr/sbin/asterisk /var/crash/
backtrace

The other way would be to install gdb and attach that to the
live process. This maybe in a detachable session like in tmux.

tmux
gdb -q -ex 'set width' -ex 'set pagination off' -ex 'cont' -ex 
'backtrace' -ex 'generate-core-file ~/asterisk.core' -ex 'detach' -ex 'quit' 
--pid $(pidof asterisk)

But without the debug information that might not be sufficient.
In that case rebuilding the packages with debug
information may be needed. See pointer for that in [1].


> > i found that my asterisk crash in dmesg on stretch:
> > 
> > [1329393.987739] asterisk[27758]: segfault at 10 ip 7facf79d5233 sp 
> > 7facc14428d0 error 4 in libiksemel.so.3.1.1[7facf79ce000+d000]


That line may point to below line in libiksemel-1.4 in src/stream.c:552.


Kind regards,
Bernhard


[1] https://wiki.debian.org/HowToGetABacktrace



(gdb) disassemble /m iks_send_raw
Dump of assembler code for function iks_send_raw:
...
   0x77bd41f7 <+55>:js 0x77bd421b 

549 } else
550 #endif
551 {
552 ret = data->trans->send (data->sock, xmlstr, strlen 
(xmlstr));
   0x77bd4220 <+96>:callq  0x77bcfef0 
   0x77bd4225 <+101>:   mov0x10(%rbx),%rcx
   0x77bd4229 <+105>:   mov0x50(%rbx),%rdi
   0x77bd422d <+109>:   mov%rax,%rdx
   0x77bd4230 <+112>:   mov%rbp,%rsi
   0x77bd4233 <+115>:   callq  *0x10(%rcx)  
   <<  here $rcx seems to contain 0 -> data->trans == NULL ?

553 if (ret) return ret;
   0x77bd4236 <+118>:   test   %eax,%eax
   0x77bd4238 <+120>:   jne0x77bd421b 

554 }
555 if (data->logHook) data->logHook (data->user_data, xmlstr, 
strlen (xmlstr), 0);


[1329393.987739] asterisk[27758]: segfault at 10 ip 7facf79d5233 sp 
7facc14428d0 error 4 in libiksemel.so.3.1.1[7facf79ce000+d000]

https://stackoverflow.com/questions/2549214/interpreting-segfault-messages

"error 4" == 0b100

/*
 * 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
 */

--> 
0: no page found
0: read access
1: user-mode access






# Jessie amd64 qemu VM 2019-01-16

apt update
apt dist-upgrade


apt install corekeeper gdb binutils asterisk





# objdump --disassemble /usr/lib/x86_64-linux-gnu/libiksemel.so.3 | grep 233
7233:   ff 51 10callq  *0x10(%rcx)  --> 
likely -> offset of 0x10 matches also the sefault line.
9233:   89 f1   mov%esi,%ecx--> 
unlikely

root@debian:~# objdump --disassemble /usr/lib/x86_64-linux-gnu/libiksemel.so.3 
| grep 7233: -B 40 -A 4

71c0 :
71c0:   41 54   push   %r12
71c2:   55  push   %rbp
71c3:   48 89 f5mov%rsi,%rbp
71c6:   53  push   %rbx
71c7:   e8 a4 be ff ff  callq  3070 
71cc:   f6 40 58 04 testb  $0x4,0x58(%rax)
71d0:   48 89 c3mov%rax,%rbx
71d3:   48 89 efmov%rbp,%rdi
71d6:   74 48   je 7220 
71d8:   e8 13 bd ff ff  callq  2ef0 
71dd:   48 8b 7b 70 mov0x70(%rbx),%rdi
71e1:   48 89 c2mov%rax,%rdx
71e4:   48 89 eemov%rbp,%rsi
71e7:   e8 f4 be ff ff  callq  30e0 
71ec:   48 89 c2mov%rax,%rdx
71ef:   b8 07 00 00 00  mov$0x7,%eax
71f4:   48 85 d2test   %rdx,%rdx
71f7:   78 22   js 721b 
71f9:   4c 8b 63 38 mov0x38(%rbx),%r12
71fd:   4d 85 e4test   %r12,%r12
7200:   74 17   je 7219 
7202:   48 89 efmov%rbp,%rdi
7205:   e8 e6 bc ff ff  callq  2ef0 
720a:   48 8b 7b 20 mov0x20(%rbx),%rdi
720e:   31 c9   xor%ecx,%ecx
7210:   48 

Bug#918863: reboot returns to Windows 10 on Lenovo X1

[Bernhard Übelacker]

Hello Tom Brown, dear Maintainer,
I just tried to reproduce this on a amd64 qemu EFI VM.

>From your description is not clear if you received on reboot
the menu to select between "Windows 10" or
"Debian GNU/Linux - Continue with install process"?
If that is missing you might add the output of following command
running in an administrative/elevated cmd:

bcdedit /enum all > c:\bcdedit-enum-all.txt


Unfortunately I am not confident if grldr.mbr is still working,
at least when a firmware without CSM or secure boot comes into play.
Therefore I raise the question if win32-loader is really supposed
to work on a secure boot EFI system?
If such a system is detected, maybe a warning could be added?


I looked for a way to load e.g. an EFI grub image [2] from
{bootmgr} (Windows Boot Manager), but could not find a working way.
The most I found is this discussion [2].

The next possiblity would be to add an boot entry to the
firmware efi itself - unfortunately the firmware boot menu
would have to be opened by the user (at least in TianoCore).

So it might be needed to make at this stage grub already the
default - with the risk to leave the user with an unbootable system ...

Find in [3] some examples how to change the boot configuration.
This may make the system unbootable, just use in a test environment!!!
This is not intended as a workaround - just a possible way to improve
win32-loader.

Also with the debian installation the real grub was put
into place and working.
Unfortunately Windows decided at next it got booted to make
again our intermediate grub the default entry ???

Kind regards,
Bernhard


[1] Create EFI grub:
grub-mkimage -o grubx64-win32-loader.efi -O x86_64-efi --prefix /EFI/debian 
part_gpt part_msdos lvm fat ext2 chain boot configfile normal minicmd linux 
reboot halt search gfxterm gfxmenu efi_gop efi_uga video loadbios gzio 
video_bochs video_cirrus echo true loadenv ntfs exfat tftp http

[2] 
http://reboot.pro/topic/17655-boot-into-3rd-party-efi-application-via-bcd/page-3

[3]
# C:\Windows\system32>bcdedit /enum {bootmgr} | find "path"
# path\EFI\Microsoft\Boot\bootmgfw.efi

# mount ESP/EFI system partition as Z: (has to be a free drive letter)
mountvol Z: /S
mkdir Z:\EFI\debian
# create a grub.cfg
(
echo menuentry "Windows" {
echo search --file --no-floppy --set=root 
/EFI/Microsoft/Boot/bootmgfw.efi
echo chainloader /EFI/Microsoft/Boot/bootmgfw.efi
echo }
echo menuentry "Debian GNU/Linux - Continue with install process" {
echo search --file --no-floppy --set=root /win32-loader/linux
echo linux /win32-loader/linux vga=788 priority=low ---
echo initrd /win32-loader/initrd.gz
echo }
)> Z:\EFI\debian\grub.cfg
# copy the grub image from [1]
copy c:\root\grubx64-win32-loader.efi Z:\EFI\debian\grubx64-win32-loader.efi
# unmount ESP
mountvol Z: /D

# add a new boot entry to EFI firmware and make it default - found no way 
to create a proper firmware application 101f ...
bcdedit /copy {bootmgr} /d "Debian GNU/Linux - Continue with install 
process copy"
::Der Eintrag wurde erfolgreich in {4c28ffdd-16ba-11e9-8632-97f1cd5def39} 
kopiert.
set GUID={4c28ffdd-16ba-11e9-8632-97f1cd5def39}
bcdedit /set %GUID% path \EFI\debian\grubx64-win32-loader.efi
bcdedit /set {fwbootmgr} timeout 15
bcdedit /set {fwbootmgr} default %GUID%
bcdedit /deletevalue %GUID% device
bcdedit /deletevalue %GUID% locale
bcdedit /deletevalue %GUID% inherit
bcdedit /deletevalue %GUID% resumeobject
bcdedit /deletevalue %GUID% toolsdisplayorder
bcdedit /deletevalue %GUID% timeout

# Was just tested with EFI win10 64bit

Bug#919291: crash: invalid kernel virtual address / crash: cannot allocate any more memory!

[Bernhard Übelacker]

Package: crash
Version: 7.2.3+real-2
Severity: normal
Tags: upstream

Dear Maintainer,

I experienced a crash with kdump-tools installed and wanted to
report that crash (#919290).
I tried to have a look at the collected core and found that crash
gives an error message and exits (see below).

This seems to be caused by recent changes in the current 4.19 series.
As it looks like this may get the next stable kernel it would
be nice if crash could analyze cores from that kernel.

Upstream seem to have some fixes for 4.19 kernels [1].

I made a local build with [2] and [3] applied,
and it did not fail anymore.

Kind regards,
Bernhard


[1] https://people.redhat.com/anderson/crash.changelog.html
[2] 
https://github.com/crash-utility/crash/commit/d7eec45d4c2cdd836ce48a81b0ae688a7d2879ba
[3] 
https://github.com/crash-utility/crash/commit/001f77a05585c15ebd14bb72d5fde314a63c06fe


Output of failing "crash":

$ crash /usr/lib/debug/lib/modules/4.19.0-1-amd64/vmlinux 
/var/crash/201901141532/dump.201901141532

crash 7.2.3
Copyright (C) 2002-2017  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
Copyright (C) 1999-2006  Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011  NEC Corporation
Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions.  Enter "help copying" to see the conditions.
This program has absolutely no warranty.  Enter "help warranty" for details.

GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...

WARNING: kernel relocated [126MB]: patching 81344 gdb minimal_symbol values

please wait... (gathering module symbol data)  
crash: invalid kernel virtual address: 68fb10  type: "module symbol 
strings"
buf_1K_used: 466
buf_2K_used: 1
buf_4K_used: 1
buf_8K_used: 0
buf_32K_used: 3
buf_1K_ovf: 0
buf_2K_ovf: 0
buf_4K_ovf: 0
buf_8K_ovf: 0
buf_32K_ovf: 0
buf_1K_maxuse:  2 of 10
buf_2K_maxuse:  1 of 10
buf_4K_maxuse:  1 of 5
buf_8K_maxuse:  0 of 5
buf_32K_maxuse:  1 of 1
buf_inuse[5]: [3][0][0][0][0]
smallest: 32
largest: 7483468619598196139
embedded: 3
max_embedded: 3
mallocs: 2
frees: 2
reqs/total: 474/7483468636778302464
average size: 15787908516409920

crash: cannot allocate any more memory!



Local rebuild:

mkdir /tmp/source/crash/orig -p
cd/tmp/source/crash/orig
apt source crash
cd


cd /tmp/source/crash
cp orig try1 -a
cd try1/crash-7.2.3+real/
wget 
https://github.com/crash-utility/crash/commit/d7eec45d4c2cdd836ce48a81b0ae688a7d2879ba.patch
 -O debian/patches/d7eec45d4c2cdd836ce48a81b0ae688a7d2879ba.patch
wget 
https://github.com/crash-utility/crash/commit/001f77a05585c15ebd14bb72d5fde314a63c06fe.patch
 -O debian/patches/001f77a05585c15ebd14bb72d5fde314a63c06fe.patch
echo d7eec45d4c2cdd836ce48a81b0ae688a7d2879ba.patch >> debian/patches/series
echo 001f77a05585c15ebd14bb72d5fde314a63c06fe.patch >> debian/patches/series
quilt push -f
# d7eec45d4c2cdd836ce48a81b0ae688a7d2879ba.patch does not apply cleanly ...
quilt refresh
quilt push
quilt refresh
dch --local bernhard "+4.19-fixes"

export PKG="binutils-dev liblzo2-dev libsnappy-dev"; apt install $PKG; 
apt-mark auto $PKG

dpkg-buildpackage


dpkg -i crash_7.2.3+real-2bernhard1_amd64.deb




-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-1-amd64 (SMP w/16 CPU cores)
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 crash depends on:
ii  binutils  2.31.1-11
ii  libc6 2.28-4
ii  liblzo2-2 2.10-0.1
ii  libncurses6   6.1+20181013-1
ii  libsnappy1v5  1.1.7-1
ii  libtinfo6 6.1+20181013-1
ii  zlib1g1:1.2.11.dfsg-1

crash recommends no packages.

Versions of packages crash suggests:
ii  kexec-tools   1:2.0.16-1
ii  makedumpfile  1:1.6.5-1

-- no debconf information

Bug#919290: SMB2_close_free: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000

[Bernhard Übelacker]

Package: src:linux
Version: 4.19.12-1
Severity: normal

Dear Maintainer,

I received following crash while having a cifs filesystem mounted
from a qemu VM running on the same host.
Unfortunately forgot to unmount and shut down the VM.
Then after some minutes system froze and restarted.

If it may be important, the mount commmand was:
mount -t cifs -o 
user=Benutzer1,pass=test,port=4445,uid=1000,gid=1000,vers=3.0,noserverino 
//127.0.254.55/C share
That port is a forward on the qemu command line:
...hostfwd=tcp:127.0.254.55:4445-:445...


kdump-tools are installed and collected a core.


Upstream has following bug that looks quite similar [1], and
[2] on the mailing list.
Last year I experienced a crash also related to SMB2 that
may be related that I just reported upstream [3].

Upstream linux-4.20.y contains patch [4] that seems related.


Kind regards,
Bernhard


[1] https://bugzilla.kernel.org/show_bug.cgi?id=202223
[2] https://lkml.org/lkml/2018/10/23/702
[3] https://bugzilla.kernel.org/show_bug.cgi?id=200907
[4] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/cifs/smb2pdu.c?id=32a1fb36f6e50183871c2c1fcf5493c633e84732


# ls -lisah /var/crash/201901141532/*
2904688  80K -rw-r--r-- 1 root root  78K Jan 14 15:32 
/var/crash/201901141532/dmesg.201901141532
2904805 158M -rw-r--r-- 1 root root 158M Jan 14 15:32 
/var/crash/201901141532/dump.201901141532




[37873.194365] CIFS VFS: Server 127.0.254.55 has not responded in 120 seconds. 
Reconnecting...
[37947.794384] BUG: unable to handle kernel NULL pointer dereference at 

[37947.794393] PGD 0 P4D 0 
[37947.794401] Oops:  [#1] SMP NOPTI
[37947.794407] CPU: 11 PID: 13315 Comm: file.so Kdump: loaded Tainted: G
   OE 4.19.0-1-amd64 #1 Debian 4.19.12-1
[37947.794411] Hardware name: System manufacturer System Product Name/PRIME 
B350M-A, BIOS 4014 05/11/2018
[37947.794466] RIP: 0010:SMB2_close_free+0x8/0x10 [cifs]



$ crash /usr/lib/debug/lib/modules/4.19.0-1-amd64/vmlinux 
/var/crash/201901141532/dump.201901141532

crash> bt
PID: 13315  TASK: 967938300ec0  CPU: 11  COMMAND: "file.so"
 #0 [accec32cb8e0] machine_kexec at 88e558f7
 #1 [accec32cb938] __crash_kexec at 88f1e19d
 #2 [accec32cba00] crash_kexec at 88f1f35d
 #3 [accec32cba18] oops_end at 88e29afd
 #4 [accec32cba38] no_context at 88e640ae
 #5 [accec32cba90] __do_page_fault at 88e64772
 #6 [accec32cbb00] page_fault at 8960108e
[exception RIP: SMB2_close_free+8]
RIP: c0f5bb48  RSP: accec32cbbb8  RFLAGS: 00010246
RAX:   RBX: 967798d61000  RCX: 
RDX: 0007  RSI: 0246  RDI: accec32cbd68
RBP: accec32cbdf0   R8: 000a   R9: 
R10: 0045  R11: 228354df9900  R12: accec32cbc50
R13: 96782d1f4000  R14: 967798d62800  R15: 
ORIG_RAX:   CS: 0010  SS: 0018
 #7 [accec32cbbb8] smb2_queryfs at c0f4e1b8 [cifs]
 #8 [accec32cbe00] cifs_statfs at c0f126fd [cifs]
 #9 [accec32cbe38] statfs_by_dentry at 890907e7
#10 [accec32cbe50] vfs_statfs at 89090a56
#11 [accec32cbe68] user_statfs at 89090b54
#12 [accec32cbea8] __do_sys_statfs at 89090bc0
#13 [accec32cbf38] do_syscall_64 at 88e040d3
#14 [accec32cbf50] entry_SYSCALL_64_after_hwframe at 89600088
RIP: 7f58114bd217  RSP: 7fffeabfea08  RFLAGS: 0246
RAX: ffda  RBX: 55981f7305b8  RCX: 7f58114bd217
RDX:   RSI: 7fffeabfea10  RDI: 55981f7305b8
RBP: 7fffeabfea10   R8: 7f581158ec40   R9: 55981f730630
R10: 0007  R11: 0246  R12: 7fffeabfead0
R13: 7fffeabfeac8  R14: 55981f77de88  R15: 55981f7316f0
ORIG_RAX: 0089  CS: 0033  SS: 002b

crash> dis SMB2_close_free
0xc0f5bb40 :   nopl   0x0(%rax,%rax,1) [FTRACE NOP]
0xc0f5bb45 : mov(%rdi),%rax
0xc0f5bb48 : mov(%rax),%rdi
0xc0f5bb4b :jmpq   0xc0f3f870 




-- Package-specific info:
** Version:
Linux version 4.19.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.2.0 (Debian 8.2.0-13)) #1 SMP Debian 4.19.12-1 (2018-12-22)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-1-amd64 
root=UUID=64e985dd-8bd3-4051-82a4-a01577abbed4 ro crashkernel=384M-:128M

** Tainted: OE (12288)
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: System manufacturer
product_name: System Product Name
product_version: System Version
chassis_vendor: Default string
chassis_version: Default string
bios_vendor: American Megatrends Inc.
bios_version: 4014
board_vendor: ASUSTeK COMPUTER 

Bug#918950: qemu-system-x86: can't use virtual FAT disk images: "Initialization of device ide-hd failed: Block node is read-only"

[Bernhard Übelacker]

Control: fixed 918950 1:2.12+dfsg-3
Control: tags 918950 + upstream


Hello Jakub Wilk, dear Maintainer,
just tried to find out when this started and found it
working with 2.12.

Then tried to build it from git and a bisect leads to
following commit:

eeae6a596b0efc092f5101c67683053e245e6250 is the first bad commit
commit eeae6a596b0efc092f5101c67683053e245e6250
Author: Kevin Wolf 
Date:   Tue Oct 9 16:57:12 2018 +0200

block: Update flags in bdrv_set_read_only()

To fully change the read-only state of a node, we must not only change
bs->read_only, but also update bs->open_flags.

Signed-off-by: Kevin Wolf 
Reviewed-by: Eric Blake 
Reviewed-by: Alberto Garcia 

:100644 100644 9d2adf79623907b42e73482701def00bbc3bb1ea 
3132c78f0104b3f9d95d3f715fbfc7e847e504c4 M  block.c


Unfortunately there were too much changes until version 3.1
where that patch cannot be reverted anymore.


A workaround, when the drive being writable does not matter, 
can be to make it explicitly writable:

qemu-system-x86_64 -hda fat:rw:$(mktemp -d)

To avoid the message about automatic raw image detection
following line could be used:

qemu-system-x86_64 -drive format=raw,file=fat:rw:$(mktemp -d)

Kind regards,
Bernhard

Bug#918959: gnucash crashes in Steuer-Bericht/ElStEr-Export when changing alteranate period to "use from-to"

[Bernhard Übelacker]

Hello Markus Blatt, dear Maintainer,
I just tried to reproduce the crash inside a minimal test VM,
with a new empty file, by these steps:

- Datei
- Neue Datei
- Weiter - Weiter - Weiter - Weiter - Weiter - Anwenden
- test.xml - Speichern
- Berichte - Steuer-Bericht & Elster Export
- Optionen
- Radiobuttons "Von" - "Bis"
- Anwenden

But I could not reproduce a crash.
So that might just manifest with some other special settings?
Could you reproduce it by using a newly created empty file
and if yes could you provide the exact steps to it ?

>From your backtrace I guess you have gnucash-dbgsym already installed?
You might add following packages to resolve also the shared libraries,
and resend another backtrace:

guile-2.2-libs-dbgsym libglib2.0-0-dbgsym libglib2.0-0-dbgsym 
libgtk-3-0-dbgsym libffi6-dbg libgtk-3-0-dbgsym libgc1c2-dbgsym

>From your backtrace it looks like the parameter to _wrap_gnc_mktime
points to invalid memory.


(Also it looks like gnucash "uses" some software written in guile
in this backtrace, but debians gdb does not include guile support,
and current gdb seems not to support guile-2.2 [1],
Is threre any way to see which guile software is
there currently interpreted? )

Kind regards,
Bernhard


[1] https://sourceware.org/bugzilla/show_bug.cgi?id=21104

Bug#918449: kate freeze when right-click the open/save file dialog

[Bernhard Übelacker]

Hello Joe Ma,
just to be sure, you did execute the proposed gdb command
while kate was frozen?

Kind regards,
Bernhard

Bug#911392: linux-image-686-pae: Kernel panic after upgrading to 4.18 (Bug #911392)

[Bernhard Übelacker]

Control: fixed 911392 linux/4.19.12-1

Dear Maintainer,
did an update on that testsystem and the error
does not show up with at least 4.19.12-1.

Kind regards,
Bernhard

Bug#918815: gimp: fatal error: speicherzugriffsfehler (gimp crash debug)

[Bernhard Übelacker]

Hello Michael Hatzold,
I tried to have a look and guess gimp received from some
plugin feedback in form of a malformed GIMP_PDB_INT16ARRAY.

Unfortunately this may not be enough information
for the maintainer to fix it.

Could you please provide more details on which exact
steps you took to trigger that crash?

Also when forwarding such backtraces it would be highly
appreciated if you could consider installing the debug
symbols for the crashing application, e.g. gimp-dbgsym.
These packages are contained in a special debian repository [1].

Kind regards,
Bernhard


[1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols


#6   () at /lib/x86_64-linux-gnu/libpthread.so.0
#7  g_type_check_value_holds () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#8  g_value_get_int () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#9  0x558c8b2b plug_in_params_to_args () at plug-in-params.c:145
0x558bd003 in gimp_plug_in_handle_proc_return () at 
gimpplugin-message.c:647
#10 gimp_plug_in_handle_message () at gimpplugin-message.c:132
0x558bbaa1 in gimp_plug_in_recv_message () at gimpplugin.c:210
gimp_plug_in_recv_message () at gimpplugin.c:178
#11 0x76cafcb8 in g_main_dispatch () at ../../../glib/gmain.c:3182
#12 g_main_context_dispatch () at ../../../glib/gmain.c:3847
#13 0x76cb00a8 in g_main_context_iterate () at 
../../../glib/gmain.c:3920
#14 0x76cb03a2 in g_main_loop_run () at ../../../glib/gmain.c:4116
#15 0x55624cb7 in app_run () at app.c:440
#16 0x556245b5 in main () at main.c:524


(gdb) list plug-in-params.c:36,258
...
38  plug_in_params_to_args (GParamSpec **pspecs,
...
94switch (gimp_pdb_compat_arg_type_from_gtype (type))
...
144 case GIMP_PDB_INT16ARRAY:
145   count = g_value_get_int (gimp_value_array_index (args, i - 
1));
   0x558c8b18 <+760>:   lea-0x1(%rbx),%esi
   0x558c8b1b <+763>:   mov%r14,%rdi
   0x558c8b1e <+766>:   callq  0x55619120 

   0x558c8b23 <+771>:   mov%rax,%rdi
   0x558c8b26 <+774>:   callq  0x5561e3b0 

146   if (full_copy)
   0x558c8b2b <+779>:   mov0x1c(%rsp),%r11d
   0x558c8b30 <+784>:   mov0x0(%rbp),%rsi
   0x558c8b34 <+788>:   mov%r12,%rdi
   0x558c8b37 <+791>:   movslq %eax,%rdx
   0x558c8b3a <+794>:   test   %r11d,%r11d
   0x558c8b3d <+797>:   je 0x558c8cd0 


147 gimp_value_set_int16array (,
...

Bug#909805: linux-image-686-pae: Kernel panic after upgrading to 4.18

[Bernhard Übelacker]

Hello,
might this just another cases of similar bugs 908924/908382/911392?

Is this still an issue with current version 4.19.12-1 ?

Kind regards,
Bernhard



signature.asc
Description: OpenPGP digital signature

Bug#918410: [qtcreator] qtcreator freezes during startup

[Bernhard Übelacker]

Hello Johannes, dear Maintainer,
tried to reproduce the hang here but just got
a NV4B and NV108, while your NVA5 is somewhere between,
and with both I did not get such a freeze ...

I fear I cannot help on this issue any deeper.
Maybe some Qt or Nouveau developer need to have a look.

Kind regards,
Bernhard

Bug#912968: Solved

[Bernhard Übelacker]

Dear Maintainer,
the bugs 912921/913133 these two bugs should be merged with are already
archived. Is it ok to just close them by 91-cl...@bugs.debian.org ?

Kind regards,
Bernhard

Bug#918696: scid: reproducible crash

[Bernhard Übelacker]

Control: tags 918696 + upstream patch


Hello Bill Allombert, dear Maintainer,

I tried to have a look at this crash and could
reproduce it inside a Buster amd64 qemu VM.

See below a backtrace of the crash with debug symbols installed.

Running with valgrind revealed accesses to uninitialized memory.
When this memory gets initialized to zero the crash does not
happen any longer.

Some more information in attached file and one more unrelated
valgrind output showing an invalid read below TkpOpenDisplay.

Find the added initializations in the patch attached.

Kind regards,
Bernhard


(gdb) bt
#0  0x55be75810e10 in Engine::UpdatePV (sm=0x7ffe87a2a1a0, 
this=0x55be77c71170) at src/engine.h:297
#1  Engine::Search (this=this@entry=0x55be77c71170, depth=depth@entry=1, 
alpha=680, alpha@entry=860, beta=beta@entry=861, 
tryNullMove=tryNullMove@entry=true) at src/engine.cpp:1628
#2  0x55be75810798 in Engine::Search (this=this@entry=0x55be77c71170, 
depth=depth@entry=1, alpha=alpha@entry=-861, beta=beta@entry=-860, 
tryNullMove=, tryNullMove@entry=true) at src/engine.cpp:1770
#3  0x55be75810aa8 in Engine::Search (this=this@entry=0x55be77c71170, 
depth=depth@entry=2, alpha=alpha@entry=860, beta=beta@entry=861, 
tryNullMove=, tryNullMove@entry=true) at src/engine.cpp:1772
#4  0x55be75810798 in Engine::Search (this=this@entry=0x55be77c71170, 
depth=depth@entry=2, alpha=alpha@entry=-861, beta=beta@entry=-860, 
tryNullMove=, tryNullMove@entry=true) at src/engine.cpp:1770
#5  0x55be75810aa8 in Engine::Search (this=this@entry=0x55be77c71170, 
depth=depth@entry=3, alpha=860, alpha@entry=31997, beta=beta@entry=31998, 
tryNullMove=, tryNullMove@entry=true) at src/engine.cpp:1772
#6  0x55be75810798 in Engine::Search (this=this@entry=0x55be77c71170, 
depth=depth@entry=3, alpha=alpha@entry=-31998, beta=beta@entry=-31997, 
tryNullMove=, tryNullMove@entry=true) at src/engine.cpp:1770
#7  0x55be75812138 in Engine::SearchRoot (this=this@entry=0x55be77c71170, 
depth=depth@entry=4, alpha=31997, alpha@entry=31962, beta=beta@entry=32032, 
mlist=mlist@entry=0x7ffe87a32710) at src/engine.cpp:1531
#8  0x55be75812ec3 in Engine::Think (this=, 
mlist=0x7ffe87a32710) at src/engine.cpp:1449
#9  0x55be757dd38a in sc_pos_bestSquare (ti=0x55be760ba000, argv=, argc=, cd=) at src/tkscid.cpp:6056
#10 0x55be757e4f49 in sc_pos_bestSquare (argv=0x55be77aa2420, argc=3, 
ti=0x55be760ba000, cd=0x0) at /usr/include/c++/6/bits/stl_algo.h:1887
#11 sc_pos (cd=0x0, ti=0x55be760ba000, argc=3, argv=0x55be77aa2420) at 
src/tkscid.cpp:5725
#12 0x7f1833d161bb in TclInvokeStringCommand (clientData=0x55be760f9fe0, 
interp=0x55be760ba000, objc=3, objv=0x55be77aa2400) at ./generic/tclBasic.c:2479
#13 0x7f1833d17f87 in TclNRRunCallbacks 
(interp=interp@entry=0x55be760ba000, result=0, rootPtr=0x0) at 
./generic/tclBasic.c:4461
#14 0x7f1833d1798f in Tcl_EvalObjv (interp=interp@entry=0x55be760ba000, 
objc=objc@entry=2, objv=objv@entry=0x55be77aa2160, flags=flags@entry=2097168) 
at ./generic/tclBasic.c:4189
#15 0x7f1833d1937f in TclEvalEx (interp=0x55be760ba000, 
script=0x7ffe87a36f30 "enterSquare 52", numBytes=, 
flags=, line=line@entry=1, clNextOuter=clNextOuter@entry=0x0, 
outerScript=0x7ffe87a36f30 "enterSquare 52") at ./generic/tclBasic.c:5330
#16 0x7f1833d18ce3 in Tcl_EvalEx (interp=, script=, numBytes=, flags=) at 
./generic/tclBasic.c:4995
#17 0x7f1832cf57bd in Tk_BindEvent (bindPtr=, 
eventPtr=eventPtr@entry=0x7ffe87a370c0, tkwin=0x55be77914e30, 
numObjects=, objectPtr=, 
objectPtr@entry=0x55be77c613a0) at ./unix/../generic/tkBind.c:1518
#18 0x7f1832d47fd8 in CanvasDoEvent 
(canvasPtr=canvasPtr@entry=0x55be76593340, 
eventPtr=eventPtr@entry=0x7ffe87a370c0) at ./unix/../generic/tkCanvas.c:5228
#19 0x7f1832d479f9 in PickCurrentItem 
(canvasPtr=canvasPtr@entry=0x55be76593340, 
eventPtr=eventPtr@entry=0x55be77952130) at ./unix/../generic/tkCanvas.c:5046
#20 0x7f1832d47674 in CanvasBindProc (clientData=0x55be76593340, 
eventPtr=0x55be77952130) at ./unix/../generic/tkCanvas.c:4824
#21 0x7f1832d04b1f in Tk_HandleEvent 
(eventPtr=eventPtr@entry=0x55be77952130) at ./unix/../generic/tkEvent.c:1352
#22 0x7f1832d05360 in WindowEventProc (flags=, 
evPtr=0x55be77952130) at ./unix/../generic/tkEvent.c:1764
#23 WindowEventProc (evPtr=evPtr@entry=0x55be77952120, flags=flags@entry=-3) at 
./unix/../generic/tkEvent.c:1735
#24 0x7f1833ddff2f in Tcl_ServiceEvent (flags=flags@entry=-3) at 
./generic/tclNotify.c:670
#25 0x7f1833de0195 in Tcl_DoOneEvent (flags=-3) at ./generic/tclNotify.c:903
#26 0x7f1832d057c2 in Tk_MainLoop () at ./unix/../generic/tkEvent.c:2148
#27 0x7f1833dda151 in Tcl_MainEx (argc=, argv=, appInitProc=0x55be757e7de0 , 
interp=0x55be760ba000) at ./generic/tclMain.c:607
#28 0x55be757e97fd in UI_impl::Main (argc=2, argv=0x7ffe87a37a18, 
exit=) at src/ui_tcltk.h:60
#29 0x7f18335f509b in __libc_start_main (main=0x55be75771490 , argc=2, argv=0x7ffe87a37a18, init=, 

Bug#918449: kate freeze when right-click the open/save file dialog

[Bernhard Übelacker]

Hello Joe Ma,


On Mon, 7 Jan 2019 15:45:27 +0800 Joe Ma  wrote:
> Here is the log after executing your command.

Unfortunately I cannot see a difference to a kate process
that runs normal.
Was this file created while your kate process was frozen?

> The whole screen (plasmashell) freeze after right-click in the open/save 
> file dialog (KDE one).

So you switched to a virtual terminal by ctrl+alt+f1
to enter 'killall kate'?
If the gdb command was not run while kate was frozen,
could you run it just before that 'killall kate'?

(That command might be now in bash's history buffer as you
executed it yesterday, which you can step through
by cursor up/down.)


Kind regards,
Bernhard

Bug#918410: [qtcreator] qtcreator freezes during startup

[Bernhard Übelacker]

Hello Johannes,

On Mon, 07 Jan 2019 21:06:28 +0100 Johannes Zarl-Zierl  wrote:
> Hello Bernhard,
> 
> Am Montag, 7. Jänner 2019, 01:00:13 CET schrieb Bernhard Übelacker:
> > Can you repeat that gdb command with following additional
> > dbgsym packages installed, to complete the backtraces:
> ...
> Of course. See the attached log.

Unfortunately all threads seem to just wait.
That may point to the direction of Xorg or the graphics driver.
Is there any related output from the 'dmesg' command,
or in ~/.xsession-errors, or /var/log/Xorg.0.log.

I found a nearly similar backtrace in [1].
Do you use ssh with X forwarding?

In any case could you try if the hang still shows up when you start
qtcreator with this environment from bug [1] set.

QT_XCB_NO_MITSHM=1 qtcreator

Or forward the output when started with this logging enabled:

QT_LOGGING_RULES=qt.qpa.xcb.debug=true qtcreator


Kind regards,
Bernhard

[1] https://bugreports.qt.io/browse/QTBUG-68783

Bug#918623: dizzy: Your vendor has not defined OpenGL macro GL_FRAMEBUFFER_EXT

[Bernhard Übelacker]

Package: dizzy
Version: 0.3-3
Severity: normal

Dear Maintainer,

this is the output of dizzy when started
on a desktop PC with amd graphics
or a qemu amd64 VM, both running current buster:

  $ dizzy
  GPU features: [x] GLSL [x] FBOs
  Your vendor has not defined OpenGL macro GL_FRAMEBUFFER_EXT, used at 
/usr/share/perl5/Dizzy/TextureGenerator.pm line 101.

I tested the same qemu VM with stretch and there it was working.
After some tests I found it stopped working when
libopengl-perl in version 0.7000+dfsg-1
entered testing in 2017-08-12.
But I am uncertain if the fault is
in package dizzy or libopengl-perl.

Kind regards,
Bernhard



-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-1-amd64 (SMP w/16 CPU cores)
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 dizzy depends on:
ii  libconvert-color-perl  0.11-2
ii  libopengl-perl 0.7000+dfsg-1+b1
ii  libsdl-perl2.548-1+b1
ii  perl   5.28.1-3

dizzy recommends no packages.

dizzy suggests no packages.

-- no debconf information

Bug#886496: libopengl-perl: glutTimerFunc: Segmentation fault

[Bernhard Übelacker]

Dear Maintainer,
I tried to have a look at this segfault.

It seems this is a case of pointer truncation.

In following location [1] a pointer gets casted to int (pogl_glut.xs:1021)
and stored in freeglut_callbacks.c:115 into field ID of a SFG_Timer struct.

This leads later [2] to the crash when in Perl_av_fetch that truncated
pointer is tried to be dereferenced.

Therefore this function seems broken on all architectures
where sizeof(void*) > sizeof(int).

I can just guess from the field name ID, that this field
might not be intended to store pointers and therefore
libopengl-perl might use some kind of mapping of pointers to IDs.

Kind regards,
Bernhard


[1]
Thread 1 "perl" hit Breakpoint 1, glutTimerFunc 
(timeOut=timeOut@entry=1000, callback=callback@entry=0x7785cf90 
, timerID=timerID@entry=1434891376) at 
freeglut_callbacks.c:98
98  {
(gdb) next
101 FREEGLUT_EXIT_IF_NOT_INITIALISED ( "glutTimerFunc" );
(gdb) 
98  {
(gdb) 
101 FREEGLUT_EXIT_IF_NOT_INITIALISED ( "glutTimerFunc" );
(gdb) 
103 if( (timer = fgState.FreeTimers.Last) )
(gdb) 
109 if( ! (timer = malloc(sizeof(SFG_Timer))) )
(gdb) 
114 timer->Callback  = callback;
(gdb) 
115 timer->ID= timerID;
(gdb) print timerID
$1 = 1434891376
(gdb) print/x timerID
$2 = 0x5586b470
(gdb) up
#1  0x77865a14 in XS_OpenGL_glutTimerFunc (my_perl=, 
cv=) at pogl_glut.xs:1021
1021glutTimerFunc(msecs, 
generic_glut_timer_handler, (int)handler_data);
(gdb) print handler_data
$3 = (AV *) 0x5586b470
(gdb) bt
#0  glutTimerFunc (timeOut=timeOut@entry=1000, 
callback=callback@entry=0x7785cf90 , 
timerID=timerID@entry=1434891376) at freeglut_callbacks.c:115
#1  0x77865a14 in XS_OpenGL_glutTimerFunc (my_perl=, 
cv=) at pogl_glut.xs:1021
#2  0x5563fd11 in Perl_pp_entersub ()
#3  0x55636026 in Perl_runops_standard ()
#4  0x555b2097 in perl_run ()
#5  0x55588402 in main ()


[2]
(gdb) cont
Continuing.

Thread 1 "perl" received signal SIGSEGV, Segmentation fault.
0x55634b03 in Perl_av_fetch ()
(gdb) bt
#0  0x55634b03 in Perl_av_fetch ()
#1  0x7785cfcd in generic_glut_timer_handler (value=1434891376) at 
pogl_glut.xs:452
#2  0x772dae24 in fghCheckTimers () at freeglut_main.c:324
#3  glutMainLoopEvent () at freeglut_main.c:1521
#4  0x772db6a5 in glutMainLoop () at freeglut_main.c:1571
#5  0x778680d4 in XS_OpenGL_glutMainLoop (my_perl=, 
cv=0x55c33d98) at pogl_glut.c:791
#6  0x5563fd11 in Perl_pp_entersub ()
#7  0x55636026 in Perl_runops_standard ()
#8  0x555b2097 in perl_run ()
#9  0x55588402 in main ()
(gdb) up
#1  0x7785cfcd in generic_glut_timer_handler (value=1434891376) at 
pogl_glut.xs:452
452 handler = *av_fetch(handler_data, 0, 0);
(gdb) print handler_data
$4 = (AV *) 0x5586b470
(gdb) up
#2  0x772dae24 in fghCheckTimers () at freeglut_main.c:324
324 timer->Callback( timer->ID );
(gdb) print timer->ID
$5 = 1434891376
(gdb) print/x timer->ID
$6 = 0x5586b470

# Buster amd64 qemu VM


apt install systemd-coredump gdb mc xserver-xorg lightdm openbox libopengl-perl 
libopengl-perl-dbgsym freeglut3-dbgsym
apt install devscripts dpkg-dev


systemctl start lightdm


mkdir source/libopengl-perl/orig -p
cdsource/libopengl-perl/orig
apt source libopengl-perl
cd

mkdir source/freeglut3/orig -p
cdsource/freeglut3/orig
apt source freeglut3
cd


export DISPLAY=:0
perl -e 'use OpenGL ":all"; glutInit(); glutCreateWindow("title"); 
glutTimerFunc(1000,sub{}); glutMainLoop();'




benutzer@debian:~$ perl -e 'use OpenGL ":all"; glutInit(); 
glutCreateWindow("title"); glutTimerFunc(1000,sub{}); glutMainLoop();'
Speicherzugriffsfehler (Speicherabzug geschrieben)


root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Mon 2019-01-07 17:52:34 CET   21003  1000  1000  11 present   /usr/bin/perl

root@debian:~# coredumpctl gdb 21003
   PID: 21003 (perl)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 11 (SEGV)
 Timestamp: Mon 2019-01-07 17:52:33 CET (28s ago)
  Command Line: perl -e use OpenGL ":all"; glutInit(); 
glutCreateWindow("title"); glutTimerFunc(1000,sub{}); glutMainLoop();
Executable: /usr/bin/perl
 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: acee30c7da674fe9bd5375e03eb824e7
Machine ID: 32f43b50ac8c4b21941bc0b02f8e7811
  Hostname: debian
   Storage: 

Bug#918410: [qtcreator] qtcreator freezes during startup

[Bernhard Übelacker]

Hello Johannes,
thanks for your fast respone.

Can you repeat that gdb command with following additional
dbgsym packages installed, to complete the backtraces:

libxcb1-dbgsym libqt5gui5-dbgsym libqt5widgets5-dbgsym libqt5gui5-dbgsym 
libqt5dbus5-dbgsym libqt5core5a-dbgsym libglib2.0-0-dbgsym 
libgl1-mesa-dri-dbgsym libqt5qml5-dbgsym

As an distant observer I cannot say if the "clang code model"
thing deserves its own separate bug, has to be better decided by
the package maintainers...

If it shows up just sometimes you probably can describe your
cpu and number of cores?
Is it hanging too, if you start qtcreator with following command:

taskset -c 0 qtcreator

Kind regards,
Bernhard




signature.asc
Description: OpenPGP digital signature

Bug#918370: libqt5gui5: Krita crashes with with QT 5.11.3

[Bernhard Übelacker]

Control: reassign 918370 krita 1:4.1.7+dfsg-1
Control: tags 918370 + upstream fixed-upstream patch

Hello Johnny, dear Maintainer
I tried to get some more information, but I think it is not
reproducable without that tablet hardware.

For future bug reports it would be very helpful if debug symbols
get installed before retrieving the backtrace [1].

Find below the last frames what I assume they look like.

That looks really similar to upstream bug report [2].
And that report [2] has a duplicate [3], that seems to
be opened by you. It would have also been very helpful
if you noted that you already opened that bug upstream,
and got already some feedback there.

[2] points to two commits for each branches master and krita/4.1.

Kind regards,
Bernhard


[1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols
[2] https://bugs.kde.org/show_bug.cgi?id=401988
[3] https://bugs.kde.org/show_bug.cgi?id=402844


#0  0x7fa49789485b in raise () from /lib/x86_64-linux-gnu/libc.so.6: 
0x7fa497894859 <__GI_raise+265>: syscall
#1  0x7fa49787f535 in abort () from /lib/x86_64-linux-gnu/libc.so.6: 
0x7fa49787f530 <+284>:   callq  0x7fa497894750 <__GI_raise>
#2  0x7fa4978d6718 in __libc_message () from 
/lib/x86_64-linux-gnu/libc.so.6: 0x7fa4978d6713 <__libc_message+707>: 
callq  0x7fa49787f414 <__GI_abort>
#3  0x7fa4978dce3a in malloc_printerr () from 
/lib/x86_64-linux-gnu/libc.so.6: 0x7fa4978dce35 : 
callq  0x7fa4978d6450 <__libc_message>
#4  0x7fa4978de91d in _int_free () from /lib/x86_64-linux-gnu/libc.so.6: 
0x7fa4978de918 <_int_free+1608>: callq  0x7fa4978dce20 
#5  0x7fa4981dfcd0 in QTabletEvent::~QTabletEvent() () from 
/usr/lib/x86_64-linux-gnu/libQt5Gui.so.5: 0x7fa4981dfccb 
:   callq  0x7fa4981864e0 <_ZdlPvm@plt>
#6  0x7fa499df9497 in processTabletEvent () from 
/usr/lib/x86_64-linux-gnu/libkritaui.so.17: 0x7fa499df9492 
:callq 
 0x7fa499961660 <_ZN12QTabletEventD1Ev@plt>
#7  0x7fa499df3105 in QXcbConnection::xi2ReportTabletEvent () from 
/usr/lib/x86_64-linux-gnu/libkritaui.so.17: 0x7fa499df3100 
: 
  callq  0x7fa499df97a0 , double, int, 
int, double, double, int, long long, QFlags)>
#8  0x7fa499df3464 in QXcbConnection::xi2HandleTabletEvent () from 
/usr/lib/x86_64-linux-gnu/libkritaui.so.17: 0x7fa499df345f 
: callq  0x7fa499df2ef0 

#9  0x7fa499df7119 in QXcbConnection::xi2HandleEvent () from 
/usr/lib/x86_64-linux-gnu/libkritaui.so.17: 0x7fa499df7114 
:callq  0x7fa499df3360 

#10 0x7fa499dfa7f8 in KisXi2EventFilter::nativeEventFilter (eventType=..., 
result=, message=0x7fa48800f970, this=0x7fa49ac832c0 
<_ZZN12_GLOBAL__N_116Q_QGS_s_instance13innerFunctionEvE6holder>) at 
./libs/ui/input/wintab/kis_xi2_event_filter.cpp:115
...

Bug#918339: dovecot-mysql: dovecot/auth segfaults with double-free in mysql_close() / passdb_deinit()

[Bernhard Übelacker]

Hello Dominik Röttsches,
the missing debug symbols for libmariadbclient.so.18
might hide in libmariadb3-dbgsym.

You may also want to install these packages too:
  dovecot-core-dbgsym dovecot-mysql-dbgsym

They should be available in a different debug symbol
repository described in [1].

I had a look at the stack without debug information and
added the line information where I would expect them.

Kind regards,
Bernhard

[1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols


#4  0x7f59d8d6791d in _int_free (av=0x7f59d8ea1c40 , 
p=0x564222bd44e0, have_lock=) at malloc.c:4193
#5  0x7f59d8c1ea8e in mysql_close (): libmariadbclient.so.18: : file 
./libmariadb/libmariadb/mariadb_lib.c, line 1921.
#6  0x7f59d91801fe in ?? (): libdriver_mysql.so: driver_mysql_deinit_v: 
file driver-mysql.c, line 314.
#7  0x564220be2a14 in ?? (): sql_deinit: file sql-api.c, line 122.
#8  0x564220bd88f1 in db_sql_unref (): file db-sql.c, line 134.
#9  0x564220bcd92e in passdb_deinit (): file passdb.c, line 266.
#10 0x564220bb7099 in auths_deinit (): file auth.c, line 333.
#11 0x564220bb5e0c in main (): file main.c, line 271.


(gdb) list ./libmariadb/libmariadb/mariadb_lib.c:1911,1935
1911void STDCALL
1912mysql_close(MYSQL *mysql)
1913{
1914  if (mysql)/* Some simple 
safety */
1915  {
1916if (mysql->extension && mysql->extension->conn_hdlr)
1917{
1918  MA_CONNECTION_HANDLER *p= mysql->extension->conn_hdlr;
1919  if (p->plugin->close)
1920p->plugin->close(mysql);
1921  free(p);
1922  /* Fix for CONC-294: Since we already called plugin->close 
function
1923 we need to prevent that mysql_close_slow_part (which sends 
COM_QUIT
1924 to the server) will be handled by plugin again. */
1925  mysql->extension->conn_hdlr= NULL;
1926}
1927

# Unstable amd64 qemu VM

apt update
apt dist-upgrade

reboot


apt install systemd-coredump psmisc mc gdb dovecot-mysql dovecot-core-dbgsym 
dovecot-mysql-dbgsym libmariadb3-dbgsym
apt install dpkg-dev devscripts



mkdir source/dovecot/orig -p
cdsource/dovecot/orig
apt source dovecot
cd




mkdir source/libmariadb3/orig -p
cdsource/libmariadb3/orig
apt source libmariadb3
cd





cp ./conf.d/auth-sql.conf.ext ./conf.d/auth-sql.conf -a


LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libmariadbclient.so.18:/usr/lib/dovecot/libdovecot-sql.so:/usr/lib/dovecot/modules/auth/libdriver_mysql.so
 \
gdb -q \
-ex 'set pagination off' \
-ex 'set width 0' \
-ex 'directory 
/home/benutzer/source/dovecot/orig/dovecot-2.3.4/src/auth' \
-ex 'directory 
/home/benutzer/source/libmariadb3/orig/mariadb-10.3-10.3.11' \
-ex 'directory 
/home/benutzer/source/dovecot/orig/dovecot-2.3.4/src/lib-sql' \
-ex 'b main' \
-ex 'run' \
--args /usr/lib/dovecot/auth


disassemble db_sql_unref
disassemble db_sql_unref,db_sql_unref+92
disassemble /m db_sql_unref,db_sql_unref+92
list db_sql_unref
b *0x5558a8f1










#1  0x7f59d8d08535 in __GI_abort () at abort.c:79
#2  0x7f59d8d5f718 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7f59d8e6a29a "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x7f59d8d65e3a in malloc_printerr (str=str@entry=0x7f59d8e6bf60 
"free(): double free detected in tcache 2") at malloc.c:5382
#4  0x7f59d8d6791d in _int_free (av=0x7f59d8ea1c40 , 
p=0x564222bd44e0, have_lock=) at malloc.c:4193
#5  0x7f59d8c1ea8e in mysql_close () from 
target:/usr/lib/x86_64-linux-gnu/libmariadbclient.so.18
#6  0x7f59d91801fe in ?? () from 
target:/usr/lib/dovecot/modules/auth/libdriver_mysql.so
#7  0x564220be2a14 in ?? ()
#8  0x564220bd88f1 in db_sql_unref ()
#9  0x564220bcd92e in passdb_deinit ()
#10 0x564220bb7099 in auths_deinit ()
#11 0x564220bb5e0c in main ()



#1  0x7f59d8d08535 in __GI_abort () at abort.c:79
#2  0x7f59d8d5f718 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7f59d8e6a29a "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x7f59d8d65e3a in malloc_printerr (str=str@entry=0x7f59d8e6bf60 
"free(): double free detected in tcache 2") at malloc.c:5382
#4  0x7f59d8d6791d in _int_free (av=0x7f59d8ea1c40 , 
p=0x564222bd44e0, have_lock=) at malloc.c:4193
#5  0x7f59d8c1ea8e in mysql_close () from 
target:/usr/lib/x86_64-linux-gnu/libmariadbclient.so.18
1921  free(p);
   0x77f9da86 : mov%r12,%rdi
   0x77f9da89 : callq  0x77f91720 

1922  /* Fix for CONC-294: Since we already called plugin->close 
function
1923 we need to prevent that mysql_close_slow_part (which sends 
COM_QUIT
1924 to the server) will be handled by plugin again. */
1925  mysql->extension->conn_hdlr= NULL;
 

Bug#910571: qemu-user-static i386 (and x86-64) on armel host errors while loading shared libraries

[Bernhard Übelacker]

Hello Michael Tokarev, hello Theo

I have now another machine at hand where I currently have
buster installed, where today qemu-user-static in
version 3.1 appeared.

So I did some tests.
It still shows the issue reported by Theo:

root@qnap-119p-ii:~# chroot /tmp/buster-chroot-i386 /bin/bash
/bin/bash: error while loading shared libraries: b/i38/-li6ux-nnu/g: nnoa 
retd fale iatadlib/i38/-li6ux-nnu/g: o

I changed the kernel alignment configuration like this:

echo 2 > /proc/cpu/alignment

Then bash, uname and ls are working:

root@qnap-119p-ii:~# chroot /tmp/buster-chroot-i386 /bin/bash
I have no name!@qnap-119p-ii:/# uname -a
Linux qnap-119p-ii 4.19.0-1-marvell #1 Debian 4.19.12-1 (2018-12-22) i686 
GNU/Linux


Unfortunately the chroot setup cannot finish and fails trying to run:
chroot "/tmp/buster-chroot-i386" dpkg-deb -f 
/var/cache/apt/archives/dpkg_1.19.2_i386.deb Version
But that is a different issue.

Attached are some more information about the
system and tested commands.

Kind regards,
Bernhard
root@qnap-119p-ii:~# lscpu
Architecture:armv5tel
Byte Order:  Little Endian
CPU(s):  1
On-line CPU(s) list: 0
Thread(s) per core:  1
Core(s) per socket:  1
Socket(s):   1
Vendor ID:   Marvell
Model:   1
Model name:  Feroceon 88FR131
Stepping:0x2
CPU max MHz: 2000,
CPU min MHz: 500,
BogoMIPS:400.00
Flags:   swp half thumb fastmult edsp


root@qnap-119p-ii:~# cat /proc/cpuinfo 
processor   : 0
model name  : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS: 400.00
Features: swp half thumb fastmult edsp 
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant : 0x2
CPU part: 0x131
CPU revision: 1

Hardware: Marvell Kirkwood (Flattened Device Tree)
Revision: 
Serial  : 


root@qnap-119p-ii:~# cat /etc/debian_version 
buster/sid






export PKG="qemu-user-static debootstrap systemd-coredump"; apt install $PKG; 
apt-mark auto $PKG


root@qnap-119p-ii:/tmp# qemu-i386-static --version
qemu-i386 version 3.1.0 (Debian 1:3.1+dfsg-2)
Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers





root@qnap-119p-ii:/tmp# qemu-i386-static 910571_test
12

# should be 123








# https://www.kernel.org/doc/Documentation/arm/mem_alignment


root@qnap-119p-ii:/tmp# echo 1 > /proc/cpu/alignment
root@qnap-119p-ii:/tmp# cat /proc/cpu/alignment 
User:   28
System: 0 (  (null))
Skipped:0
Half:   0
Word:   0
DWord:  0
Multi:  0
User faults:1 (warn)

root@qnap-119p-ii:/tmp# qemu-i386-static 910571_test
12

root@qnap-119p-ii:/tmp# cat /proc/cpu/alignment 
User:   186
System: 0 (  (null))
Skipped:0
Half:   0
Word:   0
DWord:  0
Multi:  0
User faults:1 (warn)

dmesg:
[ 1070.346332] Alignment trap: qemu-i386-stati (5664) PC=0x6058e450 
Instr=0xe1d580b0 Address=0x080b01ff FSR 0x001
[ 1070.356571] Alignment trap: qemu-i386-stati (5664) PC=0x6058e690 
Instr=0xe1d440b0 Address=0x40800f01 FSR 0x001
... 154 lines ...
[ 1072.021357] Alignment trap: qemu-i386-stati (5664) PC=0x6058e450 
Instr=0xe1d580b0 Address=0x080b02af FSR 0x001
[ 1072.041018] Alignment trap: qemu-i386-stati (5664) PC=0x60592fd0 
Instr=0xe1d450b0 Address=0x080ad009 FSR 0x001







root@qnap-119p-ii:/tmp# echo 2 > /proc/cpu/alignment
root@qnap-119p-ii:/tmp# cat /proc/cpu/alignment 
User:   186
System: 0 (  (null))
Skipped:0
Half:   0
Word:   0
DWord:  0
Multi:  0
User faults:2 (fixup)

root@qnap-119p-ii:/tmp# qemu-i386-static 910571_test
123

root@qnap-119p-ii:/tmp# cat /proc/cpu/alignment 
User:   234
System: 0 (  (null))
Skipped:0
Half:   46
Word:   2
DWord:  0
Multi:  0
User faults:2 (fixup)









# The real thing, with "echo 2 > /proc/cpu/alignment"

mkdir /tmp/buster-chroot-i386/usr/bin -p
cp -a /usr/bin/qemu-i386-static /tmp/buster-chroot-i386/usr/bin/

debootstrap --arch=i386 buster /tmp/buster-chroot-i386 
http://192.168.178.25:/debian-10-buster-deb.debian.org/




root@qnap-119p-ii:~# debootstrap --arch=i386 buster /tmp/buster-chroot-i386 
http://192.168.178.25:/debian-10-buster-deb.debian.org/
I: Target architecture can be executed
I: Retrieving InRelease 
I: Checking Release signature
I: Valid Release signature (key id 16E90B3FDF65EDE3AA7F323C04EE7237B7D453EC)
I: Retrieving Packages 
I: Validating Packages 
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Checking component main on 
http://192.168.178.25:/debian-10-buster-deb.debian.org...
I: Retrieving libacl1 2.2.52-3+b1
I: Validating libacl1 2.2.52-3+b1
I: Retrieving adduser 3.118
I: Validating adduser 3.118
I: Retrieving libapparmor1 2.13.1-3+b1
I: Validating 

Bug#910571: qemu-user-static i386 (and x86-64) on armel host errors while loading shared libraries

[Bernhard Übelacker]

Hello Michael Tokarev,
I am sorry, I have missed your mail from december.

Thanks for the information, I will report back
when I have tested it. (Forwarding to the submitter too.)

Kind regards,
Bernhard


Am 03.01.19 um 21:02 schrieb Michael Tokarev:
> Control: tag -1 + moreinfo
> 
> Adding a bit more info on this.
> 
> As one of QEMU developers puts this:
> 
>  this bu is probably "we don't work on armv5 hardware" -- likely we're
> assuming nonaligned accesses are sane
>  ISTR there's a kernel config thing for "fix up misaligned accesses",
> which should be flippable to make it work
>  get your bug reporter to check what they have /proc/cpu/alignment set to
>  it should be '2' IMHO, which makes it fix things up
>  this will not run at all fast, of course, because it's trapping to the
> kernel for unaligned accesses,
>  but then the hardware is ancient anyhow
>  alternative 2 is to get something more modern that's at least armv6
> 
> Please take a look!
> 
> Thanks,
> 
> /mjt




signature.asc
Description: OpenPGP digital signature

Bug#917959: octave: segfault on complex dot product

[Bernhard Übelacker]

Hello Adam Knapp,
you might run octave inside gdb to retrieve a backtrace of the crash.

Run below command inside a terminal application and you should
receive a file gdb-octave*.log that you might forward to this bug.

  gdb -q -batch -ex 'set pagination off' -ex 'set width 0' -ex run -ex 'bt 
full' --args octave  2>&1 | tee -a gdb-octave_$(date +%Y-%m-%d_%H-%M-%S).log

Even better would be if debug symbol packages would be installed before
like described in [1].

Kind regards,
Bernhard

[1] https://wiki.debian.org/HowToGetABacktrace

Bug#892871: tome: Segfaults when started

[Bernhard Übelacker]

Control: reassign 892871 libasan4 7.3.0-5
Control: found 892871 7.3.0-12
Control: fixed 892871 7.3.0-13

Dear Maintainer,
did some tests with snapshot.debian.org and found
that crash does not happen anymore since libasan4:i386 (7.3.0-13).

Kind regards,
Bernhard

Bug#914160: Bug#912376: fixed in qcontrol 0.5.6-2

[Bernhard Übelacker]

Hello Ian, hello Ted,
yesterday I tried to reinstall that device with the latest
buster installer - but unfortunately I was already too late,
the archive moved already too far away:
No kernel modules were found.

Therefore I did the reinstall with the stretch installer
and upgraded to buster, like in my last attempt from november.

There I can confirm the installation of the qcontrol package
failed while running the stretch kernel:
(linux-image-4.9.0-8-marvell:armel 4.9.130-2)

apt dist-upgrade
...
Setting up qcontrol (0.5.6-2) ...
Installing new version of config file /etc/qcontrol/ts209.lua ...
Installing new version of config file /etc/qcontrol/ts219.lua ...
Installing new version of config file /etc/qcontrol/ts41x.lua ...
update-initramfs: deferring update (trigger activated)
Created symlink 
/etc/systemd/system/multi-user.target.wants/qcontrol.service → 
/lib/systemd/system/qcontrol.service.
Created symlink 
/etc/systemd/system/multi-user.target.wants/qcontrold.service → 
/lib/systemd/system/qcontrold.service.
Created symlink /etc/systemd/system/sockets.target.wants/qcontrold.socket → 
/lib/systemd/system/qcontrold.socket.
A dependency job for qcontrold.service failed. See 'journalctl -xe' for 
details.
invoke-rc.d: initscript qcontrold, action "start" failed.
● qcontrold.service - qcontrold
Loaded: loaded (/lib/systemd/system/qcontrold.service; enabled; vendor 
preset: enabled)
Active: inactive (dead)

Dez 31 02:20:17 qnap-119p-ii systemd[1]: Dependency failed for qcontrold.
Dez 31 02:20:17 qnap-119p-ii systemd[1]: qcontrold.service: Job 
qcontrold.service/start failed with result 'dependency'.
dpkg: error processing package qcontrol (--configure):
installed qcontrol package post-installation script subprocess returned 
error exit status 1
Setting up libunbound8:armel (1.8.1-1+b1)
...


journalctl
Dez 31 02:20:17 qnap-119p-ii systemd[1]: 
dev-input-by\x2dpath-platform\x2dgpio_keys\x2devent.device: Job 
dev-input-by\x2dpath-platform\x2dgpio_keys\x2devent.device/start timed out.
Dez 31 02:20:17 qnap-119p-ii systemd[1]: Timed out waiting for device 
dev-input-by\x2dpath-platform\x2dgpio_keys\x2devent.device.
Dez 31 02:20:17 qnap-119p-ii systemd[1]: Dependency failed for qcontrold.
Dez 31 02:20:17 qnap-119p-ii systemd[1]: qcontrold.service: Job 
qcontrold.service/start failed with result 'dependency'.
Dez 31 02:20:17 qnap-119p-ii systemd[1]: 
dev-input-by\x2dpath-platform\x2dgpio_keys\x2devent.device: Job 
dev-input-by\x2dpath-platform\x2dgpio_keys\x2devent.device/start failed with 
result 


But after booting the buster kernel qcontrol could setup successfully:

root@qnap-119p-ii:~# apt install -f
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.   
Statusinformationen werden eingelesen Fertig
Die folgenden Pakete wurden automatisch installiert und werden nicht mehr 
benötigt:
dh-python libbind9-140 libdns162 libicu57 libisc160 libisccc140 
libisccfg140 liblwres141 libperl5.24 libpython3.5-minimal libpython3.5-stdlib 
python3-distutils python3-lib2to3 python3.5
python3.5-minimal rename sgml-base xml-core
Verwenden Sie »apt autoremove«, um sie zu entfernen.
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
1 nicht vollständig installiert oder entfernt.
Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt.
qcontrol (0.5.6-2) wird eingerichtet ...
update-initramfs: deferring update (trigger activated)
Trigger für initramfs-tools (0.132) werden verarbeitet ...
update-initramfs: Generating /boot/initrd.img-4.19.0-1-marvell
kirkwood-qnap: machine: QNAP TS219 family
Using DTB: kirkwood-ts219-6282.dtb
Installing /usr/lib/linux-image-4.19.0-1-marvell/kirkwood-ts219-6282.dtb 
into /boot/dtbs/4.19.0-1-marvell/./kirkwood-ts219-6282.dtb
Taking backup of kirkwood-ts219-6282.dtb.
Installing new kirkwood-ts219-6282.dtb.
Installing /usr/lib/linux-image-4.19.0-1-marvell/kirkwood-ts219-6282.dtb 
into /boot/dtbs/4.19.0-1-marvell/./kirkwood-ts219-6282.dtb
Taking backup of kirkwood-ts219-6282.dtb.
Installing new kirkwood-ts219-6282.dtb.
flash-kernel: installing version 4.19.0-1-marvell
flash-kernel: appending 
/usr/lib/linux-image-4.19.0-1-marvell/kirkwood-ts219-6282.dtb to kernel
Generating kernel u-boot image... done.
Flashing kernel (using 2047906/2097152 bytes)... done.
Flashing initramfs (using 4477212/9437184 bytes)... done.

Kind regards,
Bernhard

Bug#917780: slic3r: Segfault in stl_fix_normal_directions

[Bernhard Übelacker]

Dear Maintainer, hello Philipp Marek
tried to have a look at this backtrace.
Unfortunately I could not reproduce a crash with a random test file.

See the same backtrace with all needed debug symbols below.

It points to following line 147:

(gdb) list
144   /* If this edge of the facet is connected: */
145   if(stl->neighbors_start[facet_num].neighbor[j] != -1) {
146 /* If we haven't fixed this facet yet, add it to the list: 
*/
147 if(norm_sw[stl->neighbors_start[facet_num].neighbor[j]] != 
1) {
148   /* Add node to beginning of list. */
149   newn = (struct stl_normal*)malloc(sizeof(struct 
stl_normal));
150   if(newn == NULL) perror("stl_fix_normal_directions");
151   newn->facet_num = 
stl->neighbors_start[facet_num].neighbor[j];

More exactly to that instruction:

(gdb) disassemble /m 
stl_fix_normal_directions,stl_fix_normal_directions+696 
Dump of assembler code from 0x775a7f50 to 0x775a8208:
88  stl_fix_normal_directions(stl_file *stl) {
...
146 /* If we haven't fixed this facet yet, add it to the list: 
*/
147 if(norm_sw[stl->neighbors_start[facet_num].neighbor[j]] != 
1) {
   0x775a8042 :   
movslq %esi,%rax
   0x775a8045 :   mov 
   %esi,0x8(%rsp)
=> 0x775a8049 :   
cmpb   $0x1,(%r15,%rax,1)
   0x775a804e :   je  
   0x775a8079 

148   /* Add node to beginning of list. */



Unfortunately I assume that exact file would help the maintainer
or upstream to find a fix, if that file could be published.


Kind regards,
Bernhard


(gdb) bt
#0  0x775a8049 in stl_fix_normal_directions 
(stl=stl@entry=0x5983b820) at src/admesh/normals.c:147
#1  0x7775b427 in Slic3r::TriangleMesh::repair (this=0x5983b820) at 
src/libslic3r/TriangleMesh.cpp:164
#2  Slic3r::TriangleMesh::repair (this=0x5983b820) at 
src/libslic3r/TriangleMesh.cpp:144
#3  0x775972a8 in Slic3r::ModelObject::repair (this=0x55940660) at 
src/libslic3r/Model.cpp:583
#4  0x7749c46f in XS_Slic3r__Model__Object_repair (my_perl=, cv=) at /usr/bin/perl -MExtUtils::XSpp::Cmd -e xspp -- -t 
"../xsp/typemap.xspt"  "../xsp/Model.xsp":971
#5  0x5563fd11 in Perl_pp_entersub (my_perl=0x55868260) at 
pp_hot.c:5232
#6  0x55636026 in Perl_runops_standard (my_perl=0x55868260) at 
run.c:42
#7  0x555a9f02 in Perl_call_sv (my_perl=my_perl@entry=0x55868260, 
sv=0x58568390, flags=flags@entry=13) at perl.c:3021
#8  0x76d35fcd in wxPliEventCallback::Handler (this=, 
event=...) at cpp/e_cback.cpp:93
#9  0x762627ae in wxEvtHandler::ProcessEventIfMatchesId (event=..., 
handler=, entry=...) at ../include/wx/app.h:439
#10 wxEvtHandler::ProcessEventIfMatchesId (entry=..., handler=, 
event=...) at ../src/common/event.cpp:1365
#11 0x76262b2a in wxEvtHandler::SearchDynamicEventTable 
(this=0x56791da0, event=...) at ../src/common/event.cpp:1749
#12 0x76262bc0 in wxEvtHandler::TryHereOnly (this=0x56791da0, 
event=...) at ../src/common/event.cpp:1583
#13 0x76262c73 in wxEvtHandler::TryBeforeAndHere (event=..., 
this=0x56791da0) at ../include/wx/event.h:3692
#14 wxEvtHandler::ProcessEventLocally (this=0x56791da0, event=...) at 
../src/common/event.cpp:1520
#15 0x76262d11 in wxEvtHandler::ProcessEvent (this=0x56791da0, 
event=...) at ../src/common/event.cpp:1493
#16 0x7677840b in wxWindowBase::TryAfter (this=0x59424610, 
event=...) at ../include/wx/window.h:846
#17 0x76262ab7 in wxEvtHandler::SafelyProcessEvent (this=, event=...) at ../src/common/event.cpp:1611
#18 0x7677992c in wxWindowBase::HandleWindowEvent 
(this=this@entry=0x59424610, event=...) at ../include/wx/window.h:846
#19 0x7672f9e5 in wxMenuBase::SendEvent 
(this=this@entry=0x590d2f60, itemid=itemid@entry=117, checked=) at ../src/common/menucmn.cpp:666
#20 0x7662f10b in menuitem_activate (item=0x593a1730) at 
../include/wx/menuitem.h:92
#21 menuitem_activate (item=0x593a1730) at ../src/gtk/menu.cpp:553
#22 0x75664b6d in g_closure_invoke (closure=0x5941c810, 
return_value=0x0, n_param_values=1, param_values=0x7fffd9c0, 
invocation_hint=0x7fffd940) at ../../../../gobject/gclosure.c:810
#23 0x756778f3 in signal_emit_unlocked_R 
(node=node@entry=0x56886910, detail=detail@entry=0, 
instance=instance@entry=0x59266cc0, 
emission_return=emission_return@entry=0x0, 
instance_and_params=instance_and_params@entry=0x7fffd9c0) at 
../../../../gobject/gsignal.c:3635
#24 0x75680882 in g_signal_emit_valist (instance=, 
signal_id=, detail=, 
var_args=var_args@entry=0x7fffdb70) at ../../../../gobject/gsignal.c:3391
#25 0x75680ecf in g_signal_emit 
(instance=instance@entry=0x59266cc0, signal_id=, 

Bug#917437: gkrellm: Please switch Build-Depends to libsensors-dev from libsensors4-dev

[Bernhard Übelacker]

Dear maintainer,
is this bug currently causing not being able to install gkrellm in a
current buster system where some packages depending on libsensors5 are
already installed?

I guess this is an unfortunate situation if it stays until the buster
release, as following is currently not possible in testing:

  apt install libsensors4 libsensors5

Kind regards,
Bernhard

Bug#916264: apache2: stopping or restarting apache often causes segfault when fcgid is enabled

[Bernhard Übelacker]

Dear Maintainer, hello Mark Buranyi,
tried to reproduce inside a Stretch amd64 qemu VM.

I assume the first  is calling the
SIGTERM handler [frame #9].
Unfortunately it looks like the module containing sig_term was already
unloaded at that time (mod_mpm_event.so).
Therefore executing that now unloaded memory causes now a signal 11-SIGSEGV
to be received, that I guess ends up executing some function pointer whose
shared library is already gone (and just by "accident" contained most
of the time in libexpat.so).

So the main problem seems to be executing a signal handler residing
in an already unloaded module.

That signal handler does not exist in testing version 2.4.37-1 of apache.
It looks like it get moved in upstream commit [1], released with 2.4.26:
MPMs unix: Place signals handlers and helpers out of DSOs to avoid
a possible crash if a signal is caught during (graceful) restart.
PR 60487.

This bug looks like an duplicate of #867565.

Kind regards,
Bernhard


[1] 
https://github.com/apache/httpd/commit/c6ca4f85b722f0abab183c94a8e550eeb87934c6#diff-895d7e9f8add746606c82027dabc04d4
#867565 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867565


(gdb) bt
#0  0x7ff5fd64b7a0 in ?? ()
#1  0x55d899cbf15e in ap_run_mpm_query (query_code=query_code@entry=2, 
result=result@entry=0x7fff2c8361ec, _rv=_rv@entry=0x7fff2c8361c4) at 
mpm_common.c:97
#2  0x55d899cbfeee in ap_mpm_query (query_code=query_code@entry=2, 
result=result@entry=0x7fff2c8361ec) at mpm_common.c:419
#3  0x55d899cdfeb4 in log_tid (info=, arg=, 
buf=0x7fff2c83633e "", buflen=8130) at log.c:612
#4  0x55d899ce0dd6 in do_errorlog_default (buflen=8192, 
args=0x7fff2c83a380, errstr_fmt=0x55d899d077d8 "AH00060: seg fault or similar 
nasty error detected in the parent process", errstr_end=, 
errstr_start=, buf=0x7fff2c836300 "[Sat Dec 29 
14:57:57.340512 2018] [core:notice] [pid 2517:tid ", info=0x7fff2c8362b0) at 
log.c:944
#5  log_error_core (file=0x55d899d076ac "mpm_unix.c", line=989, module_index=0, 
level=, status=0, s=, c=, r=0x0, 
pool=0x0, fmt=0x55d899d077d8 "AH00060: seg fault or similar nasty error 
detected in the parent process", args=0x7fff2c83a380) at log.c:1270
#6  0x55d899ce12b7 in ap_log_error_ (file=file@entry=0x55d899d076ac 
"mpm_unix.c", line=line@entry=989, module_index=module_index@entry=0, 
level=level@entry=5, status=status@entry=0, s=, 
fmt=0x55d899d077d8 "AH00060: seg fault or similar nasty error detected in the 
parent process") at log.c:1319
#7  0x55d899ce8080 in sig_coredump (sig=11) at mpm_unix.c:986
#8  
#9  0x7ff5fd64b8d0 in ?? ()
#10 
#11 0x7ff6004213a3 in __select_nocancel () at 
../sysdeps/unix/syscall-template.S:84
#12 0x7ff600924245 in apr_sleep (t=t@entry=46875) at ./time/unix/time.c:246
#13 0x7ff600917ea3 in free_proc_chain (procs=0x7ff60113b718) at 
./memory/unix/apr_pools.c:2483
#14 0x7ff600918b90 in apr_pool_destroy (pool=0x7ff6011de028) at 
./memory/unix/apr_pools.c:817
#15 0x7ff600918b55 in apr_pool_destroy (pool=0x7ff6011e0028) at 
./memory/unix/apr_pools.c:811
#16 0x55d899cb7ed8 in destroy_and_exit_process (process_exit_value=0, 
process=) at main.c:264
#17 0x55d899cb7c97 in main (argc=, argv=) at 
main.c:796

(gdb) info share
0x7ff5fd64b080  0x7ff5fd651ce5  Yes 
/usr/lib/apache2/modules/mod_mpm_event.so

(gdb) disassemble 0x7ff5fd64b8d0,0x7ff5fd64b8d0+0x30
Dump of assembler code from 0x7ff5fd64b8d0 to 0x7ff5fd64b900:
   0x7ff5fd64b8d0 : mov0x20a7fe(%rip),%eax# 
0x7ff5fd8560d4 

# Stretch amd64 qemu VM

apt update
apt dist-upgrade

apt install systemd-coredump psmisc gdb apache2 libapache2-mod-fcgid 
apache2-dbg libapr1-dbg


root@debian:~# a2enmod fcgid 
Module fcgid already enabled

root@debian:~# systemctl restart apache2




root@debian:~# pstree -p
systemd(1)─┬─agetty(477)
   ├─apache2(2517)─┬─apache2(2518)
   │   ├─apache2(2522)─┬─{apache2}(2525)
   │   │   ├─{apache2}(2526)
...
   │   │   └─{apache2}(2568)
   │   └─apache2(2524)─┬─{apache2}(2533)
   │   ├─{apache2}(2535)
...
   │   └─{apache2}(2578)
...





root@debian:~# gdb -q --pid 2517
Attaching to process 2517
...
(gdb) generate-core-file /root/core.2517.while-running
warning: target file /proc/2517/cmdline contained unexpected null characters
Saved corefile /root/core.2517.while-running
(gdb) detach
Detaching from program: target:/usr/sbin/apache2, process 2517
(gdb) q





root@debian:~# systemctl restart apache2




root@debian:~# journalctl -f
...
Dez 29 14:57:57 debian systemd-coredump[2650]: Process 2517 (apache2) of user 0 
dumped core.
   
   Stack trace of thread 2517:
   #0  0x7ff5fd64b7a0 n/a (n/a)

Bug#917319: libdovecot: Segfault -- service(dict) killed with signal 11

[Bernhard Übelacker]

Hello Christian Schrötter,
not being involded in dovecot packaging I looked at this crash.

That address in event_unref seems to point here:

(gdb) disassemble /m event_unref,event_unref+370
Dump of assembler code from 0x77f33d70 to 0x77f33ee2:
...
210
211 void event_unref(struct event **_event)
212 {

213 struct event *event = *_event;
0x77f33d70 :  push   %rbp
0x77f33d71 :  push   %rbx
0x77f33d72 :  sub$0x8,%rsp
0x77f33d76 :  mov(%rdi),%rbx 
 <<< $rbx loaded with what $rdi (_event?) points to.

214
215 if (event == NULL)
0x77f33d79 :  test   %rbx,%rbx
0x77f33d7c : je 0x77f33e60 

216 return;
217 *_event = NULL;
0x77f33d82 : mov0x78(%rbx),%eax 
 <<< this instruction seems to crash
0x77f33d85 : movq   $0x0,(%rdi)

218
219 i_assert(event->refcount > 0);
0x77f33d8c : test   %eax,%eax
0x77f33d8e : jle0x77e8c8ca 


220 if (--event->refcount > 0)
0x77f33d94 : sub$0x1,%eax
...


So we might assume $rbx contains here an invalid pointer.
Some lines before, $rbx seems to be loaded with what _event
points to.

Unfortunately you removed all other frames from the backtrace,
therefore it would need a maintainer to be able to reproduce the fault,
to know from where event_unref got called.

But I think it would be easier for them if you could
provide all frames of the backtrace.
Even better would be if dovecot-core-dbgsym from the debug symbol
repository could be installed like described in [1],
before analyzing the core file.

Kind regards,
Bernhard

[1] https://wiki.debian.org/HowToGetABacktrace

Bug#917359: wine32: regedit doesn't paint at Deb's wine, but winehq.org's regedit paints.

[Bernhard Übelacker]

Dear Maintainer,
as far as I found is the problem related to:
  debian/patches/generate/icons.patch

That strips away the ico files from being included in the
resources in regedit. But the treeview seems just to be shown when 
programs/regedit/treeview.c:InitTreeViewImageLists was able to
load the ico resources. The same might be true for the listview,
because a package build just with folder.ico,folderopen.ico,computer.ico
did just show the treeview (left), but not the list view (right).

This got possibly introduced in 3.14-2:
  * Rebuild automatically generated icon files.

(I would have tested, but unfortunately snapshot.debian.org
is currently "503 Service Unavailable".)

That patch might remove icons from other programs unnoticed, too.

Kind regards,
Bernhard

# buster i386 qemu VM

apt update
apt dist-upgrade

apt install xserver-xorg lightdm openbox

apt install wine

systemctl start lightdm

# login

export DISPLAY=:0
wine regedit

-> debian binary 4.0~rc2-1 shows the bug in plain buster


##


apt install devscripts dpkg-dev
apt build-dep wine

mkdir source/wine/orig -p
cdsource/wine/orig
apt source wine
cd


cd source/wine
cp orig try1 -a
cd try1/wine-4.0~rc2
dpkg-buildpackage

dpkg -i fonts-wine_4.0~rc2-1_all.deb libwine_4.0~rc2-1_i386.deb  
wine_4.0~rc2-1_all.deb wine32_4.0~rc2-1_i386.deb 

-> self built binary 4.0~rc2-1 shows the bug in plain buster


##




for p in `find -type f -iname "*.patch"`; do sed -i 's/^description: /Subject: 
/i' $p; done
for p in `find -type f -iname "*.patch"`; do sed -i 's/^author: /From: /i' $p; 
done


export 
DIR=/home/bernhard/data/emu/pc/qemu/machines/debian-10-buster-i386_minimal/sshfs/home/benutzer/source/wine/try3/wine-4.0~rc2
git am $DIR/debian/patches/debianization/addons.patch
git am $DIR/debian/patches/debianization/makefile.patch
git am $DIR/debian/patches/debianization/version-string.patch
git am $DIR/debian/patches/debianization/winemenubuilder.patch
git am $DIR/debian/patches/debianization/wineserver-persistence.patch

git am $DIR/debian/patches/disable/tests.patch
git am $DIR/debian/patches/disable/line-wrapping.patch
git am $DIR/debian/patches/disable/addons-download.patch
git am $DIR/debian/patches/disable/po-modifications.patch
git am $DIR/debian/patches/disable/blacklist-extensions.patch

git am $DIR/debian/patches/generate/icons.patch
git am $DIR/debian/patches/generate/opengl.patch
git am $DIR/debian/patches/generate/unicode.patch
git am $DIR/debian/patches/generate/request.patch

git am $DIR/debian/patches/binary-indep/manpages.patch
git am $DIR/debian/patches/binary-indep/sfnt2fon.patch

git am $DIR/debian/patches/fixes/arm.patch
git am $DIR/debian/patches/fixes/arm64.patch
git am $DIR/debian/patches/fixes/gstbase.patch
git am $DIR/debian/patches/fixes/printer-resolution.patch
git am $DIR/debian/patches/fixes/temporary-directory.patch

git am $DIR/debian/patches/warnings/arm-messages.patch
git am $DIR/debian/patches/warnings/arm-longdouble.patch
git am $DIR/debian/patches/warnings/arm64-array-bounds.patch
git am $DIR/debian/patches/warnings/arm64-excess-precision.patch
git am $DIR/debian/patches/warnings/arm64-unused-functions.patch
git am $DIR/debian/patches/warnings/arm64-uninitialized-variables.patch

git am $DIR/debian/patches/warnings/array-bounds.patch
git am $DIR/debian/patches/warnings/dword64-winmm.patch
git am $DIR/debian/patches/warnings/format-overflow.patch
git am $DIR/debian/patches/warnings/unused-functions.patch
git am $DIR/debian/patches/warnings/argument-promotion.patch
git am $DIR/debian/patches/warnings/discarded-qualifiers.patch
git am $DIR/debian/patches/warnings/uninitialized-variables.patch






bernhard@rechner:/home/bernhard/data/entwicklung/2018/wine/wine-git/wine-git$ 
git am $DIR/debianization/addons.patch
Wende an: adjust search paths for addon installers
bernhard@rechner:/home/bernhard/data/entwicklung/2018/wine/wine-git/wine-git$ 
git am $DIR/debianization/makefile.patch
Wende an: don't append wine to the default path settings
bernhard@rechner:/home/bernhard/data/entwicklung/2018/wine/wine-git/wine-git$ 
git am $DIR/debianization/version-string.patch
Wende an: winelib: Append '(Debian)' at the end of the version string.
bernhard@rechner:/home/bernhard/data/entwicklung/2018/wine/wine-git/wine-git$ 
git am $DIR/debianization/winemenubuilder.patch
Wende an: call wineDEBSUFFIX instead of wine from desktop launchers
bernhard@rechner:/home/bernhard/data/entwicklung/2018/wine/wine-git/wine-git$ 
git am $DIR/debianization/wineserver-persistence.patch
Wende an: fix wineserver manpages for Debian's default persistence value
bernhard@rechner:/home/bernhard/data/entwicklung/2018/wine/wine-git/wine-git$ 
git am $DIR/disable/tests.patch
Wende an: drop generated sources from tests Makefiles
bernhard@rechner:/home/bernhard/data/entwicklung/2018/wine/wine-git/wine-git$ 
git am $DIR/disable/line-wrapping.patch
Wende an: disable manual line wrapping in makefiles

Bug#917293:

[Bernhard Übelacker]

Hello all,
that bug sounds like a duplicate of #917167.

Kind regards,
Bernhard

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917167

Bug#917312: kinit: The kdeinit5 takes about some minutes to startup and crashed

[Bernhard Übelacker]

Dear Maintainer, hello Martin Gummi,
at least the crash seems to be exact the same as seen in #917269.

Kind regards,
Bernhard

#917269  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917269

Bug#917269: kinit: Crashes when navigating to home directory in dolphin

[Bernhard Übelacker]

Control: forwarded 917269 https://bugs.kde.org/show_bug.cgi?id=400638
Control: tags 917269 + fixed-upstream


Dear Maintainer, hello Braun Gábor,
I did a quick query in the upstream bugtracker and received
this result [1], where the user seems to even use debian
testing also, because the function address offsets do match.

Following the duplicates we find [2] and [3], the latter
has an example file attached that produces the same crash
as you reported.

A local rebuilt package with that upstream patch [4]
applied shows no crash anymore when browsing to that
folder containing the example file.

Kind regards,
Bernhard

[1] https://bugs.kde.org/show_bug.cgi?id=401791
[2] https://bugs.kde.org/show_bug.cgi?id=400638
[3] https://bugs.kde.org/show_bug.cgi?id=402522
[4] 
https://cgit.kde.org/ffmpegthumbs.git/commit/?id=b8223de8e65de6de08f2e29a398f0922fa282bbb

Bug#917269: kinit: Crashes when navigating to home directory in dolphin

[Bernhard Übelacker]

Control: reassign 917269 ffmpegthumbs 4:17.08.3-1


Dear Maintainer, hello Braun Gábor,
some informations on where and how to retrieve the debug symbol packages
is described in [1]. Maybe with them you can confirm my findings which
are just based on the offsets of the function addresses.

To reproduce one seems to need a video file with less than 5 MB,
or it will not be taken as source for the folder thumbnail, which
contains that video [2]. With that information you may be able to
identify the causing file.

Even worse it seems it needs that special video file as
I did not receive the crash.
But I guess this crash happens in moviedecoder.cpp, line 202,
because "m_pFormatContext->streams[m_VideoStream]" contains
for some reason an invalid pointer.

Maybe you can also add the output of the "mediainfo" tool to
that bug, if the file causing it got identified.


Kind regards,
Bernhard



[1] https://wiki.debian.org/HowToGetABacktrace
[2] https://bugs.kde.org/show_bug.cgi?id=238690


(gdb) bt
#0  0x7f4e4a6654f4 in ffmpegthumbnailer::MovieDecoder::seek 
(this=this@entry=0x7fffa2933d00, timeInSeconds=) at 
./ffmpegthumbnailer/moviedecoder.cpp:202
#1  0x7f4e4a66720a in 
ffmpegthumbnailer::VideoThumbnailer::generateThumbnail 
(this=this@entry=0x555aa55aae58, 
videoFile="/home/benutzer/test/test/test2.mov", imageWriter=..., image=...) at 
./ffmpegthumbnailer/videothumbnailer.cpp:105
#2  0x7f4e4a667359 in 
ffmpegthumbnailer::VideoThumbnailer::generateThumbnail 
(this=this@entry=0x555aa55aae58, 
videoFile="/home/benutzer/test/test/test2.mov", image=...) at 
./ffmpegthumbnailer/videothumbnailer.cpp:141
#3  0x7f4e4a664793 in FFMpegThumbnailer::create (this=0x555aa55aae40, 
path="/home/benutzer/test/test/test2.mov", width=, img=...) at 
./ffmpegthumbnailer.cpp:46
#4  0x7f4e5c0ade80 in ThumbnailProtocol::createSubThumbnail 
(this=this@entry=0x7fffa29343c0, thumbnail=..., 
filePath="/home/benutzer/test/test/test2.mov", 
segmentWidth=segmentWidth@entry=108, segmentHeight=segmentHeight@entry=68) at 
./thumbnail/thumbnail.cpp:719
#5  0x7f4e5c0ae458 in ThumbnailProtocol::drawSubThumbnail 
(this=this@entry=0x7fffa29343c0, p=..., 
filePath="/home/benutzer/test/test/test2.mov", width=width@entry=108, 
height=height@entry=68, xPos=xPos@entry=128, yPos=76, frameWidth=3) at 
./thumbnail/thumbnail.cpp:751
#6  0x7f4e5c0aeb30 in ThumbnailProtocol::thumbForDirectory 
(this=this@entry=0x7fffa29343c0, 
directory="thumbnail:/home/benutzer/test/test") at ./thumbnail/thumbnail.cpp:557
#7  0x7f4e5c0b0041 in ThumbnailProtocol::get (this=0x7fffa29343c0, 
url="thumbnail:/home/benutzer/test/test") at ./thumbnail/thumbnail.cpp:225
#8  0x7f4e57135df6 in KIO::SlaveBase::dispatch (this=0x7fffa29343c0, 
command=67, data="\000\000\000\"thumbnail:/home/benutzer/test/test" = {...}) at 
./src/core/slavebase.cpp:1119
#9  0x7f4e57131196 in KIO::SlaveBase::dispatchLoop 
(this=this@entry=0x7fffa29343c0) at ./src/core/slavebase.cpp:318
#10 0x7f4e5c0ad08d in kdemain (argc=, argv=) 
at ./thumbnail/thumbnail.cpp:130
#11 0x555aa4fc7e1c in launch (argc=4, _name=0x555aa5380d68 
"/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/thumbnail.so", args=, cwd=, envc=0, envs=, reset_env=false, 
tty=0x0, avoid_loops=false, startup_id_str=0x555aa4fcb187 "0") at 
./src/kdeinit/kinit.cpp:706
#12 0x555aa4fc8eea in handle_launcher_request (sock=8, who=) 
at ./src/kdeinit/kinit.cpp:1146
#13 0x555aa4fc98fb in handle_requests (waitForPid=0) at 
./src/kdeinit/kinit.cpp:1339
#14 0x555aa4fc4645 in main (argc=argc@entry=5, 
argv=argv@entry=0x7fffa2934bd8) at ./src/kdeinit/kinit.cpp:1785
#15 0x7f4e5b26409b in __libc_start_main (main=0x555aa4fc3c70 , argc=5, argv=0x7fffa2934bd8, init=, fini=, rtld_fini=, stack_end=0x7fffa2934bc8) at 
../csu/libc-start.c:308
#16 0x555aa4fc52ca in _start () at ./src/kdeinit/kinit.cpp:802


(gdb) disassemble /m 0x7f4e4a665490,0x7f4e4a665510
Dump of assembler code from 0x7f4e4a665490 to 0x7f4e4a665510:
...
198 }
199
200 int ret = av_seek_frame(m_pFormatContext, -1, timestamp, 0);
   0x7f4e4a6654b8 :  mov
0x8(%rdi),%rdi
   0x7f4e4a6654c3 :  mov
$0x0,%edx
   0x7f4e4a6654c8 :  mov
$0x,%esi
   0x7f4e4a6654cd :  test   
%rax,%rax
   0x7f4e4a6654d0 :  cmovns 
%rax,%rdx
   0x7f4e4a6654d4 :  xor
%ecx,%ecx
   0x7f4e4a6654d6 :  callq  
0x7f4e4a664280 

201 if (ret >= 0) {
   0x7f4e4a6654db :  test   
%eax,%eax
   0x7f4e4a6654dd :  js 
0x7f4e4a66555a 

202 
avcodec_flush_buffers(m_pFormatContext->streams[m_VideoStream]->codec);
   0x7f4e4a6654df :  mov
0x8(%rbx),%rax
   0x7f4e4a6654e3 :  movslq 
(%rbx),%rdx
   0x7f4e4a6654e6 :  mov
$0xc8,%r12d
   0x7f4e4a6654ec :  mov
0x30(%rax),%rax
   0x7f4e4a6654f0 :  mov
(%rax,%rdx,8),%rax
=> 0x7f4e4a6654f4 : mov
0x8(%rax),%rdi
   0x7f4e4a6654f8 : callq  
0x7f4e4a664130 
   0x7f4e4a6654fd : nopl   
(%rax)

203  

Bug#917143: t-coffee breaks libbio-tools-run-alignment-tcoffee-perl autopkgtest: COREDUMP

[Bernhard Übelacker]

Sorry, missed the file.

# buster amd64 qemu VM

apt update
apt dist-upgrade


apt install systemd-coredump fakeroot mc gdb htop dpkg-dev devscripts quilt
apt build-dep libbio-tools-run-alignment-tcoffee-perl
apt build-dep t-coffee


wget 
http://ftp.de.debian.org/debian/pool/main/t/t-coffee/t-coffee_12.00.7fb08c2-1_amd64.deb
dpkg -i t-coffee_12.00.7fb08c2-1_amd64.deb


mkdir source/libbio-tools-run-alignment-tcoffee-perl/orig -p
cdsource/libbio-tools-run-alignment-tcoffee-perl/orig
apt source libbio-tools-run-alignment-tcoffee-perl
cd


mkdir source/t-coffee/orig -p
cdsource/t-coffee/orig
dget 
http://deb.debian.org/debian/pool/main/t/t-coffee/t-coffee_12.00.7fb08c2-1.dsc
cd



cd source/t-coffee
cp orig try1 -a
cd try1/t-coffee-12.00.7fb08c2
# add gdb call
dpkg-buildpackage

dpkg -i /home/benutzer/source/t-coffee/try1/t-coffee_12.00.7fb08c2-1_amd64.deb
dpkg -i 
/home/benutzer/source/t-coffee/try1/t-coffee-dbgsym_12.00.7fb08c2-1_amd64.deb




cd source/libbio-tools-run-alignment-tcoffee-perl
cp orig try1 -a
cd try1/libbio-tools-run-alignment-tcoffee-perl-1.7.4/
dpkg-buildpackage -b

-> No crash




##


# switch to unstable



apt update
apt dist-upgrade



cd source/t-coffee
cp orig try2 -a
cd try2/t-coffee-12.00.7fb08c2

cat < debian/patches/-call-gdb-on-signal.patch
Description: -call-gdb-on-signal.patch

Index: t-coffee-12.00.7fb08c2/t_coffee_source/util_lib/util.c
===
--- t-coffee-12.00.7fb08c2.orig/t_coffee_source/util_lib/util.c
+++ t-coffee-12.00.7fb08c2/t_coffee_source/util_lib/util.c
@@ -10002,6 +10002,11 @@ void error_exit (int exit_code)
  {
lock (getpid(), LERROR, LSET, "%d -- ERROR: COREDUMP: %s %s 
(%s)\n",getpid(), PROGRAM, VERSION, BUILD_INFO );
global_exit_signal=exit_code;
+   {
+  char buf[200];
+  sprintf(buf, "gdb -q -n -batch -ex 'generate-core-file' -ex 'info 
thread' -ex 'info reg' -ex 'thread apply all bt full' -ex 'info share' -ex 
'detach' -ex 'quit' --pid %d", getpid());
+  system(buf);
+   }
myexit (exit_code);
  }
 
EOF

echo -call-gdb-on-signal.patch >> debian/patches/series


dpkg-buildpackage

dpkg -i /home/benutzer/source/t-coffee/try2/t-coffee_12.00.7fb08c2-1_amd64.deb
dpkg -i 
/home/benutzer/source/t-coffee/try2/t-coffee-dbgsym_12.00.7fb08c2-1_amd64.deb




cd source/libbio-tools-run-alignment-tcoffee-perl
cp orig try2 -a
cd try2/libbio-tools-run-alignment-tcoffee-perl-1.7.4/
dpkg-buildpackage -b


$ find -iname "*core*"
./core.3995
./core.3996
./core.3994
./core.4000




$ gdb -q -ex 'set pagination off' -ex 'set width 0' -ex 'directory 
/home/benutzer/source/t-coffee/try2/t-coffee-12.00.7fb08c2/t_coffee_source' 
/usr/bin/t_coffee --core ./core.3995
Reading symbols from /usr/bin/t_coffee...Reading symbols from 
/usr/lib/debug/.build-id/26/7314cbd87aae405b78889c1e3af85806aea901.debug...done.
done.
[New LWP 3995]
Core was generated by `/usr/bin/t_coffee'.
#0  0x7fe6b33eb7f7 in __GI___waitpid (pid=4065, 
stat_loc=stat_loc@entry=0x7ffe74a7b488, options=options@entry=0) at 
../sysdeps/unix/sysv/linux/waitpid.c:30
30  ../sysdeps/unix/sysv/linux/waitpid.c: Datei oder Verzeichnis nicht 
gefunden.
Source directories searched: 
/home/benutzer/source/t-coffee/try2/t-coffee-12.00.7fb08c2/t_coffee_source:$cdir:$cwd
(gdb) bt
#0  0x7fe6b33eb7f7 in __GI___waitpid (pid=4065, 
stat_loc=stat_loc@entry=0x7ffe74a7b488, options=options@entry=0) at 
../sysdeps/unix/sysv/linux/waitpid.c:30
#1  0x7fe6b336980f in do_system (line=) at 
../sysdeps/posix/system.c:149
#2  0x55f262eef2b0 in error_exit (exit_code=11) at util_lib/util.c:10008
#3  
#4  0x55f262ebb84d in decode_name (name=name@entry=0x55f26537f1f0 
"TCTAG_53775_4", mode=mode@entry=2) at util_lib/reformat.c:14644
#5  0x55f262ebbbdd in translate_name (name=0x55f26537f1f0 "TCTAG_53775_4") 
at util_lib/reformat.c:14575
#6  0x55f262ebd1da in get_fasta_sequence (fname=, 
comment_out=0x0) at util_lib/reformat.c:5304
#7  0x55f262ebe7b7 in main_read_aln (name=name@entry=0x55f265366250 
"/var/tmp/tco/tcoifo4u0ng3972//11383988396", A=0x55f26538bf90, A@entry=0x0) at 
util_lib/reformat.c:1532
#8  0x55f262f28db1 in aln_file2constraint_list 
(alname=alname@entry=0x55f265366250 
"/var/tmp/tco/tcoifo4u0ng3972//11383988396", CL=CL@entry=0x55f2652de520, 
weight_mode=weight_mode@entry=0x55f265363858 "sim") at 
util_lib/util_constraints_list.c:4304
#9  0x55f262f3decf in read_constraint_list (CL=0x55f2652de520, 
in_fname=, in_mode=in_mode@entry=0x55f262f582fc "aln", 
mem_mode=mem_mode@entry=0x55f262f6702f "disk", 
weight_mode=weight_mode@entry=0x55f265363858 "sim") at 
util_lib/util_constraints_list.c:2368
#10 0x55f262f3dfaa in retrieve_lib_job (job=0x55f2635cb990) at 
util_lib/util_constraints_list.c:473
#11 0x55f262f20bb5 in fork_subset_produce_list (CL=CL@entry=0x55f2652de520, 
method=method@entry=0x55f263617d71 "clustalw_pair", job=0x55f2635cb990, 
job@entry=0x55f263ab2f00, nproc=, 

Bug#917143: t-coffee breaks libbio-tools-run-alignment-tcoffee-perl autopkgtest: COREDUMP

[Bernhard Übelacker]

Dear Maintainer,
just tried to get some more information out of the crash.

It was not showing up with t-coffee 12 compiled in testing.
Just with switching to unstable and recompiling t-coffee
the crash manifested when
building libbio-tools-run-alignment-tcoffee-perl-1.7.4.

Unfortunately the signal is 'eaten' and therefore no
core file is generated.
With a modification adding a call to gdb I was able to get one.

Below is the backtrace of the first failing pid.
Some more information is in the attached file describing how
the information was collected.

It looks like the static array name_list is accessed beyond the
initilialized memory.

Kind regards,
Bernhard


$ gdb -q -ex 'set pagination off' -ex 'set width 0' -ex 'directory 
/home/benutzer/source/t-coffee/try2/t-coffee-12.00.7fb08c2/t_coffee_source' 
/usr/bin/t_coffee --core ./core.3995
Reading symbols from /usr/bin/t_coffee...Reading symbols from 
/usr/lib/debug/.build-id/26/7314cbd87aae405b78889c1e3af85806aea901.debug...done.
done.
[New LWP 3995]
Core was generated by `/usr/bin/t_coffee'.
#0  0x7fe6b33eb7f7 in __GI___waitpid (pid=4065, 
stat_loc=stat_loc@entry=0x7ffe74a7b488, options=options@entry=0) at 
../sysdeps/unix/sysv/linux/waitpid.c:30
30  ../sysdeps/unix/sysv/linux/waitpid.c: Datei oder Verzeichnis nicht 
gefunden.
Source directories searched: 
/home/benutzer/source/t-coffee/try2/t-coffee-12.00.7fb08c2/t_coffee_source:$cdir:$cwd
(gdb) bt
#0  0x7fe6b33eb7f7 in __GI___waitpid (pid=4065, 
stat_loc=stat_loc@entry=0x7ffe74a7b488, options=options@entry=0) at 
../sysdeps/unix/sysv/linux/waitpid.c:30
#1  0x7fe6b336980f in do_system (line=) at 
../sysdeps/posix/system.c:149
#2  0x55f262eef2b0 in error_exit (exit_code=11) at util_lib/util.c:10008
#3  
#4  0x55f262ebb84d in decode_name (name=name@entry=0x55f26537f1f0 
"TCTAG_53775_4", mode=mode@entry=2) at util_lib/reformat.c:14644
#5  0x55f262ebbbdd in translate_name (name=0x55f26537f1f0 "TCTAG_53775_4") 
at util_lib/reformat.c:14575
#6  0x55f262ebd1da in get_fasta_sequence (fname=, 
comment_out=0x0) at util_lib/reformat.c:5304
#7  0x55f262ebe7b7 in main_read_aln (name=name@entry=0x55f265366250 
"/var/tmp/tco/tcoifo4u0ng3972//11383988396", A=0x55f26538bf90, A@entry=0x0) at 
util_lib/reformat.c:1532
#8  0x55f262f28db1 in aln_file2constraint_list 
(alname=alname@entry=0x55f265366250 
"/var/tmp/tco/tcoifo4u0ng3972//11383988396", CL=CL@entry=0x55f2652de520, 
weight_mode=weight_mode@entry=0x55f265363858 "sim") at 
util_lib/util_constraints_list.c:4304
#9  0x55f262f3decf in read_constraint_list (CL=0x55f2652de520, 
in_fname=, in_mode=in_mode@entry=0x55f262f582fc "aln", 
mem_mode=mem_mode@entry=0x55f262f6702f "disk", 
weight_mode=weight_mode@entry=0x55f265363858 "sim") at 
util_lib/util_constraints_list.c:2368
#10 0x55f262f3dfaa in retrieve_lib_job (job=0x55f2635cb990) at 
util_lib/util_constraints_list.c:473
#11 0x55f262f20bb5 in fork_subset_produce_list (CL=CL@entry=0x55f2652de520, 
method=method@entry=0x55f263617d71 "clustalw_pair", job=0x55f2635cb990, 
job@entry=0x55f263ab2f00, nproc=, local_stderr=0x55f2634f9bd0, 
mem_mode=0x55f2634f9bd0 "\204,\255", , 
weight=, S=0x55f263617d71) at 
util_lib/util_constraints_list.c:177
#12 0x55f262f3d1bf in produce_list (CL=CL@entry=0x55f2652de520, 
S=, method=method@entry=0x55f263617d71 "clustalw_pair", 
weight=weight@entry=0x55f2639d4020 "default", 
mem_mode=mem_mode@entry=0x55f2635cfbc0 "mem") at 
util_lib/util_constraints_list.c:94
#13 0x55f262f3dc70 in read_constraint_list (CL=CL@entry=0x55f2652de520, 
in_fname=, in_mode=in_mode@entry=0x0, 
mem_mode=mem_mode@entry=0x55f2635cfbc0 "mem", 
weight_mode=weight_mode@entry=0x55f2639d4020 "default") at 
util_lib/util_constraints_list.c:2332
#14 0x55f262f3e253 in fork_read_n_constraint_list (fname=0x55f2636139e0, 
n_list=, in_mode=0x0, mem_mode=0x55f2635cfbc0 "mem", 
weight_mode=0x55f2639d4020 "default", type=, 
local_stderr=0x55f2634f9bd0, CL=0x55f2652de520, seq_source=0x55f2639a9560 
"ANY", nproc=8) at util_lib/util_constraints_list.c:2218
#15 0x55f262f3e812 in read_n_constraint_list (fname=0x55f2636139e0, 
n_list=4, in_mode=0x0, mem_mode=0x55f2635cfbc0 "mem", 
weight_mode=0x55f2639d4020 "default", type=0x55f2635c74a0 "", 
local_stderr=0x55f2634f9bd0, CL=0x55f2652de520, seq_source=0x55f2639a9560 
"ANY") at util_lib/util_constraints_list.c:2141
#16 0x55f262e697f0 in batch_main (argc=, argv=) at t_coffee_lib/t_coffee.c:4942
#17 0x55f262d905ad in main (argc=, argv=) at 
t_coffee_lib/t_coffee.c:179


#4  0x55f262ebb84d in decode_name (name=name@entry=0x55f26537f1f0 
"TCTAG_53775_4", mode=mode@entry=2) at util_lib/reformat.c:14644
14644 return name_list[i-1][0];

Bug#917018: wget: Unusable - permanent segmentation fault

[Bernhard Übelacker]

Control: fixed 917018 wget/1.19.1-1
Control: tags 917018 + upstream


Dear Maintainer, hello RW Penney,
I had a look and think I found something.
You have by any chance made something like 'chmod 000 ~/.wget-hsts' ?

Because in that case we end up in a backtrace like below.
(And stretch systems with a writeable ~/.wget-hsts are not affected.)

That is because when fp is NULL it is still tried to given to fclose().

Upstream has fixed this in commit [1].

Kind regards,
Bernhard


[1] 
http://git.savannah.gnu.org/cgit/wget.git/commit/src/hsts.c?id=40870e1271c977d9b80734690a5691a68bf05473


(gdb) bt
#0  _IO_new_fclose (fp=fp@entry=0x0) at iofclose.c:53
#1  0x555722ca in hsts_store_open (filename=) at 
../../src/hsts.c:513
#2  0x5556102c in load_hsts () at ../../src/main.c:186
#3  main (argc=argc@entry=6, argv=argv@entry=0x7fffe628) at 
../../src/main.c:1897
#4  0x769b62e1 in __libc_start_main (main=0xfb40 , 
argc=6, argv=0x7fffe628, init=, fini=, 
rtld_fini=, stack_end=0x7fffe618) at ../csu/libc-start.c:291
#5  0x5556147a in _start ()

(gdb) list hsts_store_open
492 hsts_store_open (const char *filename)
493 {
...
508   if (!fp || !hsts_read_database (store, fp, false))
509 {
510   /* abort! */
511   hsts_store_close (store);
512   xfree (store);
513   fclose (fp);
514   goto out;
515 }


From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917018#18 :
Program received signal SIGSEGV, Segmentation fault.
_IO_new_fclose (fp=0x0) at iofclose.c:53
53iofclose.c: No such file or directory.
#0  _IO_new_fclose (fp=0x0) at iofclose.c:53
#1  0x555722ca in ?? ()
#2  0x5556102c in ?? ()
#3  0x769b62e1 in __libc_start_main (main=0xfb40, argc=6, 
argv=0x7fffe848, init=, fini=, 
rtld_fini=, stack_end=0x7fffe838) at ../csu/libc-start.c:291
#4  0x5556147a in ?? ()
Detaching from program: /usr/bin/wget, process 2009


#


# stretch amd64 qemu VM


apt update
apt dist-upgrade

apt install devscripts dpkg-dev systemd-coredump gdb wget-dbgsym


mkdir source/wget/orig -p
cdsource/wget/orig
apt source wget
cd ../..



mkdir /tmp/wget-test
cd/tmp/wget-test
wget -r -k -l inf http://www.debian.org
# no crash ...


root@debian:/tmp/wget-test# uname -a
Linux debian 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux
root@debian:/tmp/wget-test# cat /etc/debian_version 
9.6







gdb -q \
-ex 'set backtrace past-main on' \
-ex 'set width 0' \
-ex 'set pagination off' \
-ex 'directory /home/benutzer/source/wget/orig/wget-1.18/debian/patches' \
--args wget -r -k -l inf http://www.debian.org



(gdb) disassemble main
   0x55561027 <+5351>:  callq  0x55572190 
   0x5556102c <+5356>:  test   %rax,%rax

(gdb) disassemble hsts_store_open
   0x555722c5 <+309>:   callq  0xf600
   0x555722ca <+314>:   jmpq   0x555721f3 

(gdb) list hsts_store_open
490
491 hsts_store_t
492 hsts_store_open (const char *filename)
493 {
494   hsts_store_t store = NULL;
495
496   store = xnew0 (struct hsts_store);
497   store->table = hash_table_new (0, hsts_hash_func, hsts_cmp_func);
498   store->last_mtime = 0;
499   store->changed = false;
500
501   if (file_exists_p (filename))
502 {
503   if (hsts_file_access_valid (filename))
504 {
505   struct_stat st;
506   FILE *fp = fopen (filename, "r");
507
508   if (!fp || !hsts_read_database (store, fp, false))
509 {
510   /* abort! */
511   hsts_store_close (store);
512   xfree (store);
513   fclose (fp);
514   goto out;
515 }
516
517   if (fstat (fileno (fp), ) == 0)
518 store->last_mtime = st.st_mtime;
519
520   fclose (fp);
521 }
522   else
523 {
524   /*
525* If we're not reading the HSTS database,
526* then by all means act as if HSTS was disabled.
527*/
528   hsts_store_close (store);
529   xfree (store);
530
531   logprintf (LOG_NOTQUIET, "Will not apply HSTS. "
532  "The HSTS database must be a regular and 
non-world-writable file.\n");
533 }
534 }
535
536 out:
537   return store;
538 }



(gdb) disassemble /m hsts_store_open
...
512   xfree (store);
   0x555722b8 <+296>:   mov%rbx,%rdi
   0x555722bb <+299>:   xor%ebx,%ebx
   0x555722bd <+301>:   callq  0xf328

513

Bug#917018: wget: Unusable - permanent segmentation fault

[Bernhard Übelacker]

Hello rwpenney,
just tried to reproduce and collect some information for the maintainer
on a minimal buster amd64 qemu VM.

Unfortunately I could not reproduce the crash
and after 700 files I stopped my test.

Maybe you could run the wget command like that:

gdb -q -ex 'set pagination off' -ex 'set width 0' -ex run -ex bt -ex detach 
-ex quit --args wget -r -k -l inf http://www.debian.org

Or you install a coredump collector like systemd-coredump and
provide the output of journalctl for that time.

In [1] are also some points to get more information into the backtrace.

Kind regards,
Bernhard

[1] https://wiki.debian.org/HowToGetABacktrace

Bug#917026: xorg: All the system freezes when ejects an USB stick with Thunar

[Bernhard Übelacker]

Hello Alain,
just saw your report and though it sounds similar to another one [1].
Do you have linux-image in version 4.9.130-2 installed?
Were older kernels working like expected?
If possible you might want also check if reverting back
to 4.9.110-3+deb9u6 gives you a not hanging system on eject.

Kind regards,
Bernhard

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914696

Bug#916765: cups-browsed: Aborts when restarted with "BrowseFilter pdl postscript"

[Bernhard Übelacker]

Hello Brian Potkin,
you might have a look at following commands to build a
complete local cups-browsed package with the upstream
patch included.

That may work better, as a plain make built shared lib
might be not enough compatible with the executable from
the debian package.

Just if you do not want to wait until the upstream
change hits testing.

Kind regards,
Bernhard



(as root)
apt install dpkg-dev devscripts
apt build-dep cups-filters


(as user)
mkdir ~/source/cups-filters -p
cd~/source/cups-filters
apt source cups-filters
cd cups-filters-1.21.4
dch --local local "Rebuild for #916765"

wget 
https://github.com/OpenPrinting/cups-filters/commit/ef71337fc231eb712a737ffd9aa6d32a95920457.patch
 -O - | patch -p1
find -iname "*.rej"
# should just output ./NEWS.rej

dpkg-buildpackage -b


(as root)
cd /home/user/source/cups-filters

dpkg -l | grep -E " $(ls -1 *.deb | cut -d_ -f 1 | xargs echo | sed 's/ /|/g') 
" | awk '{print $2}' | sed 's/:i386//' | awk '{print $1 "_*.deb"}' | xargs echo 
dpkg -i
# check the output from above command and if ok execute it, should just install 
already installed files ...

Bug#916595: vlc: program doesn't close its process in some cases

[Bernhard Übelacker]

Hello bitfreak25,
trying to get more details out of it I recognised that my physical PC
is also using radeonsi. "Unfortunately" my vlc closes correctly.

I tried to watch how on my system vlc is running through 
vout_display_opengl_Delete
and found that on mine it diverts into dri2_flush_swapbuffers instead of
loader_dri3_swapbuffer_barrier as in your system.
That might depend from the hardware or driver version.

Therefore you might add the output of following commands:

  dpkg -l | grep -i -E "libglx-mesa0|libgl1-mesa-dri|vlc-plugin-video-output"

  lspci | grep VGA

Kind regards,
Bernhard

Bug#916765: cups-browsed: Aborts when restarted with "BrowseFilter pdl postscript"

[Bernhard Übelacker]

Hello Brian Potkin,

> You got exactly what I was shown.

You are right, and I just wanted to make a point how someone
who want to help can start right away with all the needed information.

> Do you really think reportbug would have added an imortant clue? It
> was clear that my original report was based on an unstable installation.

It would have shown the architecture you are working with.

> It is not exactly the bug of the year, but, as far as I am concerned, 
> there is a misbehaviour here. I know it is present, so can choose to
> not use the option.

I did really not want to make you angry at me.

Maybe you still can test my proposed changes in message [#36-#3] ?

Kind regards,
Bernhard

[#36-#3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916765#36

Bug#916765: cups-browsed: Aborts when restarted with "BrowseFilter pdl postscript"

[Bernhard Übelacker]

Control: found cups-browsed 1.11.6-3

And probably I was not clear in my message #36:

- I may have found something that could lead to your sitation,
  and attached a change that might avoid it.
- I could not reproduce the crash because I do not have such printers.
- Maintainer or Upstream are needed to confirm and correct it.

Kind regards,
Bernhard

Bug#916765: cups-browsed: Aborts when restarted with "BrowseFilter pdl postscript"

[Bernhard Übelacker]

Hello Brian Potkin,

> Does the efficient and correct operation of a program depend on whether
> the system is amd64 or i386? Most of my machines are i386 only and, to
> my knowledge, Debian has not abandoned this architecture.
> 
> I was probably incorrect in thinking I had tested the offending directive
> previously. I have now tested with Debian 9.3 on i386. The same thing
> happens.
> 
> When I summon up the energy I'll see what happens on an am64 OS.

No, you don't need to.

The problem is just if the reporter has not all debug symbols installed
I need to know the exact package version and architecture to get
something out of a backtrace. And as coredumpctl wrote
0xb747e1d7 instead of 0xb747e1d7 I just assumed it to be amd64.

So that bit of information was just missing, and the program reportbug
would have had added it to the bug report in the first place.

There is nothing wrong with i386.

Kind regards,
Bernhard

Bug#916765: cups-browsed: Aborts when restarted with "BrowseFilter pdl postscript"

[Bernhard Übelacker]

Dear Maintainer, hello Brian Potkin,

> Thanks. All this is very new to me. I hope it is what is needed and   
>  
> someone can interpret it!

Thanks for the information, in my first attempts I was under the impression
you are on a amd64 system because the coredumpctl output used 16 character
addresses - therefore address offsets never matched mine ...

Using a utiltiy like reportbug would have attached information about package
versions and architecture already in the first mail, you probably can consider
using such in future reports.


I could not reproduce the crash and therefore cannot be sure about following.

We might reach line 5648 even when key is already freed in line 5622/5626,
but the gotos in line 5624/5629 are not reached because of the condition above.

Therefore a (untested) change [3] like below could possibly avoid that.


Not related but looks suspicious that in line 5617 the empty
string "" is assigned to variable value and that might
be given to avahi_free.
I guess this may also lead to a crash.
In [4] is also an (untested) attempt to avoid that.


Both issues are possible since commit [5] "Fixed minor memory leaks".

Kind regards,
Bernhard


[1] 
https://github.com/OpenPrinting/cups-filters/blob/master/utils/cups-browsed.c#L5648


[2]
5611if (key) {
...
5614  if (filter->regexp) {
5615/* match regexp */
5616if (!value)
5617  value = "";
5618if ((filter->cregexp &&
5619 regexec(filter->cregexp, value, 0, NULL, 0) == 0) ||
5620(!filter->cregexp && !strcasecmp(filter->regexp, 
value))) {
5621  avahi_free(key);
5622  avahi_free(value);
5623  if (filter->sense == FILTER_NOT_MATCH)
5624goto filter_failed;
5625} else {
5626  avahi_free(key);
5627  avahi_free(value);
5628  if (filter->sense == FILTER_MATCH)
5629goto filter_failed;
5630} 
5631  } else {
5632/* match boolean value */
5633if (filter->sense == FILTER_MATCH) {
5634  if (!value || strcasecmp(value, "T")) {
5635avahi_free(key);
5636avahi_free(value);
5637goto filter_failed;
5638  }
5639} else {
5640  if (value && !strcasecmp(value, "T")) {
5641avahi_free(key);
5642avahi_free(value);
5643goto filter_failed;
5644  }
5645}
5646  }
5647}
5648avahi_free(key);
5649avahi_free(value);
5650goto filter_matched;
...
5703 filter_matched:
...
5712 filter_failed:



[3]
diff --git a/utils/cups-browsed.c b/utils/cups-browsed.c
index 0d5d521..8f5169e 100644
--- a/utils/cups-browsed.c
+++ b/utils/cups-browsed.c
@@ -5618,15 +5618,17 @@ matched_filters (const char *queue_name,
if ((filter->cregexp &&
 regexec(filter->cregexp, value, 0, NULL, 0) == 0) ||
(!filter->cregexp && !strcasecmp(filter->regexp, value))) {
- avahi_free(key);
- avahi_free(value);
- if (filter->sense == FILTER_NOT_MATCH)
+ if (filter->sense == FILTER_NOT_MATCH) {
+   avahi_free(key);
+   avahi_free(value);
goto filter_failed;
+ }
} else {
- avahi_free(key);
- avahi_free(value);
- if (filter->sense == FILTER_MATCH)
+ if (filter->sense == FILTER_MATCH) {
+   avahi_free(key);
+   avahi_free(value);
goto filter_failed;
+ }
} 
  } else {
/* match boolean value */






[4]
diff --git a/utils/cups-browsed.c b/utils/cups-browsed.c
index 0d5d521..d014072 100644
--- a/utils/cups-browsed.c
+++ b/utils/cups-browsed.c
@@ -5588,7 +5588,7 @@ matched_filters (const char *queue_name,
   char buf[10];
 #ifdef HAVE_AVAHI
   AvahiStringList *entry = NULL;
-  char *key = NULL, *value = NULL;
+  char *key = NULL, *value = NULL, *value2;
 #endif /* HAVE_AVAHI */
 
   debug_printf("Matching printer \"%s\" with properties Host = \"%s\", Port = 
%d, Service Name = \"%s\", Domain = \"%s\" with the BrowseFilter lines in 
cups-browsed.conf\n", queue_name, host, port, service_name, domain);
@@ -5613,11 +5613,12 @@ matched_filters (const char *queue_name,
   key, (value ? value : ""));
  if (filter->regexp) {
/* match regexp */
-   if (!value)
- value = "";
+   value2 = "";
+   if (value)
+ value2 = value;
if ((filter->cregexp &&
-

Bug#916765: cups-browsed: Aborts when restarted with "BrowseFilter pdl postscript"

[Bernhard Übelacker]

Hello Brian Potkin,
I tried to have a look in a unstable VM, but unfortunately
I get different offsets ...

You might add the output of this command:
  dpkg -l | grep -E "cups-browsed|libc6|libglib|libavahi|libdbus" | sort

And what output did you receive from this command
  coredumpctl list

and following this command, with PID from the above output:
  coredumpctl gdb PID
bt
quit

Kind regards,
Bernhard






signature.asc
Description: OpenPGP digital signature

Bug#916595: vlc: program doesn't close its process in some cases

[Bernhard Übelacker]

Hello,
probably you can also add following debug symbol packages:

/usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so   -> 
libgl1-mesa-dri-dbgsym
/usr/lib/x86_64-linux-gnu/libQt5DBus.so.5   -> 
libqt5dbus5-dbgsym
/usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5 -> 
libqt5gui5-dbgsym
/usr/lib/x86_64-linux-gnu/libvlc.so.5   -> 
libvlc5-dbgsym
/usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0  -> 
libglx-mesa0-dbgsym
/usr/lib/x86_64-linux-gnu/vlc/plugins/video_output/libgl_plugin.so  -> 
vlc-plugin-video-output-dbgsym


And execute this slightly modified gdb command (just adds the "info thread"):

for pid in `pgrep vlc`; do gdb -q --pid $pid -ex "set pagination off" -ex "set 
width 0" -ex "info thread" -ex "thread apply all bt full" -ex "info share" -ex 
detach -ex quit; done 2>&1 | tee -a vlc_$(date +%Y-%m-%d_%H-%M-%S).txt


For the current gdb output this is visible:
- Thread  1 (tid=1662) is waiting for Thread  3 (tid=1664)
- Thread  3 (tid=1664) is waiting for Thread 30 (tid=1707)
- Thread 30 (tid=1707) is waiting in "xcb_wait_for_special_event", but
  just from the (current) stacks I cannot say from which thread this event 
should come from ...


Kind regards,
Bernhard

Bug#916678: systemd: Caught , dumped core as pid 2097

[Bernhard Übelacker]

Hello Cristian Ionescu-Idbohrn,
following is what I get from a buster amd64 qemu VM,
with explicitly downgraded systemd packages to 239-13:

It has quite a similarity to upstream bug [1].
And upstream received a fix for that just a few days ago,
and is therefore not yet contained in an upstream release.

Kind regards,
Bernhard


[1] https://github.com/systemd/systemd/issues/10716

(gdb) bt
#0  0x7f2d9386bb37 in kill () at ../sysdeps/unix/syscall-template.S:78
#1  0x561672b85436 in crash (sig=11) at ../src/core/main.c:183
#2  
#3  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:93
#4  0x7f2d93680cb7 in message_append_basic (m=m@entry=0x561674c79870, 
type=, p=0x, stored=stored@entry=0x0) at 
../src/basic/string-util.h:36
#5  0x7f2d936812ab in sd_bus_message_append_basic 
(m=m@entry=0x561674c79870, type=, p=) at 
../src/libsystemd/sd-bus/bus-message.c:1565
#6  0x7f2d93681719 in sd_bus_message_appendv (m=0x561674c79870, 
types=, ap=ap@entry=0x7ffcabd85950) at 
../src/libsystemd/sd-bus/bus-message.c:2358
#7  0x7f2d93681cf9 in sd_bus_message_append (m=, 
types=) at ../src/libsystemd/sd-bus/bus-message.c:2473
#8  0x561672b01daf in send_removed_signal (bus=0x561674bb3130, 
userdata=0x561674c144f0) at ../src/core/job.c:1565
#9  0x561672b71dbf in bus_foreach_bus (m=0x561674ab5830, subscribed2=0x0, 
send_message=0x561672b01d00 , userdata=0x561674c144f0) at 
../src/core/dbus.c:1187
#10 0x561672b03f78 in bus_job_send_removed_signal (j=, 
j=) at ../src/core/dbus-job.c:225
#11 0x561672b8300e in manager_flush_finished_jobs (m=) at 
../src/core/manager.c:3359
#12 manager_reload (m=0x561674ab5830) at ../src/core/manager.c:3477
#13 invoke_main_loop (m=0x561674ab5830, ret_reexecute=0x7ffcabd85c2a, 
ret_retval=0x7ffcabd85c2c, ret_shutdown_verb=, 
ret_fds=0x7ffcabd85c30, ret_switch_root_dir=0x7ffcabd85c58, 
ret_switch_root_init=0x7ffcabd85c50, ret_error_message=0x7ffcabd85c40) at 
../src/core/main.c:1661
#14 0x561672ae4620 in main (argc=, argv=0x7ffcabd85f08) at 
../src/core/main.c:2415


# buster amd64 qemu VM



apt update
apt dist-upgrade

apt install gdb 




root@debian:~# gdb -q --pid 1
Attaching to process 1
...
(gdb) generate-core-file 
Saved corefile core.1
(gdb) detach
Detaching from program: /lib/systemd/systemd, process 1
[Inferior 1 (process 1) detached]
(gdb) q




root@debian:~# gdb -q -ex "set pagination off" -ex "info share" -ex quit 
/sbin/init --core core.1 2>&1 | grep libc.so.6
0x7f5a8f5a8320  0x7f5a8f6ee7ab  Yes 
/lib/x86_64-linux-gnu/libc.so.6





root@debian:~# gdb -q -ex "set pagination off" -ex "disassemble 
0x7f5a8f5a8320,0x7f5a8f6ee7ab" -ex quit /sbin/init --core core.1 2>&1 | 
grep 0x.647
# 64 possible locations ...




root@debian:~# gdb -q -ex "set pagination off" -ex "find /b 0x7f5a8f5a8320, 
0x7f5a8f6ee7ab, 
0xc5,0xfd,0x74,0x0f,0xc5,0xfd,0xd7,0xc1,0xd3,0xf8,0x85,0xc0,0x74,0x1b,0xf3,0x0f,0xbc,0xc0,0x48,0x01,0xf8,0x48"
 -ex quit /sbin/init --core core.1
Reading symbols from /sbin/init...(no debugging symbols found)...done.

warning: core file may not match specified executable file.
[New LWP 1]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/sbin/init'.
#0  0x7f5a8f67fb77 in epoll_wait (epfd=4, events=0x7ffc0f899920, 
maxevents=52, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
30  ../sysdeps/unix/sysv/linux/epoll_wait.c: Datei oder Verzeichnis nicht 
gefunden.
0x7f5a8f6de7a7 <__rawmemchr_avx2+55>
0x7f5a8f6e2647 <__strlen_avx2+55>
warning: Unable to access 1487 bytes of target memory at 0x7f5a8f6ee1dd, 
halting search.
2 patterns found.




root@debian:~# gdb -q -ex "set pagination off" -ex "x/64bx 0x7f5a8f6e2647-42" 
-ex "disassemble 0x7f5a8f6e2647-42,0x7f5a8f6e2647+22" /sbin/init --core core.1
Reading symbols from /sbin/init...(no debugging symbols found)...done.

warning: core file may not match specified executable file.
[New LWP 1]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/sbin/init'.
#0  0x7f5a8f67fb77 in epoll_wait (epfd=4, events=0x7ffc0f899920, 
maxevents=52, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
30  ../sysdeps/unix/sysv/linux/epoll_wait.c: Datei oder Verzeichnis nicht 
gefunden.
0x7f5a8f6e261d <__strlen_avx2+13>:  0xf90x200x770x1f0xc5
0xfd0x740x0f
0x7f5a8f6e2625 <__strlen_avx2+21>:  0xc50xfd0xd70xc10x85
0xc00x0f0x85
0x7f5a8f6e262d <__strlen_avx2+29>:  0xdf0x000x000x000x48
0x830xc70x20
0x7f5a8f6e2635 <__strlen_avx2+37>:  0x830xe10x1f0x480x83
0xe70xe00xeb
0x7f5a8f6e263d <__strlen_avx2+45>:  0x360x660x900x830xe1
0x1f0x480x83
0x7f5a8f6e2645 <__strlen_avx2+53>:  0xe7

Bug#916678: systemd: Caught , dumped core as pid 2097

[Bernhard Übelacker]

Hello Cristian Ionescu-Idbohrn,

Am 18.12.2018 um 09:35 schrieb Cristian Ionescu-Idbohrn:
> On Mon, 17 Dec 2018, Bernhard Übelacker wrote:
>>
>> Hello Cristian Ionescu-Idbohrn,
>> following is what I get from a buster amd64 qemu VM,
>> with explicitly downgraded systemd packages to 239-13:
>>
>> It has quite a similarity to upstream bug [1].
>> And upstream received a fix for that just a few days ago,
>> and is therefore not yet contained in an upstream release.
> 
> Thanks.  So, this bug is present in 239-15 too and can bite again, 
> isn't it?

If this is really the same issues I assume yes.
Nothing in the changelog entries for -14 and -15 sound related.

I can assume this backtrace contains no private information and
could be forwarded to the bug?

>> [1] https://github.com/systemd/systemd/issues/10716
>>
>> (gdb) bt
>> #0  0x7f2d9386bb37 in kill () at ../sysdeps/unix/syscall-template.S:78
>> #1  0x561672b85436 in crash (sig=11) at ../src/core/main.c:183
>> #2  
>> #3  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:93
>> #4  0x7f2d93680cb7 in message_append_basic (m=m@entry=0x561674c79870, 
>> type=, p=0x, stored=stored@entry=0x0) at 
>> ../src/basic/string-util.h:36
>> #5  0x7f2d936812ab in sd_bus_message_append_basic 
>> (m=m@entry=0x561674c79870, type=, p=) at 
>> ../src/libsystemd/sd-bus/bus-message.c:1565
>> #6  0x7f2d93681719 in sd_bus_message_appendv (m=0x561674c79870, 
>> types=, ap=ap@entry=0x7ffcabd85950) at 
>> ../src/libsystemd/sd-bus/bus-message.c:2358
>> #7  0x7f2d93681cf9 in sd_bus_message_append (m=, 
>> types=) at ../src/libsystemd/sd-bus/bus-message.c:2473
>> #8  0x561672b01daf in send_removed_signal (bus=0x561674bb3130, 
>> userdata=0x561674c144f0) at ../src/core/job.c:1565
>> #9  0x561672b71dbf in bus_foreach_bus (m=0x561674ab5830, 
>> subscribed2=0x0, send_message=0x561672b01d00 , 
>> userdata=0x561674c144f0) at ../src/core/dbus.c:1187
>> #10 0x561672b03f78 in bus_job_send_removed_signal (j=, 
>> j=) at ../src/core/dbus-job.c:225
>> #11 0x561672b8300e in manager_flush_finished_jobs (m=) at 
>> ../src/core/manager.c:3359
>> #12 manager_reload (m=0x561674ab5830) at ../src/core/manager.c:3477
>> #13 invoke_main_loop (m=0x561674ab5830, ret_reexecute=0x7ffcabd85c2a, 
>> ret_retval=0x7ffcabd85c2c, ret_shutdown_verb=, 
>> ret_fds=0x7ffcabd85c30, ret_switch_root_dir=0x7ffcabd85c58, 
>> ret_switch_root_init=0x7ffcabd85c50, ret_error_message=0x7ffcabd85c40) at 
>> ../src/core/main.c:1661
>> #14 0x561672ae4620 in main (argc=, argv=0x7ffcabd85f08) 
>> at ../src/core/main.c:2415

Kind regards,
Bernhard

Bug#916765: cups-browsed: Aborts when restarted with "BrowseFilter pdl postscript"

[Bernhard Übelacker]

Hello Brian Potkin,
you might want to install a core dump collector like systemd-coredump.

With that in place you might get a more verbose message in journalctl.
Also a later inspection of the coredump might be possible:

coredumpctl list
coredumpctl gdb [PID]
  bt
  quit

And even better when having the debug symbols installed like described
in [1]. Should be in your case cups-browsed-dbgsym to start with.

Kind regards,
Bernhard

[1] https://wiki.debian.org/HowToGetABacktrace

Bug#916595: vlc: program doesn't close its process in some cases

[Bernhard Übelacker]

Hello
when you find such a failing to close vlc, you might
consider to run following line.
That should give you a vlc_*.txt file which contains
all threads current backtrace and might point to where
the vlc process is waiting.

for pid in `pgrep vlc`; do gdb -q --pid $pid -ex "set pagination off" -ex "set 
width 0" -ex "thread apply all bt full" -ex "info share" -ex detach -ex quit; 
done 2>&1 | tee -a vlc_$(date +%Y-%m-%d_%H-%M-%S).txt

Even better if debug symbols are installed like described in [1].
Starting with vlc-bin-dbgsym.

Kind regards,
Bernhard

[1] https://wiki.debian.org/HowToGetABacktrace

Bug#916288: kea-dhcp4-server: Segfault after running for several minutes

[Bernhard Übelacker]

Hello Anton,

> (gdb)   print/x $rax
> $7 = 0x0
> (gdb) print stmt->mysql
> $8 = (MYSQL *) 0x0
> (gdb) print *stmt->mysql
> Cannot access memory at address 0x0

>> (gdb) list libmysql.c:4134
>> 4134  if (stmt->mysql->options.report_data_truncation)

That null pointer seems to be the problem here, as the mysql client
dereferences it unconditionally.


>> I looked through upstream git history and commits [1] and [2] might be
>> related: they disable automatic reconnects.
>> No such commit seem to have reached the stretch version of kea-dhcp:
>> ./isc-kea-1.1.0/src/lib/dhcpsrv/mysql_connection.cc:138:    my_bool
>> auto_reconnect = MLM_TRUE;
> Hmmm ... but if you disable autoreconnect, doesn't this means each time
> you restart your database server for any reason your dhcp server would
> become in a not working state and it would require restart also?

I fear this needs to be answered by the package maintainers or upstream 
developers.

Kind regards,
Bernhard

Bug#916364: kdepim-runtime: akonadi_akonotes_resource crashes

[Bernhard Übelacker]

Hello Vincas Dargis,
I just wanted to find out where in thread 4 this call to qTerminate
originates, without having deeper knowledge of akonadi ...

Unfortunately it looks like this backtrace just shows where we are in
the exception handler - effectively hiding where the exception really
happened in the first place.

Maybe the best chance would be to inspect the file ~/.xsession-errors,
if there is an obvious akonadi error ...

Kind regards,
Bernhard


(gdb) list qthread_unix.cpp:312,390
312
313 void *QThreadPrivate::start(void *arg)
314 {
...
320 #ifndef QT_NO_EXCEPTIONS
321 try
322 #endif
323 {
...
368 }
369 #ifndef QT_NO_EXCEPTIONS
370 #ifdef __GLIBCXX__
371 // POSIX thread cancellation under glibc is implemented by throwing 
an exception
372 // of this type. Do what libstdc++ is doing and handle it specially 
in order not to
373 // abort the application if user's code calls a cancellation 
function.
374 catch (const abi::__forced_unwind &) {
375 throw;
376 }
377 #endif // __GLIBCXX__
378 catch (...) {
379 qTerminate();
380 }


Thread 4 (Thread 0x7f663cfa6700 (LWP 3085)):
[KCrash Handler]
#6  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#7  0x7f664adb5535 in __GI_abort () at abort.c:79
#8  0x7f664affa943 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#9  0x7f664b000896 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#10 0x7f664b0008d1 in std::terminate() () from 
/lib/x86_64-linux-gnu/libstdc++.so.6
#11 0x7f664b173db3 in qTerminate() () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5
#12 0x7f664b176176 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#13 0x7f6649b03fa3 in start_thread (arg=) at 
pthread_create.c:486
#14 0x7f664ae8c88f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95


###


# buster amd64 qemu VM



apt update
apt dist-upgrade


apt install dpkg-dev devscripts systemd-coredump xserver-xorg sddm dbus-x11 
kde-plasma-desktop kdepim-runtime kalarm kdepim-runtime-dbgsym 
libqt5core5a-dbgsym pslist





mkdir libqt5core5a/orig -p
cdlibqt5core5a/orig
apt source libqt5core5a
cd ../..





systemctl start sddm

# login

# start kalarm




mkdir /home/benutzer/.local/share/akonadi/db_data/

#Otherwise:
#org.kde.pim.akonadiserver: database server stopped unexpectedly
#org.kde.pim.akonadiserver: Database process exited unexpectedly during 
initial connection!
#org.kde.pim.akonadiserver: executable: "/usr/sbin/mysqld-akonadi"
#org.kde.pim.akonadiserver: arguments: 
("--defaults-file=/home/benutzer/.local/share/akonadi/mysql.conf", 
"--datadir=/home/benutzer/.local/share/akonadi/db_data/", 
"--socket=/tmp/akonadi-benutzer.Tdwoum/mysql.socket", 
"--pid-file=/tmp/akonadi-benutzer.Tdwoum/mysql.pid")
#org.kde.pim.akonadiserver: stdout: ""
#org.kde.pim.akonadiserver: stderr: "2018-12-17 17:50:05 140020311248192 
[Note] /usr/sbin/mysqld (mysqld 10.1.37-MariaDB-3) starting as process 4023 
...\n2018-12-17 17:50:05 140020311248192 [Warning] Can't create test file 
/home/benutzer/.local/share/akonadi/db_data/debian.lower-test\n\x07/usr/sbin/mysqld:
 Can't change dir to '/home/benutzer/.local/share/akonadi/db_data/' (Errcode: 2 
\"No such file or directory\")\n2018-12-17 17:50:05 140020311248192 [ERROR] 
Aborting\n\n"
#org.kde.pim.akonadiserver: exit code: 1
#org.kde.pim.akonadiserver: process error: "Unknown error"
#org.kde.pim.akonadiserver: Failed to remove runtime connection config file
#org.kde.pim.akonadicontrol: Application 'akonadiserver' exited normally...




root@debian:~# gdb -q --pid $(pidof akonadi_akonotes_resource)
Attaching to process 4177
[New LWP 4178]
[New LWP 4179]
[New LWP 4180]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7fab578afbd9 in poll () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) generate-core-file 
warning: target file /proc/4177/cmdline contained unexpected null characters
Saved corefile core.4177
(gdb) detach
Detaching from program: /usr/bin/akonadi_akonotes_resource, process 4177
[Inferior 1 (process 4177) detached]
(gdb) q




root@debian:~# gdb -q /usr/bin/akonadi_akonotes_resource --core core.4177 -ex 
"set pagination off" -ex "info share" -ex quit | grep 
/lib/x86_64-linux-gnu/libQt5Core.so.5

warning: core file may not match specified executable file.
0x7fab57ba1290  0x7fab57e42252  Yes (*) 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5





root@debian:~# gdb -q /usr/bin/akonadi_akonotes_resource --core core.4177 -ex 
"set pagination off" -ex "disassemble 0x7fab57ba1290,0x7fab57e42252" 
-ex quit | grep 0x.176 -B1

warning: core file may not match specified executable file.
...
   0x7fab57ba4171 :   callq  
0x7fab57ba1dad 
   0x7fab57ba4176 :   mov%rax,%rbp
...






root@debian:~# gdb -q 

Bug#913715: simulide: terminates with segfault sometimes, when trying to undo changes

[Bernhard Übelacker]

Hello Nils Jarle Haugen,
these instructions are great to reproduce the crash.

Below is the backtrace with debug symbols installed.
It looks like the vector m_boardLed->m_pin contains invalid
data, and therefore we crash when calling methods on an
element retrieved from it.

Valgrind shows the same backtrace, while the accessed element
got free'd before.

This should probably be forwarded to upstream developers.
Upstream commit [1] might be related, but does not apply
cleanly to 0.1.7+dfsg-2.

Kind regards,
Bernhard



[1] https://sourceforge.net/p/simulide/svnrepo/434/




Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x5588dcda66e5 in Arduino::initialize (this=0x5588de934280) at 
../src/gui/circuitwidget/components/mcu/arduino.cpp:173
173 m_boardLed->getEpin(0)->setEnode(enod);
[Current thread is 1 (Thread 0x7f4e80ab3f80 (LWP 12035))]
(gdb) set width 0
(gdb) set pagination off
(gdb) directory /home/benutzer/simulide/orig/simulide-0.1.7+dfsg/src
Source directories searched: 
/home/benutzer/simulide/orig/simulide-0.1.7+dfsg/src:$cdir:$cwd
(gdb) bt
#0  0x5588dcda66e5 in Arduino::initialize (this=0x5588de934280) at 
../src/gui/circuitwidget/components/mcu/arduino.cpp:173
#1  0x5588dcdfee62 in Simulator::runContinuous (this=0x5588de808c30) at 
../src/simulator/simulator.cpp:176
#2  0x5588dcd321bf in Circuit::undo (this=this@entry=0x5588de808ba0) at 
../src/gui/circuitwidget/circuit.cpp:602
#3  0x5588dcd36230 in Circuit::keyPressEvent (this=0x5588de808ba0, 
event=0x7ffc53072c50) at ../src/gui/circuitwidget/circuit.cpp:999
#4  0x7f4e8912a567 in QGraphicsScene::event (this=0x5588de808ba0, 
event=0x7ffc53072c50) at graphicsview/qgraphicsscene.cpp:3387
#5  0x7f4e88e1a491 in QApplicationPrivate::notify_helper 
(this=this@entry=0x5588de7832c0, receiver=receiver@entry=0x5588de808ba0, 
e=e@entry=0x7ffc53072c50) at kernel/qapplication.cpp:3727
#6  0x7f4e88e21ad0 in QApplication::notify (this=0x7ffc53072ea0, 
receiver=0x5588de808ba0, e=0x7ffc53072c50) at kernel/qapplication.cpp:3486
#7  0x7f4e8832d039 in QCoreApplication::notifyInternal2 
(receiver=0x5588de808ba0, event=event@entry=0x7ffc53072c50) at 
../../include/QtCore/5.11.2/QtCore/private/../../../../../src/corelib/thread/qthread_p.h:307
#8  0x7f4e89146f87 in QCoreApplication::sendEvent (event=0x7ffc53072c50, 
receiver=) at 
../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:234
#9  QGraphicsView::keyPressEvent (this=0x5588de85a9e0, event=0x7ffc53072c50) at 
graphicsview/qgraphicsview.cpp:3161
#10 0x7f4e88e58de7 in QWidget::event (this=this@entry=0x5588de85a9e0, 
event=event@entry=0x7ffc53072c50) at kernel/qwidget.cpp:8940
#11 0x7f4e88efbdee in QFrame::event (this=this@entry=0x5588de85a9e0, 
e=e@entry=0x7ffc53072c50) at widgets/qframe.cpp:550
#12 0x7f4e88efea04 in QAbstractScrollArea::event (this=0x5588de85a9e0, 
e=0x7ffc53072c50) at widgets/qabstractscrollarea.cpp:1168
#13 0x7f4e88e1a491 in QApplicationPrivate::notify_helper 
(this=this@entry=0x5588de7832c0, receiver=receiver@entry=0x5588de85a9e0, 
e=e@entry=0x7ffc53072c50) at kernel/qapplication.cpp:3727
#14 0x7f4e88e22a59 in QApplication::notify (this=, 
receiver=0x5588de85a9e0, e=0x7ffc53072c50) at kernel/qapplication.cpp:3121
#15 0x7f4e8832d039 in QCoreApplication::notifyInternal2 
(receiver=0x5588de85a9e0, event=0x7ffc53072c50) at 
../../include/QtCore/5.11.2/QtCore/private/../../../../../src/corelib/thread/qthread_p.h:307
#16 0x7f4e88e75e79 in QWidgetWindow::event (event=0x7ffc53072c50, 
this=0x5588de92ce80) at kernel/qwidgetwindow.cpp:274
#17 QWidgetWindow::event (this=0x5588de92ce80, event=0x7ffc53072c50) at 
kernel/qwidgetwindow.cpp:224
#18 0x7f4e88e1a491 in QApplicationPrivate::notify_helper 
(this=this@entry=0x5588de7832c0, receiver=receiver@entry=0x5588de92ce80, 
e=e@entry=0x7ffc53072c50) at kernel/qapplication.cpp:3727
#19 0x7f4e88e21ad0 in QApplication::notify (this=0x7ffc53072ea0, 
receiver=0x5588de92ce80, e=0x7ffc53072c50) at kernel/qapplication.cpp:3486
#20 0x7f4e8832d039 in QCoreApplication::notifyInternal2 
(receiver=receiver@entry=0x5588de92ce80, event=event@entry=0x7ffc53072c50) at 
../../include/QtCore/5.11.2/QtCore/private/../../../../../src/corelib/thread/qthread_p.h:307
#21 0x7f4e8872e388 in QCoreApplication::sendSpontaneousEvent 
(event=0x7ffc53072c50, receiver=0x5588de92ce80) at 
../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:237
#22 QGuiApplicationPrivate::processKeyEvent (e=0x7f4e78028cb0) at 
kernel/qguiapplication.cpp:2207
#23 0x7f4e88733a05 in QGuiApplicationPrivate::processWindowSystemEvent 
(e=e@entry=0x7f4e78028cb0) at kernel/qguiapplication.cpp:1822
#24 0x7f4e8870dd8b in QWindowSystemInterface::sendWindowSystemEvents 
(flags=...) at kernel/qwindowsysteminterface.cpp:1032
#25 0x7f4e80a0585b in QPAEventDispatcherGlib::processEvents 
(this=0x5588de775ef0, flags=...) at qeventdispatcher_glib.cpp:70
#26 0x7f4e8832bd0b in 

Bug#916200: script: does not reap signaled children any more, deadlocks until SIGKILL

[Bernhard Übelacker]

Control: fixed 916200 1:2.30.2-0.3
Control: found 916200 1:2.31.1-0.1


Dear Maintainer,
I noticed this behaviour too and found last version that
normally exits is 2.30.2.

I did a git bisect that points to the upstream commit [1] below.

Kind regards,
Bernhard


[1] 
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=2e7a92270114cc652ea090251a374e917adb7a72


# git bisect good
2e7a92270114cc652ea090251a374e917adb7a72 is the first bad commit
commit 2e7a92270114cc652ea090251a374e917adb7a72
Author: Karel Zak 
Date:   Fri Sep 8 09:48:29 2017 +0200

script: support sig{stop/cont}

* call wait() only when child exited
* suspend all session (including script master process) when child get
  SIGSTOP and send SIGCONT to child when master process resume

This allows to suspend all session and later use "fg" shell command to
resume.

$ ps af
14722 pts/1Ss 0:00 bash
 4870 pts/1S+ 0:00  \_ ./script
 4871 pts/6Ss+0:00  \_ bash -i

$ kill -SIGSTOP 4871

and script session on another terminal:

$ script
Script started, file is typescript
$ 
[1]+  Stopped ./script

$ fg 1
./script

... session again usable ...
^D
Script done, file is typescript

Signed-off-by: Karel Zak 

:04 04 5f6d5eb332f5db3c41cb095d39efdca5be5baf6e 
cdc08b6da0bc5f5a93be049c1a80f0b0620a9417 M  term-utils



# buster amd64 qemu VM


apt update
apt dist-ugprade
apt build-dep util-linux


apt install bsdutils git


script -c "vi"
kill $(pidof vi)
kill -9 $(pidof script)


wget 
https://snapshot.debian.org/archive/debian/20170322T211511Z/pool/main/u/util-linux/bsdutils_2.29.2-1_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20180117T154752Z/pool/main/u/util-linux/bsdutils_2.30.2-0.3_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20180308T040556Z/pool/main/u/util-linux/bsdutils_2.31.1-0.5_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20180210T101430Z/pool/main/u/util-linux/bsdutils_2.31.1-0.1_amd64.deb



bsdutils  1:2.29.2-1ends
bsdutils  1:2.30.2-0.3  ends
bsdutils  1:2.31.1-0.1  hangs
bsdutils  1:2.31.1-0.5  hangs
bsdutils  1:2.32.1-0.1  hangs



git clone git://git.kernel.org/pub/scm/utils/util-linux/util-linux.git
git checkout v2.30.2
./autogen.sh
./configure
make -j8
./script -c "vi"
make clean
git checkout v2.31.1
...



git checkout v2.30.2# ends
git checkout v2.31.1# hangs




root@debian:~/util-linux# git bisect start
root@debian:~/util-linux# git bisect good v2.30.2
root@debian:~/util-linux# git bisect bad v2.31.1
binäre Suche: eine Merge-Basis muss geprüft werden
[dd9bae58ae4bc3bded2acf743981bbc8c06f468a] build-sys: release++ (v2.30)
root@debian:~/util-linux# git bisect good
binäre Suche: danach noch 315 Commits zum Testen übrig (ungefähr 8 Schritte)
[5264aebb4f822fa9147ee576562a4961ca97261d] lib/randutils: improve getrandom() 
usage
root@debian:~/util-linux# git bisect good
binäre Suche: danach noch 157 Commits zum Testen übrig (ungefähr 7 Schritte)
[6b28328255aa1248931947a4d1521288bde01837] su: properly clear child PID
root@debian:~/util-linux# git bisect bad
binäre Suche: danach noch 71 Commits zum Testen übrig (ungefähr 6 Schritte)
[d17fb726b562a69e8f174d46fa6cf794abc129cd] rfkill: merge rfkill.8 project to 
util-linux
root@debian:~/util-linux# git bisect good
binäre Suche: danach noch 35 Commits zum Testen übrig (ungefähr 5 Schritte)
[2e7a92270114cc652ea090251a374e917adb7a72] script: support sig{stop/cont}
root@debian:~/util-linux# git bisect bad
binäre Suche: danach noch 17 Commits zum Testen übrig (ungefähr 4 Schritte)
[24f9dde539777417325d6039e2f2387d792afe96] build-sys: remove unused rfkill.py
root@debian:~/util-linux# git bisect good
binäre Suche: danach noch 8 Commits zum Testen übrig (ungefähr 3 Schritte)
[5b8e46f7e7710e2bb88ff8e763997830c9494df2] hwclock: close hwaudit_fd 
unconditionally
root@debian:~/util-linux# git bisect good
binäre Suche: danach noch 4 Commits zum Testen übrig (ungefähr 2 Schritte)
[3184afa529de5efc77c4ea1f0574276a6f482f7e] uuidgen: add more details to man page
root@debian:~/util-linux# git bisect good
binäre Suche: danach noch 2 Commits zum Testen übrig (ungefähr 1 Schritt)
[08e3c9e6620232aa5433d102d3f8ac28bbae01b0] hwclock: update usage()
root@debian:~/util-linux# git bisect good
binäre Suche: danach noch 0 Commits zum Testen übrig (ungefähr 1 Schritt)
[e12364cdfb2c8046bfe34f18af9583f1dcf934c9] lsblk: small man page change in 
return codes description
root@debian:~/util-linux# git bisect good
2e7a92270114cc652ea090251a374e917adb7a72 is the first bad commit
commit 2e7a92270114cc652ea090251a374e917adb7a72
Author: Karel Zak 
Date:   Fri Sep 8 09:48:29 2017 +0200

script: support sig{stop/cont}

* call wait() only when child exited
* suspend all 

Bug#916288: kea-dhcp4-server: Segfault after running for several minutes

[Bernhard Übelacker]

Hello Anton,

On Fri, 14 Dec 2018 16:34:23 -0500 Anton Avramov  wrote:
> Hello Bernhard,
> 
> Well no. I've actually installed. apt install 
> libmariadbclient18=10.1.26-0+deb9u1 libmariadbclient18-dbgsym
> 
> (gdb) display/i $pc
> 2: x/i $pc
> => 0x7479eccc :    movzbl 0x451(%rax),%eax

At this instruction $rax seems to contain the address stored in stmt->mysql.
This address seems to be invalid in your process.
And therefore accessing the options member crashes.


Could you please add the output of following commands, when the crash happened:
  print/x $rax
  print stmt->mysql
  print stmt
  set print pretty on
  print *stmt
  print *stmt->mysql
  set print pretty off
  up
  print 
conn_.statements_[isc::dhcp::MySqlHostDataSourceImpl::GET_HOST_SUBID4_DHCPID]
  up
  x/6xb identifier_begin


The last line should output 6 bytes showing the MAC address of the
requesting client. Maybe you could check if that crash is
triggered always by the same client or kind of client.


I looked through upstream git history and commits [1] and [2] might be
related: they disable automatic reconnects.
No such commit seem to have reached the stretch version of kea-dhcp:
./isc-kea-1.1.0/src/lib/dhcpsrv/mysql_connection.cc:138:my_bool 
auto_reconnect = MLM_TRUE;


Kind regards,
Bernhard


(gdb) list libmysql.c:4134
4129  field->type, param_count);
4130  DBUG_RETURN(1);
4131}
4132  }
4133  stmt->bind_result_done= BIND_RESULT_DONE;
4134  if (stmt->mysql->options.report_data_truncation)
4135stmt->bind_result_done|= REPORT_DATA_TRUNCATION;
4136
4137  DBUG_RETURN(0);
4138}


[1] 
https://gitlab.isc.org/isc-projects/kea/commit/9881ef6d772f27de82c048e198ba0ff9e71b9351
[2] 
https://gitlab.isc.org/isc-projects/kea/commit/6b278a3f54ecf6bd6e2d381047a9eced4bf165f5


# From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916288#5

Thread 1 "kea-dhcp4" received signal SIGSEGV, Segmentation fault.
0x747f525c in mysql_stmt_bind_result () from 
/usr/lib/x86_64-linux-gnu/libmariadbclient.so.18
(gdb) (gdb) bt
#0  0x747f525c in mysql_stmt_bind_result () from 
/usr/lib/x86_64-linux-gnu/libmariadbclient.so.18
#1  0x77a9ed19 in ?? () from 
/usr/lib/x86_64-linux-gnu/libkea-dhcpsrv.so.6
#2  0x77a9f540 in ?? () from 
/usr/lib/x86_64-linux-gnu/libkea-dhcpsrv.so.6
#3  0x77aa0551 in isc::dhcp::MySqlHostDataSource::get4(unsigned int 
const&, isc::dhcp::Host::IdentifierType const&, unsigned char const*, unsigned 
long) const ()from /usr/lib/x86_64-linux-gnu/libkea-dhcpsrv.so.6
#4  0x77a5acba in isc::dhcp::HostMgr::get4(unsigned int const&, 
isc::dhcp::Host::IdentifierType const&, unsigned char const*, unsigned long) 
const ()from /usr/lib/x86_64-linux-gnu/libkea-dhcpsrv.so.6
#5  0x779eeb8c in boost::shared_ptr 
boost::_mfi::cmf4, isc::dhcp::HostMgr, 
unsigned int const&, isc::dhcp::Host::IdentifierType const&, unsigned char 
const*, unsigned long>::call(isc::dhcp::HostMgr* const&, void const*, unsigned int const&, 
isc::dhcp::Host::IdentifierType const&, unsigned char const*&, unsigned long&) 
const () from /usr/lib/x86_64-linux-gnu/libkea-dhcpsrv.so.6
#6  0x779ed9b1 in boost::shared_ptr 
boost::_mfi::cmf4, isc::dhcp::HostMgr, 
unsigned int const&, isc::dhcp::Host::IdentifierType const&, unsigned char 
const*, unsigned long>::operator()(isc::dhcp::HostMgr* 
const&, unsigned int const&, isc::dhcp::Host::IdentifierType const&, unsigned 
char const*, unsigned long) const () from 
/usr/lib/x86_64-linux-gnu/libkea-dhcpsrv.so.6
#7  0x779ec881 in boost::shared_ptr 
boost::_bi::list5, boost::arg<1>, 
boost::arg<2>, boost::arg<3>, boost::arg<4> 
>::operator(), 
boost::_mfi::cmf4, isc::dhcp::HostMgr, 
unsigned int const&, isc::dhcp::Host::IdentifierType const&, unsigned char 
const*, unsigned long>, boost::_bi::rrlist4 
>(boost::_bi::type >, 
boost::_mfi::cmf4, isc::dhcp::HostMgr, 
unsigned int const&, isc::dhcp::Host::IdentifierType const&, unsigned char 
const*, unsigned long>&, boost::_bi::rrlist4&, 
long) () from /usr/lib/x86_64-linux-gnu/libkea-dhcpsrv.so.6
#8  0x779eadbe in boost::shared_ptr 
boost::_bi::bind_t, 
boost::_mfi::cmf4, isc::dhcp::HostMgr, 
unsigned int const&, isc::dhcp::Host::IdentifierType const&, unsigned char 
const*, unsigned long>, 
boost::_bi::list5, boost::arg<1>, 
boost::arg<2>, boost::arg<3>, boost::arg<4> > >::operator()(unsigned int const&, isc::dhcp::Host::IdentifierType const&, unsigned 
char const*&&, unsigned long&&) () from 
/usr/lib/x86_64-linux-gnu/libkea-dhcpsrv.so.6
#9  0x779e83e8 in 
boost::detail::function::function_obj_invoker4, boost::_mfi::cmf4, 
isc::dhcp::HostMgr, unsigned int const&, isc::dhcp::Host::IdentifierType 
const&, unsigned char const*, unsigned long>, 
boost::_bi::list5, boost::arg<1>, 
boost::arg<2>, boost::arg<3>, boost::arg<4> > >, 
boost::shared_ptr, unsigned int const&, 
isc::dhcp::Host::IdentifierType const&, unsigned char const*, unsigned 

Bug#916288: kea-dhcp4-server: Segfault after running for several minutes

[Bernhard Übelacker]

Hello Anton,
sorry, did completely miss the option that upstream could
also provide dbgsym packages ...

Just to be sure, the last backtrace was retrieved with upstream
binaries of version 10.2.19+maria~stretch?
And debug symbols are contained in libmariadb3-dbgsym?

Because your last backtrace shows mysql_stmt_bind_result
from "./libmysql/libmysql.c:4134".
But in [1] I just found a "./libmysqld/libmysql.c"
(the directory is not equal).
And in that line 4134 is the end of the expected function.

But attaching a debugger to a live process and setting a breakpoint
to mysql_stmt_bind_result shows ./libmariadb/libmariadb/mariadb_stmt.c:1210
in my test environment.
And in that file is another implementation for mysql_stmt_bind_result ...

Therefore you probably can supply another backtrace with the output of
following additional commands?

  display/i $pc
  info share

And maybe what this command outputs:
  ls -lisah /usr/lib/x86_64-linux-gnu/{*maria*,*mysql*}

Kind regards,
Bernhard


[1] Get:1 http://mirror.23media.de/mariadb/repo/10.2/debian stretch/main 
mariadb-10.2 10.2.19+maria~stretch (dsc) [3275 B]
Get:2 http://mirror.23media.de/mariadb/repo/10.2/debian stretch/main 
mariadb-10.2 10.2.19+maria~stretch (tar) [45.6 MB]

Bug#916288: kea-dhcp4-server: Segfault after running for several minutes

[Bernhard Übelacker]

Hello Anton Avramov,
not involved in packaging of isc-kea I just read
your report and may have some points.

Why do you use the upstream binary of libmariadbclient.so.18.
Is the stretch packaged version 10.1.37-0+deb9u1 too old? [1]

And it looks like you installed the debug symbol package 
kea-dhcp4-server-dbgsym?
Maybe you could also add kea-common-dbgsym?
And if it fails with libmariadbclient18 from stretch also
I would have suggested to install libmariadbclient18-dbgsym,
but unfortunately it looks like there are no debug symbols from
security packages broadly available [2].
(Maybe a set of local rebuilt packages for 10.1.37-0+deb9u1
including the dbgsym package?)

Kind regards,
Bernhard

[1] https://packages.debian.org/stretch/libmariadbclient18
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894081

Bug#916179: roger-router: selecting Preferences makes the program hang

[Bernhard Übelacker]

Hello Marc Lehmann,
are you able to reproduce this hang on a installation
with just stretch package versions, too.
(Or maybe on a buster installation)
I ask because at least following packages are more current as
the plain stretch versions:

| versions reported | currently in stretch
libatk1.0-0 | 2.30.0-1  | 2.22.0-1
libc6   | 2.27-8| 2.24-11+deb9u3
libcairo-gobject2   | 1.16.0-1  | 1.14.8-1
libcairo2   | 1.16.0-1  | 1.14.8-1
libglib2.0-0| 2.58.1-2  | 2.50.3-2
libgtk-3-0  | 3.24.1-2  | 3.22.11-1
libjson-glib-1.0-0  | 1.4.4-1   | 1.2.6-1
libpango-1.0-0  | 1.42.4-4  | 1.40.5-1
libpangocairo-1.0-0 | 1.42.4-4  | 1.40.5-1
libsoup2.4-1| 2.64.2-1  | 2.56.0-2+deb9u2

Even when upgrading these packages inside my test VM
I could not reproduce this hang, therefore if it is not
related to the package versions it may be related to your
sound equipment ...



... after some more trying I found that I could reproduce a quite
matching hang when I use following sequence (with just stretch packages):

export PULSE_BINARY=/not-existing
pulseaudio -k
roger

That effectively avoids the start of the pulseaudio daemon.
(except when some other application would restart it.)
Therefore another thing to check would be if there is really an
pulseaudio daemon running on your system? Do you start roger with some
other environments that prevent the connection to the daemon?

Kind regards,
Bernhard

# stretch amd64 qemu VM, with -soundhw hda


apt update
apt dist-upgrade

apt install mc dpkg-dev devscripts gdb xserver-xorg lightdm openbox pulseaudio 
dbus-x11 roger-router roger-router-dbgsym roger-router-cli-dbgsym


systemctl start lightdm

adduser benutzer fax



mkdir roger-router/orig -p
cdroger-router/orig
apt source roger-router
cd ../..



export LANG=C
export DISPLAY=:0
export PULSE_BINARY=/not-existing
pulseaudio -k
roger


# open preferences - hangs



benutzer@debian:~$ gdb -q --pid 22998
Attaching to process 22998
[New LWP 23002]
[New LWP 23004]
[New LWP 23005]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7fbb11753741 in __GI_ppoll (fds=0x562a7b666750, nfds=1, 
timeout=, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:39
39  ../sysdeps/unix/sysv/linux/ppoll.c: Datei oder Verzeichnis nicht 
gefunden.
(gdb) bt
#0  0x7fbb11753741 in __GI_ppoll (fds=0x562a7b666750, nfds=1, 
timeout=, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:39
#1  0x7fbaf77b154d in pa_mainloop_poll () from 
/usr/lib/x86_64-linux-gnu/libpulse.so.0
#2  0x7fbaf77b1b3e in pa_mainloop_iterate () from 
/usr/lib/x86_64-linux-gnu/libpulse.so.0
#3  0x7fbaf7be53d9 in pulse_get_device_list (input=0x7fbaf7de7240 
, output=0x7fbaf7dea2c0 ) at 
pulseaudio.c:247
#4  pulse_audio_detect_devices () at pulseaudio.c:263
#5  0x562a7a716219 in plugin_combobox_changed_cb (box=, 
user_data=) at pref_audio.c:74
#6  0x7fbb1299af75 in g_closure_invoke () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#7  0x7fbb129acf82 in ?? () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#8  0x7fbb129b5bdc in g_signal_emit_valist () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#9  0x7fbb129b5fbf in g_signal_emit () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#10 0x7fbb147d515b in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#11 0x7fbb147d7618 in gtk_combo_box_set_active_iter () from 
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#12 0x7fbb147d8b40 in gtk_combo_box_set_active_id () from 
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#13 0x7fbb129a318b in g_object_set_property () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#14 0x7fbb12f1a9c3 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#15 0x7fbb12f1d6c0 in g_settings_bind_with_mapping () from 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#16 0x7fbb12f1d93a in g_settings_bind () from 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#17 0x562a7a7166a2 in pref_page_audio () at pref_audio.c:168
#18 0x562a7a71461f in preferences () at pref.c:140
#19 0x7fbb1299af75 in g_closure_invoke () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#20 0x7fbb129acf82 in ?? () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#21 0x7fbb129b5bdc in g_signal_emit_valist () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#22 0x7fbb129b5fbf in g_signal_emit () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#23 0x7fbb12eb9705 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#24 0x7fbb1476f0be in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#25 0x7fbb1476f0f4 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#26 0x7fbb1476f0f4 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#27 0x7fbb148c7fc6 in ?? () from 

Bug#914879: Сlosing a tab causes the window to close

[Bernhard Übelacker]

Dear Maintainer,
tried just to reproduce and found that this issue should be
solved upstream with commit [1].
Upstream has also an entry in their bug tracker [2].

This commit is not yet included in an upstream released version.

[1] 
https://git.xfce.org/apps/xfce4-terminal/commit/terminal/terminal-window.c?id=49de8821b08c490297a518f9a4472f85de5f3c25
[2] https://bugzilla.xfce.org/show_bug.cgi?id=14645

Kind regards,
Bernhard

Bug#916220: saidar: segfault after couple of minutes

[Bernhard Übelacker]

Hello Mindaugas Celiesius,
I just tried to reproduce the crash.
Unfortunately it did not crash in my test.

Therefore I assume the information you provided is not
sufficient for the Maintainer to correct the program.

Maybe you could install a core dump collector like systemd-coredump.
When another crash happens you can enumerate the recorded crashes by:
  coredumpctl list

And possibly provide the information given by:
  coredumpctl gdb

This output would be even better if saidar-dbgsym from the
debug symbol repositories described in [1].

Kind regards,
Bernhard

[1] https://wiki.debian.org/HowToGetABacktrace

Bug#909015: abiword: Crashes on startup with GLib-ERROR

[Bernhard Übelacker]

Control: reassign 909015 libcogl20 1.22.2-2
Control: affects 909015 abiword

Dear Maintainer,
this crash seems to be caused by a broken opengl configuration.
It could still be seen with buster when e.g. someone has the
nvidia-driver-libs-nonglvnd installed without the kernel module loaded.

Unfortunately there is no output at stdout that would point
the user to that direction. Instead the application just crashes.

With attached patch the cogl initialization would at least just fail and
clutter could write an error message to stdout.
  Unable to initialize Clutter: Unable to initialize the Clutter backend: no 
available drivers found.

Kind regards,
Bernhard
From 338a1c3c8a10c4e28cadf96e0ce76d933ede625d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
Date: Tue, 11 Dec 2018 18:25:59 +0100
Subject: [PATCH] Fail gracefully when no usable device is found.

Debian-Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909015
---
 cogl/cogl-context.c|  2 +-
 cogl/driver/gl/gles/cogl-driver-gles.c | 20 
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/cogl/cogl-context.c b/cogl/cogl-context.c
index a7eed29..9503561 100644
--- a/cogl/cogl-context.c
+++ b/cogl/cogl-context.c
@@ -679,7 +679,7 @@ _cogl_context_get_gl_extensions (CoglContext *context)
 #ifdef HAVE_COGL_GL
   if (context->driver == COGL_DRIVER_GL3)
 {
-  int num_extensions, i;
+  int num_extensions = 0, i;
 
   context->glGetIntegerv (GL_NUM_EXTENSIONS, _extensions);
 
diff --git a/cogl/driver/gl/gles/cogl-driver-gles.c b/cogl/driver/gl/gles/cogl-driver-gles.c
index e94449f..7ef375a 100644
--- a/cogl/driver/gl/gles/cogl-driver-gles.c
+++ b/cogl/driver/gl/gles/cogl-driver-gles.c
@@ -238,6 +238,23 @@ _cogl_get_gl_version (CoglContext *ctx,
  minor_out);
 }
 
+static CoglBool
+check_gl_version (CoglContext *ctx,
+  char **gl_extensions,
+  CoglError **error)
+{
+  if (!_cogl_context_get_gl_version (ctx))
+{
+  _cogl_set_error (error,
+   COGL_DRIVER_ERROR,
+   COGL_DRIVER_ERROR_UNKNOWN_VERSION,
+   "The GLES version could not be determined");
+  return FALSE;
+}
+
+  return TRUE;
+}
+
 static CoglBool
 _cogl_driver_update_features (CoglContext *context,
   CoglError **error)
@@ -259,6 +276,9 @@ _cogl_driver_update_features (CoglContext *context,
 
   gl_extensions = _cogl_context_get_gl_extensions (context);
 
+  if (!check_gl_version (context, gl_extensions, error))
+return FALSE;
+
   if (G_UNLIKELY (COGL_DEBUG_ENABLED (COGL_DEBUG_WINSYS)))
 {
   char *all_extensions = g_strjoinv (" ", gl_extensions);
-- 
2.19.2

Bug#865460: No login and crash at reconnect

[Bernhard Übelacker]

Hello Jörg Frings-Fürst,
I am not maintaining roger-router, but just saw this report.
Do you still receive this segmentation fault?

If yes you might run roger like the following:
(That should print the backtrace when the segmentation fault happens.)

  gdb -q -ex run -ex bt -ex detach -ex quit --args roger

Another way would be to install a core dump collector like systemd-coredump.
Then a backtrace can be extracted from that stored core dump.

  coredumpctl list
  coredumpctl gdb 

Even better if debug symbols are installed like described in [1].

Kind regards,
Bernhard

[1] https://wiki.debian.org/HowToGetABacktrace

Bug#916179: roger-router: selecting Preferences makes the program hang

[Bernhard Übelacker]

Hello Marc Lehmann,
in that situation an strace is probably not that helpful.
Maybe you can provide a backtrace while the program is frozen.


You might use following in a different terminal:
(Basically attaches a debugger every 30 seconds, prints the backtrace and 
detaches.)

while true; do echo  $(date); cat /proc/$(pidof roger)/stack; gdb -q -ex bt 
-ex detach -ex quit --pid $(pidof roger); sleep 30s; done


Even better if debug symbols would be installed like described in [1].
At least roger-router-dbgsym, better for the shown shared objects in the
backtrace too (if available in stretch).

Kind regards,
Bernhard

[1] https://wiki.debian.org/HowToGetABacktrace

Bug#914616: Fixed by latest binNMU

[Bernhard Übelacker]

Control: notfixed 914616 20181001.4.a99aaec~ds6-2+b1

Hello Petter Reinholdtsen,
in another bug I got told that BTS is not handling
binNMU versions, therefore ending up with fixed+found
versions being the same (915364).

Maybe that is also the case here why the autoremoval stays.
Let's try to just remove the fixed and see if the autoremoval
is removed tomorrow?

Kind regards,
Bernhard

Bug#914565: php7.3-intl: Segfaults after apache2 graceful restart

[Bernhard Übelacker]

While looking into #915642 I found that this bug might just
be another case of bug #904808.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904808

Kind regards,
Bernhard

Bug#915642: AuthBasicProvider PAM crashes apache

[Bernhard Übelacker]

Dear Maintainer,
I just tried to reproduce and found it crash on service startup when
using the given /etc/apache2/sites-enabled/default.conf.

It looks like here the apache2 process wants to fork and calls the
fork_handlers. Unfortunately one of them belongs to an unloaded module.
Therefore we end up trying to execute unmapped memory.

>From the similar offset I would expect that the first fork_handler belong
to function deinit from libcap-ng.so.0.
The first one 0x7f50c8e0e660 points to the current location of libcap-ng.so.0.
But the second 0x7f50c8e12660 looks like pointing to an unloaded location of 
libcap-ng.so.0.

This situation looks quite similar to what I tried to collect in bug #914565.
And now that I looked up the bugs for libcap-ng0 this one seems related: 
#904808.

Kind regards,
Bernhard


#914565 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914565
#904808 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904808


(gdb) bt
#0  0x7f50c8e12660 in ?? ()
#1  0x7f50c921470e in __libc_fork () at ../sysdeps/nptl/fork.c:204
#2  0x7f50c9357875 in apr_proc_detach (daemonize=daemonize@entry=1) at 
./threadproc/unix/procsup.c:31
#3  0x7f50c8b93fc5 in event_pre_config (pconf=0x7f50c90b8028, 
plog=0x7f50c908c028, ptemp=) at event.c:3416
#4  0x55e968fd81be in ap_run_pre_config (pconf=0x7f50c90b8028, 
plog=0x7f50c908c028, ptemp=0x7f50c9090028) at config.c:89
#5  0x55e968fb3e5f in main (argc=, argv=) at 
main.c:775

(gdb) up
#2  0x7f50c9357875 in apr_proc_detach (daemonize=daemonize@entry=1) at 
./threadproc/unix/procsup.c:31
31  if ((x = fork()) > 0) {

(gdb) print *__fork_handlers
$1 = {next = 0x7f50c9309998 , prepare_handler = 0x0, 
parent_handler = 0x0, child_handler = 0x7f50c8e0e660 , dso_handle = 
0x7f50c93282a0, refcntr = 2, need_signal = 0}
(gdb) print *__fork_handlers->next
$2 = {next = 0x7f50c9309968 , prepare_handler = 0x0, 
parent_handler = 0x0, child_handler = 0x7f50c8e12660, dso_handle = 
0x7f50c93282a0, refcntr = 2, need_signal = 0}
(gdb) print *__fork_handlers->next->next
$3 = {next = 0x0, prepare_handler = 0x0, parent_handler = 0x0, child_handler = 
0x7f50c93133d0 <__reclaim_stacks>, dso_handle = 0x0, refcntr = 1, need_signal = 
0}

(gdb) info share
>FromTo  Syms Read   Shared Object Library
...
0x7f50c8e0e560  0x7f50c8e10419  Yes 
/lib/x86_64-linux-gnu/libcap-ng.so.0
...

Bug#916060: tuxmath: Starts and immediately closes

[Bernhard Übelacker]

Dear Maintainer,
I just tried to reproduce and collect some more information,
used a minimal buster amd64 qemu VM.

This issue seems to be more located in libt4k-common0.
It uses "rsvg_handle_get_desc(file_handle)" to retrieve
a char pointer to the description and tries to convert that
into an integer by sscanf [1].

Unfortunately seems librsvg-2.42 [2] the last release that
supported that way of operation. 
librsvg removed that functionality in commit [3].

Therefore in current version just a null pointer [4] is returned
by rsvg_handle_get_desc that leads to the crash in load_svg_sprite:


(gdb) bt
#0  __rawmemchr_sse2 () at ../sysdeps/x86_64/multiarch/../rawmemchr.S:37
#1  0x7febe0ac3342 in _IO_str_init_static_internal 
(sf=sf@entry=0x7ffd7b8ad720, ptr=ptr@entry=0x0, size=size@entry=0, 
pstart=pstart@entry=0x0) at strops.c:41
#2  0x7febe0ab624d in _IO_vsscanf (string=0x0, format=0x7febe0c35c62 "%d", 
args=args@entry=0x7ffd7b8ad850) at iovsscanf.c:40
#3  0x7febe0ab03f4 in __sscanf (s=, 
format=format@entry=0x7febe0c35c62 "%d") at sscanf.c:32
#4  0x7febe0c2c3c9 in load_svg_sprite (file_name=, 
width=width@entry=-1, height=height@entry=-1) at t4k_loaders.c:217
#5  0x7febe0c2d52b in load_sprite (name=name@entry=0x55b6034762a1 
"comets/comet", mode=mode@entry=4, w=w@entry=-1, h=h@entry=-1, 
proportional=proportional@entry=false) at t4k_loaders.c:714
#6  0x7febe0c2d978 in T4K_LoadScaledSprite (name=name@entry=0x55b6034762a1 
"comets/comet", mode=mode@entry=4, width=width@entry=-1, 
height=height@entry=-1) at t4k_loaders.c:651
#7  0x7febe0c2d98c in T4K_LoadSprite (name=name@entry=0x55b6034762a1 
"comets/comet", mode=mode@entry=4) at t4k_loaders.c:646
#8  0x55b60345b961 in load_image_data () at fileops_media.c:213
#9  0x55b603448962 in load_data_files () at setup.c:759
#10 0x55b6034497c5 in setup (argc=1, argv=0x7ffd7b8ae758) at setup.c:139
#11 0x55b603447be9 in main (argc=, argv=) at 
tuxmath.c:40


Kind regards,
Bernhard


[1] https://github.com/tux4kids/t4kcommon/blob/master/src/t4k_loaders.c#L228
[2] 
https://gitlab.gnome.org/GNOME/librsvg/blob/librsvg-2.42/librsvg/rsvg-handle.c#L772
[3] 
https://gitlab.gnome.org/GNOME/librsvg/commit/1006c2001d4775b6d5b20d5f77c5aea9ac280fcb
[4] 
https://gitlab.gnome.org/GNOME/librsvg/blob/master/librsvg/rsvg-handle.c#L1007

# buster amd64 qemu VM

apt update
apt dist-upgrade

apt install mc psmisc devscripts dpkg-dev systemd-coredump strace gdb 
xserver-xorg lightdm openbox tuxmath tuxmath-dbgsym libt4k-common0-dbgsym 
librsvg2-2-dbgsym
apt build-dep t4kcommon


systemctl start lightdm





mkdir libt4k-common0/orig -p
cdlibt4k-common0/orig
apt source libt4k-common0
cd ../..

mkdir librsvg2-2/orig -p
cdlibrsvg2-2/orig
apt source librsvg2-2
cd ../..









export LANG=C
export DISPLAY=:0
tuxmath





root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Sun 2018-12-09 22:02:02 CET8201  1000  1000  11 present   
/usr/lib/tuxmath/tuxmath
root@debian:~# coredumpctl gdb 8201
   PID: 8201 (tuxmath)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 11 (SEGV)
 Timestamp: Sun 2018-12-09 22:02:02 CET (28s ago)
  Command Line: tuxmath
Executable: /usr/lib/tuxmath/tuxmath
 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: b8debb360de74c7698ecca6a9e56eac5
Machine ID: 32f43b50ac8c4b21941bc0b02f8e7811
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.tuxmath.1000.b8debb360de74c7698ecca6a9e56eac5.8201.154438932200.lz4
   Message: Process 8201 (tuxmath) of user 1000 dumped core.

Stack trace of thread 8201:
#0  0x7febe0ad67af __rawmemchr_sse2 (libc.so.6)
#1  0x7febe0ac3342 _IO_str_init_static_internal (libc.so.6)
#2  0x7febe0ab624d _IO_vsscanf (libc.so.6)
#3  0x7febe0ab03f4 __sscanf (libc.so.6)
#4  0x7febe0c2c3c9 load_svg_sprite (libt4k_common.so.0)
#5  0x7febe0c2d52b load_sprite (libt4k_common.so.0)
#6  0x55b60345b961 n/a (tuxmath)
#7  0x55b603448962 n/a (tuxmath)
#8  0x55b6034497c5 n/a (tuxmath)
#9  0x55b603447be9 main (tuxmath)
#10 0x7febe0a67b17 __libc_start_main (libc.so.6)
#11 0x55b603447c2a n/a (tuxmath)

GNU gdb (Debian 8.2-1) 8.2
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for 

Bug#915607: prelink breaks kwallet5d, plasmashell on amd64

[Bernhard Übelacker]

Dear Maintainer,
tried to reproduce this issue and attached backtrace is created by
- using a minimal buster amd64 qemu VM
- installing a minimal plasma desktop
- logging into graphical session
- via ssh: running "prelink -mR /usr/bin/plasmashell"
- via ssh: running "DISPLAY=:0 /usr/bin/plasmashell --replace"


The crash seems to happen on an attempt to resolve the member
QQuickWindow::event through the executables .plt section.
For some reason with prelink this pointer looks damaged and
points not into the .plt section:

With prelink:
0x77e3f978 <_ZTVN12KQuickAddons21QuickViewSharedEngineE+56>:
0x551d8b171af0
(gdb) stepi
0x551d8b171af0 in ?? ()

Without prelink:
0x77e3f978 <_ZTVN12KQuickAddons21QuickViewSharedEngineE+56>:
0x55571af0
(gdb) stepi
0x55571af0 in QQuickWindow::event(QEvent*)@plt ()


Kind regards,
Bernhard


(gdb) bt
#0  0x551d8b171af0 in ?? ()
#1  0x767ea491 in QApplicationPrivate::notify_helper 
(this=this@entry=0x55610610, receiver=receiver@entry=0x55a95530, 
e=e@entry=0x7fffd3b0) at kernel/qapplication.cpp:3727
#2  0x767f1ad0 in QApplication::notify (this=0x7fffe470, 
receiver=0x55a95530, e=0x7fffd3b0) at kernel/qapplication.cpp:3486
#3  0x75d95039 in QCoreApplication::notifyInternal2 
(receiver=0x55a95530, event=event@entry=0x7fffd3b0) at 
../../include/QtCore/5.11.2/QtCore/private/../../../../../src/corelib/thread/qthread_p.h:307
#4  0x75dc47b8 in QCoreApplication::sendEvent (event=0x7fffd3b0, 
receiver=) at 
../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:234
#5  QObjectPrivate::setParent_helper (this=0x5596ccb0, o=0x55a95530) at 
kernel/qobject.cpp:2040
#6  0x75dc5394 in QObject::QObject (this=0x55aad850, 
parent=0x55a95530) at kernel/qobject.cpp:812
#7  0x77adfb92 in KDeclarative::QmlObject::QmlObject 
(this=0x55aad850, engine=0x5568d3d0, rootContext=0x5596bf50, 
obj=0x55aad850, parent=) at 
./src/kdeclarative/qmlobject.cpp:170
#8  0x77ae20ff in 
KDeclarative::QmlObjectSharedEngine::QmlObjectSharedEngine 
(this=0x55aad850, parent=0x55a95530) at 
./src/kdeclarative/qmlobjectsharedengine.cpp:58
#9  0x77e39210 in 
KQuickAddons::QuickViewSharedEnginePrivate::QuickViewSharedEnginePrivate 
(module=0x55a95530, this=0x5596bf70) at 
./src/quickaddons/quickviewsharedengine.cpp:50
#10 KQuickAddons::QuickViewSharedEngine::QuickViewSharedEngine 
(this=0x55a95530, parent=) at 
./src/quickaddons/quickviewsharedengine.cpp:147
#11 0x77f8ea26 in PlasmaQuick::ContainmentView::ContainmentView 
(this=0x55a95530, corona=0x55661a00, parent=) at 
./src/plasmaquick/containmentview.cpp:197
#12 0x5557f0a3 in DesktopView::DesktopView (this=0x55a95530, 
corona=0x55661a00, targetScreen=0x5562ee90) at 
./shell/desktopview.cpp:40
#13 0x55595f4a in ShellCorona::addOutput 
(this=this@entry=0x55661a00, screen=, 
screen@entry=0x5562ee90) at ./shell/shellcorona.cpp:1199
#14 0x5559dae3 in ShellCorona::load (this=this@entry=0x55661a00) at 
./shell/shellcorona.cpp:697
#15 0x5559dfd9 in ShellCorona::load (this=0x55661a00) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qstring.h:937
#16 0x75dbe3e0 in QtPrivate::QSlotObjectBase::call (a=0x7fffd950, 
r=0x55661a00, this=0x5577c6b0) at 
../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:376
#17 QMetaObject::activate (sender=0x55664f50, signalOffset=, 
local_signal_index=, argv=) at 
kernel/qobject.cpp:3754
#18 0x77e6c1b1 in KActivities::Consumer::serviceStatusChanged 
(this=, _t1=) at 
./obj-x86_64-linux-gnu/src/lib/KF5Activities_autogen/EWIEGA46WW/moc_consumer.cpp:248
#19 0x77e6d62b in KActivities::Consumer::qt_static_metacall 
(_o=, _c=, _id=, _a=) at 
./obj-x86_64-linux-gnu/src/lib/KF5Activities_autogen/EWIEGA46WW/moc_consumer.cpp:114
#20 0x75dbe28b in QMetaObject::activate (sender=0x55678a60, 
signalOffset=, local_signal_index=, 
argv=) at kernel/qobject.cpp:3771
#21 0x77e6c071 in KActivities::ActivitiesCache::serviceStatusChanged 
(this=this@entry=0x55678a60, _t1=, 
_t1@entry=KActivities::Consumer::Running) at 
./obj-x86_64-linux-gnu/src/lib/KF5Activities_autogen/EWIEGA46WW/moc_activitiescache_p.cpp:407
#22 0x77e651bd in KActivities::ActivitiesCache::setAllActivities 
(this=this@entry=0x55678a60, _activities=...) at 
./src/lib/activitiescache_p.cpp:300
#23 0x77e653ee in 
KActivities::ActivitiesCache::passInfoFromReply, void 
(KActivities::ActivitiesCache::*)(QList const&)> (f=(void 
(KActivities::ActivitiesCache::*)(KActivities::ActivitiesCache * const, const 
QList &)) 0x77e65010 
 const&)>, 
watcher=0x556711e0, this=) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qlist.h:156
#24 KActivities::ActivitiesCache::setAllActivitiesFromReply (this=, 

Bug#915411: dovecot-core: doveadm crashes with segmentation fault ('batch -A : kick')

[Bernhard Übelacker]

Control: found -1 dovecot/1:2.3.4-2

Dear Maintainer,
I could reproduce this crash in a minimal stretch amd64 VM
with just dovecot-core installed and default configuration.

That command crashes also in a similar VM with current
buster/testing version.

Kind regards,
Bernhard


(gdb) bt
#0  0x in ?? ()
#1  0x55dfefbe3f1c in doveadm_mail_cmd_init (cmd=cmd@entry=0x7ffe8dfe1ab0, 
set=0x55dff0e09178) at doveadm-mail.c:540
#2  0x55dfefbe561b in cmd_batch_add (argv=, argc=, batchctx=0x55dff0e19250) at doveadm-mail-batch.c:78
#3  cmd_batch_preinit (_ctx=0x55dff0e19250) at doveadm-mail-batch.c:126
#4  0x55dfefbe3b15 in doveadm_mail_cmd_exec (ctx=ctx@entry=0x55dff0e19250, 
cctx=cctx@entry=0x7ffe8dfe1ba0, wildcard_user=wildcard_user@entry=0x0) at 
doveadm-mail.c:575
#5  0x55dfefbe44ea in doveadm_mail_cmd (argv=, argc=4, 
cmd=0x55dff0e17a10) at doveadm-mail.c:693
#6  doveadm_mail_try_run (cmd_name=, argc=, 
argv=) at doveadm-mail.c:766
#7  0x55dfefbd3d6a in main (argc=, argv=) at 
doveadm.c:381

(gdb) directory /home/benutzer/dovecot-core/orig/dovecot-2.2.27/src/doveadm
Source directories searched: 
/home/benutzer/dovecot-core/orig/dovecot-2.2.27/src/doveadm:$cdir:$cwd
(gdb) up
#1  0x55dfefbe3f1c in doveadm_mail_cmd_init (cmd=cmd@entry=0x7ffe8dfe1ab0, 
set=0x55dff0e09178) at doveadm-mail.c:540
540 ctx = cmd->alloc();
(gdb) print cmd
$1 = (const struct doveadm_mail_cmd *) 0x7ffe8dfe1ab0
(gdb) print *cmd
$2 = {alloc = 0x0, name = 0x55dfefc19130 "kick", usage_args = 0x55dfefc19af8 
"[-a ] [|]"}

# stretch amd64 qemu VM

apt update
apt dist-upgrade

apt install mc devscripts dpkg-dev systemd-coredump gdb dovecot-core dovecot-dbg


mkdir dovecot-core/orig -p
cddovecot-core/orig
apt source dovecot-core
cd ../..









root@debian:~# doveadm batch -A : kick
Speicherzugriffsfehler (Speicherabzug geschrieben)








root@debian:~# coredumpctl list 
TIMEPID   UID   GID SIG COREFILE EXE
Fri 2018-12-07 11:05:33 CET4030 0 0  11 present  /usr/bin/doveadm
root@debian:~# coredumpctl gdb 4030
   PID: 4030 (doveadm)
   UID: 0 (root)
   GID: 0 (root)
Signal: 11 (SEGV)
 Timestamp: Fri 2018-12-07 11:05:33 CET (41s ago)
  Command Line: doveadm batch -A : kick
Executable: /usr/bin/doveadm
 Control Group: /user.slice/user-1000.slice/session-1.scope
  Unit: session-1.scope
 Slice: user-1000.slice
   Session: 1
 Owner UID: 1000 (benutzer)
   Boot ID: b831f41ee9ac4b90ac996b4db60e7332
Machine ID: 9e5901179cfe4b73bc18669e6a6e0ab9
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.doveadm.0.b831f41ee9ac4b90ac996b4db60e7332.4030.1544177133.lz4
   Message: Process 4030 (doveadm) of user 0 dumped core.

Stack trace of thread 4030:
#0  0x n/a (n/a)

GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/doveadm...(no debugging symbols found)...done.
[New LWP 4030]
Core was generated by `doveadm batch -A : kick'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x in ?? ()
(gdb) set width 0
(gdb) set pagination off
(gdb) bt
#0  0x in ?? ()
#1  0x55dfefbe3f1c in doveadm_mail_cmd_init ()
#2  0x55dfefbe561b in ?? ()
#3  0x55dfefbe3b15 in ?? ()
#4  0x55dfefbe44ea in doveadm_mail_try_run ()
#5  0x55dfefbd3d6a in main ()








# With debug symbols

(gdb) set width 0
(gdb) set pagination off
(gdb) bt
#0  0x in ?? ()
#1  0x55dfefbe3f1c in doveadm_mail_cmd_init (cmd=cmd@entry=0x7ffe8dfe1ab0, 
set=0x55dff0e09178) at doveadm-mail.c:540
#2  0x55dfefbe561b in cmd_batch_add (argv=, argc=, batchctx=0x55dff0e19250) at doveadm-mail-batch.c:78
#3  cmd_batch_preinit (_ctx=0x55dff0e19250) at doveadm-mail-batch.c:126
#4  0x55dfefbe3b15 in doveadm_mail_cmd_exec (ctx=ctx@entry=0x55dff0e19250, 
cctx=cctx@entry=0x7ffe8dfe1ba0, wildcard_user=wildcard_user@entry=0x0) at 
doveadm-mail.c:575
#5  0x55dfefbe44ea in doveadm_mail_cmd (argv=, argc=4, 
cmd=0x55dff0e17a10) at doveadm-mail.c:693
#6  doveadm_mail_try_run (cmd_name=, argc=, 
argv=) at doveadm-mail.c:766
#7  0x55dfefbd3d6a in main (argc=, argv=) at 

Bug#915347: slic3r segfaulting under wayland

[Bernhard Übelacker]

Dear Maintainer,
this issue seems to be caused by wxGLCanvas not being yet ready
for wayland. At least in version current version in testing.

There are already bugs [1] and [2], the first one also for slic3r.
Both are forwarded to [3].
And all describing as workaround using something like
"GDK_BACKEND=x11 slic3r" to start affected applications.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900678
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904753
[3] https://trac.wxwidgets.org/ticket/17702

Kind regards,
Bernhard



Thread 1 "perl" received signal SIGSEGV, Segmentation fault.
0x7fff0001 in ?? ()
(gdb) bt
#0  0x7fff0001 in ?? ()
#1  0x7570600b in XQueryExtension (dpy=dpy@entry=0x5682e000, 
name=name@entry=0x7fffe2e26006 "GLX", 
major_opcode=major_opcode@entry=0x58c063d4, 
first_event=first_event@entry=0x7fffd184, 
first_error=first_error@entry=0x58c063d8) at ../../src/QuExt.c:43
#2  0x7fffe2e21862 in InitDisplayInfoEntry (dpy=0x5682e000) at 
../../../src/GLX/libglxmapping.c:641
#3  __glXLookupDisplay (dpy=, dpy@entry=0x5682e000) at 
../../../src/GLX/libglxmapping.c:733
#4  0x7fffe2e1d8e5 in glXQueryVersion (dpy=0x5682e000, 
major=0x7fffd230, minor=0x7fffd234) at ../../../src/GLX/libglx.c:1170
#5  0x7fffe2d51e55 in wxGLCanvasX11::GetGLXVersion () at 
../include/wx/utils.h:780
#6  0x7fffe2d52455 in wxGLCanvasX11::ConvertWXAttrsToGL 
(wxattrs=0x58c065c0, glattrs=0x7fffd3d0, n=512) at 
../src/unix/glx11.cpp:343
#7  0x7fffe2d52b68 in wxGLCanvasX11::InitXVisualInfo 
(attribList=attribList@entry=0x58c065c0, pFBC=pFBC@entry=0x5660ac20, 
pXVisual=pXVisual@entry=0x5660ac28) at ../src/unix/glx11.cpp:498
#8  0x7fffe2d52c59 in wxGLCanvasX11::InitVisual 
(this=this@entry=0x5660a970, attribList=attribList@entry=0x58c065c0) at 
../src/unix/glx11.cpp:226
#9  0x7fffe2d53b5f in wxGLCanvas::Create (this=this@entry=0x5660a970, 
parent=parent@entry=0x58ba1e80, id=id@entry=-1, pos=..., size=..., 
style=style@entry=0, name=..., attribList=0x58c065c0, palette=...) at 
../src/gtk/glcanvas.cpp:233
#10 0x7fffe2d53d03 in wxGLCanvas::wxGLCanvas (this=0x5660a970, 
parent=0x58ba1e80, id=-1, attribList=0x58c065c0, pos=..., size=..., 
style=0, name=..., palette=...) at ../src/gtk/glcanvas.cpp:157
#11 0x7002d5d9 in XS_Wx__GLCanvas_newDefault (my_perl=0x55867260, 
cv=) at GLCanvas.xs:132
#12 0x5563fd11 in Perl_pp_entersub ()
#13 0x55636026 in Perl_runops_standard ()
#14 0x555a9cf5 in Perl_call_sv ()
#15 0x7002c8ba in XS_Wx__GLCanvas_new (my_perl=0x55867260, 
cv=) at GLCanvas.xs:113
#16 0x5563fd11 in Perl_pp_entersub ()
#17 0x55636026 in Perl_runops_standard ()
#18 0x555a9f02 in Perl_call_sv ()
#19 0x76f0b188 in call_oninit (sub=0x566a4208, This=0x56c3ac60, 
my_perl=0x55867260) at Wx.c:134
#20 XS_Wx___App_Start (my_perl=0x55867260, cv=) at Wx.c:14746
#21 0x5563fd11 in Perl_pp_entersub ()
#22 0x55636026 in Perl_runops_standard ()
#23 0x555b2097 in perl_run ()
#24 0x55588402 in main ()

(gdb) up
#1  0x7570600b in XQueryExtension (dpy=dpy@entry=0x5682e000, 
name=name@entry=0x7fffe2e26006 "GLX", 
major_opcode=major_opcode@entry=0x58c063d4, 
first_event=first_event@entry=0x7fffd184, 
first_error=first_error@entry=0x58c063d8) at ../../src/QuExt.c:43
43  LockDisplay(dpy);
(gdb) print dpy
$1 = (Display *) 0x5682e000
(gdb) print dpy->lock_fns 
$2 = (struct _XLockPtrs *) 0x5682e980
(gdb) print dpy->lock_fns->lock_display 
$3 = (void (*)(Display *)) 0x7fff0001

Bug#915364: qbittorrent again crashes when starting talks of symbol lookup error

[Bernhard Übelacker]

Dear Maintainer,
sorry, tried to mark it as fixed in the rebuild 1.1.9-1+b1.
But cont...@bugs.debian.org processed just version 1.1.9-1.

Kind regards,
Bernhard

Bug#915364: Bug #915364: qbittorrent again crashes when starting talks of symbol lookup error

[Bernhard Übelacker]

Hello Martin Haase,

> ii  libtorrent-rasterbar9  1.1.9-1

You probably have also to update your libtorrent-rasterbar9
package to version 1.1.9-1+b1.


libtorrent-rasterbar (1.1.9-1+b1) sid; urgency=low, binary-only=yes

  * Binary-only non-maintainer upload for amd64; no source changes.
  * Rebuild against boost1.67.

 -- amd64 / i386 Build Daemon (x86-ubc-01) 
  Sat, 17 Nov 2018 00:04:35 +


Kind regards,
Bernhard

Bug#915299: Bug #915299: xfburn: Segfault when adding files to project

[Bernhard Übelacker]

Hello Wojciech Muła,
I am just trying to reproduce the crash inside a minimal
buster amd64 qemu VM.

Unfortunately I was not able to reproduce and found most of
the listed versions are already outdated in testing.

Is there a reason, why your debian unstable installation
is not receiving updates?

Another point would be, you copied just the first frame of
gdb's bt output, but there should have been more lines following?

And such a backtrace would be even better if the matching dbgsym
packages are installed like described in [1]. In your example that
would be at least xfburn-dbgsym libglib2.0-0-dbgsym.
(But I guess if you currently do not install updates on purpose
that would pull in new versions of the libraries.)

Kind regards,
Bernhard


[1] https://wiki.debian.org/HowToGetABacktrace


# dpkg -S /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
libglib2.0-0:amd64: /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0

Bug#914565: Bug #914565: php7.3-intl: Segfaults after apache2 graceful restart

[Bernhard Übelacker]

Hello Dino,
I tried to have another look at this issue.


> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing')

I found your report claims you are running testing, but
php7.3-intl 7.3.0~rc5-2 is currently just in unstable.

Are there more packages installed from unstable?


This "every nights graceful restart", is this something
you issue e.g. by a cron job?

Does the crash always happen just after 24 hours of running?
Or can you reproduce by stopping/restarting at any time?


Have you an coredump collector like systemd-coredump installed?
That would make a later inspection possible by:
coredumpctl list
coredumpctl gdb 
But as the segfaults happen then in a fast flow that might put
an unexpected load to the system.


If you want to reproduce again, you might show when you reached
the segfault some of the surrounding disassembly by
disassemble $pc-0x40,$pc+40

And also what is contained in libc's fork handler:
print *__fork_handlers
print *__fork_handlers->next

Maybe also a "pstree -p | grep apache" when you have the debugger attached.


Kind regards,
Bernhard

Bug#906609: fixed in gnucash 1:3.3-1

[Bernhard Übelacker]

On Fri, 23 Nov 2018 00:26:28 +0100 =?UTF-8?Q?Bernhard_=c3=9cbelacker?= 
 wrote:
> but I cannot make a clue out of the
> armel "Not-For-Us" [1] for the build dependeny guile-2.2.
> What does that mean?
Hello Dimitry, hello Chris,
I just stepped over the answer to "Not-For-Us"
in [1] and [2] for the armel side.
[3] got opened in the meantime for armel side of gnucash too.

Kind regards,
Bernhard

[1] https://lists.debian.org/debian-arm/2018/09/msg00059.html
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883778
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914674

Bug#914565: Bug #914565: php7.3-intl: Segfaults after apache2 graceful restart

[Bernhard Übelacker]

Hello Dino,
if possible you might want to install the package php7.3-intl-dbgsym
matching to your php7.3-intl. That is in a separate repository [1].

Then that last frame should show up in the debugger with a
function name and line of source code.

Kind regards,
Bernhard

[1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols

Bug#807179: Bug #807179: area of memory

[Bernhard Übelacker]

notfound 807179 2.10.09-1
found 807179 2.11.05-1
found 807179 2.11.06-1really2.11.05-1
found 807179 2.11.06-1
fixed 807179 2.11.08-1
tags 807179 + upstream fixed
forwarded 807179 https://bugzilla.nasm.us/show_bug.cgi?id=3392289
bye


Dear Maintainer,
tried to some more details out of that report.

I could reproduce it in a stretch/testing amd64 VM
of date 2015-12-07.

I found it not to crash with 2.10.09-1.

It got fixed upstream in folowing commit:


9b05974022da69c12b8b190c6ad100402771e5ad is the first bad commit
commit 9b05974022da69c12b8b190c6ad100402771e5ad
Author: Cyrill Gorcunov 
Date:   Sun Dec 14 22:44:54 2014 +0300

ndisasm: Prevent nil dereference on registerd decoding

The sequence | 0x0F 0x1B 0x75 | get matched into
one of BNDx instruction which register value 6
which is of course out of possible BND registers
implemented in hardware at the moment leading to
nil dereference.

Instead lets use a macro in whichreg() helper
which would test the registers bounds and force
the caller to try another template if register is
out of range. In the case above it simply means
ndisasm instead of crashing outputs

 |   0Fdb 0x0f
 | 0001  1Bdb 0x1b
 | 0002  75db 0x75

http://bugzilla.nasm.us/show_bug.cgi?id=3392289

Reported-by: Hanno Boeck 
Signed-off-by: Cyrill Gorcunov 

:100644 100644 8ee0b1c3c3c72801def4598aca0af5ac7f1de095 
161868d08d8493fd2d03ffd8483006629484b0cc M  disasm.c


Kind regards,
Bernhard


Stretch amd64 VM:

apt update
apt install devscripts dpkg-dev systemd-coredump gdb nasm nasm-dbgsym git 
autogen autoconf

ndisasm /usr/lib/gcc/x86_64-linux-gnu/6/cc1plus
-> no crash

dpkg -l | grep nasm
nasm 2.12.01-1+b1


###


Stretch testing as of date 20151207:


debian-9-stretch-snapshot.debian.org
https://snapshot.debian.org/archive/debian/20151207T00Z/
deb [check-valid-until=no] 
http://192.168.178.25:/debian-10-buster-snapshot.debian.org/ stretch main


apt-get -o Acquire::Check-Valid-Until=false -o 
Acquire::CompressionTypes::Order::=gz -o Acquire::Languages=none update
apt dist-upgrade



apt install devscripts dpkg-dev systemd-coredump gdb nasm gcc-4.9 ghostscript   


mkdir nasm/orig -p
cdnasm/orig
apt source nasm
cd ../..


benutzer@debian:~$ ls -lisah /usr/bin/gcc
276245 0 lrwxrwxrwx 1 root root 5 Aug  3  2015 /usr/bin/gcc -> gcc-5
root@debian:~# ln -sf /usr/bin/gcc-4.9 /usr/bin/gcc



cd nasm
cp orig try1-gcc-4.9 -a
cd try1-gcc-4.9/nasm-2.11.06-1really2.11.05/
dpkg-buildpackage -b



benutzer@debian:~$ ndisasm /usr/lib/gcc/x86_64-linux-gnu/5/cc1plus
...
00015F04  B5FF  mov ch,0xff
Speicherzugriffsfehler (Speicherabzug geschrieben)


[  137.226089] ndisasm[10069]: segfault at 24c4838 ip 00402b24 sp 
7ffeb8b20b70 error 4 in ndisasm[40+97000]


root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG PRESENT EXE
Mo 2018-11-26 06:19:29 CET10069  1000  1000  11 * /usr/bin/ndisasm
root@debian:~# coredumpctl gdb 10069
   PID: 10069 (ndisasm)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 11 (SEGV)
 Timestamp: Mo 2018-11-26 06:19:29 CET (43s ago)
  Command Line: ndisasm /usr/lib/gcc/x86_64-linux-gnu/5/cc1plus
Executable: /usr/bin/ndisasm
 Control Group: /system.slice/ssh.service
  Unit: ssh.service
 Slice: system.slice
   Boot ID: 718ef12558e14b51b01f270ea473fd35
Machine ID: 0cc81cdce83142f0b9c65e10b756c1dc
  Hostname: debian
  Coredump: 
/var/lib/systemd/coredump/core.ndisasm.1000.718ef12558e14b51b01f270ea473fd35.10069.154320956900.xz
   Message: Process 10069 (ndisasm) of user 1000 dumped core.

Stack trace of thread 10069:
#0  0x00402b24 n/a (ndisasm)
#1  0x00400f98 n/a (ndisasm)
#2  0x7f59feec8b45 __libc_start_main (libc.so.6)
#3  0x00401901 n/a (ndisasm)

GNU gdb (Debian 7.10-1) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/ndisasm...(no debugging symbols found)...done.
[New LWP 10069]
Core was generated by `ndisasm /usr/lib/gcc/x86_64-linux-gnu/5/cc1plus'.
Program 

Bug#840580: apache2-bin: crashes when issuing a restart while mod_cgid is enabled

[Bernhard Übelacker]

Dear Maintainer,
tried to find out the actual location that the backtrace points to.

Unfortunately I could not make any clue out of the line
containing /usr/sbin/apache2(+0x29e450).

But at least, I think, the line containing mod_mpm_prefork.so(+0x4c08)
translates to function prefork_run in server/mpm/prefork/prefork.c.

As this is a rather big function, and looks like it is never left while
the server runs, and there are no local arrays accessed, the stack
canary may be overwritten by some function called from there.
But the stack canary is just checked when prefork_run exits.

Kind regards,
Bernhard



*** stack smashing detected ***: /usr/sbin/apache2 terminated
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x731af)[0x7f6d8e1c11af]| 
0x7f6d8e1c11af | 
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f6d8e246aa7] | 
0x7f6d8e246aa7 | 
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x0)[0x7f6d8e246a70]  | 
0x7f6d8e246a70 | 
/usr/lib/apache2/modules/mod_mpm_prefork.so(+0x4c08)[0x7f6d8b462c08] | 
0x7f6d8b462c08 | 0x7f6193a75c08: 0x7f6193a75c03 : 
  callq  0x7f6193a73400 <__stack_chk_fail@plt>
/usr/sbin/apache2(+0x29e450)[0x7f6d8f2a3450] | 
0x7f6d8f2a3450 | 
=== Memory map: 
7f6d8f005000-7f6d8f09d000 r-xp  fe:00 3882   
/usr/sbin/apache2
7f6d8b45e000-7f6d8b465000 r-xp  fe:00 127839 
/usr/lib/apache2/modules/mod_mpm_prefork.so










apt install dpkg-dev devscripts mc gdb binutils apache2-bin apache2-dbg



# http://snapshot.debian.org/package/apache2/2.4.10-10%2Bdeb8u7/

wget 
http://snapshot.debian.org/archive/debian/20160916T101556Z/pool/main/a/apache2/apache2-bin_2.4.10-10%2Bdeb8u7_amd64.deb
wget 
http://snapshot.debian.org/archive/debian/20160916T101556Z/pool/main/a/apache2/apache2-dbg_2.4.10-10%2Bdeb8u7_amd64.deb

dpkg -i --force-depends apache2-bin_2.4.10-10+deb8u7_amd64.deb 
apache2-dbg_2.4.10-10+deb8u7_amd64.deb


mkdir apache2/orig -p
cdapache2/orig
dget 
http://snapshot.debian.org/archive/debian/20160916T101556Z/pool/main/a/apache2/apache2_2.4.10-10%2Bdeb8u7.dsc
dpkg-source -x apache2_2.4.10-10%2Bdeb8u7.dsc
cd ../..



a2dismod mpm_event
a2enmod mpm_prefork
systemctl stop apache2
systemctl start apache2




root@debian:~# gdb -q --pid 16415
...
(gdb) set width 0
(gdb) set pagination off
(gdb) directory /home/benutzer/apache2/orig/apache2-2.4.10/server
Source directories searched: 
/home/benutzer/apache2/orig/apache2-2.4.10/server:$cdir:$cwd
(gdb) b main
Breakpoint 1 at 0x556c539ec940: file main.c, line 439.
(gdb) disassemble prefork_run,prefork_run+3830
Dump of assembler code from 0x7f6193a74d60 to 0x7f6193a75c56:
   0x7f6193a74d60 :  push   %r15
...
   0x7f6193a74d81 : mov%fs:0x28,%rax
 ; Value loaded into $rax
   0x7f6193a74d8a : mov%rax,0xe8(%rsp)  
 ; Value stored in canary
...
   0x7f6193a75288 :   mov0xe8(%rsp),%rbx  
 ; Canary loaded into $rbx
   0x7f6193a75290 :   xor%fs:0x28,%rbx
 ; Canary compared to the original value
   0x7f6193a75299 :   mov%r13d,%eax
   0x7f6193a7529c :   jne0x7f6193a75c03 

...
   0x7f6193a75c03 :   callq  0x7f6193a73400 
<__stack_chk_fail@plt>
   0x7f6193a75c08 :   callq  0x7f6193a73300 
<__errno_location@plt>
...
   0x7f6193a75c4b :   jmpq   0x7f6193a75b9c 

   0x7f6193a75c50 : push   %rbp
End of assembler dump.






set width 0
set pagination off
directory /home/benutzer/apache2/orig/apache2-2.4.10/server
b main
run

Bug#910731: kaddressbook: crashes at startup

[Bernhard Übelacker]

Hello Francesco,
can you still observe the crash, or got it fixed by updates
in mid October? (Like mentioned in #910581)

If it is fixed that bug might be closed.

Kind regards,
Bernhard

Bug#470706: xfsprogs: xfs_repair crashes during attempted repair

[Bernhard Übelacker]

Dear Maintainer,
I tried to find out where this given backtrace points to.

I think that following would be the location
where the invalid pointer was tried to be freed.

Attached file contains some details on how it was retrieved.

Upstream removed/replaced function teardown_ag_bmap in [1],
therefore this bug might be just closed.

Kind regards,
Bernhard



Phase 5 - rebuild AG headers and trees...
*** glibc detected *** xfs_repair: munmap_chunk(): invalid pointer: 0xb092c008 
***
=== Backtrace: =
/lib/i686/cmov/libc.so.6(cfree+0x1bb)[0xb7de24ab]| 0xb7de24ab | 
xfs_repair[0x8061f2d]| 0x08061f2d | 
:   call   
xfs_repair[0x806b311]| 0x0806b311 | 
: call   
xfs_repair[0x807cb28]| 0x0807cb28 | 
:  call   
/lib/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0xb7d89450] | 0xb7d89450 | 
<__libc_start_main+226>: call   *0x8(%ebp)
xfs_repair[0x8049541]| 0x08049541 | 
<_start+28>: call   <__libc_start_main@plt>
=== Memory map: 



[1] 
https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/commit/repair?id=c1f7a46c4d6403e3313c13487e2f2174f92db670



Phase 5 - rebuild AG headers and trees...
*** glibc detected *** xfs_repair: munmap_chunk(): invalid pointer:
0xb092c008 ***
=== Backtrace: =
/lib/i686/cmov/libc.so.6(cfree+0x1bb)[0xb7de24ab]| 0xb7de24ab | 
xfs_repair[0x8061f2d]| 0x08061f2d | 
:   call   0x80492c4 
xfs_repair[0x806b311]| 0x0806b311 | 
: call   0x8061d60 
xfs_repair[0x807cb28]| 0x0807cb28 | 
:  call   0x806ae60 
/lib/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0xb7d89450] | 0xb7d89450 | 
<__libc_start_main+226>: call   *0x8(%ebp)
xfs_repair[0x8049541]| 0x08049541 | 
<_start+28>: call   0x8049254 <__libc_start_main@plt>
=== Memory map: 
08048000-080ce000 r-xp  03:01 195863 /sbin/xfs_repair
080ce000-080cf000 rw-p 00085000 03:01 195863 /sbin/xfs_repair
080cf000-0aadc000 rw-p 080cf000 00:00 0  [heap]




##



deb [check-valid-until=no] 
http://snapshot.debian.org/archive/debian/20091004T111800Z/ lenny main
deb-src [check-valid-until=no] 
http://snapshot.debian.org/archive/debian/20091004T111800Z/ lenny main

apt-get update
apt-get install debian-archive-keyring gdb xfsprogs devscripts dpkg-dev 
build-essential uuid-dev autoconf debhelper gettext libtool libreadline5-dev 
gcc-4.1


wget 
http://snapshot.debian.org/archive/debian/20060822T00Z/pool/main/x/xfsprogs/xfsprogs_2.8.11-1_i386.deb
dpkg -i xfsprogs_2.8.11-1_i386.deb


https://buildd.debian.org/status/fetch.php?pkg=xfsprogs=amd64=2.8.11-1=1156139624=0
# Unfortunately no log for i386
# -> was built with gcc-4.1


ln -sf gcc-4.1 /usr/bin/gcc



mkdir xfsprogs/orig -p
cdxfsprogs/orig
dget 
http://snapshot.debian.org/archive/debian/20060822T00Z/pool/main/x/xfsprogs/xfsprogs_2.8.11-1.dsc
dpkg-source -x xfsprogs_2.8.11-1.dsc
cd ../..



cd xfsprogs
cp orig try1 -a
cd try1/xfsprogs-2.8.11/
dpkg-buildpackage -b





benutzer@debian:~$ objdump -D /sbin/xfs_repair > objdump.txt




debian:~/xfsprogs/try1/xfsprogs-2.8.11# file /sbin/xfs_repair 
/root/xfsprogs/try1/xfsprogs-2.8.11/repair/xfs_repair
/sbin/xfs_repair:  ELF 32-bit LSB 
executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.4.1, dynamically 
linked (uses shared libs), for GNU/Linux 2.4.1, stripped
/root/xfsprogs/try1/xfsprogs-2.8.11/repair/xfs_repair: ELF 32-bit LSB 
executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically 
linked (uses shared libs), for GNU/Linux 2.6.8, not stripped




debian:~/xfsprogs/try1/xfsprogs-2.8.11# gdb -q --args 
/root/xfsprogs/try1/xfsprogs-2.8.11/repair/xfs_repair
(gdb) set width 0
(gdb) set pagination off
(gdb) disassemble main




debian:~# gdb -q --args /sbin/xfs_repair 
(no debugging symbols found)
(gdb) set width 0
(gdb) set pagination off
(gdb) b __libc_start_main
















   --- original binary ---  
|  --- rebuild with debug info ---

| 
(gdb) info target   
| (gdb) info target
Symbols from "/sbin/xfs_repair".
| Symbols from "/root/xfsprogs/try1/xfsprogs-2.8.11/repair/xfs_repair".
Local exec file:
| Local exec file:
`/sbin/xfs_repair', file type elf32-i386.   
| `/root/xfsprogs/try1/xfsprogs-2.8.11/repair/xfs_repair', file type 
elf32-i386.

Bug#858045: Bug #858045: xcircuit: The File List Window can crash XCircuit

[Bernhard Übelacker]

Dear Maintainer, hello Gonçalo,
I tried to have a look at this issue, and could
reproduce it in a jessie and buster amd64 qemu VM.

As far as I see xcircuit tries to draw all files into one big pixmap.

(gdb) list filelist.c:480
477   pixheight = flfiles * FILECHARHEIGHT + 25;
478   if (pixheight < textheight) pixheight = textheight;
479
480   flistpix = XCreatePixmap(dpy, areawin->window, textwidth, 
pixheight,
481DefaultDepthOfScreen(xcScreen(w)));
(gdb) print pixheight 
$1 = 42039
(gdb) print textheight
$2 = 98
(gdb) print flfiles
$3 = 3001

Unfortunately, depending on the font size, we get then a height
of e.g. 42039, that is not allowed in the xserver:

(gdb) list ProcCreatePixmap
1392int
1393ProcCreatePixmap(ClientPtr client)
...
1415if (stuff->width > 32767 || stuff->height > 32767) {
1416/* It is allowed to try and allocate a pixmap which is 
larger than
1417 * 32767 in either dimension. However, all of the 
framebuffer code
1418 * is buggy and does not reliably draw to such big pixmaps, 
basically
1419 * because the Region data structure operates with signed 
shorts
1420 * for the rectangles in it.
1421 *
1422 * Furthermore, several places in the X server computes the
1423 * size in bytes of the pixmap and tries to store it in an
1424 * integer. This integer can overflow and cause the 
allocated size
1425 * to be much smaller.
1426 *
1427 * So, such big pixmaps are rejected here with a BadAlloc
1428 */
1429return BadAlloc;
1430}


So a check like in filelist.c:478 could be added
to limit pixheight to 32767, or give a error message like
in the "(Invalid Directory)" case.

Kind regards,
Bernhard


Client:
(gdb) bt
#0  XCreatePixmap (dpy=0x561a0f1f4f60, d=8389047, width=339, height=42039, 
depth=24) at ../../src/CrPixmap.c:50
#1  0x7f67bfa7d020 in listfiles (w=0x561a0f846e00, 
okaystruct=0x561a0fa27f60, calldata=0x0) at filelist.c:480
#2  0x7f67bfa7d51a in newfilelist (w=0x561a0f846e00, 
okaystruct=0x561a0fa27f60) at filelist.c:547
#3  0x7f67bfafaec2 in xctk_fileselect (clientData=0x561a0fa27f60, 
eventPtr=0x70ef86f0) at tclxcircuit.c:9567
#4  0x7f67c19c7ff5 in Tk_HandleEvent 
(eventPtr=eventPtr@entry=0x70ef86f0) at ./unix/../generic/tkEvent.c:1352
#5  0x7f67c19bb3b0 in HandleEventGenerate 
(interp=interp@entry=0x561a0f46b6f0, mainWin=mainWin@entry=0x561a0f624180, 
objc=objc@entry=4, objv=objv@entry=0x561a0f486840) at 
./unix/../generic/tkBind.c:3458
#6  0x7f67c19baaf1 in Tk_EventObjCmd (clientData=0x561a0f624180, 
interp=0x561a0f46b6f0, objc=6, objv=0x561a0f486830) at 
./unix/../generic/tkBind.c:2413
#7  0x7f67c1608a96 in TclNRRunCallbacks 
(interp=interp@entry=0x561a0f46b6f0, result=0, rootPtr=0x0) at 
./generic/tclBasic.c:4435
#8  0x7f67c1607ecf in Tcl_EvalObjv (interp=interp@entry=0x561a0f46b6f0, 
objc=objc@entry=6, objv=objv@entry=0x561a0f486830, flags=flags@entry=2097168) 
at ./generic/tclBasic.c:4165
#9  0x7f67c160964a in TclEvalEx (interp=0x561a0f46b6f0, 
script=0x70ef8af0 "event generate .filelist.listwin.win  
-button 2 ;  event generate .filelist.listwin.win  -button 2", 
numBytes=, flags=, line=line@entry=1, 
clNextOuter=clNextOuter@entry=0x0, outerScript=0x70ef8af0 "event generate 
.filelist.listwin.win  -button 2 ;  event generate 
.filelist.listwin.win  -button 2") at ./generic/tclBasic.c:5304
#10 0x7f67c16090f3 in Tcl_EvalEx (interp=, 
script=, numBytes=, flags=) at 
./generic/tclBasic.c:4969
#11 0x7f67c19b9705 in Tk_BindEvent (bindPtr=, 
eventPtr=eventPtr@entry=0x561a0f9f3aa0, tkwin=tkwin@entry=0x561a0f84c020, 
numObjects=, numObjects@entry=4, objectPtr=, 
objectPtr@entry=0x70ef8d20) at ./unix/../generic/tkBind.c:1505
#12 0x7f67c19bff4d in TkBindEventProc 
(winPtr=winPtr@entry=0x561a0f84c020, eventPtr=eventPtr@entry=0x561a0f9f3aa0) at 
./unix/../generic/tkCmds.c:319
#13 0x7f67c19c8173 in Tk_HandleEvent 
(eventPtr=eventPtr@entry=0x561a0f9f3aa0) at ./unix/../generic/tkEvent.c:1374
#14 0x7f67c19c8920 in WindowEventProc 
(evPtr=evPtr@entry=0x561a0f9f3a90, flags=flags@entry=-3) at 
./unix/../generic/tkEvent.c:1764
#15 0x7f67c16d0e17 in Tcl_ServiceEvent (flags=flags@entry=-3) at 
./generic/tclNotify.c:670
#16 0x7f67c16d1066 in Tcl_DoOneEvent (flags=-3) at 
./generic/tclNotify.c:903
#17 0x7f67c19c8d72 in Tk_MainLoop () at ./unix/../generic/tkEvent.c:2148
#18 0x7f67c19d741a in Tk_MainEx (argc=, argv=, appInitProc=0x561a0d485b30, interp=0x561a0f195f00) at 
./unix/../generic/tkMain.c:390
#19 0x561a0d485a0c in ?? ()
#20 0x7f67c07e7b17 in __libc_start_main 

Bug#827672: Bug #827672: WDM crashes after user logged in if selinux is enabled (and in permissive mode)

[Bernhard Übelacker]

Dear Maintainer, hello Klaus Ethgen,
I just tried to get some more information out of this bug.

I could not reproduce it with a stretch testing or unstable
as of date 2016-07-20 inside a i386 qemu VM.

As far as I see is the problematic function in WDM:

(gdb) list ManageSession# wdm-1.28/src/wdm/session.c
...
522 static Bool
523 StartClient (
524 struct verify_info  *verify,
525 struct display  *d,
526 int *pidp,
527 char*name,
528 char*passwd)
529 {
...
627 #ifdef WITH_SELINUX
628 if (is_selinux_enabled())
629 {
630 security_context_t scontext;
631 if (get_default_context(name,NULL,))
632 WDMError("Failed to get default security 
context"
633 " for %s.", name);
634 WDMDebug("setting security context to %s", 
scontext);
635 if (setexeccon(scontext))
636 {
637 freecon(scontext);
638 WDMError("Failed to set exec security 
context %s "
639 "for %s.", scontext, name);
640 }
641 freecon(scontext);
642 }
643 #endif


There it looks like function get_default_context failed - the message
"Failed to get default security context" appears in the log.

Therefore variable scontext may have stayed uninitilized,
which led to the observed crash in line 637, when trying to free
that uninitilized pointer.

(gdb) list freecon  # libselinux-2.5/src/freecon.c
5
6   void freecon(char * con)
7   {
8   free(con);
9   }


I think this crash may happen with current testing version of wdm too,
when get_default_context fails.
But why in the first place the get_default_context may have failed I cannot say.

Does this problem still occour?
Or is it known if there was a selinux misconfiguration on this machine at that 
time?
Was there any other selinux configuration done?

Attached file shows some notes about the debugging attempts.

Kind regards,
Bernhard


   wdm: *** Error in `-:0 ': free(): invalid pointer: 0x80101d24 ***
   wdm: === Backtrace: =
   wdm: /lib/i386-linux-gnu/libc.so.6(+0x6929b)[0xb738a29b]   | 
0x...29b | 
   wdm: /lib/i386-linux-gnu/libc.so.6(+0x6f527)[0xb7390527]   | 
0x...527 | 
   wdm: /lib/i386-linux-gnu/libc.so.6(+0x6fcd1)[0xb7390cd1]   | 
0x...cd1 | 
   wdm: /lib/i386-linux-gnu/libselinux.so.1(freecon+0x18)[0xb750a698] | 
0x...698 | 0xb7df7698: 0xb7df7693 :call   0xb7df25b0 

   wdm: -:0 (+0xd104)[0x800f4104] | 
0x...104 | 0x8000d104: 0x8000d0ff : call   0x80002d80   
 ; 637 freecon(scontext);
   wdm: -:0 (+0x8450)[0x800ef450] | 
0x...450 | 0x80008450: 0x8000844b :   call   0x8000c9b0 

   wdm: -:0 (+0x8828)[0x800ef828] | 
0x...828 | 0x80008828: 0x80008826 :  call   *%esi
   wdm: -:0 (+0x8077)[0x800ef077] | 
0x...077 | 0x80008077: 0x80008072 :  call   0x80008800 

   wdm: -:0 (+0xe24e)[0x800f524e] | 
0x...24e | 0x8000e24e: 0x8000e249 :call   0x80007b60 

   wdm: -:0 (main+0x1a5)[0x800e9ff5]  | 
0x...ff5 | 0x80002ff5: 0x80002ff0 :   call   0x8000e200 

   wdm: /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf7)[0xb7339517] | 
0x...517 | 
   wdm: -:0 (+0x3327)[0x800ea327] | 
0x...327 | 

# starting with current Stretch i386

apt install devscripts dpkg-dev xserver-xorg wdm gdb





wget 
http://snapshot.debian.org/archive/debian/20160507T220956Z/pool/main/w/wdm/wdm_1.28-19_i386.deb
wget 
http://snapshot.debian.org/archive/debian-debug/20160507T215014Z/pool/main/w/wdm/wdm-dbgsym_1.28-19_i386.deb
wget 
http://snapshot.debian.org/archive/debian/20160517T222057Z/pool/main/libs/libselinux/libselinux1_2.5-3_i386.deb
wget 
http://snapshot.debian.org/archive/debian-debug/20160517T215638Z/pool/main/libs/libselinux/libselinux1-dbgsym_2.5-3_i386.deb
dpkg -i *.deb


mkdir wdm/orig -p
cdwdm/orig
dget 
http://snapshot.debian.org/archive/debian-debug/20160507T215014Z/pool/main/w/wdm/wdm_1.28-19.dsc
cd ../..


mkdir libselinux/orig -p
cdlibselinux/orig
dget 
http://snapshot.debian.org/archive/debian-debug/20160517T215638Z/pool/main/libs/libselinux/libselinux_2.5-3.dsc
cd ../..





benutzer@debian:~$ gdb -q --args /usr/bin/wdm
Reading symbols from 

Bug#906115: Bug #906115: gnucash: Crash when press key on new entry in accout

[Bernhard Übelacker]

Hello Michael Ott,
I just tried to reproduce this crash.


You were really using the gtk+3.0 packages from experimental at that time?


> Aug 14 13:49:22 king-coder13 kernel: [16027.866859] gnucash[22985]:
> segfault at f0 ip 7f76d6ba7952 sp 7ffcb1fd9198
> error 4 in libgdk-3.so.0.2301.0[7f76d6b88000+81000]

>From the limited information of the kernel log line I just can
guess the error was a null pointer dereference
in _gdk_window_has_impl.


(gdb) disassemble _gdk_window_has_impl
Dump of assembler code for function _gdk_window_has_impl:
   0x7fcb833b2950 <+0>: xor%eax,%eax
   0x7fcb833b2952 <+2>: cmp%rdi,0xf0(%rdi)
   0x7fcb833b2959 <+9>: sete   %al
   0x7fcb833b295c <+12>:retq   
End of assembler dump.

(gdb) list 660,665
660
661 static gboolean
662 gdk_window_has_impl (GdkWindow *window)
663 {
664   return window->impl_window == window;
665 }

(gdb) list _gdk_window_has_impl
674
675 gboolean
676 _gdk_window_has_impl (GdkWindow *window)
677 {
678   return gdk_window_has_impl (window);
679 }


Is this issue still visible?


If yes it would be a great help if a complete backtrace could be added.

A good information would be just to run it that way:
gdb -q -ex run -ex bt -ex detach -ex quit --args gnucash

Another way would be to install a core dump collector like systemd-coredump
and execute something like this:
coredumpctl list
coredumpctl gdb 

Even better when debug symbols are installed like described in [1].


Kind regards,
Bernhard

[1] https://wiki.debian.org/HowToGetABacktrace

Bug#911084: Bug #911084: sagemath crashes as cantor backend

[Bernhard Übelacker]

Dear Maintainer, hello Kinky Nekoboi,
just tried to reproduce this issue and there is really a crash.

In a minimal buster amd64 qemu VM,
with installed cantor and cantor-backend-sage packages.

Then follow these steps:
- start cantor
- select Sage backend
- enter in the field below the "Session 1" tab marked with ">>>":
plot(cos, (-5,5))
- press "Evaluate Worksheet"




The actual crash happens in cantor_sagebackend.so.
There the version of sagemath is tried to be retrieved by
executing "/usr/bin/sage -v".

Unfortunately this outputs just an error message, therefore
is nothing read from stdinput. In the console the output
"found version:  ()" from line 472 is visible.
This empty line is processed then by a regular expression
and that is expected to return results on index 1 and 2.


benutzer@debian:~$ /usr/bin/sage -v
/usr/bin/sage: line 16: /src/bin/sage-version.sh: No such file or directory


(gdb) list sagesession.cpp:462,500
462 bool SageSession::updateSageVersion()
463 {
464 QProcess get_sage_version;
465 
get_sage_version.setProgram(SageSettings::self()->path().toLocalFile());
466 
get_sage_version.setArguments(QStringList()<&2
else
. "$0-env" >&2
fi
...



Attached patch moves the sourcing of sage-env above the call to sage_version.
With that applied cantor successfully can draw and show that plot command.
But I really cannot estimate what else that could break elsewhere.



I think both issues deserve to be tracked separately:
- cantor_sagebackend.so should be more robust against the output of 
/usr/bin/sage
- /usr/bin/sage should report its version


Kind regards,
Bernhard


(gdb) bt
#0  0x7f97c94617ac in QString::toIntegral_helper (base=10, ok=0x0, 
len=, data=) at 
../../include/QtCore/../../src/corelib/tools/qstring.h:895
#1  QString::toInt (this=, ok=ok@entry=0x0, base=base@entry=10) 
at tools/qstring.cpp:7078
#2  0x7f97c005007d in SageSession::updateSageVersion() () at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qlist.h:115
#3  0x7f97c00503f1 in SageSession::login() () at 
./src/backends/sage/sagesession.cpp:119
#4  0x7f97b0042621 in Worksheet::loginToSession 
(this=this@entry=0x55b0052087f0) at ./src/worksheet.cpp:93
#5  0x7f97b0042c10 in Worksheet::evaluate() () at ./src/worksheet.cpp:457
#6  0x7f97b00387d2 in CantorPart::evaluateOrInterrupt() () at 
./src/cantor_part.cpp:529
#7  0x7f97b00767ed in CantorPart::qt_static_metacall (_o=, 
_id=, _a=, _c=) at 
./obj-x86_64-linux-gnu/src/cantorpart_autogen/EWIEGA46WW/moc_cantor_part.cpp:207
#8  0x7f97c95bb28b in QMetaObject::activate(QObject*, int, int, void**) () 
at kernel/qobject.cpp:3771
#9  0x7f97c95bb8a7 in QMetaObject::activate 
(sender=sender@entry=0x55b00525e970, m=m@entry=0x7f97ca3d1840 
, local_signal_index=local_signal_index@entry=1, 
argv=argv@entry=0x7ffdca3ab9d0) at kernel/qobject.cpp:3633
#10 0x7f97c9f01ee2 in QAction::triggered (this=this@entry=0x55b00525e970, 
_t1=) at .moc/moc_qaction.cpp:376
#11 0x7f97c9f044f0 in QAction::activate (this=0x55b00525e970, 
event=) at kernel/qaction.cpp:1166
#12 0x7f97c9fefc8d in QAbstractButtonPrivate::click (this=0x55b0053538b0) 
at widgets/qabstractbutton.cpp:397
#13 0x7f97c9fefec5 in QAbstractButton::mouseReleaseEvent 
(this=0x55b0053533a0, e=0x7ffdca3abea0) at widgets/qabstractbutton.cpp:1011
#14 0x7f97ca0d9c0a in QToolButton::mouseReleaseEvent (this=, 
e=) at widgets/qtoolbutton.cpp:622
#15 0x7f97c9f467c8 in QWidget::event (this=0x55b0053533a0, 
event=0x7ffdca3abea0) at kernel/qwidget.cpp:8925
#16 0x7f97c9ff1103 in QAbstractButton::event 
(this=this@entry=0x55b0053533a0, e=e@entry=0x7ffdca3abea0) at 
widgets/qabstractbutton.cpp:968
#17 0x7f97ca0d9cb3 in QToolButton::event (this=0x55b0053533a0, 
event=0x7ffdca3abea0) at widgets/qtoolbutton.cpp:985
#18 0x7f97c9f08491 in QApplicationPrivate::notify_helper 
(this=this@entry=0x55b004f5e380, receiver=receiver@entry=0x55b0053533a0, 
e=e@entry=0x7ffdca3abea0) at kernel/qapplication.cpp:3727
#19 0x7f97c9f0fd18 in QApplication::notify(QObject*, QEvent*) () at 
kernel/qapplication.cpp:3203
#20 0x7f97c9592039 in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
() at 
../../include/QtCore/5.11.2/QtCore/private/../../../../../src/corelib/thread/qthread_p.h:307
#21 0x7f97c9f0f019 in QCoreApplication::sendEvent (event=, 
receiver=) at 
../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:234
#22 QApplicationPrivate::sendMouseEvent 
(receiver=receiver@entry=0x55b0053533a0, event=event@entry=0x7ffdca3abea0, 
alienWidget=alienWidget@entry=0x55b0053533a0, nativeWidget=0x55b004fa5610, 
buttonDown=buttonDown@entry=0x7f97ca400870 , 
lastMouseReceiver=..., spontaneous=true) at kernel/qapplication.cpp:2695
#23 0x7f97c9f61304 in QWidgetWindow::handleMouseEvent(QMouseEvent*) () at 
/usr/include/c++/8/bits/atomic_base.h:390
#24 0x7f97c9f63e8e in 

Bug#914360: Bug #914360: tinc: Random segfault after connection drop

[Bernhard Übelacker]

Hello Maximilian,

Am 23.11.2018 um 16:58 schrieb Maximilian Stein:
> Maybe the connection object ptr c
> was free'd or NULL?

Yes, I think c was NULL at the time of the crash.

Kind regards,
Bernhard

Bug#914433: Bug #914433: iwd: Crash on failed scan request

[Bernhard Übelacker]

Dear Maintainer, hello Felipe Sateler,
that output would match that output in bug #913859 from
the unmodified package iwd 0.10-1.

In your backtrace the paramter method_call=0x0.
Therefore I would suspect it belongs to line 366, where method_call
gets unconditionally dereferenced.


(gdb) list l_dbus_message_new_error_valist
359
360 LIB_EXPORT struct l_dbus_message *l_dbus_message_new_error_valist(
361 struct l_dbus_message 
*method_call,
362 const char *name,
363 const char *format, va_list 
args)
364 {
365 char str[1024];
366 struct dbus_header *hdr = method_call->header;  
   method_call == 0


(gdb) list l_dbus_message_new_error
378
379 LIB_EXPORT struct l_dbus_message *l_dbus_message_new_error(
380 struct l_dbus_message 
*method_call,
...
388 reply = l_dbus_message_new_error_valist(method_call, name,  
    method_call == 0
389 
format, args);


(gdb) list dbus_error_failed
63  struct l_dbus_message *dbus_error_failed(struct l_dbus_message *msg)
64  {
65  return l_dbus_message_new_error(msg, IWD_SERVICE ".Failed", 
   msg == 0
66  "Operation failed");
67  }


(gdb) list dbus_error_from_errno
155 struct l_dbus_message *dbus_error_from_errno(int err,
156 struct 
l_dbus_message *msg)
157 {
158 switch (err) {  
   the switch statement contains no -ENETDOWN
...
186 return dbus_error_failed(msg);  
   msg == 0


(gdb) list station_dbus_scan_triggered
1961static void station_dbus_scan_triggered(int err, void *user_data)
...
1970reply = dbus_error_from_errno(err, 
station->scan_pending); station->scan_pending == 0


/usr/include/asm-generic/errno.h:83:
#define ENETDOWN100 /* Network is down */


Kind regards,
Bernhard

Bug#891233: Bug #891233: kamoso: segmentation fault in kamoso in Debian 9 stable. Buster not affected

[Bernhard Übelacker]

Dear Maintainer, hello Laura Arjona Reina,
I just tried to have a look at this crash.

Unfortunately given information point to no exact location.

In that case the line from dmesg would already be helpful:
[  609.690904] kamoso[28487]: segfault at 0 ip 55bc679e7fd5 sp 
7ffc474fd950 error 4 in kamoso[55bc679d3000+2b000]

A good information would be just to run it that way:
gdb -q -ex run -ex bt -ex detach -ex quit --args kamoso

Another way would be to install a core dump collector like systemd-coredump
and execute something like this:
coredumpctl list
coredumpctl gdb 

Even better when debug symbols are installed like described in [1].


Nevertheless I could reproduce a crash in a minimal stretch amd64 qemu VM,
with a forwarded usb webcam.

(gdb) bt
#0  0x55bc679e7fd5 in WebcamControl::play (this=this@entry=0x7ffc474fdc80, 
device=0x55bc68b82220) at ./src/video/webcamcontrol.cpp:135
#1  0x55bc679e8bfd in WebcamControl::WebcamControl (this=0x7ffc474fdc80) at 
./src/video/webcamcontrol.cpp:86
#2  0x55bc679e071f in main (argc=, argv=0x7ffc474fdde8) at 
./src/main.cpp:43

(gdb) print cameraSource
$1 = {m_class = 0x0}

134 auto cameraSource = 
QGst::ElementFactory::make("wrappercamerabinsrc", "video_balance");
135 cameraSource->setProperty("video-source-filter", bin);


That "wrappercamerabinsrc" points to a missing package gstreamer1.0-plugins-bad.
Maybe you can confirm that installing that package avoids the crash,
if you still run a stretch installation that shows it.

This crash got fixed upstream in [2].

Kind regards,
Bernhard

[1] https://wiki.debian.org/HowToGetABacktrace
[2] 
https://cgit.kde.org/kamoso.git/commit/?id=1ff5f14fedd42bfa61ae181e0c598ec991ba4407

Bug#914441: kamoso: no user interface is shown: qrc:/qml/Main.qml:7 module "org.kde.kirigami" is not installed

[Bernhard Übelacker]

Package: kamoso
Version: 18.04.0-3
Severity: normal

Dear Maintainer,
on a minimal installation of kamosos following is written to the console:

benutzer@debian:~$ kamoso
No device found
QQmlApplicationEngine failed to load component
qrc:/qml/Main.qml:7 module "org.kde.kirigami" is not installed

After installing package qml-module-org-kde-kirigami2 the user interface is 
shown.
Maybe a dependency should be considered.

Kind regards,
Bernhard

Bug#906609: fixed in gnucash 1:3.3-1

[Bernhard Übelacker]

Am 22.11.2018 um 23:15 schrieb Dmitry Smirnov:
> On Thursday, 22 November 2018 9:50:02 AM AEDT Chris Lamb wrote:
>> grep-excuses claims:
>>
>> missing build on armel: gnucash, python-gnucash (from 1:2.6.19-1)
>> missing build on mips: gnucash, python-gnucash (from 1:2.6.19-1)
>>
>> Is there a bug for this? (Would you like one?)
> 
> https://bugs.gnucash.org/show_bug.cgi?id=796899
> 
> The problem is likely to be related but slightly different as this time it is 
> the test that fails...
> 

Hello Dimitry, hello Chris,
being just curious, the mips part is from gnucash,
but I cannot make a clue out of the
armel "Not-For-Us" [1] for the build dependeny guile-2.2.
What does that mean?

Kind regards,
Bernhard

[1] https://buildd.debian.org/status/package.php?p=guile-2.2=sid

Bug#914360: Bug #914360: tinc: Random segfault after connection drop

[Bernhard Übelacker]

Hello Maximilian Stein,
maybe the package maintainer can get some information out of that
kernel line, but maybe you can install a core dump collector
like e.g. systemd-coredump.
When the next crash happens you can examine the core by:

coredumpctl list
coredumpctl gdb 

Even better if debug symbols could be installed before. [1]


Now I see one thing - you are running 1.0.35-1, is this
a local rebuilt package or the package from testing?

If the latter with some guessing the location *could* be there:
   0x929d :   movslq 0x98c(%rbx),%rdx

And that would point to following line:
   src/meta.c:44  if(!c->outbuflen) {

But this is just based on the offsets and if the used package
was built by debian.


Kind regards,
Bernhard

[1] https://wiki.debian.org/HowToGetABacktrace


apt install devscripts dpkg-dev binutils gdb

wget http://ftp.de.debian.org/debian/pool/main/t/tinc/tinc_1.0.35-1_amd64.deb
wget 
http://snapshot.debian.org/archive/debian-debug/20181008T214825Z/pool/main/t/tinc/tinc-dbgsym_1.0.35-1_amd64.deb
dpkg -i *.deb


mkdir tinc/orig -p
cdtinc/orig
dget http://deb.debian.org/debian/pool/main/t/tinc/tinc_1.0.35-1.dsc
cd ../..


# From #914360:
kernel: [52018.886642] tincd[691]: segfault at 98c ip 557ae018e29d sp 
7c40f5b0 error 4 in tincd[557ae0189000+19000]


0x557ae0189000 - 0x557ae018e29d = 0x529D


benutzer@debian:~$ script -a out.txt -c "gdb -q --args /usr/sbin/tincd"
Reading symbols from /usr/sbin/tincd...Reading symbols from 
/usr/lib/debug/.build-id/5b/0adb3822421ae6a87900b011c2b6af3e355be8.debug...done.
done.
(gdb) set width 0
(gdb) set pagination off
(gdb) directory /home/benutzer/tinc/orig/tinc-1.0.35/src
Source directories searched: /home/benutzer/tinc/orig/tinc-1.0.35/src:$cdir:$cwd
(gdb) info target
Symbols from "/usr/sbin/tincd".
Local exec file:
`/usr/sbin/tincd', file type elf64-x86-64.
Entry point: 0x5ac0
...
0x4c90 - 0x0001c922 is .text
...
(gdb) disassemble 0x4c90,0x0001c922
(gdb) q

# grep for 29d
benutzer@debian:~$ grep -i "29d " out.txt 
   0x929d :   movslq 0x98c(%rbx),%rdx 
< looks promising as it uses that 98c offset too
   0x93d8 :  jmpq   0x929d 
   0xd29d :   retq   
   0xe29d :  lea0xf1b2(%rip),%rsi
# 0x1d456
   0x0001029d :je 0xff2a 

   0x0001329d :   mov%rax,0x90(%rbx)
   0x0001629d :   mov%r14,%rdi
   0x0001a29d :push   %rax


(gdb) disassemble /m send_meta
Dump of assembler code for function send_meta:
37  bool send_meta(connection_t *c, const char *buffer, int length) {
   0x9270 <+0>: push   %r12
   0x9272 <+2>: mov%rsi,%r12
   0x9275 <+5>: push   %rbp
   0x9276 <+6>: mov%edx,%ebp
   0x9278 <+8>: push   %rbx
   0x9279 <+9>: mov%rdi,%rbx
   0x927c <+12>:sub$0x10,%rsp
   0x9280 <+16>:mov%fs:0x28,%rax
   0x9289 <+25>:mov%rax,0x8(%rsp)
   0x928e <+30>:xor%eax,%eax

38  int outlen;

39  int result;

40
41  ifdebug(META) logger(LOG_DEBUG, "Sending %d bytes of metadata 
to %s (%s)", length,
   0x9290 <+32>:cmpl   $0x3,0x1ef51(%rip)# 0x281e8 

   0x9297 <+39>:ja 0x93c0 
   0x93c0 <+336>:   mov0x28(%rdi),%r8
   0x93c4 <+340>:   mov(%rdi),%rcx
   0x93c7 <+343>:   lea0x14302(%rip),%rsi# 0x1d6d0
   0x93ce <+350>:   mov$0x7,%edi
   0x93d3 <+355>:   callq  0x8fe0 
   0x93d8 <+360>:   jmpq   0x929d 
   0x93dd <+365>:   nopl   (%rax)

42   c->name, c->hostname);
43
44  if(!c->outbuflen) { 
 would be here maybe with c == NULL ?
   0x929d <+45>:movslq 0x98c(%rbx),%rdx
   0x92a4 <+52>:test   %edx,%edx
   0x92a6 <+54>:jne0x92b6 

45  c->last_flushed_time = now;
   0x92a8 <+56>:mov0x1ef81(%rip),%rax# 0x28230 
   0x92af <+63>:mov%rax,0x9a0(%rbx)

46  }







gdb -q --args /usr/sbin/tincd

set width 0
set pagination off
directory /home/benutzer/tinc/orig/tinc-1.0.35/src

Bug#912223: auto-wrapping in the web interface Bad

[Bernhard Übelacker]

Hello,

On Tue, 30 Oct 2018 18:47:41 -0700 Don Armstrong  wrote:
> On Mon, 29 Oct 2018, Peter Palfrader wrote:
> > debbugs tries to wrap messages such as
> >  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912215#10
> > in its web interface.
> > 
> > This makes the message entirely unreadable.
> 
> Heh; that one shouldn't be wrapped. We need something to do
> wrapping because people send messages which aren't wrapped either, so
> I'm going to try to tweak this to not fire on messages which look
> rectangular and still follow the 80 column wide convention.

Could such unwrapped sentences and gdb backtraces just be separted
by ignoring lines starting with '#' ?

Kind regards,
Bernhard

Bug#914344: gdb: record feature leads to Assertion `lwp_is_stopped (lwp)' failed

[Bernhard Übelacker]

Package: gdb
Version: 8.1-4+b1
Severity: normal
Tags: upstream

Dear Maintainer,

while trying to debug #914300 I wanted to use the record feature of gdb.

Unfortunately that stopped on me with an assertion failed.
See at the bottom of this mail for an example run.

I was able to find the issue starting between these debian packages.
- gdb-minimal_7.10-1.1 works
- gdb-minimal_7.11.1-1 fails

This upstream bug [1] seems to handle that exact issue.
There I have forwarded my findings and a git bisect result,
of which commit [2] has introduced this.

Kind regards,
Bernhard

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=20456
[2] 
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=patch;h=398e081380a204e3b9fb4eb4da069ccf471f930e


-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-2-amd64 (SMP w/8 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gdb depends on:
ii  libbabeltrace1  1.5.6-1
ii  libc6   2.27-8
ii  libexpat1   2.2.6-1
ii  libipt2 2.0-2
ii  liblzma55.2.2-1.3
ii  libncursesw66.1+20181013-1
ii  libpython3.63.6.7-1
ii  libreadline77.0-5
ii  libtinfo6   6.1+20181013-1
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages gdb recommends:
ii  libc6-dbg [libc-dbg]  2.27-8

Versions of packages gdb suggests:
pn  gdb-doc
pn  gdbserver  

-- no debconf information





benutzer@debian:~$ gdb -q --args kalgebra
Reading symbols from kalgebra...Reading symbols from 
/usr/lib/debug/.build-id/db/c25dd2c87a837265a5fccb742e0b65684c3166.debug...done.
done.
(gdb) b ConsoleHtml::clear
Breakpoint 1 at 0x1edc0: file ./src/consolehtml.cpp, line 225.
(gdb) run
Starting program: /usr/bin/kalgebra 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffdce9d700 (LWP 22111)]
[New Thread 0x7fffd3078700 (LWP 22112)]
[New Thread 0x7fffd2877700 (LWP 22113)]
[New Thread 0x7fffd2076700 (LWP 22114)]
[New Thread 0x7fffd1875700 (LWP 22115)]
[New Thread 0x7fffd1074700 (LWP 22116)]
[New Thread 0x7fffd0873700 (LWP 22117)]
[New Thread 0x7fffbbfff700 (LWP 22118)]
[New Thread 0x7fffb37fe700 (LWP 22119)]
[New Thread 0x7fffbb7fe700 (LWP 22120)]
[New Thread 0x7fffba793700 (LWP 22122)]
[New Thread 0x7fffb9f92700 (LWP 22124)]
[New Thread 0x7fffb9791700 (LWP 22125)]
[New Thread 0x7fffb8f90700 (LWP 22126)]
[New Thread 0x7fffb3fff700 (LWP 22127)]
[New Thread 0x7fffb2ffd700 (LWP 22128)]
[New Thread 0x7fffb27fc700 (LWP 22129)]
[New Thread 0x7fffb1ffb700 (LWP 22130)]
[New Thread 0x7fffb17fa700 (LWP 22131)]
[New Thread 0x7fffb0ff9700 (LWP 22132)]
[New Thread 0x7fff83fff700 (LWP 22133)]
[New Thread 0x7fff837fe700 (LWP 22134)]
[New Thread 0x7fff82ffd700 (LWP 22135)]
[New Thread 0x7fff827fc700 (LWP 22136)]
[New Thread 0x7fff81ffb700 (LWP 22137)]
[New Thread 0x7fff817fa700 (LWP 22138)]
[New Thread 0x7fff80ff9700 (LWP 22139)]
[New Thread 0x7fff5700 (LWP 22140)]
[New Thread 0x7fff5f7fe700 (LWP 22141)]
[New Thread 0x7fff5effd700 (LWP 22142)]
[New Thread 0x7fff5e7fc700 (LWP 22143)]
[New Thread 0x7fff5dffb700 (LWP 22144)]
[New Thread 0x7fff5d7fa700 (LWP 22152)]
[New Thread 0x7fff43fff700 (LWP 22161)]
[Thread 0x7fff43fff700 (LWP 22161) exited]

Thread 1 "kalgebra" hit Breakpoint 1, ConsoleHtml::clear (this=0x55ab9ff0) 
at ./src/consolehtml.cpp:225
225 ./src/consolehtml.cpp: No such file or directory.
(gdb) record
(gdb) cont
Continuing.
/build/gdb-KOFU8D/gdb-8.1/gdb/nat/x86-linux-dregs.c:146: internal-error: void 
x86_linux_update_debug_registers(lwp_info*): Assertion `lwp_is_stopped (lwp)' 
failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) 

Bug#914300: Bug #914300: kalgebra: Segfault when clearing empty calculator

[Bernhard Übelacker]

Dear Maintainer,
I tried to have a look at this issue.


This is the stack with debug symbols:

(gdb) bt
#0  QByteArray::QByteArray (a=..., this=0x7fffd4e8) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qbytearray.h:492
#1  QList::takeLast (this=0x7fffd4e0) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qlist.h:565
#2  ConsoleHtml::updateView (this=0x55ab9ac0) at ./src/consolehtml.cpp:182
#3  0x55572dd6 in ConsoleHtml::clear (this=) at 
./src/consolehtml.cpp:227
#4  0x55577da5 in ConsoleHtml::qt_static_metacall (_o=, 
_id=, _a=0x7fffd6a0, _c=) at 
./obj-x86_64-linux-gnu/src/kalgebra_autogen/EWIEGA46WW/moc_consolehtml.cpp:134
#5  0x769df28b in QMetaObject::activate(QObject*, int, int, void**) () 
at kernel/qobject.cpp:3771
#6  0x769df8a7 in QMetaObject::activate 
(sender=sender@entry=0x55be7820, m=m@entry=0x777f5840 
, local_signal_index=local_signal_index@entry=1, 
argv=argv@entry=0x7fffd6a0) at kernel/qobject.cpp:3633
#7  0x77325ee2 in QAction::triggered (this=this@entry=0x55be7820, 
_t1=) at .moc/moc_qaction.cpp:376
#8  0x773284f0 in QAction::activate (this=0x55be7820, 
event=) at kernel/qaction.cpp:1166
#9  0x77498e1c in QMenuPrivate::activateCausedStack 
(this=this@entry=0x55be3bb0, causedStack={...}, 
action=action@entry=0x55be7820, action_e=action_e@entry=QAction::Trigger, 
self=self@entry=true) at widgets/qmenu.cpp:1371
#10 0x774a03f0 in QMenuPrivate::activateAction 
(this=this@entry=0x55be3bb0, action=action@entry=0x55be7820, 
action_e=action_e@entry=QAction::Trigger, self=self@entry=true) at 
widgets/qmenu.cpp:1448
#11 0x774a141b in QMenu::mouseReleaseEvent (this=, 
e=0x7fffdcb0) at widgets/qmenu.cpp:2942
#12 0x7736a7c8 in QWidget::event (this=this@entry=0x55bbd0a0, 
event=event@entry=0x7fffdcb0) at kernel/qwidget.cpp:8925
#13 0x774a3aab in QMenu::event (this=0x55bbd0a0, e=0x7fffdcb0) 
at widgets/qmenu.cpp:3064
#14 0x7732c491 in QApplicationPrivate::notify_helper 
(this=this@entry=0x55784680, receiver=receiver@entry=0x55bbd0a0, 
e=e@entry=0x7fffdcb0) at kernel/qapplication.cpp:3727
#15 0x77333d18 in QApplication::notify(QObject*, QEvent*) () at 
kernel/qapplication.cpp:3203
#16 0x769b6039 in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
() at 
../../include/QtCore/5.11.2/QtCore/private/../../../../../src/corelib/thread/qthread_p.h:307
#17 0x77333019 in QCoreApplication::sendEvent (event=, 
receiver=) at 
../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:234
#18 QApplicationPrivate::sendMouseEvent 
(receiver=receiver@entry=0x55bbd0a0, event=event@entry=0x7fffdcb0, 
alienWidget=0x0, alienWidget@entry=0x55bbd0a0, nativeWidget=0x55bbd0a0, 
buttonDown=buttonDown@entry=0x77824870 , 
lastMouseReceiver=..., spontaneous=true) at kernel/qapplication.cpp:2695
#19 0x773856c3 in QWidgetWindow::handleMouseEvent(QMouseEvent*) () at 
kernel/qwidgetwindow.cpp:556
#20 0x77387e8e in QWidgetWindow::event (this=0x7fffd8007910, 
event=0x7fffe0b0) at kernel/qwidgetwindow.cpp:281
#21 0x7732c491 in QApplicationPrivate::notify_helper 
(this=this@entry=0x55784680, receiver=receiver@entry=0x7fffd8007910, 
e=e@entry=0x7fffe0b0) at kernel/qapplication.cpp:3727
#22 0x77333ad0 in QApplication::notify(QObject*, QEvent*) () at 
kernel/qapplication.cpp:3486
#23 0x769b6039 in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
() at 
../../include/QtCore/5.11.2/QtCore/private/../../../../../src/corelib/thread/qthread_p.h:307
#24 0x76d5fb2b in QCoreApplication::sendSpontaneousEvent 
(event=0x7fffe0b0, receiver=0x7fffd8007910) at 
../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:237
#25 QGuiApplicationPrivate::processMouseEvent (e=0x56940e70) at 
kernel/qguiapplication.cpp:2081
#26 0x76d61a25 in QGuiApplicationPrivate::processWindowSystemEvent 
(e=e@entry=0x56940e70) at kernel/qguiapplication.cpp:1816
#27 0x76d3bd8b in QWindowSystemInterface::sendWindowSystemEvents 
(flags=...) at kernel/qwindowsysteminterface.cpp:1032
#28 0x7fffddc4985b in QPAEventDispatcherGlib::processEvents 
(this=0x55800360, flags=...) at qeventdispatcher_glib.cpp:70
#29 0x769b4d0b in 
QEventLoop::exec(QFlags) () at 
../../include/QtCore/../../src/corelib/global/qflags.h:140
#30 0x769bce82 in QCoreApplication::exec() () at 
../../include/QtCore/../../src/corelib/global/qflags.h:120
#31 0x555661a9 in main (argc=, argv=) at 
./src/main.cpp:43


In ConsoleHtml::clear is unconditionally the last element retrieved,
even when the log is empty.

182 const auto newEntry = log.takeLast();


It looks like upstream have fixed this in commit [1].
This is contained in branch Applications/18.08.

Have not found a matching upstream bug.

Kind regards,
Bernhard

[1] 

Bug#914249: Bug #914249: gimp: GIMP Crashed when I was editing a image

[Bernhard Übelacker]

Dear Maintainer,
just tried to reconstruct a better readable stack with
function names, that would probably look like this:


0x...e27 | 0x779c9e27: 0x779c9e22 : 
callq  0x779bf150 
0x...4a0 | 0x556274a0: 0x5562749b :   callq  
0x55621790 
0x...8d8 | 0x556278d8: 0x556278d3 :
callq  0x556271b0 
0x...037 | 0x55628037 :   callq  
0x556278f0 
0x...8e0 | 0x767068e0 <__restore_rt+0>: mov$0xf,%rax  ; 
0x...f3b | 0x7656bf3b: 0x7656bf39 <__GI_raise+265>: syscall 
0x...2f1 | 0x7656d2f1: 0x7656d2ec <__GI_abort+332>: callq  
0x7656be30 <__GI_raise>  ; abort.c:79raise (SIGABRT);
0x...a8a | 0x76564a8a: 0x76564a85 <__assert_fail_base+325>: 
callq  0x7656d1a0 <__GI_abort>
0x...b02 | 0x76564b02: 0x76564afd <__GI___assert_fail+61>:  
callq  0x76564940 <__assert_fail_base>
0x...6bb | 0x764326bb: 0x764326b6 : 
callq  0x7640bdd0 <__assert_fail@plt>
0x...760 | 0x76432760 in poll_for_response (...) at 
../../src/xcb_io.c:303
0x...a5d | 0x76432a5d in _XEventsQueued (...) at ../../src/xcb_io.c:363
0x...7b7 | 0x764247b7 in XPending (...) at ../../src/Pending.c:55
0x...8d5 | 0x77a8a8d5 in gdk_check_xpending (...) at 
./gdk/x11/gdkevents-x11.c:159
0x...821 | 0x768fc821 in g_main_context_check (...) at 
../../../../glib/gmain.c:3753
0x...df0 | 0x768fcdf0 in g_main_context_iterate (...) at 
../../../../glib/gmain.c:3917
0x...1d2 | 0x768fd1d2 in g_main_loop_run (...) at 
../../../../glib/gmain.c:4116
0x...cb7 | 0x55626cb7 in app_run (...) at app.c:440
0x...5b5 | 0x556265b5 in main (...) at main.c:524


I assume the point where things started to go wrong is in function 
poll_for_event.


disassemble /m poll_for_event
...
260 throw_thread_fail_assert("Unknown 
sequence "
   0x7643269c : lea0x7241d(%rip),%rcx   
 # 0x764a4ac0 <__PRETTY_FUNCTION__.15060>
   0x764326a3 : mov$0x107,%edx
   0x764326a8 : lea0x71fc4(%rip),%rsi   
 # 0x764a4673
   0x764326af : lea0x72152(%rip),%rdi   
 # 0x764a4808
   0x764326b6 : callq  0x7640bdd0 
<__assert_fail@plt>
   0x764326bb:  nopl   0x0(%rax,%rax,1)
...
(xcb_io.c)


(gdb) list poll_for_event
233 static xcb_generic_reply_t *poll_for_event(Display *dpy, Bool 
queued_only)
...
258 if (XLIB_SEQUENCE_COMPARE(event_sequence, >, 
request))
259 {
260 throw_thread_fail_assert("Unknown 
sequence "
261  "number while "
262  "processing 
queue",
263 
xcb_xlib_threads_sequence_lost);


If this issue is reproducable the output, when started from a terminal,
could give further information.

In that case would it also be great to have gdb and the debug symbols
installed like described in [1].

Kind regards,
Bernhard

[1] https://wiki.debian.org/HowToGetABacktrace
> fatal error: Abortado

Stack trace:
```
/usr/lib/libgimpbase-2.0.so.0(gimp_stack_trace_print+0x397)[0x7f8ed515fe27]
gimp-2.10(+0xd34a0)[0x559a57d004a0]
gimp-2.10(+0xd38d8)[0x559a57d008d8]
gimp-2.10(+0xd4037)[0x559a57d01037]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x128e0)[0x7f8ed3e9d8e0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x10b)[0x7f8ed3d01f3b]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x151)[0x7f8ed3d032f1]
/lib/x86_64-linux-gnu/libc.so.6(+0x2ea8a)[0x7f8ed3cfaa8a]
/lib/x86_64-linux-gnu/libc.so.6(+0x2eb02)[0x7f8ed3cfab02]
/usr/lib/x86_64-linux-gnu/libX11.so.6(+0x436bb)[0x7f8ed3bc86bb]
/usr/lib/x86_64-linux-gnu/libX11.so.6(+0x43760)[0x7f8ed3bc8760]
/usr/lib/x86_64-linux-gnu/libX11.so.6(_XEventsQueued+0x5d)[0x7f8ed3bc8a5d]
/usr/lib/x86_64-linux-gnu/libX11.so.6(XPending+0x57)[0x7f8ed3bba7b7]
/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0(+0x588d5)[0x7f8ed52208d5]
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_check+0x1e1)[0x7f8ed4092821]
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4ddf0)[0x7f8ed4092df0]
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_loop_run+0xb2)[0x7f8ed40931d2]
gimp-2.10(app_run+0x357)[0x559a57cffcb7]
gimp-2.10(main+0x395)[0x559a57cff5b5]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f8ed3ceeb17]
gimp-2.10(_start+0x2a)[0x559a57cff73a]

```



apt install devscripts dpkg-dev xserver-xorg lightdm openbox gdb dbus-x11 gimp 
gimp-dbgsym libglib2.0-0-dbgsym libgtk2.0-0-dbgsym libx11-6-dbgsym libc6-dbg 

systemctl start lightdm


mkdir glibc/orig -p
cdglibc/orig
apt source glibc
cd ../..

mkdir libx11-6/orig -p
cdlibx11-6/orig
apt source libx11-6
cd ../..





export DISPLAY=:0
gdb -q --args gimp

directory 

Bug#857580: adb dev*** Error in `adb': free(): invalid pointer: 0x000055867c446b90 ***

[Bernhard Übelacker]

Dear Maintainer,
this crash on key generation when running adb for the first time seems
now fixed in current buster/testing, version 1:8.1.0+r23-3.
The patches adb_libssl_*.diff seem to have been dropped.

This issue is still visible in current stretch version 1:7.0.0+r33-1.

The duplicate candidate bug 859195 got closed already some days ago,
858764 was tagged unreproducible, 903939 is unchanged.

Kind regards,
Bernhard

Bug#914150: Bug #914150: pcmanfm: SIGSEGV, Segmentation fault on opening folder

[Bernhard Übelacker]

Dear Maintainer,
just tried to reproduce the crash and succeeded:

The backtrace looks like this with debug symbols installed:

(gdb) bt
#0  fm_file_info_get_path (fi=0x0) at base/fm-file-info.c:1028
#1  0x7f4397419b7b in on_file_info_job_finished (job=0x558b83a39960, 
folder=0x558b83a2c230) at base/fm-folder.c:400
#2  0x7f439720db6d in g_closure_invoke (closure=0x558b83a27170, 
return_value=0x0, n_param_values=1, param_values=0x7ffca2eca0f0, 
invocation_hint=0x7ffca2eca070) at ../../../../gobject/gclosure.c:810
#3  0x7f43972208f3 in signal_emit_unlocked_R 
(node=node@entry=0x558b8380eb90, detail=detail@entry=0, 
instance=instance@entry=0x558b83a39960, 
emission_return=emission_return@entry=0x0, 
instance_and_params=instance_and_params@entry=0x7ffca2eca0f0) at 
../../../../gobject/gsignal.c:3635
#4  0x7f4397229882 in g_signal_emit_valist (instance=, 
signal_id=, detail=, 
var_args=var_args@entry=0x7ffca2eca2a0) at ../../../../gobject/gsignal.c:3391
#5  0x7f4397229ecf in g_signal_emit 
(instance=instance@entry=0x558b83a39960, signal_id=, 
detail=detail@entry=0) at ../../../../gobject/gsignal.c:3447
#6  0x7f439742b4f0 in fm_job_emit_finished (job=0x558b83a39960) at 
job/fm-job.c:94
#7  on_idle_cleanup (unused=) at job/fm-job.c:578
#8  0x7f439712dae8 in g_main_dispatch (context=0x558b837e52a0) at 
../../../../glib/gmain.c:3182
#9  g_main_context_dispatch (context=context@entry=0x558b837e52a0) at 
../../../../glib/gmain.c:3847
#10 0x7f439712ded8 in g_main_context_iterate (context=0x558b837e52a0, 
block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
../../../../glib/gmain.c:3920
#11 0x7f439712e1d2 in g_main_loop_run (loop=0x558b83a39640) at 
../../../../glib/gmain.c:4116
#12 0x7f4397d288e7 in IA__gtk_main () at ./gtk/gtkmain.c:1270
#13 0x558b81b188d6 in main (argc=, argv=) at 
pcmanfm.c:282


It might not just related to high activity in the directory,
but also needs pressing or holding F5 for reloading the current directory.

With attached patch I was not able to get it to crash anymore.
The other attached file shows some details on debugging it.

Kind regards,
Bernhard
Description: Avoid crash on reload while directory changes

---

Author: Bernhard Übelacker 
Bug-Debian: https://bugs.debian.org/914150
Forwarded: no
Last-Update: 2018-11-20

--- libfm-1.3.0.2.orig/src/base/fm-folder.c
+++ libfm-1.3.0.2/src/base/fm-folder.c
@@ -397,7 +397,7 @@ static void on_file_info_job_finished(Fm
 FmFileInfo* fi = (FmFileInfo*)l->data;
 FmPath* path = fm_file_info_get_path(fi);
 GList* l2;
-if (path == fm_file_info_get_path(folder->dir_fi))
+if (fm_folder_is_valid(folder) && path == fm_file_info_get_path(folder->dir_fi))
 /* update for folder itself, also see FIXME below! */
 fm_file_info_update(folder->dir_fi, fi);
 else if ((l2 = _fm_folder_get_file_by_path(folder, path)))



https://wiki.debian.org/HowToGetABacktrace




##



apt update
apt dist-upgrade

apt install systemd-coredump htop xserver-xorg lightdm openbox pcmanfm

systemctl start lightdm


export LANG=C
export DISPLAY=:0




##




# terminal 1
taskset -c 0 pcmanfm

# terminal 2
mkdir x; cd x
taskset -c 0 nice -n 19 pcmanfm
for i in {1..10}; do echo test > delete-$i; mkdir delete-dir-$i; echo test 
> delete-dir-$i/delete$i; rm delete-$i delete-dir-$i/delete$i; rmdir 
delete-dir-$i;  done

# watching in pcmanfm that directory, some refresh F5  ... crash


benutzer@debian:~$ taskset -c 0 nice -n 19 pcmanfm
** Message: 11:38:05.509: x-terminal-emulator has very limited support, 
consider choose another terminal

(pcmanfm:27512): Gdk-WARNING **: 11:38:05.671: gdk_window_set_icon_list: icons 
too large
Segmentation fault (core dumped)


[ 1485.670647] pcmanfm[27512]: segfault at 0 ip 7f4397417070 sp 
7ffca2ec9ed8 error 4 in libfm.so.4.1.1[7f43973fa000+48000]
[ 1485.670653] Code: 7d 58 48 83 ff ff 0f 85 e5 fe ff ff 48 89 7b 58 e9 e5 fe 
ff ff 0f 1f 44 00 00 48 8b 87 88 00 00 00 c3 0f 1f 84 00 00 00 00 00 <48> 8b 07 
c3 66 90 66 2e 0f 1f 84 00 00 00 00 00 48 8b 


root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Tue 2018-11-20 11:38:21 CET   27512  1000  1000  11 present   /usr/bin/pcmanfm
root@debian:~# coredumpctl gdb 27512
   PID: 27512 (pcmanfm)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 11 (SEGV)
 Timestamp: Tue 2018-11-20 11:38:20 CET (1min 42s ago)
  Command Line: pcmanfm
Executable: /usr/bin/pcmanfm
 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: 867b6f2f07de46dab6f59fc032b7a93c
Machine ID: 32f43b50ac8c4b21941bc0b02f8e7811
  Hostname: debian
   Storage: 

Bug#913715: Bug #913715: simulide: terminates with segfault sometimes, when trying to undo changes

[Bernhard Übelacker]

Hello Nils Jarle Haugen,
I just tried to reproduce the issue.

Unfortunately without having deeper knowledge about
simulide and not knowing which elements you are using,
I did not receive a crash.

Running with valgrind led just to an unintialized variable
m_deltaV that might be more related to the elements I used,
and that I guess should not be able to cause a crash.

Also there seems to be a problem with your upload to
paste.debian.net.

Therefore and because its happens just randomly, you might
have a look at [1], which contains informations to install
some debug information and let simulide run inside a debugger.
Without the output of the bt command inside gdb chances
are very low to find what is causing this.

[1] https://wiki.debian.org/HowToGetABacktrace

Kind regards,
Bernhard

Bug#913929: Bug #913929: pldd never stops

[Bernhard Übelacker]

Dear Maintainer,
this looks like a matching upstream bug:

   https://sourceware.org/bugzilla/show_bug.cgi?id=18035

Kind regards,
Bernhard

Bug#913632: Bug #913632: connmand service segfaults on start after iwd-0.10 package upgrade

[Bernhard Übelacker]

Hello,
just for completeness, the backtrace above points to these functions:

 backtrace 
#0  0x7efd7c3dbfc0 in /lib/x86_64-linux-gnu/libc.so.6| 
#1  0x556a4c101217 in /usr/sbin/connmand |  
 0x556460d38217 
:repz cmpsb %es:(%rdi),%ds:(%rsi); 
iwd.c:101 if (!strcmp(str, "connected"))
#2  0x556a4c101773 in /usr/sbin/connmand | 
0x556460d38773 :   0x556460d3876e 
:  callq  0x556460d38200 
#3  0x556a4c1676df in /usr/sbin/connmand | 
0x556460d9e6df :0x556460d9e6dd 
:   callq  *%rax
#4  0x556a4c168ae8 in /usr/sbin/connmand | 
0x556460d9fae8 :   0x556460d9fae3 
:  callq  0x556460d9e5b0 
#5  0x7efd7c720ada in /lib/x86_64-linux-gnu/libdbus-1.so.3   | 
0x7feb54801ada : 0x7feb54801ad5 
:callq  0x7feb548158a0 
<_dbus_pending_call_finish_completion>
#6  0x7efd7c724448 in /lib/x86_64-linux-gnu/libdbus-1.so.3   | 
0x7feb54805448 :0x7feb54805443 
:   callq  0x7feb54801aa0 

#7  0x556a4c162780 in /usr/sbin/connmand | 
0x556460d99780 : 0x556460d9977b 
:callq  0x556460d186f0 
#8  0x7efd7c7adae8 in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 | 
0x7feb5488eae8 : 0x7feb5488eae5 
:callq  *%r15
#9  0x7efd7c7aded8 in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 | 
0x7feb5488eed8 :  0x7feb5488eed3 
: callq  0x7feb5488e990 

#10 0x7efd7c7ae1d2 in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 | 
0x7feb5488f1d2 : 0x7feb5488f1cd 
:callq  0x7feb5488ecd0 
#11 0x556a4c0e2868 in /usr/sbin/connmand | 
0x556460d19868 :0x556460d19863 
:   callq  0x556460d18a70 
#12 0x7efd7c3c8b17 in /lib/x86_64-linux-gnu/libc.so.6| 
+++

Kind regards,
Bernhard