Bug#1082747: cod-tools: FTBFS (only) on riscv64

[Bernhard Übelacker]

On Fri, 27 Sep 2024 19:25:10 +0200 Aurelien Jarno  wrote:


TIL disorderfs. I have also been able to reproduce it with disorderfs.
In addition knowing the root of the issue, I have been able to
reproduce the issue on a riscv64 machine using tmpfs as a build
directory, just like on the build daemons.

> Didn't have time to debug it further yet.
> 
> Hope this helps,


Definitely, thanks a lot!




Hello everyone,
I am also amazed, I did not know about disorderfs before.

I could reproduce the failure with rr-debugger on top of
a disorderfs and compared it with a successful run (both on amd64).
In the unsuccessful run the iteration through the
predicted readdir does not return the expected file [1].

So in the bad case readdir of directory src/components/codcif
does "just" not return the file "cif_list_tags" in my example
and at least for the disorderfs case.

Even more bad is this file looks like it was created just before [2].
So does disorderfs some caching, which causes this readdir
not to return the already created file?
Or is there some caching on kernel side involved as this affects
also tmpfs (not just fuse)?

I would be happy to debug this further,
with some pointers to which parts are of interest...

Kind regard,
Bernhard




[1]
Breakpoint 22, dir_contents_file_exists_p (dir=0x55c8aa58a3c0, 
filename=filename@entry=0x55c8aba3cc66 "cif_list_tags") at ../../src/dir.c:713
713   if (!REAL_DIR_ENTRY (d))
7: x/i $pc
=> 0x55c8872cce20 : cmpq   $0x0,(%rax)
9: (char*)d->d_name = 0x55c8aa8abba3 "cif_options.c"
(rr) bt
#0  dir_contents_file_exists_p (dir=0x55c8aa58a3c0, 
filename=filename@entry=0x55c8aba3cc66 "cif_list_tags") at ../../src/dir.c:713
#1  0x55c8872cd2a1 in dir_contents_file_exists_p (filename=0x55c8aba3cc66 
"cif_list_tags", dir=) at ../../src/dir.c:849
#2  dir_file_exists_p (filename=0x55c8aba3cc66 "cif_list_tags", dirname=) at ../../src/dir.c:774
#3  file_exists_p (name=0x55c8aba3cc50 "src/components/codcif/cif_list_tags") 
at ../../src/dir.c:851
#4  0x55c8872d5f45 in pattern_search (file=file@entry=0x55c8aa595710, 
archive=archive@entry=0, depth=depth@entry=5, recursions=recursions@entry=0) at 
../../src/implicit.c:758
#5  0x55c8872d6aa3 in try_implicit_rule (file=file@entry=0x55c8aa595710, 
depth=depth@entry=5) at ../../src/implicit.c:45
#6  0x55c8872e49ac in update_file_1 (depth=, 
file=0x55c8aa595710) at ../../src/remake.c:506
#7  update_file (file=, depth=) at 
../../src/remake.c:336
#8  0x55c8872e5875 in check_dep (file=0x55c8aa595710, depth=4, 
depth@entry=3, this_mtime=this_mtime@entry=1, 
must_make_ptr=must_make_ptr@entry=0x7ffcf9a5c664) at ../../src/remake.c:1024
#9  0x55c8872e4676 in update_file_1 (depth=, 
file=0x55c8aa5958f0) at ../../src/remake.c:572
#10 update_file (file=, depth=) at 
../../src/remake.c:336
#11 0x55c8872e5875 in check_dep (file=0x55c8aa5958f0, depth=2, 
depth@entry=1, this_mtime=this_mtime@entry=1, 
must_make_ptr=must_make_ptr@entry=0x7ffcf9a5c7a4) at ../../src/remake.c:1024
#12 0x55c8872e4676 in update_file_1 (depth=, 
file=0x55c8aa589db0) at ../../src/remake.c:572
#13 update_file (file=file@entry=0x55c8aa589db0, depth=) at 
../../src/remake.c:336
#14 0x55c8872e5cd4 in update_goal_chain (goaldeps=) at 
../../src/remake.c:151
#15 0x55c8872c9ef5 in main (argc=, argv=, 
envp=) at ../../src/main.c:2589
(rr) print *dir->dirstream
$37 = {fd = 4, lock = 0, allocation = 32768, size = 1632, offset = 920, filepos = 1000, 
errcode = 0, data = 0x55c8aa8ab820 "1'\002"}
(rr)



[2]
...
sed 's/@VERSION@/3.10.0/' version.hin > version.h
gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/home/benutzer/source/cod-tools/tryC-disorderfs/cod-tools-3.10.0+dfsg=. 
-fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
-Wall -Wsign-compare -g -O3 -funroll-loops -fomit-frame-pointer -foptimize-register-move 
-DYYDEBUG=1 -D_YACC_ -I. -I../../externals/cexceptions -I../../externals/getoptions -fPIC 
-DSVN_VERSION="\"10068\""  -Wl,-z,relro -Wl,-z,now -o cif_list_tags 
programs/cif_list_tags.c obj/cif2_grammar.tab.o obj/cif_grammar.tab.o lib/libcodcif.a 
../../externals/cexceptions/lib/libcexceptions.a ../../externals/getoptions/lib/libgetoptions.a 
version.h -lm
gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/home/benutzer/source/cod-tools/tryC-disorderfs/cod-tools-3.10.0+dfsg=. 
-fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
-Wall -Wsign-compare -g -O3 -funroll-loops -fomit-frame-pointer -foptimize-register-move 
-DYYDEBUG=1 -D_YACC_ -I. -I../../externals/cexceptions -I../../externals/getoptions -fPIC 
-DSVN_VERSION="\"10068\""  -Wl,-z,relro -Wl,-z,now -o cifparse 
programs/cifparse.c obj/cif2_grammar.tab.o obj/cif_grammar.tab.o lib/libcodcif.a 
../../externals/cexceptions/lib/libcexceptions.a ../../externals/getoptions/lib/libgetoptions

Bug#1079025: freerdp2: failing autopkgtests

[Bernhard Übelacker]

On Mon, 19 Aug 2024 07:10:13 +0200 Sebastian Ramacher  
wrote:

Source: freerdp2
Version: 2.11.7+dfsg1-2
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

https://ci.debian.net/packages/f/freerdp2/testing/amd64/49289917/

 58s autopkgtest [21:09:03]: test compare: [---
 58s + screenshot=xrdp-screenshot.png
 58s + magickout=match-matrix
 58s + dirname 
/tmp/autopkgtest-lxc.n8yozz_a/downtmp/build.bj0/src/debian/tests/compare
 58s + testdir=/tmp/autopkgtest-lxc.n8yozz_a/downtmp/build.bj0/src/debian/tests
 58s + sudo systemctl start xrdp
 58s + xvfb-run -l 
/tmp/autopkgtest-lxc.n8yozz_a/downtmp/build.bj0/src/debian/tests/connect-and-capture
 xrdp-screenshot.png
 58s /usr/bin/xvfb-run: 184: 
/tmp/autopkgtest-lxc.n8yozz_a/downtmp/build.bj0/src/debian/tests/connect-and-capture:
 Permission denied
 58s + compare -metric RMSE -subimage-search xrdp-screenshot.png 
/usr/share/xrdp/xrdp_logo.bmp png:match-matrix
 58s compare-im6.q16: unable to open image `xrdp-screenshot.png': No such file 
or directory @ error/blob.c/OpenBlob/2967.
 58s + grep -qi #FF
 58s + convert match-matrix-1 -threshold 95% txt:
 58s convert-im6.q16: unable to open image `match-matrix-1': No such file or 
directory @ error/blob.c/OpenBlob/2967.
 58s convert-im6.q16: no decode delegate for this image format `' @ 
error/constitute.c/ReadImage/581.
 58s convert-im6.q16: no images defined `txt:' @ 
error/convert.c/ConvertImageCommand/3234.
 58s + printf %s\n Imagemagick did not find any occurence of the XRDP logo 
inside the screenshot of the remote desktop. This test therefore failed.
 58s + exit 2
 58s Imagemagick did not find any occurence of the XRDP
 58s logo inside the screenshot of the remote desktop.
 58s This test therefore failed.
 59s autopkgtest [21:09:04]: test compare: ---]
 59s compare  FAIL non-zero exit status 2

The change in -2 not enough to fix the failure.

Cheers
--
Sebastian Ramacher





Dear Maintainer,
I tried to have a look and I think there are multiple issues here.

One is the connect-and-capture file is missing the execute bit,
therefore the error "Permission denied".

Second I received a interactive question "Do you trust the above certificate? 
(Y/T/N)".
This can be avoided by the "/cert-tofu" parameter.

Third the compare does not find the logo in the screenshot of the login screen.
I could convince imagemagick to find it by resizeing the search logo to 50%.

And the fourth issue is the size of the screenshot makes the search taking 
quite long.
To get the screenshot size down the screen size could be given to the
xvfb-run command (xvfb-run --server-args=-screen 0 640x480x24).
Or another imagemagick call can automatically remove the border (the "mogrify" 
call below).

With following modifications I think the autopkgtest should be able pass.

Kind regards,
Bernhard


diff --git a/debian/tests/compare b/debian/tests/compare
index 9db5cd6..5dd3d31 100644
--- a/debian/tests/compare
+++ b/debian/tests/compare
@@ -12,6 +12,13 @@ sudo systemctl start xrdp
 # login screen.
 xvfb-run -l "$testdir/connect-and-capture" "$screenshot"
 
+# Try to remove the background to leave just the login window in the image

+cp -a "$screenshot" "${screenshot}.before.mogrify.png"
+mogrify -fuzz 4% -define trim:percent-background=0% -trim +repage -format png 
"$screenshot"
+
+# Resize the search image to match nearly the really displayed size
+convert -resize 50% /usr/share/xrdp/xrdp_logo.bmp xrdp_logo_50percent.png
+
 # Confirm that the XRDP logo is in the log in screen (so as to confirm that the
 # login screen is really there).
 # 
https://stackoverflow.com/questions/31867093/how-to-search-an-image-for-subimages-using-linux-console
@@ -21,7 +28,7 @@ xvfb-run -l "$testdir/connect-and-capture" "$screenshot"
 # will fail but we don't need to check that specifically, because so
 # will the if below.
 compare -metric RMSE -subimage-search \
-  "$screenshot" /usr/share/xrdp/xrdp_logo.bmp png:"$magickout"
+  "$screenshot" xrdp_logo_50percent.png png:"$magickout"
 # In case of match, output will be like
 # "520,347: (255,255,255)  #FF  gray(255)"
 # in which the first field is the coordinates of the match.
diff --git a/debian/tests/connect-and-capture b/debian/tests/connect-and-capture
old mode 100644
new mode 100755
index 9700676..5b98fd7
--- a/debian/tests/connect-and-capture
+++ b/debian/tests/connect-and-capture
@@ -1,4 +1,4 @@
 #!/bin/sh
-xfreerdp /f /v:localhost:3389 /p: /u: /d: &
+xfreerdp /f /v:localhost:3389 /p: /u: /d: /cert-tofu &
 sleep 12
 import -window root "$1"

Bug#1079572: libfabric ftbfs on i386

[Bernhard Übelacker]

On Sat, 24 Aug 2024 21:05:54 +0200 Matthias Klose  wrote:

Package: src:libfabric
Version: 1.17.0-3
Severity: serious
Tags: sid trixie

libfabric ftbfs at least on i386, there might be more follow-up errors:

[...]


prov/hook/src/hook_domain.c:124:54: error: passing argument 2 of 
‘domain->base_ops_flow_ctrl->set_send_handler’ from incompatible pointer 
type [-Wincompatible-pointer-types]
   124 | 
hook_credit_handler);
   | 
^~~



Dear Maintainer,
this seems to be reported upstream in [1] and [2].
The first one got fixed in [3], but the other seems unresolved.

Kind regards,
Bernhard


[1] https://github.com/ofiwg/libfabric/issues/7860
[2] https://github.com/ofiwg/libfabric/issues/9763
[3] 
https://github.com/ofiwg/libfabric/commit/cd607326318534eca4763f29882ada90c5935799

Bug#1079588: mandos-client postrm purge can mysteriously fail

[Bernhard Übelacker]

On Sun, 25 Aug 2024 00:16:33 +0200 Ben Hutchings  wrote:

Package: mandos-client
Version: 1.8.16-1
Severity: serious

mandos-client's postrm script can fail on purge with no obvious error
message.  dpkg reports that it exited with error code 128 but it's not
clear why.  I can reproduce this in a bookworm/amd64 or unstable/amd64
build chroot by running:

apt install -y mandos-client linux-image-amd64
apt purge -y mandos-client

Ben.




Dear Maintainer,
I just tried to get some more info about this.

By adding a "set -x" at the top of the postrm script I could watch
which commands get executed [2].
At the end it looks like the output of the earlier update-initramfs
gets into stdin of the db_purge call later.

At least when redirecting stdout to stderr [1] of the update-initramfs call
the removal completes without error.

Kind regards,
Bernhard




[1]
--- orig/mandos-client.postrm   2024-04-22 21:13:43.0 +0200
+++ redirect/mandos-client.postrm   2024-09-11 09:10:06.222806231 +0200
@@ -34,3 +34,3 @@ update_initramfs()
 if command -v update-initramfs >/dev/null; then
-   update-initramfs -k all -u
+   update-initramfs -k all -u 1>&2
 elif command -v dracut >/dev/null; then
EOF




[2]
root@debian:~# LANG=C apt purge -y mandos-client
The following packages were automatically installed and are no longer required:
  cryptsetup  cryptsetup-initramfs  libavahi-common-data  libavahi-common3  
libavahi-core7  libgpgme11t64  libnl-3-200  libnl-route-3-200  ssh
Use 'apt autoremove' to remove them.

REMOVING:
  mandos-client*

Summary:
  Upgrading: 0, Installing: 0, Removing: 1, Not Upgrading: 0
  Freed space: 577 kB

(Reading database ... 38713 files and directories currently installed.)
Removing mandos-client (1.8.16-1.2) ...
+ set -e
+ update_initramfs
+ command -v update-initramfs
+ update-initramfs -k all -u
update-initramfs: Generating /boot/initrd.img-6.10.6-amd64
+ [ remove = purge ]
+ exit 0
(Reading database ... 38657 files and directories currently installed.)
Purging configuration files for mandos-client (1.8.16-1.2) ...
+ set -e
+ shred --remove /etc/keys/mandos/seckey.txt
+ rm --force /etc/mandos/plugin-runner.conf /etc/keys/mandos/pubkey.txt 
/etc/keys/mandos/seckey.txt /etc/keys/mandos/tls-privkey.pem 
/etc/keys/mandos/tls-pubkey.pem /etc/keys/mandos/dhparams.pem
+ update_initramfs
+ command -v update-initramfs
+ update-initramfs -k all -u
update-initramfs: Generating /boot/initrd.img-6.10.6-amd64
+ [ purge = purge ]
+ [ -e /usr/share/debconf/confmodule ]
+ . /usr/share/debconf/confmodule
+ [ !  ]
+ PERL_DL_NONLAZY=1
+ export PERL_DL_NONLAZY
+ [  ]
+ exec /usr/share/debconf/frontend /var/lib/dpkg/info/mandos-client.postrm purge
+ set -e
+ shred --remove /etc/keys/mandos/seckey.txt
+ :
+ rm --force /etc/mandos/plugin-runner.conf /etc/keys/mandos/pubkey.txt 
/etc/keys/mandos/seckey.txt /etc/keys/mandos/tls-privkey.pem 
/etc/keys/mandos/tls-pubkey.pem /etc/keys/mandos/dhparams.pem
+ update_initramfs
+ command -v update-initramfs
+ update-initramfs -k all -u
+ [ purge = purge ]
+ [ -e /usr/share/debconf/confmodule ]
+ . /usr/share/debconf/confmodule
+ [ ! 1 ]
+ [ -z  ]
+ exec
+ [  ]
+ exec
+ DEBCONF_REDIR=1
+ export DEBCONF_REDIR
+ db_purge
+ _db_cmd PURGE
+ _db_internal_IFS=

+ IFS=
+ printf %s\n PURGE
+ IFS=

+ read -r _db_internal_line
+ IFS=

+ RET=20 Unsupported command "update-initramfs:" (full line was "update-initramfs: 
Generating /boot/initrd.img-6.10.6-amd64") received from confmodule.
+ return 20
dpkg: error processing package mandos-client (--purge):
 installed mandos-client package post-removal script subprocess returned error 
exit status 128
Errors were encountered while processing:
 mandos-client
Error: Sub-process /usr/bin/dpkg returned an error code (1)
root@debian:~#

Bug#1076933: win32-loader: FTBFS: Error: Can't find IDC_LIST1 (1016) in the custom UI!

[Bernhard Übelacker]

Control: tag + upstream fixed-upstream

Another short addition:
A patch got discussed and commited upstream:

https://sourceware.org/pipermail/binutils/2024-August/136268.html
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=8c1cd8603443ffeee6e9cc97b738527ea1e2b3e5

Bug#1077047: numba: FTBFS when running tests: Fatal Python error: Segmentation fault [arm64, mips64el]

[Bernhard Übelacker]

The package fails to build from source on arm64 and mips64el with
multiple test failures that look similar at first glance. For example,
on arm64:

Fatal Python error: Segmentation fault




Hello,
I tried to collect some more information.

I could just follow that far as a bogus pointer
gets written in NRT_MemInfo_new_varsize_dtor,
which gets later called in nrt_varsize_dtor.

Unfortunately I cannot see where this value originates from.
Below an example debugging session, after a failing build on arm64 hardware.
In below example the bogus pointer has a value of 0xf9000be0d10083ff.

Kind regards,
Bernhard




benutzer@chroot-13-trixie-arm64:~/source/numba/try1/numba-0.59.1+dfsg$ gdb -q 
--args python3.12
Reading symbols from python3.12...
Reading symbols from 
/usr/lib/debug/.build-id/d9/3d40f59d70863566375339beb0f380251a6436.debug...
(gdb) directory /home/benutzer/source/numba/try1/numba-0.59.1+dfsg
Source directories searched: 
/home/benutzer/source/numba/try1/numba-0.59.1+dfsg:$cdir:$cwd
(gdb) set width 0
(gdb) set pagination off
(gdb) set environment 
PYTHONPATH=/home/benutzer/source/numba/try1/numba-0.59.1+dfsg/debian/python3-numba/usr/lib/python3.12/dist-packages:/home/benutzer/source/numba/try1/numba-0.59.1+dfsg/.pybuild/cpython3_3.12_numba/build
(gdb) set environment NUMBA_DEBUGINFO=1
(gdb) set environment NUMBA_OPT=0
(gdb) b nrt.cpp:177
No source file named nrt.cpp.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (nrt.cpp:177) pending.
(gdb) b nrt_varsize_dtor
Function "nrt_varsize_dtor" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (nrt_varsize_dtor) pending.
(gdb) run numba/tests/test_array_iterators.py
Starting program: /usr/bin/python3.12 numba/tests/test_array_iterators.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".

Breakpoint 1.4, NRT_MemInfo_init (mi=0x2056870, data=0x18d2510, size=0, 
dtor=0xf5901f28 , dtor_info=0xe93ae7f0, 
external_allocator=0x0) at numba/core/runtime/nrt.cpp:177
177 if (TheMSys.stats.enabled)
(gdb) disa 1.1
(gdb) disa 1.2
(gdb) disa 1.3
(gdb) disa 1.4
(gdb) disa 1.5
(gdb) disa 1.6
(gdb) disa 1.7
(gdb) disa 1.9
(gdb) disa 1.10
(gdb) disa 1.11
(gdb) disa 1.12
(gdb) ignore 1 1
Will ignore next crossing of breakpoint 1.
(gdb) ignore 2 1
Will ignore next crossing of breakpoint 2.
(gdb) cont
Continuing.
..
Breakpoint 1.8, NRT_MemInfo_init (mi=0x29cdbd0, data=0x29bfd90, size=24, 
dtor=, dtor_info=0x0, external_allocator=0x0) at 
numba/core/runtime/nrt.cpp:177
177 if (TheMSys.stats.enabled)
(gdb) print mi
$1 = (NRT_MemInfo *) 0x29cdbd0
(gdb) print *mi
$2 = {refct = std::atomic = { 1 }, dtor = 0xf5903580 
, dtor_info = 0x0, data = 0x29bfd90, size = 
24, external_allocator = 0x0}
(gdb) print &mi->dtor_info
$3 = (void **) 0x29cdbe0
(gdb) watch *(void **) 0x29cdbe0
Hardware watchpoint 3: *(void **) 0x29cdbe0
(gdb) display *(NRT_MemInfo *) 0x29cdbd0
1: *(NRT_MemInfo *) 0x29cdbd0 = {refct = std::atomic = { 1 }, dtor = 
0xf5903580 , dtor_info = 0x0, data = 
0x29bfd90, size = 24, external_allocator = 0x0}
(gdb) cont
Continuing.

Hardware watchpoint 3: *(void **) 0x29cdbe0

Old value = (void *) 0x0
New value = (void *) 0xf9000be0d10083ff
NRT_MemInfo_new_varsize_dtor (size=24, dtor=0xf9000be0d10083ff) at 
numba/core/runtime/nrt.cpp:472
472 return mi;
1: *(NRT_MemInfo *) 0x29cdbd0 = {refct = std::atomic = { 1 }, dtor = 
0xf5903580 , dtor_info = 
0xf9000be0d10083ff, data = 0x29bfd90, size = 24, external_allocator = 0x0}
(gdb) bt 6
#0  NRT_MemInfo_new_varsize_dtor (size=24, dtor=0xf9000be0d10083ff) at 
numba/core/runtime/nrt.cpp:472
#1  0xf6dbd0f0 in 
numba::cpython::listobj::list_constructor::_3clocals_3e::list_impl[abi:v39][abi:c8tJTC_2fWQI8IW1CiAAYKPM6RBFDjESZRVAJmaQIA](iter_28array_28int64_2c_201d_2c_20A_29_29)
 () at listobj.py:469
#2  0xf6db91f4 in 
__main__::array_iter_items[abi:v38][abi:c8tJTC_2fWwGaMLShh6CjAIxrKR0t9qKIYaQ0qDQwmMEsTAA_3d_3d](Array) (arr=...) at test_array_iterators.py:18
#3  0xf6db9540 in 
cpython::__main__::array_iter_items[abi:v38][abi:c8tJTC_2fWwGaMLShh6CjAIxrKR0t9qKIYaQ0qDQwmMEsTAA_3d_3d](Array) ()
#4  0xeb133e20 in call_cfunc (self=0xf6db9380 
)>, locals=, cfunc=, args=, kws=) at 
numba/_dispatcher.cpp:745
#5  Dispatcher_call (self=self@entry=0xe7e9d090, 
args=args@entry=(,), kws=kws@entry=0x0) 
at numba/_dispatcher.cpp:1037
(More stack frames follow...)
(gdb) up
#1  0xf6dbd0f0 in 
numba::cpython::listobj::list_constructor::_3clocals_3e::list_impl[abi:v39][abi:c8tJTC_2fWQI8IW1CiAAYKPM6RBFDjESZRVAJmaQIA](iter_28array_28int64_2c_201d_2c_20A_29_29)
 () at listobj.py:469
469 res = []
(gdb) list
464
465 @lower_builtin(list, types.IterableType)
466 def list_constructor(context, builder, sig, args):
467
468 def list_impl(iterable):
469 res = []
470 res.extend(it

Bug#1076933: win32-loader: FTBFS: Error: Can't find IDC_LIST1 (1016) in the custom UI!

[Bernhard Übelacker]

But I am not completely sure if the generated instdlg.o
is valid and expected, and nsis needs to be able to handle it.
Or GNU assembler should really generate object files in the old layout?



Just a short addition:

If GNU assembler and nsis is found to be working as expected
and there exists no other notation to create wide strings,
attached patch might be to considered for win32-loader,
which avoids the irpc by embedding the null bytes manually
in the ascii strings to mimic a wide string.

Kind regards,
Bernhard--- helpers/instdlg/instdlg.s.orig	2024-08-12 00:07:12.0 +0200
+++ helpers/instdlg/instdlg.s	2024-08-12 00:23:11.0 +0200
@@ -50,13 +50,6 @@ _WinMainCRTStartup:
 .set	WS_VISIBLE,		0x1000
 .set	WS_CHILD,		0x4000
 
-.macro WIDESTRING String
-.irpcCharacter,"\String"
-.asciz  "\Character"
-.endr
-.short 	0
-.endm
-
 .macro	IMAGE_RESOURCE_DIRECTORY Characteristics=0, TimeDateStamp=0, MajorVersion=0, MinorVersion=0, NumberOfNamedEntries=0, NumberOfIdEntries=0
 .long	\Characteristics
 .long	\TimeDateStamp
@@ -78,7 +71,7 @@ _WinMainCRTStartup:
 .long	\Reserved
 .endm
 
-.macro	DLGTEMPLATEEX_WITH_FONT dlgVer=1, signature=0x, helpID=0, exStyle=0, style=0, cDlgItems=0, x=0, y=0, cx=0, cy=0, menu=0, windowClass=0, title="", pointsize=0, weight=0, italic=0, charset=0, typeface=""
+.macro	DLGTEMPLATEEX_WITH_FONT dlgVer=1, signature=0x, helpID=0, exStyle=0, style=0, cDlgItems=0, x=0, y=0, cx=0, cy=0, menu=0, windowClass=0, title="\0", pointsize=0, weight=0, italic=0, charset=0, typeface="\0"
 .short	\dlgVer
 .short	\signature
 .long	\helpID
@@ -91,15 +84,15 @@ _WinMainCRTStartup:
 .short	\cy
 .short	\menu
 .short	\windowClass
-WIDESTRING "\title"
+.asciz	"\title"
 .short	\pointsize
 .short	\weight
 .byte	\italic
 .byte	\charset
-WIDESTRING "\typeface"
+.asciz	"\typeface"
 .endm
 
-.macro	DLGITEMTEMPLATEEX helpID=0, exStyle=0, style=0, x=0, y=0, cx=0, cy=0, id=0, windowClass=0, title="", extraCount=0
+.macro	DLGITEMTEMPLATEEX helpID=0, exStyle=0, style=0, x=0, y=0, cx=0, cy=0, id=0, windowClass=0, title="\0", extraCount=0
 .long	\helpID
 .long	\exStyle
 .long	\style
@@ -110,11 +103,11 @@ WIDESTRING "\typeface"
 .long	\id
 .short	0x
 .short	\windowClass
-WIDESTRING "\title"
+.asciz	"\title"
 .short	\extraCount
 .endm
 
-.macro	DLGITEMTEMPLATEEX_SZCLASS helpID=0, exStyle=0, style=0, x=0, y=0, cx=0, cy=0, id=0, windowClass="", title="", extraCount=0
+.macro	DLGITEMTEMPLATEEX_SZCLASS helpID=0, exStyle=0, style=0, x=0, y=0, cx=0, cy=0, id=0, windowClass="\0", title="\0", extraCount=0
 .long	\helpID
 .long	\exStyle
 .long	\style
@@ -123,17 +116,19 @@ WIDESTRING "\title"
 .short	\cx
 .short	\cy
 .long	\id
-WIDESTRING "\windowClass"
-WIDESTRING "\title"
+.asciz	"\windowClass"
+.asciz	"\title"
 .short	\extraCount
 .endm
 
-.macro	DLGITEMTEMPLATEEX_PROGRESSBAR helpID=0, exStyle=0, style=0, x=0, y=0, cx=0, cy=0, id=0, title="", extraCount=0
-DLGITEMTEMPLATEEX_SZCLASS helpID=\helpID, exStyle=\exStyle, style=\style, x=\x, y=\y, cx=\cx, cy=\cy, id=\id, windowClass="MSCTLS_PROGRESS32", title=\title, extraCount=\extraCount
+.macro	DLGITEMTEMPLATEEX_PROGRESSBAR helpID=0, exStyle=0, style=0, x=0, y=0, cx=0, cy=0, id=0, title="\0", extraCount=0
+DLGITEMTEMPLATEEX_SZCLASS helpID=\helpID, exStyle=\exStyle, style=\style, x=\x, y=\y, cx=\cx, cy=\cy, id=\id, windowClass="M\0S\0C\0T\0L\0S\0_\0P\0R\0O\0G\0R\0E\0S\0S\0\x33\0\x32\0\0", title=\title, extraCount=\extraCount
+/*windowClass="MSCTLS_PROGRESS32"*/
 .endm
 
-.macro	DLGITEMTEMPLATEEX_LISTVIEW helpID=0, exStyle=0, style=0, x=0, y=0, cx=0, cy=0, id=0, title="", extraCount=0
-DLGITEMTEMPLATEEX_SZCLASS helpID=\helpID, exStyle=\exStyle, style=\style, x=\x, y=\y, cx=\cx, cy=\cy, id=\id, windowClass="SYSLISTVIEW32", title=\title, extraCount=\extraCount
+.macro	DLGITEMTEMPLATEEX_LISTVIEW helpID=0, exStyle=0, style=0, x=0, y=0, cx=0, cy=0, id=0, title="\0", extraCount=0
+DLGITEMTEMPLATEEX_SZCLASS helpID=\helpID, exStyle=\exStyle, style=\style, x=\x, y=\y, cx=\cx, cy=\cy, id=\id, windowClass="S\0Y\0S\0L\0I\0S\0T\0V\0I\0E\0W\0\x33\0\x32\0\0", title=\title, extraCount=\extraCount
+/*windowClass="SYSLISTVIEW32"*/
 .endm
 
 .section .rsrc
@@ -158,7 +153,8 @@ rsrc_dialog_content:
 
 .align 4, 0
 rsrc_dialog_data:
-	DLGTEMPLATEEX_WITH_FONT style=(DS_FIXEDSYS|DS_SETFONT|DS_CONTROL|WS_CHILD), cDlgItems=6, x=0, y=0, cx=300, cy=140, pointsize=8, charset=1, typeface="MS Shell Dlg"
+	DLGTEMPLATEEX_WITH_FONT style=(DS_FIXEDSYS|DS_SETFONT|DS_CONTROL|WS_CHILD), cDlgItems=6, x=0, y=0, cx=300, cy=140, pointsize=8, charset=1, typeface="M\0S\0 \0S\0h\0e\0l\0l\0 \0D\0l\0g\0\0"
+	 /*typeface="MS Shell Dlg"*/
 rsrc_dialog_ite

Bug#1076933: win32-loader: FTBFS: Error: Can't find IDC_LIST1 (1016) in the custom UI!

[Bernhard Übelacker]

On Wed, 24 Jul 2024 12:50:23 +0200 Santiago Vila  wrote:

Package: src:win32-loader
Version: 0.10.6
Severity: serious
Tags: ftbfs



During a rebuild of all packages in unstable, your package failed to build:



i686-w64-mingw32-as --defsym IMAGE_BASE=0x40 -march=i486  -o instdlg.o 
/<>/helpers/instdlg/instdlg.s
/<>/helpers/instdlg/instdlg.s: Assembler messages:
/<>/helpers/instdlg/instdlg.s:161: Warning: end of file in string; 
'"' inserted
/<>/helpers/instdlg/instdlg.s:94:   Info: macro invoked from here
/<>/helpers/instdlg/instdlg.s:161:Info: macro invoked from here



makensis -V3 "-XUnicode True" -DVERSION=0.10.6 -D4DIGITS_DATE=2022.03.21.2258 
-D_OUTFILE_NAME=build/win32-loader_0.10.6_all.exe -DBUILD_DIR=build -DNOCD=yes -DPXE=yes -DNOCD=yes 
-DOPTIONS_TXT="+net +pxe" main.nsi
MakeNSIS v3.10-2 - Copyright 1999-2023 Contributors
See the file COPYING for license details.
Credits can be found in the Users Manual.

Command line defined: "VERSION=0.10.6"
Command line defined: "4DIGITS_DATE=2022.03.21.2258"
Command line defined: "_OUTFILE_NAME=build/win32-loader_0.10.6_all.exe"
Command line defined: "BUILD_DIR=build"
Command line defined: "NOCD=yes"
Command line defined: "PXE=yes"
Command line defined: "NOCD=yes"
Command line defined: "OPTIONS_TXT=+net +pxe"
Processing config: /etc/nsisconf.nsh
Processing script file: "main.nsi" (UTF8)
Error: Can't find IDC_LIST1 (1016) in the custom UI!
!include: error in script: "download.nsi" on line 42
Error in script "main.nsi" on line 127 -- aborting creation process





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

It looks like makensis is failing to manipulate
an executable build/helpers/instdlg/instdlg.exe.
This seems to happen because the layout/content
of instdlg.o is different than expected.
The object instdlg.o get generated from helpers/instdlg/instdlg.s.

It starts to get visible since binutils-mingw-w64-i686
migrated into Trixie/testing at 2024-07-08.

I did a git-bisect of sourceware.org/git/binutils-gdb.git and
found below commit [1] to be the first which shows this different behaviour.

The file instdlg.s also uses nested macros with string parameters [3].
This looks like it should generate UTF16 wide strings in the object file.
And since the new gas version there are plenty of warnings related to it 
visible.

The layout of the generated binary instdlg.o is with the new version
different [2], and I assume therefore nsis is failing.


But I am not completely sure if the generated instdlg.o
is valid and expected, and nsis needs to be able to handle it.
Or GNU assembler should really generate object files in the old layout?


I hope it is ok to CC Jan as author of the commit in GNU assembler.

Kind regards,
Bernhard



[1]
69cab370cf666f2e7692158ac7dffc6a65207f4a is the first broken commit
commit 69cab370cf666f2e7692158ac7dffc6a65207f4a
Author: Jan Beulich 
Date:   Fri May 24 12:22:54 2024 +0200

gas: adjust handling of quotes for .irpc

The present handling of inner double quotes can lead to very strange

diagnostics. Follow one of the two possible interpretations of the doc:
@dots{} referring to possibly multiple white space separated
@var{values}, each of which may be quoted. The original implementation,
prior to 465e5617233f ("PR gas/3856"), hints at the other possible
interpretation: When quoted there's only a single @var{values}, with
inner quotes taken as ordinary characters. That, however, seems overall
less useful to me.

While touching the documentation, mirror the (inverse) spelling

correction (@section line inconsistent with actual description) to .irp
as well.

 gas/doc/as.texi   | 15 ---
 gas/macro.c   | 20 ++--
 gas/testsuite/gas/macros/irpc-quote.l | 18 ++
 gas/testsuite/gas/macros/irpc-quote.s |  6 ++
 gas/testsuite/gas/macros/macros.exp   |  2 ++
 5 files changed, 40 insertions(+), 21 deletions(-)
 create mode 100644 gas/testsuite/gas/macros/irpc-quote.l
 create mode 100644 gas/testsuite/gas/macros/irpc-quote.s


[2]
build/helpers/instdlg/instdlg.o
2.42-4+11.5   | 
2.42.50.20240625-1+11.6
0120  48 04 00 40 06 00 00 00  00 00 2c 01 8c 00 00 00  |H..@..,.|| 
48 04 00 40 06 00 00 00  00 00 2c 01 8c 00 00 00  |H..@..,.|
0130  00 00 00 00 08 00 00 00  00 01 4d 00 53 00 20 00  |..M.S. .|| 00 00 0a 
00 00 00 08 00  00 00 00 01 4d 00 53 00  |M.S.| <<<
0140  53 00 68 00 65 00 6c 00  6c 00 20 00 44 00 6c 00  |S.h.e.l.l. .D.l.|| 
20 00 53 00 68 00 65 00  6c 00 6c 00 20 00 44 00  | .S.h.e.l.l. .D.|
0150  67 00 00 00 00 00 00 00  00 00 00 00 00 00 01 50  |g..P|| 
6c 00 67 00 00 00 00 00  00 00 00 00 00 00 00 00  |l.g.|
0160  01 00 1a 00 3c 00 0e 00  03 04 00 00 ff ff 80 00  |<...|| 01 
50 01 00 1a 00 3c 00  0e 00 03 04 00 00 ff f

Bug#1040375: /usr/lib/x86_64-linux-gnu/simplescreenrecorder/libssr-glinject.so: Segmentation fault when used with anything

[Bernhard Übelacker]

On Sat, 10 Feb 2024 11:01:54 +0100 Petter Reinholdtsen  wrote:

[Petter Reinholdtsen]
> I do not use ssr much myself, and have not had time to test.

I applied the upstream commit in git branch fix-1040375-glinject and
tested it on Bookworm, but alas, the .so file still segfaults with a
useless backtrace.  I might have applied the commit incorrectly, as it
did not apply without changes, but hope not.  Perhaps someone
who understand what is happening can have a look?

--
Happy hacking
Petter Reinholdtsen




Hello,
looking through some bugs about crashes I came to this one
and found found it interesting.

If a proper backtrace is still helping one can get one by using
systemd-coredump.

Another nice way to debug early startup is using rr debugger.
(Plus the ability to debug back and forth.)


As far as I see the crash happens because it wants to print this message:

57  GLINJECT_PRINT("Error: Can't open libdl.so!");

But unfortunately libstdc++ seems not yet prepared to output the error.


(rr) bt
#0  0x7fbf7ff2fd9a in std::basic_ostream 
>::sentry::sentry(std::basic_ostream >&) () from 
/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x7fbf7ff3074c in std::basic_ostream >& std::__ostream_insert >(std::basic_ostream >&, char const*, long) () 
from /lib/x86_64-linux-gnu/libstdc++.so.6
#2  0x7fbf7ff30bdb in std::basic_ostream >& std::operator<< 
 >(std::basic_ostream >&, char const*) () from 
/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x7fbf805cef6f in InitGLInject () at ./glinject/Hook.cpp:57
#4  0x7fbf805cf13f in dlsym (handle=0x7fbf8060d2e0, symbol=0x7fbf80185f7a 
"pthread_create") at ./glinject/Hook.cpp:231
#5  0x7fbf80136dd7 in glvndSetupPthreads () at 
../src/util/glvnd_pthread.c:452
#6  0x7fbf801351a9 in __glDispatchOnLoadInit () at 
../src/GLdispatch/GLdispatch.c:174
#7  0x7fbf805de9ce in call_init (env=0x7ffeea4b1538, argv=0x7ffeea4b1528, argc=1, 
l=) at ./elf/dl-init.c:74
#8  call_init (l=, argc=1, argv=0x7ffeea4b1528, 
env=0x7ffeea4b1538) at ./elf/dl-init.c:26
#9  0x7fbf805deab4 in _dl_init (main_map=0x7fbf8060d2e0, argc=1, 
argv=0x7ffeea4b1528, env=0x7ffeea4b1538) at ./elf/dl-init.c:121
#10 0x7fbf805f4a70 in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#11 0x0001 in ?? ()
#12 0x7ffeea4b25ea in ?? ()
#13 0x in ?? ()
(rr)

(For some reason with libstdc++6-dbgsym the backtrace gets less good.)



I guess upstream discussed this issue here:

  https://github.com/MaartenBaert/ssr/issues/947


And a package built from `fix-1040375-glinject` did no
longer show this crash to me.


Attached file shows my actions inside a minimal bookworm VM.

Kind regards,
Bernhard
# 2024-05-07 Bookworm/stable amd64 qemu VM

apt update
apt dist-upgrade
apt install systemd-coredump mc gdb rr mesa-utils git simplescreenrecorder-lib 
simplescreenrecorder-lib-dbgsym libglvnd0-dbgsym libstdc++6-dbgsym appstream
apt build-dep simplescreenrecorder-lib






mkdir /home/benutzer/source/simplescreenrecorder/orig -p
cd/home/benutzer/source/simplescreenrecorder/orig
apt source simplescreenrecorder







benutzer@debian:~$ 
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/simplescreenrecorder/libssr-glinject.so 
/usr/bin/true
Speicherzugriffsfehler (Speicherabzug geschrieben)
benutzer@debian:~$ 


benutzer@debian:~$ coredumpctl list
Hint: You are currently not seeing messages from other users and the system.
  Users in groups 'adm', 'systemd-journal' can see all messages.
  Pass -q to turn off this notice.
TIME PID  UID  GID SIG COREFILE EXESIZE
Tue 2024-05-07 00:10:28 CEST 994 1000 1000 SIGSEGV present  /usr/bin/true 89.0K
benutzer@debian:~$ 



benutzer@debian:~$ coredumpctl gdb --debugger-argument=-q 994
Hint: You are currently not seeing messages from other users and the system.
  Users in groups 'adm', 'systemd-journal' can see all messages.
  Pass -q to turn off this notice.
   PID: 994 (true)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 11 (SEGV)
 Timestamp: Tue 2024-05-07 00:10:28 CEST (1min 26s ago)
  Command Line: /usr/bin/true
Executable: /usr/bin/true
 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: 4df23299079540e38e42560b3966b576
Machine ID: 55a5ad9df1d547f38d7696343d9fde7d
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.true.1000.4df23299079540e38e42560b3966b576.994.171503342800.zst
 (present)
  Size on Disk: 89.0K
   Message: Process 994 (true) of user 1000 dumped core.

Stack trace of thread 994:
#0  0x7f988d92fd9a _ZNSo6sentryC1ERSo (libstdc++.so.6 + 
0x12fd9a)
#1  0x7f988d93074c 
_ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l 
(libstdc++.so.6 + 0x13074c)
 

Bug#1054661: blastem: Segfault when trying to open rom or access system settings

[Bernhard Übelacker]

On Sat, 28 Oct 2023 12:52:30 +0200 Tobias Frost  wrote:

Control: tags -1 confirmed

Here's a backtrace when clicking on Settings -> System. 
Thread 1 "blastem" received signal SIGSEGV, Segmentation fault.

tern_foreach_int (head=, fun=0x555c12a0 , 
data=0x7fffd7f0, keybuf=0x7fffd8c0 "\020", pos=0)
at /build/blastem-kipVNx/blastem-0.6.3.4/tern.c:268
268 if (!head->el) {
(gdb) bt
#0  tern_foreach_int (head=, fun=0x555c12a0 , 
data=0x7fffd7f0, keybuf=0x7fffd8c0 "\020", pos=0) at 
/build/blastem-kipVNx/blastem-0.6.3.4/tern.c:268
#1  0x555c7e15 in tern_foreach (data=0x7fffd7f0, fun=0x555c12a0 
, head=) at 
/build/blastem-kipVNx/blastem-0.6.3.4/tern.c:291
#2  get_models (num_out=0x557a8ba0 ) at 
nuklear_ui/blastem_nuklear.c:1873
#3  view_system_settings (context=0x55611ab8 ) at 
nuklear_ui/blastem_nuklear.c:1907
#4  0x555c8354 in blastem_nuklear_render () at 
nuklear_ui/blastem_nuklear.c:2049
#5  0x55589e1b in render_update_display () at 
/build/blastem-kipVNx/blastem-0.6.3.4/render_sdl.c:1783
#6  0x555caeeb in ui_idle_loop () at nuklear_ui/blastem_nuklear.c:2075
#7  0xdefa in blastem_nuklear_init (file_loaded=0 '\000') at 
nuklear_ui/blastem_nuklear.c:2332
#8  main (argc=, argv=) at 
/build/blastem-kipVNx/blastem-0.6.3.4/blastem.c:714
(gdb) 


Did not investigate further.



Hello,
tried to take a little deeper look.
And it seems it is just a missing packaged config file:


(rr)
0x55c0356f0361  1012return NULL;
1: x/i $pc
=> 0x55c0356f0361 :  xor%r13d,%r13d
10: /x $r13 = 0x0
(rr) bt
#0  0x55c0356f0361 in read_bundled_file (name=name@entry=0x55c03574ae4a 
"systems.cfg", sizeret=sizeret@entry=0x7ffc07889c88) at 
/build/blastem-kipVNx/blastem-0.6.3.4/util.c:1012
#1  0x55c0356f0a2d in parse_bundled_config (config_name=0x55c03574ae4a 
"systems.cfg") at /build/blastem-kipVNx/blastem-0.6.3.4/config.c:217
#2  0x55c03571ff56 in get_systems_config () at 
/build/blastem-kipVNx/blastem-0.6.3.4/config.c:331
#3  get_models (num_out=0x55c035900ba0 ) at 
nuklear_ui/blastem_nuklear.c:1866
#4  view_system_settings (context=0x55c035769ab8 ) at 
nuklear_ui/blastem_nuklear.c:1907
#5  0x55c035720354 in blastem_nuklear_render () at 
nuklear_ui/blastem_nuklear.c:2049
#6  0x55c0356e1e1b in render_update_display () at 
/build/blastem-kipVNx/blastem-0.6.3.4/render_sdl.c:1783
#7  0x55c035722eeb in ui_idle_loop () at nuklear_ui/blastem_nuklear.c:2075
#8  0x55c0356b5efa in blastem_nuklear_init (file_loaded=0 '\000') at 
nuklear_ui/blastem_nuklear.c:2332
#9  main (argc=, argv=) at 
/build/blastem-kipVNx/blastem-0.6.3.4/blastem.c:714


Function `read_bundled_file` does not find "systems.cfg",
therefore returns NULL,
therefore `parse_bundled_config` returns also NULL,
which is then also returned by `get_systems_config`.

This NULL is given unconditionally into tern_foreach in blasem_nuklear.c line 
1873,
and gets dereferenced.


Following change would add systems.cfg to the Debian package,
and did avoid the crash in a short test.

Kind regards,
Bernhard


diff -Nurp orig/blastem-0.6.3.4/debian/blastem.install 
try2/blastem-0.6.3.4/debian/blastem.install
--- orig/blastem-0.6.3.4/debian/blastem.install 2021-09-24 22:14:33.0 
+0200
+++ try2/blastem-0.6.3.4/debian/blastem.install 2024-05-06 14:31:55.277695226 
+0200
@@ -6,3 +6,4 @@ gamecontrollerdb.txtusr/share/games/bl
 images usr/share/games/blastem
 rom.db usr/share/games/blastem
 shadersusr/share/games/blastem
+systems.cfgusr/share/games/blastem

Bug#1064372: evolution: segfault during startup

[Bernhard Übelacker]

Hello,
just tried to extract the backtrace from the attached core dump.

Kind regards,
Bernhard


Core was generated by `/usr/bin/evolution'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x in ?? ()

(gdb) bt
#0  0x in ?? ()
#1  0x7f5ad98da8b6 in g_get_worker_context () at ../../../glib/gmain.c:6598
#2  0x7f5ad98dac0c in ref_unix_signal_handler_unlocked (signum=15) at 
../../../glib/gmain.c:5726
#3  _g_main_create_unix_signal_watch (signum=15) at ../../../glib/gmain.c:5834
#4  0x7f5ad992f8de in g_unix_signal_add_full (priority=priority@entry=0, 
signum=signum@entry=15, handler=handler@entry=0x556725eb22e0 
, user_data=user_data@entry=0x0, notify=notify@entry=0x0) 
at ../../../glib/glib-unix.c:231
#5  0x556725eb1b08 in main (argc=, argv=) at 
./src/shell/main.c:729
(gdb) up
#1  0x7f5ad98da8b6 in g_get_worker_context () at ../../../glib/gmain.c:6598
6598  pthread_sigmask (SIG_SETMASK, &all, &prev_mask);
(gdb)
# 2024-04-26 Trixie/testing amd64 qemu VM

apt update
apt dist-upgrade
apt install systemd-coredump wget zstd ncdu gdb evolution-dbgsym 
libglib2.0-0-dbgsym
apt build-dep glib2.0


mkdir /home/benutzer/source/glib2.0/orig -p
cd/home/benutzer/source/glib2.0/orig
apt source glib2.0


wget 
"https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1064372;filename=core.evolution.1000.1a4c16b6b1594876901650d63de977bc.12161.170846511800.zst;msg=5";
 -O 
core.evolution.1000.1a4c16b6b1594876901650d63de977bc.12161.170846511800.zst
unzstd --keep 
core.evolution.1000.1a4c16b6b1594876901650d63de977bc.12161.170846511800.zst


export DEBUGINFOD_URLS="https://debuginfod.debian.net";
echo "set debuginfod enabled on" >> .gdbinit

gdb -q --core 
core.evolution.1000.1a4c16b6b1594876901650d63de977bc.12161.170846511800 
/usr/bin/evolution

set width 0
set pagination off
directory /home/benutzer/source/glib2.0/orig/glib2.0-2.78.4/glib/tests/markups


Core was generated by `/usr/bin/evolution'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x in ?? ()
(gdb) set width 0
(gdb) set pagination off
(gdb) directory 
/home/benutzer/source/glib2.0/orig/glib2.0-2.78.4/glib/tests/markups
Source directories searched: 
/home/benutzer/source/glib2.0/orig/glib2.0-2.78.4/glib/tests/markups:$cdir:$cwd
(gdb) bt
#0  0x in ?? ()
#1  0x7f5ad98da8b6 in g_get_worker_context () at ../../../glib/gmain.c:6598
#2  0x7f5ad98dac0c in ref_unix_signal_handler_unlocked (signum=15) at 
../../../glib/gmain.c:5726
#3  _g_main_create_unix_signal_watch (signum=15) at ../../../glib/gmain.c:5834
#4  0x7f5ad992f8de in g_unix_signal_add_full (priority=priority@entry=0, 
signum=signum@entry=15, handler=handler@entry=0x556725eb22e0 
, user_data=user_data@entry=0x0, notify=notify@entry=0x0) 
at ../../../glib/glib-unix.c:231
#5  0x556725eb1b08 in main (argc=, argv=) at 
./src/shell/main.c:729
(gdb) up
#1  0x7f5ad98da8b6 in g_get_worker_context () at ../../../glib/gmain.c:6598
6598  pthread_sigmask (SIG_SETMASK, &all, &prev_mask);
(gdb)

Bug#1064613: vtun: Segmentation fault with default config

[Bernhard Übelacker]

On Sat, 24 Feb 2024 23:55:18 + =?utf-8?q?Lucas_L=C3=B3pez?= 
 wrote:

I copied the example server file /usr/share/doc/vtun/examples/vtund-server.conf 
into
/etc/vtund.conf and enabled server mode in /etc/default/vtun. When I start the 
service
with systemctl I get the following error on the dmesg log:

[343358.769324] vtund[3002]: segfault at 0 ip 5572cac05e34 sp 
7ffc9a47f610 error 4 in vtund[5572cabff000+b000] likely on CPU 0 (core 0, 
socket 0)
[343358.769342] Code: 24 10 e8 2f 96 ff ff 85 c0 0f 88 0d 01 00 00 48 8b 44 24 10 48 
89 44 24 08 48 85 c0 0f 84 f0 00 00 00 48 89 c3 90 48 8b 6b 18 <66> 44 39 7d 00 
0f 85 d1 00 00 00 48 8b 73 08 4c 89 ef e8 55 97 ff

I checked the config and the manual but I haven't been able to use the package 
due to the segfault.
BTW, the autogenerated systemd unit has the attributes RemainAfterExit=yes, 
SuccessExitStatus=5 6,
so even on failure the unit appears as "active (exited)". Hence it needs a 
"systemctl restart",
"systemctl start" won't do anything which is a bit counterintuitive.



Hello,
I am not the maintainer of vtun, just tried to find some more informations 
about the crash.
I was not able to reproduce it inside a minimal VM, but I think
from the dmesg lines it happened in netlib.c line 156.

This looks like ifa->ifa_addr is no valid pointer but gets dereferenced.
I guess it might be related to the network configuration of this specific host,
maybe containing an interface without having an address assigned.

Kind regards,
Bernhard


148 int getifaddr(struct sockaddr_storage *addr, char * ifname, sa_family_t 
af)
...
154
155  for (ifa = ifas; ifa; ifa = ifa->ifa_next) {
156 if( ifa->ifa_addr->sa_family != af ||
157strcmp(ifname, ifa->ifa_name) )

https://sources.debian.org/src/vtun/3.0.4-2/netlib.c/#L156
https://man7.org/linux/man-pages/man3/getifaddrs.3.html
# 2024-04-22 Trixie/testing amd64 qemu VM

apt update
apt install systemd-coredump mc htop gdb

# with unstable
apt install vtun vtun-dbgsym devscripts
apt build-dep vtun



mkdir /home/benutzer/source/vtun/orig -p
cd/home/benutzer/source/vtun/orig
dget 
https://snapshot.debian.org/archive/debian-debug/20191112T220504Z/pool/main/v/vtun/vtun_3.0.4-2.dsc
dpkg-source -x vtun_3.0.4-2.dsc


cp -a /usr/share/doc/vtun/examples/vtund-server.conf /etc/vtund.conf

cp -a /etc/default/vtun /etc/default/vtun.orig
sed -i 's/# RUN_SERVER=no/RUN_SERVER=yes/g' /etc/default/vtun


wget 
https://snapshot.debian.org/archive/debian/20220514T093947Z/pool/main/v/vtun/vtun_3.0.4-2%2Bb1_amd64.deb
wget 
https://snapshot.debian.org/archive/debian-debug/20220514T091215Z/pool/main/v/vtun/vtun-dbgsym_3.0.4-2%2Bb1_amd64.deb
dpkg -i *.deb

systemctl start vtun.service

-> Could not reproduce the crash




[343358.769324] vtund[3002]: segfault at 0 ip 5572cac05e34 sp 
7ffc9a47f610 error 4 in vtund[5572cabff000+b000] likely on CPU 0 (core 0, 
socket 0)
[343358.769342] Code: 24 10 e8 2f 96 ff ff 85 c0 0f 88 0d 01 00 00 48 8b 44 24 
10 48 89 44 24 08 48 85 c0 0f 84 f0 00 00 00 48 89 c3 90 48 8b 6b 18 <66> 44 39 
7d 00 0f 85 d1 00 00 00 48 8b 73 08 4c 89 ef e8 55 97 ff

# https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash

error 4
0b0100
 *   bit 0 ==0: no page found
 *   bit 1 ==0: read access
 *   bit 2 ==1: user-mode access

 
echo -n "find /b ..., ..., 0x" && \
echo "24 10 e8 2f 96 ff ff 85 c0 0f 88 0d 01 00 00 48 8b 44 24 10 48 89 44 24 
08 48 85 c0 0f 84 f0 00 00 00 48 89 c3 90 48 8b 6b 18 <66> 44 39 7d 00 0f 85 d1 
00 00 00 48 8b 73 08 4c 89 ef e8 55 97 ff" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'



gdb -q --pid $(pgrep vtund)
(gdb) pipe info target | grep -E ".text$"
0x55c1fbd0f7f0 - 0x55c1fbd19ba1 is .text
(gdb) find /b 0x55c1fbd0f7f0, 0x55c1fbd19ba1, 0x24, 0x10, 0xe8, 0x2f, 
0x96, 0xff, 0xff, 0x85, 0xc0, 0x0f, 0x88, 0x0d, 0x01, 0x00, 0x00, 0x48, 0x8b, 
0x44, 0x24, 0x10, 0x48, 0x89, 0x44, 0x24, 0x08, 0x48, 0x85, 0xc0, 0x0f, 0x84, 
0xf0, 0x00, 0x00, 0x00, 0x48, 0x89, 0xc3, 0x90, 0x48, 0x8b, 0x6b, 0x18, 0x66, 
0x44, 0x39, 0x7d, 0x00, 0x0f, 0x85, 0xd1, 0x00, 0x00, 0x00, 0x48, 0x8b, 0x73, 
0x08, 0x4c, 0x89, 0xef, 0xe8, 0x55, 0x97, 0xff
0x55c1fbd15e0a 
1 pattern found.
(gdb) b * (0x55c1fbd15e0a + 42)
Breakpoint 1 at 0x55c1fbd15e34: file ./netlib.c, line 156.
(gdb) info b
Num Type   Disp Enb AddressWhat
1   breakpoint keep y   0x55c1fbd15e34 in getifaddr at 
./netlib.c:156
(gdb) disassemble /r 0x55c1fbd15e0a, 0x55c1fbd15e0a + 62
Dump of assembler code from 0x55c1fbd15e0a to 0x55c1fbd15e48:
   0x55c1fbd15e0a :   24 10   and$0x10,%al
   0x55c1fbd15e0c :   e8 2f 96 ff ff  call   
0x55c1fbd0f440 
   0x55c1fbd15e11 :   85 c0   test   %eax,%eax
   0x55c1fbd15e13 :   0f 88 0d 01 00 00   js 
0x55c1fbd15f26 
   0x55c1fbd15e19 :   48 8b 44 24 10  mov
0x10(%rsp),%rax
   0x55c1fbd15e1e :   48 89 44 24 08 

Bug#1067691: FTBFS: double free or corruption

[Bernhard Übelacker]

Hello,
I found this one interesting and tried to reproduce it,
and hit this issue quite reliable with an unstable armel chroot,
inside an armhf unstable qemu VM,
or with a Android/LineageOS with real arm CPU.

Unfortunately valgrind is no longer built for armel, and a local armel rebuild
shows issues with latest "-fstack-protector-strong -fstack-clash-protection".

Finally I found this issue leads not to a crash at amd64, but
valgrind uncovers it there reliable [1].

dpkg-buildpackage with valgrind installed uses it automatically.
Therefore the change in [2] might be an improvement?


Increasing the allocation of the input buffer like in [3]
makes the valgrind errors go away.
Unfortunately I don't know what exact size this buffer is expected to have.

Kind regards,
Bernhard




[1]
...
fft const
==1105453== Invalid write of size 4
==1105453==at 0x60BFC25: ??? (in 
/usr/lib/x86_64-linux-gnu/libavutil.so.58.29.100)
==1105453==by 0x4CE1880: av_rdft_calc (in 
/usr/lib/x86_64-linux-gnu/libavcodec.so.60.31.102)
==1105453==by 0x11246F: FFTPlanImpl::execute() (spek-fft.cc:38)
==1105453==by 0x110A76: test_const() (test-fft.cc:21)
==1105453==by 0x1105F5: test_fft() (test-fft.cc:77)
==1105453==by 0x10BF5C: main (test.cc:11)
==1105453==  Address 0x11a828c4 is 4 bytes after a block of size 64 alloc'd
==1105453==at 0x4845DA0: memalign (in 
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1105453==by 0x4845F01: posix_memalign (in 
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1105453==by 0x608CC14: av_malloc (in 
/usr/lib/x86_64-linux-gnu/libavutil.so.58.29.100)
==1105453==by 0x1126A0: FFTPlan (spek-fft.h:29)
==1105453==by 0x1126A0: FFTPlanImpl::FFTPlanImpl(int) (spek-fft.cc:27)
==1105453==by 0x112745: FFT::create(int) (spek-fft.cc:24)
==1105453==by 0x1109AE: test_const() (test-fft.cc:13)
==1105453==by 0x1105F5: test_fft() (test-fft.cc:77)
==1105453==by 0x10BF5C: main (test.cc:11)
...


[2]
--- debian/control.orig 2023-01-11 07:25:51.0 +0100
+++ debian/control  2024-04-21 16:30:57.545576734 +0200
@@ -11,3 +11,4 @@ Build-Depends: debhelper-compat (= 13),
libwxgtk3.2-dev,
-   wx-common
+   wx-common,
+   valgrind-if-available
 Standards-Version: 4.6.2


[3]
--- src/spek-fft.h.orig 2023-01-10 05:00:39.0 +0100
+++ src/spek-fft.h  2024-04-21 16:28:07.0 +0200
@@ -28,3 +28,3 @@ public:
 // input data to be aligned by up to 32 bytes (e.g. AVX)
-this->input = (float*) av_malloc(sizeof(float) * input_size);
+this->input = (float*) av_malloc(sizeof(float) * (input_size + 2));
 }

Bug#1032510: packagekit: pkcon what-provides application/x-keepass2 makes PK crash

[Bernhard Übelacker]

On Wed, 08 Mar 2023 10:47:25 +0100 Laurent Bigonville  wrote:

$ pkcon what-provides application/x-keepass2
Getting provides[=]
Loading cache   [=]
Querying[=] e 
daemon crashed mid-transaction!
Finished[ ] (0%)

   Stack trace of thread 10447:
#0  0x7faf3ef75ccc __pthread_kill_implementation (libc.so.6 
+ 0x8accc)
#1  0x7faf3ef26ef2 __GI_raise (libc.so.6 + 0x3bef2)
#2  0x7faf3ef11472 __GI_abort (libc.so.6 + 0x26472)
#3  0x7faf3c89d919 
_ZN9__gnu_cxx27__verbose_terminate_handlerEv (libstdc++.so.6 + 0x9d919)
#4  0x7faf3c8a8e1a _ZN10__cxxabiv111__terminateEPFvvE 
(libstdc++.so.6 + 0xa8e1a)
#5  0x7faf3c8a8e85 _ZSt9terminatev (libstdc++.so.6 + 
0xa8e85)
#6  0x7faf3c8a90d8 __cxa_throw (libstdc++.so.6 + 0xa90d8)
#7  0x7faf3c8a00e4 _ZSt19__throw_logic_errorPKc 
(libstdc++.so.6 + 0xa00e4)
#8  0x7faf3e96cb3a 
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC4IS3_EEPKcRKS3_ 
(libpk_backend_apt.so + 0x2cb3a)
#9  0x7faf3e95d122 backend_what_provides_thread 
(libpk_backend_apt.so + 0x1d122)
#10 0x5644cb0c7aca pk_backend_job_thread_setup (packagekitd 
+ 0x23aca)
#11 0x7faf3f5dbcfd g_thread_proxy (libglib-2.0.so.0 + 
0x7ecfd)
#12 0x7faf3ef73fd4 start_thread (libc.so.6 + 0x88fd4)
#13 0x7faf3eff466c __clone3 (libc.so.6 + 0x10966c)



Hello Laurent,
I am just looking at some random crash reports.
Unfortunately I cannot reproduce the crash in a
current QEMU VM, neither minimal nor with a Gnome desktop.
I cannot even convince the pkcon processes to load the
library libpk_backend_apt.so.

Can you still reproduce it. And do you probably have
done some changes to the configuration?
It looks like the system wide packagekitd is contacted,
maybe that shows something in the journal.

Kind regards,
Bernhard

Bug#877106: pinta: Pinta 1.6-2 crashes on image scaling and other image manipulation.

[Bernhard Übelacker]

  at  <0x>
  at (wrapper managed-to-native) GLib.SList.g_free (intptr) <0x0005f>
  at GLib.ListBase.Empty () <0x0013c>
  at GLib.ListBase.Dispose (bool) <0xf>
  at GLib.ListBase.Finalize () <0x0001d>
  at (wrapper runtime-invoke) 
object.runtime_invoke_virtual_void__this__(object,intptr,intptr,intptr) 
<0x00068>





Dear Maintainer,
I took a look at the bug report [1] and guess this crash in Pinta
could be caused by the same error.

Therefore it might be interesting if this crash in Pinta could
also be fixed by rebuilding the gtk-sharp2 package with
the upstream patch [2] applied?





[1] https://bugs.debian.org/1028220
[2] 
https://github.com/mono/gtk-sharp/commit/72637de6f2e519592f946a5acdf29a334c7bff75

Bug#1027952: pcre2 causes crashes in link-grammar

[Bernhard Übelacker]

Dear Maintainer,
I tried to reproduce this segfault.
Unfortunately this did not work as expected.
The segfault in multi-thread did not show up.
But I received one in multi-dict (in e.g. 3 of 6 runs).

This was done in a up-to-date unstable amd64 VM,
running at a AMD cpu, 16 threads given to the VM.

The segfault did manifest in each case in libhunspell.
This seems to be caused by the static variable "utf_tbl"
possibly being shared between threads, and being freed and
initialized while maybe used in another thread.

Kind regards,
Bernhard


(gdb) bt
#0  0x7f56b5b3159b in unicodetolower(unsigned short, int) () from 
/lib/x86_64-linux-gnu/libhunspell-1.7.so.0
#1  0x7f56b5b317ae in get_captype_utf8(std::vector 
> const&, int) () from /lib/x86_64-linux-gnu/libhunspell-1.7.so.0
#2  0x7f56b5b385bc in ?? () from /lib/x86_64-linux-gnu/libhunspell-1.7.so.0
...
(gdb) bt
#0  0x7f56b5b3159b in unicodetolower (c=c@entry=116, 
langnum=langnum@entry=0) at ./src/hunspell/csutil.cxx:2482
#1  0x7f56b5b317ae in get_captype_utf8 (word=std::vector of length 6, 
capacity 64 = {...}, langnum=0) at ./src/hunspell/csutil.cxx:2538
#2  0x7f56b5b385bc in HashMgr::get_clen_and_captype (workbuf=std::vector of length 6, 
capacity 64 = {...}, captype=, word="tenant", 
this=0x7f568eb64d90) at ./src/hunspell/hashmgr.cxx:468
#3  HashMgr::get_clen_and_captype (workbuf=..., captype=, 
word=..., this=0x7f568eb64d90) at ./src/hunspell/hashmgr.cxx:464
#4  HashMgr::load_tables (this=0x7f568eb64d90, tpath=, 
key=) at ./src/hunspell/hashmgr.cxx:690
#5  0x7f56b5b38dfc in HashMgr::HashMgr (this=this@entry=0x7f568eb64d90, 
tpath=tpath@entry=0x7f56adffa800 "/usr/share/hunspell/en_US.dic", 
apath=apath@entry=0x7f56adffa400 "/usr/share/hunspell/en_US.aff", key=key@entry=0x0) at 
./src/hunspell/hashmgr.cxx:101
#6  0x7f56b5b43616 in HunspellImpl::HunspellImpl (this=0x7f568fb8c850, affpath=0x7f56adffa400 
"/usr/share/hunspell/en_US.aff", dpath=0x7f56adffa800 
"/usr/share/hunspell/en_US.dic", key=0x0) at ./src/hunspell/hunspell.cxx:179
#7  0x7f56b5b43a27 in Hunspell_create (affpath=affpath@entry=0x7f56adffa400 
"/usr/share/hunspell/en_US.aff", dpath=dpath@entry=0x7f56adffa800 
"/usr/share/hunspell/en_US.dic") at ./src/hunspell/hunspell.cxx:2164
#8  0x7f56b60decc1 in spellcheck_create (lang=0x7f568d0e22c0 "en") at 
tokenize/spellcheck-hun.c:101
#9  0x7f56b60af6e5 in dictionary_six_str (lang=lang@entry=0x560b8f8ac37a "en", input=input@entry=0x7f568f9bc460 "\n %", '*' , 
"%\n %", ' ' , "%\n %   Copyright (C) 1991-1998  Daniel "..., dict_name=dict_name@entry=0x7f568fa3e630 "en/4.0.dict", 
pp_name=pp_name@entry=0x7f568fa3e6f0 "en/4.0.knowledge", cons_name=cons_name@entry=0x7f568fa3e8e0 "en/4.0.constituent-knowledge", 
affix_name=affix_name@entry=0x7f568fa3e930 "en/4.0.affix", regex_name=0x7f568fa3e070 "en/4.0.regex") at dict-file/dictionary.c:159
#10 0x7f56b60afc28 in dictionary_six (regex_name=0x7f568fa3e070 "en/4.0.regex", affix_name=0x7f568fa3e930 
"en/4.0.affix", cons_name=0x7f568fa3e8e0 "en/4.0.constituent-knowledge", pp_name=0x7f568fa3e6f0 
"en/4.0.knowledge", dict_name=0x7f568fa3e630 "en/4.0.dict", lang=0x560b8f8ac37a "en") at 
dict-file/dictionary.c:281
#11 dictionary_create_from_file (lang=0x560b8f8ac37a "en") at 
dict-file/dictionary.c:307
#12 0x560b8f8ab598 in parse_one_sent (sent_str=0x560b8f8ac248 "The line extends 
10 miles offshore.") at ./tests/multi-dict.cc:28
#13 parse_sents (thread_id=, niter=30) at 
./tests/multi-dict.cc:82
#14 0x7f56b5ed44a3 in std::execute_native_thread_routine 
(__p=0x560b90a39a70) at ../../../../../src/libstdc++-v3/src/c++11/thread.cc:82
#15 0x7f56b5ca7fd4 in start_thread (arg=) at 
./nptl/pthread_create.c:442
#16 0x7f56b5d2866c in clone3 () at 
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

2482  return (utf_tbl) ? utf_tbl[c].clower : c;

=> 0x7f56b5b3159b <_Z14unicodetolowerti+27>:movzwl 0x4(%rdx,%rax,2),%eax
(gdb) print/x $rdx
$49 = 0x7f56ac614010
(gdb) print/x $rax
$50 = 0x15c
(gdb) x/1xg ($rdx + $rax * 2) + 0x4
0x7f56ac6142cc: Cannot access memory at address 0x7f56ac6142cc
(gdb) print utf_tbl
$51 = (unicode_info2 *) 0x0
# Unstable amd64 qemu VM 2023-01-20

apt update
apt dist-upgrade

apt install systemd-coredump mc gdb valgrind rr autopkgtest dpkg-dev 
libhunspell-1.7-0-dbgsym libstdc++6-dbgsym
apt build-dep link-grammar

autopkgtest --shell-fail link-grammar -- null



PASS: mem-leak
PASS: multi-java
PASS: dict-reopen
../test-driver: Zeile 112: 12435 Speicherzugriffsfehler  (Speicherabzug 
geschrieben) "$@" >> "$log_file" 2>&1
FAIL: multi-dict
PASS: multi-thread
===
   link-grammar 5.12.0: tests/test-suite.log
===

# TOTAL: 5
# PASS:  4
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: multi-dict







[  348.182545] multi-dict[12511]: segfault at 7f56ac6142cc ip 7f56b5b3159b 
sp 7f56adffa188 error 4 in libhun

Bug#1026069: scrcpy: Bug#1026069: Cannot find symbols during build

[Bernhard Übelacker]

On Wed, 14 Dec 2022 10:07:27 +0100 martin f krafft  
wrote:

Package: scrcpy
Version: 1.24-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Running `apt build-dep scrcpy` and `fakeroot debian/rules binary` 
results in plenty of unresolvable symbols.



Hello Martin,
I could not reproduce an issue inside a minimal unstable VM.

The package builds with "fakeroot debian/rules binary" and
"dpkg-buildpackage" without showing an error.

Can you still reproduce it?

Kind regards,
Bernhard

Bug#1025498: scrcpy: Bug#1025498: Links to old libavdevice58

[Bernhard Übelacker]

On Mon, 5 Dec 2022 21:33:03 +0100 martin f krafft  wrote:

Package: scrcpy
Version: 1.24-1
Severity: grave

The package depends on libavdevice59, but it's apparently built 
against libavdevice58:


lotus:~% ldd =scrcpy | grep libavdevice
  libavdevice.so.58 => not found



Hello Martin,
can you still reproduce this issue?

I have installed scrcpy inside a minimal unstable VM,
and receive the output below [1].

Also the build log [2] seems to show that libavdevice59
was installed during package build.

Your ldd shows "=scrcpy" instead of an absolute path,
does it really point to the binary from the package?

Kind regards,
Bernhard


[1]
benutzer@debian:~$ ldd /usr/bin/scrcpy | grep libavdevice
libavdevice.so.59 => /lib/x86_64-linux-gnu/libavdevice.so.59 
(0x7fa06f9cd000)
benutzer@debian:~$ dpkg -l | grep scrcpy
ii  scrcpy1.24-1 amd64  
  Display and control your Android device
ii  scrcpy-server 1.24-1 all
  Display and control your Android device - server binary


[2] 
https://buildd.debian.org/status/fetch.php?pkg=scrcpy&arch=amd64&ver=1.24-1&stamp=1658088686&raw=0
Unpacking libavdevice59:amd64 (7:5.0.1-3+b1) ...
Unpacking libavdevice-dev:amd64 (7:5.0.1-3+b1) ...

Bug#1004154: Fwd: Bug#1004154: xserver-xorg-video-qxl: XOrg frequently crashes when using qxl driver: qxl(0): error doing QXL_ALLOC

[Bernhard Übelacker]

Forwarding, as the email from TJ possibly did not reach Felix.


On Fri, 21 Oct 2022 11:43:07 +0100 TJ  wrote:

On Sat, 12 Feb 2022 08:21:55 + Felix Leimbach  wrote:
> I noticed that vgamem_mb was still low (32 MB).
> So I changed to this (slightly wasteful) command-line and am now running the 
latest kernel (5.15.0-3-amd64):
> 
> -vga none -device qxl-vga,ram_size_mb=256,vgamem_mb=256,vram_size_mb=256,vram64_size_mb=256,max_outputs=1
> 
> Will report back if that helps.


Did the vgamem_mb change fix the issue?

This bug is currently keeping the package out of bookworm and, if it was 
a user-specific issue, ought to be closed and the package reintroduced 
to bookworm.


I'm currently doing a full-upgrade bullseye to bookworm and this removal 
is a blocker for VMs.

Bug#1026061: bart: FTBFS randomly in bullseye (failing test)

[Bernhard Übelacker]

Am 01.01.23 um 16:55 schrieb Uecker, Martin:


This is likely a numerical error caused by reordering a
floating point sum by parallelization. It is not worth
spending time on it.

I can apply the patch, but I do not have much time now.
Is there some urgency?


Not from my side, I just tried to help debugging the issue.

Kind regards,
Bernhard

Bug#1026061: bart: FTBFS randomly in bullseye (failing test)

[Bernhard Übelacker]

Hello,
thanks for your immediate responses.


Am 01.01.23 um 15:55 schrieb Uecker, Martin:


One could just relax (or simply remove) the test from bullseye
or packport the version bookworm.


I guess that would be applying 0003-relax-failing-unit-test.patch
to the Bullseye version.



The wine code is broken (it violates the effective types
rules of ISO C).


Ok, just wanted to offer an option.



Am 01.01.23 um 16:02 schrieb Santiago Vila:


Hi. Such failure rate differs a lot from what I get, which is
about 50% in some systems (which is why I believe we should fix this
in bullseye).

Maybe this is an issue of tests optimized for Intel and failing
a lot on AMD or viceversa (there was another package for which that
happened).



If it might be of any help - my system is a "AMD Ryzen 7 1700",
the qemu VM runs with "-enable-kvm -cpu host -smp 16".

By locking the process to just a single cpu I do not get any failures:
  taskset -c 0 bash -c "while true; do ./test_nufft ; done"

If I allow two cpus the failure rate is at 77%:
  taskset -c 0,1 bash -c "while true; do ./test_nufft ; done"


This still does not affect a Bookworm VM, no failures even with
the relax patch removed.


Kind regards,
Bernhard

Bug#1026061: bart: FTBFS randomly in bullseye (failing test)

[Bernhard Übelacker]

Dear Maintainer,
I could reproduce this failure in a bullseye VM.
There the "test_nufft_adjoint" fails in about 1.2 % of the runs.

Attached diff helps to make it more visible.

It looks like the float comparison fails because the
limit of "1.E-6f" is slightly not enough.

If interpret following floating point comparison document right,
then the failing cases are just 8 representable floats "ULPs"
away from the expected value, below 8 it does not fail.

  
https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/

Maybe upstream could consider changing that
float comparison to something like this:

  
https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ddraw/tests/ddraw7.c#l61


In the newer Bookworm package I have found following patch,
which does relax exactly this test:

  
https://salsa.debian.org/med-team/bart/-/blob/master/debian/patches/0003-relax-failing-unit-test.patch

But for some reason it does still not fail if I remove that
patch in the Bookworm version.

Kind regards,
Bernhard



make utest
while true; do ./test_nufft ; done


Bullseye/stable/bart-0.6.00:
- -1.067273+3.247031i - -1.067273+3.247030i - sc1=6.3619987432198080e+01 
sc2=6.3619926397041880e+01 diff=9.6109602054639254e-07 diff_ulp=7
adjoint diff: 0.01 9.6109602054639254e-07, limit: 9.999747524271e-07
./test_nufft:  1/ 1 passed.

- -1.067273+3.247030i - -1.067273+3.247030i - sc1=6.3619926397041830e+01 
sc2=6.3619926397041880e+01 diff=8.3446502685546875e-07 diff_ulp=7
adjoint diff: 0.01 8.3446502685546875e-07, limit: 9.999747524271e-07
./test_nufft:  1/ 1 passed.

- -1.067273+3.247031i - -1.067273+3.247030i - sc1=6.3619987432198087e+01 
sc2=6.3619926397041880e+01 diff=8.5963040419301251e-07 diff_ulp=6
adjoint diff: 0.01 8.5963040419301251e-07, limit: 9.999747524271e-07
./test_nufft:  1/ 1 passed.

- -1.067272+3.247031i - -1.067273+3.247030i - sc1=6.3619987432198073e+01 
sc2=6.3619926397041880e+01 diff=1.0662403155947686e-06 diff_ulp=8
adjoint diff: 0.01 1.0662403155947686e-06, limit: 9.999747524271e-07
ERROR: ./test_nufft:  0/ 1 passed.

- -1.067273+3.247031i - -1.067273+3.247030i - sc1=6.3619987432198087e+01 
sc2=6.3619926397041880e+01 diff=8.5963040419301251e-07 diff_ulp=6
adjoint diff: 0.01 8.5963040419301251e-07, limit: 9.999747524271e-07
./test_nufft:  1/ 1 passed.

- -1.067273+3.247031i - -1.067273+3.247030i - sc1=6.3619987432198080e+01 
sc2=6.3619926397041880e+01 diff=9.6109602054639254e-07 diff_ulp=7
adjoint diff: 0.01 9.6109602054639254e-07, limit: 9.999747524271e-07
./test_nufft:  1/ 1 passed.


Bookworm/testing/bart-0.8.00:
- -1.067272+3.247031i - -1.067273+3.247030i - sc1=6.3619987432198073e+01 
sc2=6.3619926397041880e+01 diff=1.0662403155947686e-06 diff_ulp=8
adjoint diff: 0.00 3.1195452265819767e-07, limit: 9.999747524271e-07
./test_nufft:  1/ 1 passed.diff --git a/src/linops/lintest.c b/src/linops/lintest.c
index c1d1ebc..b0e3bc1 100644
--- a/src/linops/lintest.c
+++ b/src/linops/lintest.c
@@ -59,7 +59,7 @@ static float linop_test_adjoint_generic(const struct linop_s* op, bool rvc)
 	md_free(tmp3);
 	md_free(tmp4);
 
-	debug_printf(DP_DEBUG4, "- %f%+fi - %f%+fi -\n", crealf(sc1), cimagf(sc1), crealf(sc2), cimagf(sc2));
+	debug_printf(DP_INFO, "- %f%+fi - %f%+fi - sc1=%.16e sc2=%.16e diff=%.16e diff_ulp=%d\n", crealf(sc1), cimagf(sc1), crealf(sc2), cimagf(sc2), sc1, sc2, cabsf(sc1 - sc2), abs(*(int*)&sc1 - *(int*)&sc2));
 
 	return cabsf(sc1 - sc2);
 }
diff --git a/utests/test_nufft.c b/utests/test_nufft.c
index ec02762..54163dc 100644
--- a/utests/test_nufft.c
+++ b/utests/test_nufft.c
@@ -112,7 +112,7 @@ static bool test_nufft_adjoint(void)
 
 	float diff = linop_test_adjoint(op);
 
-	debug_printf(DP_DEBUG1, "adjoint diff: %f\n", diff);
+	debug_printf(DP_INFO, "adjoint diff: %f %.16e, limit: %.16e\n", diff, diff, 1.E-6f);
 
 	bool ret = (diff < 1.E-6f);
 
@@ -231,13 +231,6 @@ static bool test_nufft_basis_toeplitz(void)
 
 
 
-UT_REGISTER_TEST(test_nufft_forward);
 UT_REGISTER_TEST(test_nufft_adjoint);
-UT_REGISTER_TEST(test_nufft_normal);
-UT_REGISTER_TEST(test_nufft_toeplitz_weights);
-UT_REGISTER_TEST(test_nufft_toeplitz_noweights);
-UT_REGISTER_TEST(test_nufft_basis_adjoint);
-UT_REGISTER_TEST(test_nufft_basis_normal);
-UT_REGISTER_TEST(test_nufft_basis_toeplitz);
 
 

Bug#1024438: mutter: autopkgtest regression: segfault in workspace-basic.metatest

[Bernhard Übelacker]

Am 18.12.22 um 16:58 schrieb Simon McVittie:


I was unable to reproduce this in a test VM, ...
..., but it is reproducible
on my laptop. Perhaps it's only reproducible if mutter has access to
some resource that my ssh login session to my test VM lacks, or perhaps
there's a race condition that makes this timing-dependent?



Hello Simon,
I forgot to mention that I had to add to
my qemu test VM this graphics configuration:

   -device virtio-vga-gl -display gtk,gl=on

Kind regards,
Bernhard

Bug#1024824: The software outputs: "No access to printer device file" ...

[Bernhard Übelacker]

The software outputs: "No access to printer device file".

Normal user should be added to lp group to make `mtink` work
and it has been added to it indeed, so it is in the /etc/group file
beside the `lp` and `lpadmin` groups, yet the software seems
to be unable to access device file from the USB-conncted EPSON XP-2100. 


Dependencies and suggestions are installed in the system.

I have experienced this package to be working on Ubuntu 22.04 a month ago.




Hello Nicholas,
I guess the Maintainer would need more information about this issue.
A first step might be to provide a "strace" of a mtink startup.

Therefore please install the packages: bsdutils strace

Then execute following line in a terminal:
  script -c "LANG=C strace -f mtink" -a "mtink-strace_$(date 
+%Y-%m-%d_%H-%M-%S).log"

This will create a file like mtink-strace_2022-12-11_14-16-46.log
Maybe you could compress this file and attach it to your answer to this mail?
(Please use the "reply all", to have the bug in CC in your answer.)

Kind regards,
Bernhard

Bug#1025659: libgl1-mesa-dri: mesa causes xorg segfault; regression against 22.2.0-1

[Bernhard Übelacker]

After updating mesa from 22.2.0-1 to 22.3.0-2 (according to dpkg.log)
earlier today U.S. time as part of a routine upgrade to up-to-date sid,
the greeter stopped appearing, and over the course of the last two hours
we chased it down to that upgrade, which made X.org die with
  iris_dri.so (nouveau_drm_screen_create+[three addresses])
  iris_dri.so (?+0x0)
  iris_dri.so (__driDriverGetExtensions_d3d12+[three addresses])
in the backtrace of a segfault at 0x20.

This may be tangentially related to other d3d12 fuckups in 22.3.0,
like #1025312, given the timeline and d3d12ness.



00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 630 
[8086:591b] (rev 04)



Dear Maintainer,
I tried to reconstruct a better backtrace with the
help of the dbgsym packages.

What I find strange is the system has a Intel GPU, but
is calling in some nouveau functions?

Kind regards,
Bernhard


...ebc in nouveau_pushbuf_destroy at 
../src/gallium/drivers/nouveau/nouveau_screen.c:244  
(nouveau_drm_screen_create+0x4406c)
...319 in nvc0_screen_destroy at 
../src/gallium/drivers/nouveau/nvc0/nvc0_screen.c:740
(nouveau_drm_screen_create+0x1e4c9)
...0b6 in nouveau_drm_screen_create at 
../src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c:133 
(nouveau_drm_screen_create+0x266)
...df6 in pipe_nouveau_create_screen at 
../src/gallium/auxiliary/target-helpers/drm_helper.h:144  (0x7f205d0a9df6)
...0c4 in pipe_loader_create_screen_vk at 
../src/gallium/auxiliary/pipe-loader/pipe_loader.c:175  
(__driDriverGetExtensions_d3d12+0x60ad84)
...dd3 in dri2_init_screen at ../src/gallium/frontends/dri/dri2.c:2265  
  (__driDriverGetExtensions_d3d12+0x1a93)
...4b5 in driCreateNewScreen2 at ../src/gallium/frontends/dri/dri_util.c:143
  (__driDriverGetExtensions_d3d12+0xa175)
...eae in dri_screen_create_dri2 at ../src/gbm/backends/dri/gbm_dri.c:434   
  (gbm_format_get_name+0xf2e)
...678 in dri_screen_create at ../src/gbm/backends/dri/gbm_dri.c:511
  (gbm_format_get_name+0x16f8)
...74c in backend_create_device at ../src/gbm/main/backend.c:101
  (0x7f205edc274c)
...884 in gbm_create_device at ../src/gbm/main/gbm.c:138
  (gbm_create_device+0x44)
...3c1 in glamor_egl_init at ../../../../../../glamor/glamor_egl.c:947  
  (glamor_egl_init+0x61)
...733 in try_enable_glamor at 
../../../../../../../hw/xfree86/drivers/modesetting/driver.c:945   
(0x7f205f118733)
...56a in InitOutput at ../../../../../../hw/xfree86/common/xf86Init.c:490  
  (InitOutput+0xa2a)
...


The crashing instruction:  (the 0x20 offset matches, maybe NULL given to 
nouveau_pushbuf_destroy?)

   0x75f56ebc : mov0x20(%rax),%rdi


https://sources.debian.org/src/mesa/22.3.0-2/src/gallium/drivers/nouveau/nouveau_screen.c/#L244
241 void
242 nouveau_pushbuf_destroy(struct nouveau_pushbuf **push)
243 {
244FREE((*push)->user_priv);
245nouveau_pushbuf_del(push);
246 }

Bug#1024438: mutter: autopkgtest regression: Segmentation fault

[Bernhard Übelacker]

Hello,
I tried to collect some informations.

The segfault happens because "workspace" contains a null pointer.
This null originates from "window->workspace".

Kind regards,
Bernhard



Core was generated by 
`/usr/libexec/installed-tests/mutter-11/mutter-test-runner --all'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0xb7ce33f4 in meta_workspace_index (workspace=0x0) at 
../src/core/workspace.c:722
722   ret = g_list_index (workspace->manager->workspaces, workspace);
[Current thread is 1 (Thread 0xb5082980 (LWP 11034))]
(gdb) bt
#0  0xb7ce33f4 in meta_workspace_index (workspace=0x0) at 
../src/core/workspace.c:722
#1  0xb2e96606 in switch_workspace (plugin=0xe9f200 [MetaDefaultPlugin], 
from=0, to=1, direction=META_MOTION_RIGHT) at 
../src/compositor/plugins/default.c:572
#2  0xb7c9e3a0 in meta_plugin_manager_switch_workspace (plugin_mgr=0xe9b3e0, 
from=0, to=1, direction=META_MOTION_RIGHT) at 
../src/compositor/meta-plugin-manager.c:272
#3  0xb7c94a98 in meta_compositor_switch_workspace (compositor=0xc0e9c0 
[MetaCompositorNative], from=0xe7a320 [MetaWorkspace], to=0xe7a370 
[MetaWorkspace], direction=META_MOTION_RIGHT) at 
../src/compositor/compositor.c:682
#4  0xb7ce5a2f in meta_workspace_activate_with_focus (workspace=0xe7a370 
[MetaWorkspace], focus_this=0x0, timestamp=492883) at 
../src/core/workspace.c:684
#5  0xb7ce5c1e in meta_workspace_activate (workspace=0xe7a370 [MetaWorkspace], 
timestamp=492883) at ../src/core/workspace.c:714
#6  0x0047d8a5 in test_case_do (error=0xbfeb8408, argv=, 
argc=, test=0xece680) at ../src/tests/test-runner.c:1068
#7  run_test (index=, filename=0xac7e20 
"/usr/share/mutter-11/tests/stacking/workspace-basic.metatest", context=) at ../src/tests/test-runner.c:1280
#8  run_tests (context=0xaa4c58 [MetaContextTest], info=0xbfeb8934) at 
../src/tests/test-runner.c:1361
#9  0xb5de77d8 in ffi_call_i386 () at ../src/x86/sysv.S:121
#10 0xb5de6d97 in ffi_call_int (cif=, fn=, rvalue=, rvalue@entry=0xbfeb8570, avalue=, closure=) at 
../src/x86/ffi.c:406
#11 0xb5de7001 in ffi_call (cif=, fn=, 
rvalue=0xbfeb8570, avalue=0xbfeb8530) at ../src/x86/ffi.c:415
#12 0xb7a6f8d5 in g_cclosure_marshal_generic_va (closure=, return_value=, 
instance=, args_list=, marshal_data=, 
n_params=, param_types=) at ../../../gobject/gclosure.c:1650
#13 0xb7a6eed6 in _g_closure_invoke_va (closure=0xab5eb0, return_value=0xbfeb8718, 
instance=0xaa4c58, args=0xbfeb87bc "ȇ\353\277\005", n_params=0, 
param_types=0x0) at ../../../gobject/gclosure.c:895
#14 0xb7a87e4a in g_signal_emit_valist (instance=, signal_id=, detail=, var_args=) at 
../../../gobject/gsignal.c:3456
#15 0xb7a88005 in g_signal_emit (instance=0xaa4c58, signal_id=3, detail=0) at 
../../../gobject/gsignal.c:3606
#16 0xb7eecdb8 in run_tests_idle (user_data=0xaa4c58) at 
../src/tests/meta-context-test.c:221
#17 0xb76fb41e in g_main_dispatch (context=0xaa93f0) at 
../../../glib/gmain.c:3444
#18 g_main_context_dispatch (context=0xaa93f0) at ../../../glib/gmain.c:4162
#19 0xb76fb819 in g_main_context_iterate (context=0xaa93f0, block=block@entry=1, 
dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:4238
#20 0xb76fbb31 in g_main_loop_run (loop=) at 
../../../glib/gmain.c:4438
#21 0xb7cc2c33 in meta_context_run_main_loop (context=0xaa4c58 
[MetaContextTest], error=0xbfeb88e8) at ../src/core/meta-context.c:453
#22 0xb7eed30c in meta_context_test_run_tests (context_test=0xaa4c58 
[MetaContextTest], flags=META_TEST_RUN_FLAG_NONE) at 
../src/tests/meta-context-test.c:283
#23 0x0047aa29 in main (argc=, argv=) at 
../src/tests/test-runner.c:1483

(gdb) print workspace
$1 = 0x0

(gdb) list meta_workspace_index
716
717 int
718 meta_workspace_index (MetaWorkspace *workspace)
719 {
720   int ret;
721
722   ret = g_list_index (workspace->manager->workspaces, workspace);
723   g_return_val_if_fail (ret >= 0, -1);





(gdb) up
#1  0xb2e96606 in switch_workspace (plugin=0xe9f200 [MetaDefaultPlugin], 
from=0, to=1, direction=META_MOTION_RIGHT) at 
../src/compositor/plugins/default.c:572
572   win_workspace = meta_workspace_index (workspace);

(gdb) print window->on_all_workspaces
$2 = 0
(gdb) print window->workspace
$3 = 0x0

(gdb) list switch_workspace
...
567 {
568   MetaWorkspace *workspace;
569   gint   win_workspace;
570
571   workspace = meta_window_get_workspace (window);
572   win_workspace = meta_workspace_index (workspace);
573
574   if (win_workspace == to || win_workspace == from)

Bug#1024169: csound breaks csound-plugins autopkgtest: *** stack smashing detected ***: terminated

[Bernhard Übelacker]

Just a short addition:
There is already an upstream bug reported:

https://github.com/csound/csound/issues/1651

Kind regards,
Bernhard

Bug#1024169: csound breaks csound-plugins autopkgtest: *** stack smashing detected ***: terminated

[Bernhard Übelacker]

Dear Maintainer,
this looks like caused by a disaggrement about the size of type OPARMS.
In libcsound64-6.0 it has 264 bytes, but in csound-plugins
only 260 bytes.

This difference is caused by the last member "mp3_mode", that is missing
in the OPARMS type used in csound-plugins.
It got introduced in commit [1] and caused this ABI break.

Attached are relevant parts of the debugging.

Kind regards,
Bernhard

[1] 
https://github.com/csound/csound/commit/11df83f60d6afa51e5e0d25dc5efe5b2beec621e

(rr) bt
#0  0xb7a1e4f6 in memcpy (__len=264, __src=0x10d3de0, __dest=0xbfb5aee8) at 
/usr/include/i386-linux-gnu/bits/string_fortified.h:29
#1  csoundGetOParms (csound=, p=0xbfb5aee8) at ./Top/csound.c:230
#2  0xb51310c0 in csoundModuleInit (csound=0x10c61a0) at ./widgets/winFLTK.c:73
#3  0xb7b6388a in csoundInitModule (csound=csound@entry=0x10c61a0, 
m=m@entry=0x11baed8) at ./Top/csmodule.c:249
#4  0xb7b63a51 in csoundInitModules (csound=0x10c61a0) at ./Top/csmodule.c:825
#5  0xb7a233f5 in csoundReset (csound=) at ./Top/csound.c:3554
#6  0xb7a23af4 in csoundCreate (hostdata=0x0) at ./Top/csound.c:1361
#7  0x004c24c7 in main (argc=3, argv=0xbfb5b224) at 
./Frontends/csound/csound_main.c:322
# Unstable i386 qemu VM 2022-11-15

apt update
apt dist-upgrade

apt install systemd-coredump gdb rr autopkgtest dpkg-dev csound csound-plugins 
python3-csound csound-plugins-dbgsym libcsound64-6.0-dbgsym csound-dbgsym





$ autopkgtest csound-plugins --shell-fail -- null
autopkgtest [23:05:23]: starting date and time: 2022-11-15 23:05:23+0100
autopkgtest [23:05:23]: version 5.27
autopkgtest [23:05:23]: host debian; command line: /usr/bin/autopkgtest 
csound-plugins --shell-fail -- null
autopkgtest [23:05:23]: testbed dpkg architecture: i386
autopkgtest [23:05:23]: testbed running kernel: Linux 6.0.0-4-686-pae #1 SMP 
PREEMPT_DYNAMIC Debian 6.0.8-1 (2022-11-11)
autopkgtest [23:05:23]:  apt-source csound-plugins
gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: Schlüsselblockhilfsmittel`/tmp/dpkg-verify-sig.OC9zItqO/trustedkeys.kbx': 
General error
gpgv: Signatur vom Mi 28 Sep 2022 09:29:57 CEST
gpgv:mittels RSA-Schlüssel 
7405E745574809734800156DB65019C47F7A36F8
gpgv: Signatur kann nicht geprüft werden: No public key
dpkg-source: Warnung: Signatur ./csound-plugins_1.0.2~dfsg1-2.dsc kann nicht 
überprüft werden
autopkgtest [23:05:24]: testing package csound-plugins version 1.0.2~dfsg1-2
autopkgtest [23:05:24]: build not needed
autopkgtest [23:05:24]: test command1: preparing testbed
autopkgtest [23:05:24]: test command1: csound --nosound 
py/examples/embeddedCtcsound.csd
autopkgtest [23:05:24]: test command1: [---
*** stack smashing detected ***: terminated

csound command: Aborted

csound command: Segmentation fault
autopkgtest [23:05:25]: test command1: ---]
autopkgtest [23:05:25]: test command1:  - - - - - - - - - - results - - - - - - 
- - - -
command1 FAIL non-zero exit status 1
autopkgtest [23:05:25]:  - - - - - - - - - - running shell - - - - - - - - - -
benutzer@debian:/tmp/autopkgtest.2VfrCV/build.Tvx/src$ rr record csound 
--nosound py/examples/embeddedCtcsound.csd
rr: Saving execution to trace directory 
`/home/benutzer/.local/share/rr/csound-0'.
*** stack smashing detected ***: terminated

csound command: Aborted

csound command: Segmentation fault
$ rr replay -o -q csound-0
Reading symbols from /usr/bin/csound...
(No debugging symbols found in /usr/bin/csound)
Really redefine built-in command "restart"? (y or n) [answered Y; input not 
from terminal]
Really redefine built-in command "jump"? (y or n) [answered Y; input not from 
terminal]
Remote debugging using 127.0.0.1:3587
Reading symbols from /lib/ld-linux.so.2...
Reading symbols from 
/usr/lib/debug/.build-id/9b/f5ef863480886a4c2159e109d63c656ca30739.debug...
BFD: warning: system-supplied DSO at 0x6fffd000 has a section extending past 
end of file
0xb7f40450 in _start () from /lib/ld-linux.so.2
(rr) cont
Continuing.
*** stack smashing detected ***: terminated

Program received signal SIGABRT, Aborted.
0x7002 in syscall_traced ()
(rr) bt
#0  0x7002 in syscall_traced ()
#1  0xb7f1513d in _raw_syscall () at 
/build/rr-Rm2x32/rr-5.6.0/src/preload/raw_syscall.S:34
#2  0xb7f10b33 in traced_raw_syscall (call=0x681fffd8) at 
./src/preload/syscallbuf.c:338
#3  0xb7f12c4d in sys_recvfrom (call=) at 
./src/preload/syscallbuf.c:2952
#4  syscall_hook_internal (call=0x681fffd8) at ./src/preload/syscallbuf.c:3843
#5  syscall_hook (call=0x681fffd8) at ./src/preload/syscallbuf.c:3949
#6  syscall_hook (call=) at ./src/preload/syscallbuf.c:3933
#7  0xb7f10361 in _syscall_hook_trampoline () at 
/build/rr-Rm2x32/rr-5.6.0/src/preload/syscall_hook.S:131
#8  0xb7f103d2 in _syscall_hook_trampoline_90_90_90 () at 
/build/rr-Rm2x32/rr-5.6.0/src/preload/syscall_hook.S:211
#9  0x6005 in __kernel_vsyscall ()
#10 0xb768a1d7 in __pthread_kill_implementation 
(threadid=threadid@entry=3084

Bug#1022282: staden-io-lib: FTBFS: ./data/9827_rand3.cram.fai: No such file or directory

[Bernhard Übelacker]

Dear Maintainer,
the original staden-io-lib seems to be built with
libhtscodecs2 in version 1.2.2-1 [1].

The rebuild seems to be using libhtscodecs2 in version 1.3.0-4.

Unfortunately htscodecs upstream integrated this commit [3],
which renamed e.g. function encode_names to tok3_encode_names.
It added a compatibility function encode_names, but does not
declare it in the header file.
Therefore in the build of staden-io-lib the function encode_names
is implicitly declared - therefore seems to default to
a return type of int [4] - and therefore the returned pointer
gets truncated to the lower 4 bytes [5].
This get through unnoticed until the pointer is freed and
produces a segfault there [6].

I guess the right thing would be to have the short function name
in the header file of htscodecs, therefore solve this issue for
other packages using htscodecs.

A short term solution might be the patch in [7] which makes
the build and tests succeed without "implicit declarations".

Kind regards,
Bernhard



[1] 
https://buildd.debian.org/status/fetch.php?pkg=staden-io-lib&arch=amd64&ver=1.14.14%2Bdfsg-1%2Bb1&stamp=1663567926&raw=0
[2] https://tracker.debian.org/pkg/htscodecs
[3] 
https://github.com/jkbonfield/htscodecs/commit/6211b208d2bd21e93f3f62c0cd0d8c43546f98b5

[4]
cram_io.c: In function ‘cram_compress_by_method’:
cram_io.c:2420:23: warning: implicit declaration of function 
‘encode_names’; did you mean ‘tok3_encode_names’? 
[-Wimplicit-function-declaration]
2420 | uint8_t *cp = encode_names(in, in_size, lev, strat, 
&out_len, NULL);
|   ^~~~
|   tok3_encode_names
cram_io.c:2420:23: warning: initialization of ‘uint8_t *’ {aka ‘unsigned 
char *’} from ‘int’ makes pointer from integer without a cast [-Wint-conversion]


[5]
(rr) bt
#0  tok3_encode_names (blk=, len=, level=, 
use_arith=, out_len=, last_start_p=) at 
./htscodecs/tokenise_name3.c:1540
#1  0x7f281aa34454 in cram_compress_by_method (s=s@entry=0x55e9af757e50, in=0x7f281000e930 
"s0", in_size=9, out_size=out_size@entry=0x7f2819611730, method=method@entry=TOK3, 
level=, strat=0, content_id=) at ./io_lib/cram_io.c:2420
#2  0x7f281aa38ebe in cram_compress_block (fd=fd@entry=0x55e9af71f930, 
s=s@entry=0x55e9af757e50, b=0x55e9af758830, metrics=0x55e9af731f50, 
method=65794, level=level@entry=5) at ./io_lib/cram_io.c:2562
#3  0x7f281aa22d75 in cram_compress_slice (s=0x55e9af757e50, c=, fd=0x55e9af71f930) at ./io_lib/cram_encode.c:951
#4  cram_encode_slice (fd=fd@entry=0x55e9af71f930, 
c=c@entry=0x55e9af73c270, h=h@entry=0x55e9af73c520, s=0x55e9af757e50) at 
./io_lib/cram_encode.c:1219
#5  0x7f281aa27881 in cram_encode_container (fd=, 
c=) at ./io_lib/cram_encode.c:2119
#6  0x7f281aa33fb0 in cram_flush_thread (arg=0x55e9af4d0500) at 
./io_lib/cram_io.c:4328
#7  0x7f281aa44272 in t_pool_worker (arg=0x55e9af737460) at 
./io_lib/thread_pool.c:434
#8  0x7f281a68784a in start_thread (arg=) at 
./nptl/pthread_create.c:442
#9  0x7f281a70a530 in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:100
(rr) print out
$6 = (uint8_t *) 0x7f2810010320 "\t"
(rr) finish
Run till exit from #0  tok3_encode_names (blk=, len=, 
level=, use_arith=, out_len=, 
last_start_p=) at ./htscodecs/tokenise_name3.c:1540
0x7f281aa34454 in cram_compress_by_method (s=s@entry=0x55e9af757e50, in=0x7f281000e930 
"s0", in_size=9, out_size=out_size@entry=0x7f2819611730, method=method@entry=TOK3, 
level=, strat=0, content_id=) at ./io_lib/cram_io.c:2420
2420uint8_t *cp = encode_names(in, in_size, lev, strat, 
&out_len, NULL);
Value returned is $8 = (uint8_t *) 0x7f2810010320 "\t"
(rr) stepi
2421*out_size = out_len;
(rr) print cp
$7 = (uint8_t *) 0x10010320 
(rr) list
2416int out_len;
2417int lev = level;
2418if (method == NAME_TOK3 && lev > 3)
2419lev = 3;
2420uint8_t *cp = encode_names(in, in_size, lev, strat, 
&out_len, NULL);
2421*out_size = out_len;
2422return (char *)cp;
2423}
2424
2425case RAW:


[6]
Thread 2 received signal SIGSEGV, Segmentation fault.
0x7f281a69788a in __GI___libc_free (mem=0x10010320) at 
./malloc/malloc.c:3363
3363./malloc/malloc.c: Datei oder Verzeichnis nicht gefunden.
(rr) bt
#0  0x7f281a69788a in __GI___libc_free (mem=0x10010320) at 
./malloc/malloc.c:3363
#1  0x7f281aa39238 in cram_compress_block (fd=fd@entry=0x55e9af71f930, 
s=s@entry=0x55e9af757e50, b=0x55e9af758830, metrics=0x55e9af731f50, 
method=65794, level=level@entry=5) at ./io_lib/cram_io.c:2575
#2  0x7f281aa22d75 in cram_compress_slice (s=0x55e9af757e50, c=, fd=0x55e9af71f930) at ./io_lib/cram_encode.c:951
#3  cram_encode_slice (fd=fd@entry=0x55e9af71f930, 
c=c@entry=0x55e9af7

Bug#1020702: prusa-slicer: SEGV on start

[Bernhard Übelacker]

Hello,
it looks like following line should expect the Get() call returning a nullptr,
which wxWidget documentation explicitly notes.

   2079
wxTranslations::Get()->SetLanguage(wxLANGUAGE_DEFAULT);


I have raised this question to upstream here:

   https://github.com/prusa3d/PrusaSlicer/issues/9024

Kind regards,
Bernhard


Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f2589f565f3 in std::__cxx11::basic_string, 
std::allocator >::_M_data (this=) at 
/build/gcc-12-GwPmq4/gcc-12-12.2.0/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.h:234
234 
/build/gcc-12-GwPmq4/gcc-12-12.2.0/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.h:
 Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0  0x7f2589f565f3 in std::__cxx11::basic_string, 
std::allocator >::_M_data (this=) at 
/build/gcc-12-GwPmq4/gcc-12-12.2.0/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.h:234
#1  std::__cxx11::basic_string, 
std::allocator >::_M_is_local (this=) at 
/build/gcc-12-GwPmq4/gcc-12-12.2.0/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.h:274
#2  std::__cxx11::basic_string, 
std::allocator >::capacity (this=) at 
/build/gcc-12-GwPmq4/gcc-12-12.2.0/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.h:1134
#3  std::__cxx11::basic_string, std::allocator 
>::_M_assign (this=this@entry=0x0, __str=L"") at 
/build/gcc-12-GwPmq4/gcc-12-12.2.0/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:279
#4  0x7f258896e05a in std::__cxx11::basic_string, 
std::allocator >::assign (__str=L"", this=0x0) at 
/usr/include/c++/12/bits/basic_string.h:1540
#5  0x7f258896e0c6 in wxTranslations::SetLanguage (this=0x0, 
lang=lang@entry=wxLANGUAGE_DEFAULT) at ./src/common/translation.cpp:1384
#6  0x563e57fb8e26 in Slic3r::GUI::GUI_App::load_language (this=0x563e59d29200, 
language=..., initial=) at ./src/slic3r/GUI/GUI_App.cpp:2079
#7  0x563e57fbaaf5 in Slic3r::GUI::GUI_App::on_init_inner 
(this=0x563e59d29200) at ./src/slic3r/GUI/GUI_App.cpp:1093
#8  0x563e57fbd4c6 in Slic3r::GUI::GUI_App::OnInit (this=) 
at ./src/slic3r/GUI/GUI_App.cpp:1035
#9  0x7f258891feda in wxEntry (argc=, argv=) 
at ./src/common/init.cpp:487
#10 0x563e57f9f7b9 in Slic3r::GUI::GUI_Run (params=...) at 
./src/slic3r/GUI/GUI_Init.cpp:54
#11 0x563e577605de in Slic3r::CLI::run (this=, argc=, argv=) at ./src/PrusaSlicer.cpp:618
#12 0x563e57735bf4 in main (argc=, argv=) at 
./src/PrusaSlicer.cpp:844


https://docs.wxwidgets.org/3.0/classwx_translations.html#ab384ea68c44e74cfd2cd59e782529540

Bug#1020677: httraqt: Segfault upon mirroring initiation

[Bernhard Übelacker]

Dear Maintainer,
I tried to have a look and found unfortunately the dbgsym package
not containing useful files.

This seems related to CMAKE_CXX_FLAGS getting reset,
therefore loosing Qt related flags.

Before the application crashed already when trying to open
one leaf in the tree view, with the Qt flags this crash did not happen,
so this might be related.

The second patch just removes a leftover CMakeLists.txt.rej from a previous 
patch.

Kind regards,
Bernhard


Before:
-- CMAKE_CXX_FLAGS -O3 -DNDEBUG -Wall

After:
-- CMAKE_CXX_FLAGS -g -O2 
-ffile-prefix-map=/home/benutzer/source/httraqt/git/httraqt=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -O3 -DNDEBUG -Wall -DQT_NO_DEPRECATED_WARNINGSFrom 1349c117855ba576dd9eb7aea2612550c58a1727 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
Date: Sun, 9 Oct 2022 16:29:40 +0200
Subject: Remove CMakeLists.txt.rej from 10_reproducible_build.patch.

---
 debian/patches/10_reproducible_build.patch | 27 --
 1 file changed, 27 deletions(-)

diff --git a/debian/patches/10_reproducible_build.patch b/debian/patches/10_reproducible_build.patch
index 22f5ebb..7a620e5 100644
--- a/debian/patches/10_reproducible_build.patch
+++ b/debian/patches/10_reproducible_build.patch
@@ -17,30 +17,3 @@ Last-Update: 2017-07-18
  MESSAGE("-- Version build date: ${BUILD_DATE}")
  
  configure_file (
 /dev/null
-+++ httraqt-1.4.9/CMakeLists.txt.rej
-@@ -0,0 +1,24 @@
-+--- CMakeLists.txt
- CMakeLists.txt
-+@@ -6,7 +6,7 @@ CMAKE_POLICY(SET CMP0003 OLD)
-+ CMAKE_POLICY(SET CMP0015 OLD)
-+ 
-+ # if you use the version 5, please change it to 5
-+-SET(USE_QT_VERSION 4)
-++SET(USE_QT_VERSION 5)
-+ 
-+ MESSAGE("Qt version for compiling: " ${USE_QT_VERSION})
-+ 
-+@@ -62,12 +62,6 @@ set(APP_RESOURCES  "${PROJECT_SOURCE_DIR
-+ MESSAGE("-- Version info: ${HTTRAQT_VERSION}") 
-+ SET(VERSION ${HTTRAQT_VERSION})
-+ 
-+-EXECUTE_PROCESS (
-+-  COMMAND date +"%d %b %Y"
-+-  COMMAND sed -e "s/\"//g"
-+-  OUTPUT_VARIABLE BUILD_DATE
-+-  OUTPUT_STRIP_TRAILING_WHITESPACE)
-+-
-+ MESSAGE("-- Version build date: ${BUILD_DATE}")
-+ 
-+ configure_file (
-- 
2.35.1

From a678025eece455ffcc3916c65bfac194b5747b1a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
Date: Sun, 9 Oct 2022 16:34:36 +0200
Subject: Do not override CMAKE_CXX_FLAGS.

Adds additionally QT_NO_DEPRECATED_WARNINGS as those warnings
might be mostly useful for upstream developers.
---
 .../30_do_not_override_CMAKE_CXX_FLAGS.patch  | 21 +++
 debian/patches/series |  1 +
 2 files changed, 22 insertions(+)
 create mode 100644 debian/patches/30_do_not_override_CMAKE_CXX_FLAGS.patch

diff --git a/debian/patches/30_do_not_override_CMAKE_CXX_FLAGS.patch b/debian/patches/30_do_not_override_CMAKE_CXX_FLAGS.patch
new file mode 100644
index 000..b11608a
--- /dev/null
+++ b/debian/patches/30_do_not_override_CMAKE_CXX_FLAGS.patch
@@ -0,0 +1,21 @@
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index 1310490..a51d391 100644
+--- a/CMakeLists.txt
 b/CMakeLists.txt
+@@ -26,11 +26,14 @@ OPTION (USE_PROFILER "Include in binary file profiling information" OFF)
+ 
+ 
+ IF(${USE_DEBUGGER})
+-  SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS_DEBUG} -Wall")
++  SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_DEBUG} -Wall")
+ ELSE()
+-  SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS_RELEASE} -Wall")
++  SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_RELEASE} -Wall")
+ ENDIF()
+ 
++SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -DQT_NO_DEPRECATED_WARNINGS")
++
++
+ MESSAGE(STATUS "CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS}")
+ 
+ 
diff --git a/debian/patches/series b/debian/patches/series
index 8d027f0..43c04ea 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 10_reproducible_build.patch
 20_cross.patch
+30_do_not_override_CMAKE_CXX_FLAGS.patch
-- 
2.35.1

Bug#1019340: tucnak: Segfaults on startup

[Bernhard Übelacker]

Hello Christoph, hello tony,


#12 0x5586f25c0438 tucnak_crash (tucnak + 0xb0438)
#13 0x7febdc3589d4 z_sig_segv (libzia-4.36.so + 0x169d4)
#14 0x7febdaa3daf0 __restore_rt (libc.so.6 + 0x3daf0)
#15 0x7febd5ead5ee n/a (crocus_dri.so + 0xad5ee)
#16 0x7febd80836e6 glPrimitiveBoundingBox (libGLX_mesa.so.0 
+ 0x4e6e6)


The crash looks like it happened in crocus_dri.so.
Could the possible difference be the gpu driver that is in use on your systems.
As far as I see crocus is for Intel gpus, and arrived just last year in Mesa.
Therefore it might be just reproducible with this hardware.

From [1] it might be possible to use another driver.
Maybe MESA_LOADER_DRIVER_OVERRIDE=i965 could work for this hardware?

Kind regards,
Bernhard

[1] https://wiki.archlinux.org/title/OpenGL#Installation

Bug#996761: kwin-x11: KWin crashes and doesn't start

[Bernhard Übelacker]

Hello Francisco, hello Albert,
this might be the same as in bug #996726
and not directly related to the nvidia driver.

I hit a crash in kwin_x11 with an AMD graphics card
and could workaround by installing
libkdecorations2-5v5_5.21.5-2_amd64.deb like
mentioned in #996726.

Kind regards,
Bernhard

https://bugs.debian.org/996726

Bug#995242: isc-dhcp-server: omshell returns inconsistent results or segfaults

[Bernhard Übelacker]

On Tue, 28 Sep 2021 15:01:22 +0200 uninsubria.it 
 wrote:


example from 'dmesg' output:
[Tue Sep 28 11:05:22 2021] omshell[4604]: segfault at 0 ip 55623cdd06dc sp 
7ffd5a2c7c78 error 4 in omshell[55623cd97000+45000]




Hello,
maybe you can add a few pairs of the
dmesg "segfault" and "code" lines.
This would make it possible to locate the crashing instruction,
and therefore maybe point to a source code line.

Kind regards,
Bernhard

Bug#986692: crash at startup

[Bernhard Übelacker]

Dear Maintainer,
I tried to have a look, but got no clue why a Unwind should take place
until I saw the old build log [1].

There I found this warning:
  Levels.cpp: In member function ‘bool Levels::addLevel(const string&, int, 
int)’:
  Levels.cpp:118:1: warning: no return statement in function returning non-void 
[-Wreturn-type]
118 | }
| ^

So I assume g++ puts no ret instruction to this method
and therefore the Unwind gets executed because of this.
I wonder why this is just a warning ...

Attached patch contains a few changes for these warnings:
  warning: no return statement in function returning non-void [-Wreturn-type]
  warning: control reaches end of non-void function [-Wreturn-type]
  warning: attempt to free a non-heap object ‘host’ [-Wfree-nonheap-object]

A build with this patch applied does not crash at startup.
(Testing if it really starts up took longer than the actual error ;-) )

Kind regards,
Bernhard

[1] 
https://buildd.debian.org/status/fetch.php?pkg=numptyphysics&arch=amd64&ver=0.2%2Bsvn157-0.4&stamp=1573519484&raw=0
Bug-Debian: https://bugs.debian.org/986692
Forwarded: no
Last-Update: 2021-04-22

--- numptyphysics-0.2+svn157.orig/Game.h
+++ numptyphysics-0.2+svn157/Game.h
@@ -58,7 +58,7 @@ struct GameControl
   virtual ~GameControl() {}
   virtual bool save( const char *file=NULL ) =0;
   virtual bool send() =0;
-  virtual bool load( const char* file ) {};
+  virtual bool load( const char* file ) { return false; };
   virtual void gotoLevel( int l, bool replay=false ) =0;
   virtual void clickMode(int cm) =0;
   Levels& levels() { return *m_levels; }
--- numptyphysics-0.2+svn157.orig/Http.cpp
+++ numptyphysics-0.2+svn157/Http.cpp
@@ -114,7 +114,6 @@ bool Http::get( const char* uri,
   }
 
   fclose ( m_file );
-  free( host );
   return m_size > 0;
 }
 
@@ -175,6 +174,7 @@ bool Http::post( const char* uri, const
   fprintf(stderr,"http_get wobbly: %s\n",w.what());
 }
   }
+  return true;
 }
 
 
--- numptyphysics-0.2+svn157.orig/Levels.cpp
+++ numptyphysics-0.2+svn157/Levels.cpp
@@ -114,7 +114,7 @@ bool Levels::addPath( const char* path )
 
 bool Levels::addLevel( const string& file, int rank, int index )
 {
-  addLevel( getCollection(MISC_COLLECTION), file, rank, index );
+  return addLevel( getCollection(MISC_COLLECTION), file, rank, index );
 }
 
 bool Levels::addLevel( Collection* collection,
@@ -248,6 +248,7 @@ int Levels::collectionFromLevel( int i,
   }
 }
   }
+  return -1;
 }
 
 std::string Levels::collectionName( int i, bool pretty )
--- numptyphysics-0.2+svn157.orig/Scene.cpp
+++ numptyphysics-0.2+svn157/Scene.cpp
@@ -616,6 +616,7 @@ bool Scene::activateStroke( Stroke *s )
 {
   activate(s);
   m_recorder.activateStroke( m_strokes.indexOf(s) );
+  return true;
 }
 
 void Scene::getJointCandidates( Stroke* s, Path& pts )
--- numptyphysics-0.2+svn157.orig/Ui.cpp
+++ numptyphysics-0.2+svn157/Ui.cpp
@@ -1081,7 +1081,7 @@ bool Dialog::onEvent( Event& ev )
   return Panel::onEvent(ev);
 }
 
-bool Dialog::close()
+void Dialog::close()
 {
   if (m_parent) {
 //fprintf(stderr,"close dialog\n");
--- numptyphysics-0.2+svn157.orig/Ui.h
+++ numptyphysics-0.2+svn157/Ui.h
@@ -321,7 +321,7 @@ class Dialog : public Panel
   void onTick( int tick );
   bool processEvent( SDL_Event& ev );
   bool onEvent( Event& ev );
-  bool close();
+  void close();
   virtual Container* content() { return m_content; }
   Button* leftControl() { return m_left; }
   Button* rightControl() { return m_right; }
--- numptyphysics-0.2+svn157.orig/Worker.cpp
+++ numptyphysics-0.2+svn157/Worker.cpp
@@ -64,4 +64,5 @@ int WorkerBase::startThread(void* wbase)
   event.user.data1 = wbase;
   event.user.data2 = 0;
   SDL_PushEvent(&event);
+  return 0;
 }

Bug#986692: crash at startup

[Bernhard Übelacker]

Just for reference, why g++ does not error here,
this gcc bug might be interesting:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43943

Kind regards,
Bernhard

Bug#984953: libgtkmm-3.0-1v5: GParted crashes on Gdk::Pixbuf::get_width() const ()

[Bernhard Übelacker]

Dear Maintainer,
I tried to have a look at the core file and a backtrace
with all needed symbols looks like in [1].

In the end it looks like in refresh_combo_devices [2] it
is attempted to load a harddisk icon.

This failed for some reason in [3], therefore a local variable
"theme_icon" contains a null pointer, which gets unconditionally
called member function get_width on and therefore
crashes a few lines later.

A wild guess would be that the harddisk icon file
is missing or is not accessible.
Possibly there is some hint written to stdout before the crash.

Kind regards,
Bernhard


[1]
(gdb) bt
#0  Gdk::Pixbuf::gobj (this=0x0) at ../gdkmm/pixbuf.h:389
#1  Gdk::Pixbuf::get_width (this=0x0) at pixbuf.cc:517
#2  0xaab89ca4 in GParted::Utils::mk_pixbuf (widget=..., 
stock_id=..., icon_size=..., icon_size@entry=...) at 
/usr/include/glibmm-2.4/glibmm/refptr.h:259
#3  0xaab92020 in GParted::Win_GParted::refresh_combo_devices 
(this=0xe960) at /usr/include/gtkmm-3.0/gtkmm/enums.h:2870
#4  0xaab95980 in GParted::Win_GParted::menu_gparted_refresh_devices 
(this=) at Win_GParted.cc:1674
#5  0xaab95e2c in GParted::Win_GParted::initial_device_refresh 
(data=) at Win_GParted.cc:1605
#6  0xf6b8dab4 in g_main_dispatch (context=0xaaca6f10) at 
../../../glib/gmain.c:3325
#7  g_main_context_dispatch (context=0xaaca6f10) at 
../../../glib/gmain.c:4043
#8  0xf6b8de5c in g_main_context_iterate (context=0xaaca6f10, 
block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
../../../glib/gmain.c:4119
#9  0xf6b8e1b0 in g_main_loop_run (loop=loop@entry=0xabb23860) 
at ../../../glib/gmain.c:4317
#10 0xf70b98f0 in gtk_main () at ../../../../gtk/gtkmain.c:1328
#11 0xaab2138c in main (argc=, argv=) 
at main.cc:62

[2]
https://gitlab.gnome.org/GNOME/gparted/-/blob/master/src/Win_GParted.cc#L727

[3]
https://gitlab.gnome.org/GNOME/gparted/-/blob/master/src/Utils.cc#L109

# Bullseye/testing arm64 qemu VM 2021-03-25

echo "set enable-bracketed-paste off" >> /etc/inputrc; bash
apt update

# to speedup testing
mv /etc/manpath.config /etc/manpath.config.renamed
apt install libeatmydata1
export LD_PRELOAD=/usr/lib/$(uname -m)-linux-gnu/libeatmydata.so

apt dist-upgrade
apt install gdb zstd mc gparted \
gparted-dbgsym libgtk-3-0-dbgsym libgtkmm-3.0-1v5-dbgsym 
libglib2.0-0-dbgsym
apt build-dep gparted





mkdir /home/benutzer/source/gparted/orig -p
cd/home/benutzer/source/gparted/orig
apt source gparted
cd





wget 
"https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=984953;filename=gpartedbin.core.tar.zstd;msg=10";
 -O gpartedbin.core.tar.zstd
tar axf gpartedbin.core.tar.zstd

gdb -q --core gpartedbin.core
gdb -q /usr/sbin/gpartedbin --core gpartedbin.core

set width 0
set pagination off


Core was generated by `/usr/sbin/gpartedbin'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0xf794d760 in Gdk::Pixbuf::get_width() const () from 
/usr/lib/aarch64-linux-gnu/libgdkmm-3.0.so.1
[Current thread is 1 (Thread 0xf51947a0 (LWP 9937))]
(gdb) set width 0
(gdb) set pagination off
(gdb) bt
#0  0xf794d760 in Gdk::Pixbuf::get_width() const () from 
/usr/lib/aarch64-linux-gnu/libgdkmm-3.0.so.1
#1  0xaab89ca4 in ?? ()
#2  0xaab92020 in ?? ()
#3  0xaab95e2c in ?? ()
#4  0xf6b8dab4 in g_main_context_dispatch () from 
/usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#5  0xf6b8de5c in ?? () from /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#6  0xf6b8e1b0 in g_main_loop_run () from 
/usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#7  0xf70b98f0 in gtk_main () from 
/usr/lib/aarch64-linux-gnu/libgtk-3.so.0
#8  0xaab2138c in ?? ()
#9  0xf6707218 in __libc_start_main (main=0xaab21290, argc=1, 
argv=0xf4e8, init=, fini=, 
rtld_fini=, stack_end=) at ../csu/libc-start.c:308
#10 0xaab219ec in ?? ()
Backtrace stopped: not enough registers or memory available to unwind further


Core was generated by `/usr/sbin/gpartedbin'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  Gdk::Pixbuf::gobj (this=0x0) at ../gdkmm/pixbuf.h:389
389 ../gdkmm/pixbuf.h: No such file or directory.
[Current thread is 1 (Thread 0xf51947a0 (LWP 9937))]
(gdb) set width 0
(gdb) set pagination off
(gdb) bt
#0  Gdk::Pixbuf::gobj (this=0x0) at ../gdkmm/pixbuf.h:389
#1  Gdk::Pixbuf::get_width (this=0x0) at pixbuf.cc:517
#2  0xaab89ca4 in GParted::Utils::mk_pixbuf (widget=..., stock_id=..., 
icon_size=..., icon_size@entry=...) at 
/usr/include/glibmm-2.4/glibmm/refptr.h:259
#3  0xaab92020 in GParted::Win_GParted::refresh_combo_devices 
(this=0xe960) at /usr/include/gtkmm-3.0/gtkmm/enums.h:2870
#4  0xaab95980 in GParted::Win_GParted::menu_gparted_refresh_devices 
(this=) at Win_GParted.cc:1674
#5  0xaab95e2c in GParted::Win_GParted::initial_device_

Bug#972339: armhf: hpcups crashes with free() invalid pointer for some printers

[Bernhard Übelacker]

Hello Didier,
I have retried with the patch in #974828, but it still
crashed with the test files from this bug, therefore
I guess #974828 is similar but unrelated.


Then I took another look at the valgrind runs and found
that these invalid reads and writes also appear at amd64.

After some digging I gave up to understand the pointer
calculations and such and tried to just increase the
allocations and came up with the attached three patches.

(While working at #974828 I found one such "+ 32" in
HPCupsFilter.cpp which might be already a workaround by upstream?)


With these three applied a valgrind run shows no more errors
with amd64 or armhf, and also does not abort at armhf.

As this just allocates a few extra bytes I assume that the
print result should not be different by these patches.
And I hope that memset'ing these buffers has no security
related effects.

For the crash is just the Halftoner patch important.
The other two are currently just for valgrind, but that
might change in future with compiler changes or similar.

What do you think?

Kind regards,
Bernhard

Description: Workaround: Add 32 bytes to allocation ColorMatcher

Bug-Debian: https://bugs.debian.org/972339
Bug-Ubuntu: https://launchpad.net/bugs/1901209
Last-Update: 2021-02-27

==12899== Invalid read of size 1
==12899==at 0x1174D6: Backward16PixelsNonWhite (Halftoner.h:106)
==12899==by 0x1174D6: Halftoner::HTEDiffOpen(Halftoner::THTDitherParms*, unsigned short) (Halftoner.cpp:734)
==12899==by 0x117C67: Halftoner::Process(RASTERDATA*) (Halftoner.cpp:548)
==12899==by 0x115D5F: Process (Pipeline.cpp:72)
==12899==by 0x115D5F: Pipeline::Execute(RASTERDATA*) (Pipeline.cpp:79)
==12899==by 0x115D81: Pipeline::Execute(RASTERDATA*) (Pipeline.cpp:83)
==12899==by 0x10D151: HPCupsFilter::processRasterData(_cups_raster_s*) (HPCupsFilter.cpp:779)
==12899==by 0x10D651: HPCupsFilter::StartPrintJob(int, char**) (HPCupsFilter.cpp:597)
==12899==by 0x4B9BA1F: (below main) (libc-start.c:308)
==12899==  Address 0x55f8ed2 is 6 bytes after a block of size 12,100 alloc'd
==12899==at 0x48416F4: operator new[](unsigned int) (vg_replace_malloc.c:425)
==12899==by 0x116011: ColorMatcher::ColorMatcher(ColorMap_s, unsigned int, unsigned int) (ColorMatcher.cpp:63)
==12899==by 0x11101B: Pcl3::Configure(Pipeline**) (Pcl3.cpp:90)
==12899==by 0x115B71: Job::Configure() (Job.cpp:248)
==12899==by 0x115C07: Job::Init(SystemServices*, JobAttributes_s*, Encapsulator*) (Job.cpp:63)
==12899==by 0x10C9C1: HPCupsFilter::startPage(cups_page_header2_s*) (HPCupsFilter.cpp:481)
==12899==by 0x10D273: HPCupsFilter::processRasterData(_cups_raster_s*) (HPCupsFilter.cpp:668)
==12899==by 0x10D651: HPCupsFilter::StartPrintJob(int, char**) (HPCupsFilter.cpp:597)
==12899==by 0x4B9BA1F: (below main) (libc-start.c:308)

--- hplip-3.20.11+dfsg0.orig/prnt/hpcups/ColorMatcher.cpp
+++ hplip-3.20.11+dfsg0/prnt/hpcups/ColorMatcher.cpp
@@ -60,7 +60,8 @@ ColorMatcher::ColorMatcher
 EndPlane = K;
 }
 
-Contone = (BYTE *) new BYTE[InputWidth * ColorPlaneCount];
+Contone = (BYTE *) new BYTE[InputWidth * ColorPlaneCount + 32];
+memset(Contone, 0, InputWidth * ColorPlaneCount + 32);
 if (Contone == NULL)
 {
 goto MemoryError;
Description: Workaround: Add 32 bytes to allocation Halftoner

Bug-Debian: https://bugs.debian.org/972339
Bug-Ubuntu: https://launchpad.net/bugs/1901209
Last-Update: 2021-02-27

==144269== Invalid read of size 1
==144269==at 0x114577: Mode9::Process(RASTERDATA*) (Mode9.cpp:332)
==144269==by 0x11EDA4: Process (Pipeline.cpp:72)
==144269==by 0x11EDA4: Pipeline::Execute(RASTERDATA*) (Pipeline.cpp:79)
==144269==by 0x11EDDF: Pipeline::Execute(RASTERDATA*) (Pipeline.cpp:83)
==144269==by 0x11EDDF: Pipeline::Execute(RASTERDATA*) (Pipeline.cpp:83)
==144269==by 0x112677: HPCupsFilter::processRasterData(_cups_raster_s*) (HPCupsFilter.cpp:779)
==144269==by 0x112DE8: HPCupsFilter::StartPrintJob(int, char**) (HPCupsFilter.cpp:597)
==144269==by 0x4C17D09: (below main) (libc-start.c:308)
==144269==  Address 0x5a8cc0b is 0 bytes after a block of size 379 alloc'd
==144269==at 0x483950F: operator new[](unsigned long) (vg_replace_malloc.c:431)
==144269==by 0x12047B: Halftoner::Halftoner(PrintMode_s*, unsigned int, int*, int, bool) (Halftoner.cpp:184)
==144269==by 0x11817B: Pcl3::Configure(Pipeline**) (Pcl3.cpp:92)
==144269==by 0x11EA30: Job::Configure() (Job.cpp:248)
==144269==by 0x11EB67: Job::Init(SystemServices*, JobAttributes_s*, Encapsulator*) (Job.cpp:63)
==144269==by 0x111A35: HPCupsFilter::startPage(cups_page_header2_s*) (HPCupsFilter.cpp:481)
==144269==by 0x112792: HPCupsFilter::processRasterData(_cups_raster_s*) (HPCupsFilter.cpp:668)
==144269==by 0x112DE8: HPCupsFilter::StartPrintJob(int, char**) (HPCupsFilter.cpp:597)
==144269==by 0x4C17D09: (below main) (libc-start.c:308)

--- hplip-3.20.11+dfsg0.orig/prnt/hpcups/Halfto

Bug#974828: printer-driver-hpcups: SIGABRT with "free(): invalid next size (normal)" in HPCupsFilter::cleanup

[Bernhard Übelacker]

Hello Ian,

Am 27.02.21 um 08:49 schrieb Ian Campbell:

On Fri, 2021-02-26 at 15:41 +0100, Bernhard Übelacker wrote:

The attached patch is an attempt to grow the buffer size
if the header changes on a new page.
This is just tested for the given crash, nothing more, therefore
there might be side effects on replacing this buffer?


It doesn't look unreasonable to me, although the related shuffling of
pointers between rgbRaster, kRaster and m_pPrinterBuffer makes my head
hurt a bit (this code could really do with a dollop of modern c++
memory management idiom).

Do you think there is a need to preserve the current contents (e.g.
something approximating realloc rather than delete+new)? Or maybe it is
fine to simply unconditionally allocate a new buffer each time round
the loop? It could almost be a local variable like *Raster at that
point... But I think if you are looking for a minimal fix your patch
seems pretty sensible to me (speaking as a competent enough C/C++
programmer but not someone familiar with this codebase before today).

Ian.


I guess I am similar unfamiliar with this code as you - so I am not 
really sure if there is any interaction with the old content or pointers 
stored to the old memory for later use ...

(I was just doing the debugging fun ;-) )
I had hoped, now as we could point to a source location,
that upstream could judge about it ...

Kind regards,
Bernhard

Bug#974828: printer-driver-hpcups: SIGABRT with "free(): invalid next size (normal)" in HPCupsFilter::cleanup

[Bernhard Übelacker]

Dear Maintainer,
with the original PPD and input files from Ian I could
reproduce the issue and with the help of rr-debugger
this is what I assume what happens:

- The buffer m_pPrinterBuffer is allocated here with
  the current sizes inside cups_header. [1]

- The first page got processed and for the second page
  a new cups_header record gets copied. [2]
  Unfortunately now the header contains higher sizes,
  but the buffer is not grown accordingly.

- Now to this buffer is written by a read function, and beyond
  where the management information of malloc got overwritten for
  some other random memory. [3]

- The defect in the management information of malloc is detected
  and the process is aborted. [4]


The attached patch is an attempt to grow the buffer size
if the header changes on a new page.
This is just tested for the given crash, nothing more, therefore
there might be side effects on replacing this buffer?


Kind regards,
Bernhard


[1]
500 m_pPrinterBuffer = new BYTE[cups_header->cupsWidth * 4 + 32];
(rr) bt
#0  HPCupsFilter::startPage (this=0x556369c551c0 , 
cups_header=0x7ffe94b8e030) at prnt/hpcups/HPCupsFilter.cpp:500
#1  0x556369bf4793 in HPCupsFilter::processRasterData 
(this=this@entry=0x556369c551c0 , cups_raster=, 
cups_raster@entry=0x55636ac39d00) at prnt/hpcups/HPCupsFilter.cpp:668
#2  0x556369bf4de9 in HPCupsFilter::StartPrintJob (this=0x556369c551c0 
, argc=, argv=0x7ffe94b8ecf8) at 
prnt/hpcups/HPCupsFilter.cpp:597
...
(rr) when
Current event: 898

[2]
#0  0x7f504dcaa190 in memcpy (__len=1796, __src=0x564615c8cd1c, 
__dest=0x7ffc2a13f080) at 
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
#1  cupsRasterReadHeader2 (r=0x564615c8cd00, h=h@entry=0x7ffc2a13f080) at 
raster-stubs.c:209
#2  0x5646141d356d in HPCupsFilter::processRasterData 
(this=this@entry=0x5646142341c0 , cups_raster=, 
cups_raster@entry=0x564615c8cd00) at prnt/hpcups/HPCupsFilter.cpp:661
#3  0x5646141d3de9 in HPCupsFilter::StartPrintJob (this=0x5646142341c0 
, argc=, argv=0x7ffc2a13fd48) at 
prnt/hpcups/HPCupsFilter.cpp:597
#4  0x7f504d83fd0a in __libc_start_main (main=0x5646141d0e10 , argc=6, 
argv=0x7ffc2a13fd48, init=, fini=, rtld_fini=, stack_end=0x7ffc2a13fd38) at ../csu/libc-start.c:308
#5  0x5646141d0efa in _start ()
(rr) when
Current event: 1230

[3]
...
#9  0x7f504dcaa00d in read (__nbytes=19220, __buf=0x564615cb1ca0, 
__fd=0) at /usr/include/x86_64-linux-gnu/bits/unistd.h:44
#10 cups_read_fd (ctx=, buf=0x564615cb1ca0 '\377' ..., bytes=19220) at raster-stubs.c:323
#11 0x7f504dca9340 in cups_raster_io (bytes=19220, buf=0x564615cb1ca0 '\377' 
..., r=0x564615c8cd00) at raster-stream.c:1372
#12 _cupsRasterReadPixels (r=0x564615c8cd00, p=0x564615cb1ca0 '\377' ..., len=19220) at raster-stream.c:782
#13 0x7f504dcaa1e5 in cupsRasterReadPixels (r=, p=, len=) at raster-stubs.c:228
#14 0x5646141d36e8 in HPCupsFilter::processRasterData 
(this=this@entry=0x5646142341c0 , cups_raster=, 
cups_raster@entry=0x564615c8cd00) at prnt/hpcups/HPCupsFilter.cpp:758
#15 0x5646141d3de9 in HPCupsFilter::StartPrintJob (this=0x5646142341c0 
, argc=, argv=0x7ffc2a13fd48) at 
prnt/hpcups/HPCupsFilter.cpp:597
...

[4]
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7f504d83e537 in __GI_abort () at abort.c:79
#2  0x7f504d897768 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7f504d9a5e31 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x7f504d89ea5a in malloc_printerr (str=str@entry=0x7f504d9a8258 "free(): 
invalid next size (normal)") at malloc.c:5347
#4  0x7f504d89ff2c in _int_free (av=0x7f504d9d7b80 , 
p=0x564615cb1c90, have_lock=) at malloc.c:4322
#5  0x5646141d15c6 in HPCupsFilter::cleanup (this=this@entry=0x5646142341c0 
) at prnt/hpcups/HPCupsFilter.cpp:227
#6  0x5646141d3e1b in HPCupsFilter::closeFilter (this=0x5646142341c0 
) at prnt/hpcups/HPCupsFilter.cpp:221
#7  HPCupsFilter::StartPrintJob (this=0x5646142341c0 , argc=, argv=0x7ffc2a13fd48) at prnt/hpcups/HPCupsFilter.cpp:617
...

Description: Grow m_pPrinterBuffer if needed on each page

Author: Bernhard Übelacker 
Bug-Debian: https://bugs.debian.org/974828
Bug-Ubuntu: https://launchpad.net/bugs/1904318
Last-Update: 2021-02-26

Index: hplip-3.20.11+dfsg0/prnt/hpcups/HPCupsFilter.cpp
===
--- hplip-3.20.11+dfsg0.orig/prnt/hpcups/HPCupsFilter.cpp
+++ hplip-3.20.11+dfsg0/prnt/hpcups/HPCupsFilter.cpp
@@ -199,7 +199,7 @@ void HPCupsFilter::WriteKBMPRaster (FILE
 fwrite (black_raster, 1, adj_k_width, fp);
 }
 
-HPCupsFilter::HPCupsFilter() : m_pPrinterBuffer(NULL)
+HPCupsFilter::HPCupsFilter() : m_pPrinterBuffer(NULL), m_PrinterBufferSize(0)
 {
 setbuf (stderr, NULL);
 
@@ 

Bug#974828: Fwd: Bug#974828: printer-driver-hpcups: SIGABRT with "free(): invalid next size (normal)" in HPCupsFilter::cleanup

[Bernhard Übelacker]

Sorry missed your email.


 Weitergeleitete Nachricht 
Betreff: Re: Bug#974828: printer-driver-hpcups: SIGABRT with "free(): 
invalid next size (normal)" in HPCupsFilter::cleanup

Datum: Thu, 25 Feb 2021 17:03:02 +0100
Von: Bernhard Übelacker 
An: 974...@bugs.debian.org



Hello Ian,
I tried to collect some informations for the
maintainer in the other report #972339.
Therefore I tried to reproduce this issue now too, because
my amd64 hardware is much faster as my armhf systems...

But I failed to reproduce maybe because I use the wrong ppd file,
or something else might be different here.

Do you still see this issue?

Maybe you could make your
/etc/cups/ppd/HP_Officejet_Pro_8610.ppd public?

Or maybe this issue might be reproducible just with
one of your print_step_2.raster file,
if size permits and its possible to make it public?

Kind regards,
Bernhard

Bug#974828: printer-driver-hpcups: SIGABRT with "free(): invalid next size (normal)" in HPCupsFilter::cleanup

[Bernhard Übelacker]

Hello Ian,
I tried to collect some informations for the
maintainer in the other report #972339.
Therefore I tried to reproduce this issue now too, because
my amd64 hardware is much faster as my armhf systems...

But I failed to reproduce maybe because I use the wrong ppd file,
or something else might be different here.

Do you still see this issue?

Maybe you could make your
/etc/cups/ppd/HP_Officejet_Pro_8610.ppd public?

Or maybe this issue might be reproducible just with
one of your print_step_2.raster file,
if size permits and its possible to make it public?

Kind regards,
Bernhard

Bug#943396: FTBFS on armhf: testsuite segfault

[Bernhard Übelacker]

Dear Maintainer,
a short addition.
The backtrace that I received building with CC=gcc-10 seems
to be the same as in #972665, therefore they might be related?

Kind regards,
Bernhard

Bug#972339: armhf: hpcups crashes with free() invalid pointer for some printers

[Bernhard Übelacker]

Dear Maintainer,
I could reproduce this issue too.

Attached is a valgrind run showing one invalid write
and a gdb session showing the issue.

It looks like mallocs management data, which resides in the 8 bytes
before a returned pointer, gets overwritten and therefore
the free fails because "mchunk_size" is then 0.

Kind regards,
Bernhard


Old value = 6057
New value = 0
__memcpy_neon () at ../sysdeps/arm/armv7/multiarch/memcpy_impl.S:295
warning: Source file is more recent than executable.
295 tst count, #4
1: compressBuf = 
2: /x *(int*)(0x7f5f43e8-4) = 0x0
(gdb) bt
#0  __memcpy_neon () at ../sysdeps/arm/armv7/multiarch/memcpy_impl.S:295
#1  0x7f55b8d2 in memcpy (__len=379, __src=, 
__dest=) at 
/usr/include/arm-linux-gnueabihf/bits/string_fortified.h:34
#2  Mode9::Process (this=0x7f5e0e70, input=0x7f5e0e84) at 
prnt/hpcups/Mode9.cpp:405
#3  0x7f562de0 in Pipeline::Process (raster=, 
this=0x7f5d7340) at prnt/hpcups/Pipeline.cpp:79
#4  Pipeline::Execute (this=0x7f5d7340, InputRaster=) at 
prnt/hpcups/Pipeline.cpp:79
#5  0x7f562e02 in Pipeline::Execute (this=0x7f5e6b88, 
InputRaster=) at prnt/hpcups/Pipeline.cpp:83
#6  0x7f562e02 in Pipeline::Execute (this=0x7f5e6b70, 
InputRaster=) at prnt/hpcups/Pipeline.cpp:83
#7  0x7f55a20a in HPCupsFilter::processRasterData (this=0x7f5b87c4 
, cups_raster=) at prnt/hpcups/HPCupsFilter.cpp:766
#8  0x7f55a6ee in HPCupsFilter::StartPrintJob (this=0x7f5b87c4 , 
argc=6, argv=0xbefff7b4) at prnt/hpcups/HPCupsFilter.cpp:584
#9  0xb6bd9a20 in __libc_start_main (main=0x7f5587d1 , 
argc=6, argv=0xbefff7b4, init=, fini=0x7f56ed5d 
<__libc_csu_fini>, rtld_fini=0xb6fe1075 <_dl_fini>, stack_end=0xbefff7b4) at 
libc-start.c:308
#10 0x7f55889c in _start () at prnt/hpcups/HPCupsFilter.cpp:919


https://sources.debian.org/src/hplip/3.20.5+dfsg0-3/prnt/hpcups/Mode9.cpp/#L405


# Bullseye/testing chroot 2020-10-23 running on Android/LineageOS kernel


apt update
apt dist-upgrade


apt install mc htop psmisc net-tools strace sshfs wget gdb gdbserver cups 
printer-driver-hpcups printer-driver-hpcups-dbgsym
apt build-dep libc6



root@localhost:~# lscpu
Architecture: armv7l
Byte Order:   Little Endian
CPU(s):   4
On-line CPU(s) list:  0
Off-line CPU(s) list: 1-3
Thread(s) per core:   1
Core(s) per socket:   1
Socket(s):1
Vendor ID:Qualcomm
Model:0
Model name:   Krait
Stepping: 0x1
CPU max MHz:  1728,
CPU min MHz:  384,
BogoMIPS: 13.50
Flags:swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 
idiva idivt
root@localhost:~# uname -a
Linux localhost 3.4.113-g2fff5b1955c0 #1 SMP PREEMPT Sun Mar 8 06:23:52 CST 
2020 armv7l GNU/Linux

groupadd -g 3001 aid_net_bt_admin
groupadd -g 3002 aid_net_bt
groupadd -g 3003 aid_inet
groupadd -g 3004 aid_net_raw
groupadd -g 3005 aid_net_admin
groupadd -g 3006 aid_net_bw_stats
groupadd -g 3007 aid_net_bw_acct
groupadd -g 3008 aid_net_bt_stack
usermod -G 3003,3004 -a root
usermod -G 3003 -a benutzer
usermod -g 3003 -G 3003,3004 -a _apt

root@localhost:~# dpkg -l | grep driver-hpcups
ii  printer-driver-hpcups 3.20.5+dfsg0-3+b1  armhf
HP Linux Printing and Imaging - CUPS Raster driver (hpcups)
ii  printer-driver-hpcups-dbgsym  3.20.5+dfsg0-3+b1  armhf
debug symbols for printer-driver-hpcups






mkdir /home/benutzer/source/libc6/orig -p
cd/home/benutzer/source/libc6/orig
apt source libc6
cd










wget 
https://sources.debian.org/data/main/h/hplip/3.20.9+dfsg0-3/ppd/hpcups/hp-officejet_pro_1150c.ppd
gzip hp-officejet_pro_1150c.ppd

export PPD=/home/benutzer/hp-officejet_pro_1150c.ppd.gz
/usr/lib/cups/filter/pdftopdf   1 debian '' 1 '' 
print_step_1.pdf
/usr/lib/cups/filter/gstoraster 1 debian '' 1 '' print_step_2.raster
/usr/lib/cups/filter/hpcups 1 debian '' 1 '' print_step_3.hpcups




/usr/bin/gdbserver localhost: /usr/lib/cups/filter/hpcups 1 debian '' 1 
'' print_step_3.hpcups

gdb -q
set width 0
set pagination off
target remote localhost:
cont




benutzer@localhost:~$ /usr/bin/gdbserver localhost: 
/usr/lib/cups/filter/hpcups 1 debian x 1 x print_step_3.hpcups
Process /usr/lib/cups/filter/hpcups created; pid = 9723
Listening on port 
Remote debugging from host ::1, port 42055
STATE: -marker-supply-low-warning
PAGE: 1 1
free(): invalid pointer



benutzer@localhost:~$ gdb -q
(gdb) set width 0
(gdb) set pagination off
(gdb) target remote localhost:
Remote debugging using localhost:
Reading /usr/lib/cups/filter/hpcups from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to 
access files locally instead.
Reading /usr/lib/cups/filter/hpcups from remote target...
Reading symbols from target:/usr/lib/cups/filter/hpcups...
Reading /usr/lib/cups/filter/25b6b40d5874920ba6c57ce85bb60b35661f71.debug from 

Bug#966638: gkrellm-cpufreq: Error: /usr/lib/gkrellm2/plugins/cpufreq.so: undefined symbol: cpufreq_cpu_exists

[Bernhard Übelacker]

Dear Maintainer,
it seems like previous versions just optimized the call to
cpufreq_cpu_exists away? The current build relies to have the
symbol external defined.
Attached patch tries to query the number of CPUs from another
function and (kind of ugly) avoids a later crash if frequencies
could not be queried.
Therefore and because the last upstream version is from 2006
one might ask if this package is really still useful?
(At least on amd64?)

Kind regards,
Bernhard
Description: Get number of CPUs

Author: Bernhard Übelacker 
Bug-Debian: https://bugs.debian.org/966638
Forwarded: no
Last-Update: 2020-10-16

Index: gkrellm2-cpufreq-0.6.4/cpufreq.c
===
--- gkrellm2-cpufreq-0.6.4.orig/cpufreq.c
+++ gkrellm2-cpufreq-0.6.4/cpufreq.c
@@ -49,6 +49,7 @@
 
 #include 
 #include 
+#include 
 
 /* version number */
 #define  VERSION"0.6.4"
@@ -616,8 +617,7 @@ GkrellmMonitor* gkrellm_init_plugin(void
   monitor = &plugin_mon;
 
   /* determine number of cpus */
-  for( ncpu = 0; cpufreq_cpu_exists(ncpu)==0; ++ncpu )
-;
+  ncpu = get_nprocs();
   ncpu = ncpu > NCPU_MAX ? NCPU_MAX : ncpu;
 
   /* determine maximal frequency */
@@ -625,7 +625,10 @@ GkrellmMonitor* gkrellm_init_plugin(void
   for ( cpu = 0; cpu

Bug#972185: libre0: stack smashing detected in v1.1.0

[Bernhard Übelacker]

Hello Kevin,
I don't know the details, but I guess there will no automatic
rebuild of baresip triggered on migration.
As far as I see [1], the only users of libre0 are
baresip and librem0, so I guess both might need a rebuild.
Maybe someone with more shared library packaging knowledge
might give some pointers what steps need to be taken now?

Kind regards,
Bernhard

[1] `apt-cache rdepends libre0` in an unstable VM.

Bug#972185: libre0: stack smashing detected in v1.1.0

[Bernhard Übelacker]

Dear Maintainer,
I could reproduce the issue and it looks like there is a ABI break
of libre0 because the size of struct sip_addr has changed
from 152 bytes to 168, and therefore overwrites the stack canary here [1].

A baresip built agains libre0 1.1.0-1 did not show this problem.

Kind regards,
Bernhard


[1]
(rr) bt
#0  0x7f9dc0bf22eb in memset (__len=168, __ch=0, __dest=0x7fff4bc3ae80) at 
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:71
#1  sip_addr_decode (addr=addr@entry=0x7fff4bc3ae80, 
pl=pl@entry=0x7fff4bc3af50) at src/sip/addr.c:32
#2  0x556a958a831c in call_connect (call=0x556a95dbb7a0, 
paddr=paddr@entry=0x7fff4bc3af50) at src/call.c:932
#3  0x556a958b635c in ua_connect (ua=0x556a95db6940, callp=callp@entry=0x0, 
from_uri=from_uri@entry=0x0, req_uri=req_uri@entry=0x556a95dbd5a0 "sip:", '0' 
, "@fritz.box", vmode=vmode@entry=VIDMODE_ON) at src/ua.c:928
#4  0x7f9dc02a5e1f in dial_handler (pf=, arg=0x7fff4bc3b030) 
at modules/menu/menu.c:266
#5  0x556a9586 in cmd_report (data=0x0, mb=, 
pf=0x7f9dc0c66020 , cmd=0x7f9dc02aa8c0 ) at src/cmd.c:293
#6  cmd_process_edit (commands=, ctxp=, 
key=, pf=, data=0x0) at src/cmd.c:389
#7  0x556a958aaf74 in cmd_process (commands=, 
ctxp=, key=, pf=pf@entry=0x7f9dc0c66020 
, data=data@entry=0x0) at src/cmd.c:539
#8  0x556a958b7fe0 in ui_input_key (uis=, key=key@entry=10 
'\n', pf=pf@entry=0x7f9dc0c66020 ) at src/ui.c:66
#9  0x7f9dc0c6348a in report_key (ui=, key=10 '\n') at 
modules/stdio/stdio.c:66
#10 ui_fd_handler (flags=, arg=) at 
modules/stdio/stdio.c:90
#11 0x7f9dc0c312dc in fd_poll (re=re@entry=0x7f9dc0c5d0e0 ) at 
src/main/main.c:896
#12 0x7f9dc0c31d52 in re_main (signalh=0x556a958babd0 ) at 
src/main/main.c:1030
#13 0x556a958a052f in main (argc=, argv=) at 
src/main.c:301


# Unstable amd64 qemu VM 2020-10-14


apt update
apt dist-upgrade


apt install systemd-coredump mc htop fakeroot gdb rr baresip 
baresip-core-dbgsym libre0-dbgsym
apt build-dep libre0
apt build-dep baresip
echo 1 > /proc/sys/kernel/perf_event_paranoid




mkdir /home/benutzer/source/libre0/orig -p
cd/home/benutzer/source/libre0/orig
apt source libre0
cd

mkdir /home/benutzer/source/baresip-core/orig -p
cd/home/benutzer/source/baresip-core/orig
apt source baresip-core
cd




baresip
d
sip:...@fritz.box



benutzer@debian:~$ baresip
baresip v1.0.0 Copyright (C) 2010 - 2020 Alfred E. Heggestad et al.
Local network address:  IPv4=ens4|10.0.2.15  IPv6=ens4|fec0::5054:ff:fe12:3456
aucodec: PCMU/8000/1
aucodec: PCMA/8000/1
ausrc: alsa
auplay: alsa
medianat: stun
medianat: turn
medianat: ice
Populated 1 account
Populated 3 contacts
Populated 2 audio codecs
Populated 0 audio filters
Populated 0 video codecs
Populated 0 video filters
baresip is ready.
>sip:...@fritz.box
ua: using best effort AF: af=AF_INET
call: connecting to 'sip:...@fritz.box'..
*** stack smashing detected ***: terminated
Abgebrochen (Speicherabzug geschrieben)



root@debian:~# journalctl -e
...
Okt 14 17:49:57 debian systemd[1]: Started Process Core Dump (PID 11453/UID 0).
Okt 14 17:49:58 debian systemd-coredump[11454]: Process 11451 (baresip) of user 
1000 dumped core.

Stack trace of thread 11451:
#0  0x7f7c802e8c41 
__GI_raise (libc.so.6 + 0x3bc41)
#1  0x7f7c802d2537 
__GI_abort (libc.so.6 + 0x25537)
#2  0x7f7c8032b6c8 
__libc_message (libc.so.6 + 0x7e6c8)
#3  0x7f7c803ba5b2 
__GI___fortify_fail (libc.so.6 + 0x10d5b2)
#4  0x7f7c803ba590 
__stack_chk_fail (libc.so.6 + 0x10d590)
#5  0x55ccf95ed3da 
call_connect (baresip + 0x143da)
#6  0x55ccf95fb35c 
ua_connect (baresip + 0x2235c)
#7  0x7f7c7fdb9e1f n/a 
(menu.so + 0x4e1f)
#8  0x55ccf95efaa6 n/a 
(baresip + 0x16aa6)
#9  0x7f7c8067348a n/a 
(stdio.so + 0x148a)
#10 0x7f7c8063f2dc n/a 
(libre.so.0 + 0x562dc)
#11 0x7f7c8063fd52 re_main 
(libre.so.0 + 0x56d52)
#12 0x55ccf95e552f main 
(baresip + 0xc52f)
#13 0x7f7c802d3cca 
__libc_start_main (libc.so.6 + 0x26cca)
#14 0x55ccf95e56ba _start 
(baresip + 0xc6ba)
Okt 14 17:49:58 debian systemd[1]: systemd-coredump@2-11453-0.service: 
Succeeded.



root@debian:~# coredumpctl lis

Bug#970763: wminput immedinately exits with Segmentation Fault on use

[Bernhard Übelacker]

Dear Maintainer,
I tried to track down the segfault and I guess it is related to
the usage of "-shared" when linking wminput [1].
Therefore, I guess, the resulting wminput binary is build like
a shared object instead of an executable.

A binary built without "-shared" shows a version info with "--version".

Kind regards,
Bernhard


[1] 
https://salsa.debian.org/georgesk/cwiid/-/commit/bd0f4c89556dbaed72e3082c5273b986cd47c35a#748fb62c420a28ecccff1a9a6c92a29a7dc3f4eb_19_18


# Bullseye/testing amd64 qemu VM 2020-10-10


apt update
apt dist-upgrade


apt install systemd-coredump mc htop quilt fakeroot gdb rr wminput 
wminput-dbgsym
apt build-dep wminput




mkdir /home/benutzer/source/wminput/orig -p
cd/home/benutzer/source/wminput/orig
apt source wminput
cd








benutzer@debian:~$ wminput --version
Speicherzugriffsfehler (Speicherabzug geschrieben)


root@debian:~# journalctl -e
...
Okt 10 13:43:51 debian kernel: wminput[2343]: segfault at 2 ip 0002 
sp 7fff69ea69c8 error 14 in wminput[7f3fa2bff000+7000]
Okt 10 13:43:51 debian kernel: Code: Bad RIP value.
Okt 10 13:43:51 debian systemd[1]: Created slice 
system-systemd\x2dcoredump.slice.
Okt 10 13:43:51 debian systemd[1]: Started Process Core Dump (PID 2344/UID 0).
Okt 10 13:43:52 debian systemd-coredump[2345]: Process 2343 (wminput) of user 
1000 dumped core.
   
   Stack trace of thread 2343:
   #0  0x0002 n/a (n/a 
+ 0x0)
Okt 10 13:43:52 debian systemd[1]: systemd-coredump@0-2344-0.service: Succeeded.


root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Sat 2020-10-10 13:43:52 CEST   2343  1000  1000  11 present   /usr/bin/wminput


root@debian:~# coredumpctl gdb 2343
   PID: 2343 (wminput)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 11 (SEGV)
 Timestamp: Sat 2020-10-10 13:43:51 CEST (1min 18s ago)
  Command Line: wminput --version
Executable: /usr/bin/wminput
 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: 14e01e6856a647e78081573d2c4ee54d
Machine ID: 33f18f39d2a9438eb75b0ed52848afcd
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.wminput.1000.14e01e6856a647e78081573d2c4ee54d.2343.160233023100.zst
   Message: Process 2343 (wminput) of user 1000 dumped core.

Stack trace of thread 2343:
#0  0x0002 n/a (n/a + 0x0)

GNU gdb (Debian 9.2-1) 9.2
Copyright (C) 2020 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/wminput...
(No debugging symbols found in /usr/bin/wminput)
[New LWP 2343]
Core was generated by `wminput --version'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0002 in ?? ()
(gdb) bt
#0  0x0002 in ?? ()
#1  0x7fff69ea8868 in ?? ()
#2  0x7fff69ea8870 in ?? ()
#3  0x in ?? ()







benutzer@debian:~$ rr wminput --version
rr: Saving execution to trace directory 
`/home/benutzer/.local/share/rr/wminput-0'.
Speicherzugriffsfehler



benutzer@debian:~$ rr replay /home/benutzer/.local/share/rr/wminput-0
GNU gdb (Debian 9.2-1) 9.2
Copyright (C) 2020 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/wminput...
Reading symbols from 
/usr/lib/debug/.build-id/83/0f5a5b55af2a7278f125c2ffcb446e9a7f16a3.debug...
Really redefine built-in command "restart"? (y or n) [answered Y; input not 
from terminal]
Remote debuggin

Bug#970878: ghostscript breaks doc-rfc autopkgtest: segmentation fault

[Bernhard Übelacker]

Dear Maintainer,
tried to have a look at this one, found the segfault [1],
and can point to the place where the pointer gets overwritten [2].
Unfortunately Valgrind or ASAN gave me not more details.

Kind regards,
Bernhard


[1]
Program received signal SIGSEGV, Segmentation fault.
0x7fa54364fc11 in gs_grestore (pgs=0x1) at ./base/gsstate.c:409
409 if (!pgs->saved)
(rr) bt
#0  0x7fa54364fc11 in gs_grestore (pgs=0x1) at ./base/gsstate.c:409
#1  0x7fa543662c39 in gx_default_text_restore_state (pte=) 
at ./base/gxchar.c:252
#2  0x7fa54358ad46 in textw_text_process (pte=0x55dc1a95c2f8) at 
./devices/vector/gdevtxtw.c:2287
#3  0x7fa54371ca20 in op_show_continue (i_ctx_p=0x55dc17e6be98) at 
./psi/zchar.c:690
#4  op_show_continue (i_ctx_p=0x55dc17e6be98) at ./psi/zchar.c:685
#5  0x7fa5436fd7e5 in interp (perror_object=, 
pref=, pi_ctx_p=) at ./psi/interp.c:1300
#6  gs_call_interp (pi_ctx_p=pi_ctx_p@entry=0x55dc17e38bf0, 
pref=pref@entry=0x7ffeafc82fa0, user_errors=user_errors@entry=1, 
pexit_code=pexit_code@entry=0x7ffeafc83050, perror_object=) at 
./psi/interp.c:520
#7  0x7fa5436fee08 in gs_interpret (pi_ctx_p=pi_ctx_p@entry=0x55dc17e38bf0, 
pref=pref@entry=0x7ffeafc82fa0, user_errors=user_errors@entry=1, 
pexit_code=pexit_code@entry=0x7ffeafc83050, perror_object=, 
perror_object@entry=0x7ffeafc83060) at ./psi/interp.c:477
#8  0x7fa5436f17de in gs_main_interpret (perror_object=0x7ffeafc83060, 
pexit_code=0x7ffeafc83050, user_errors=1, pref=0x7ffeafc82fa0, minst=) at ./psi/imain.c:927
#9  gs_main_run_string_end (minst=minst@entry=0x55dc17e38b50, 
user_errors=user_errors@entry=1, pexit_code=pexit_code@entry=0x7ffeafc83050, 
perror_object=perror_object@entry=0x7ffeafc83060) at ./psi/imain.c:927
#10 0x7fa5436f1871 in gs_main_run_string_with_length 
(perror_object=0x7ffeafc83060, pexit_code=0x7ffeafc83050, user_errors=1, 
length=9, str=0x7fa543801aef ".runstdin", minst=0x55dc17e38b50) at 
./psi/imain.c:871
#11 gs_main_run_string_with_length (minst=0x55dc17e38b50, str=0x7fa543801aef 
".runstdin", length=9, user_errors=1, pexit_code=0x7ffeafc83050, 
perror_object=0x7ffeafc83060) at ./psi/imain.c:857
#12 0x7fa5436f4323 in run_string (perror_object=0x7ffeafc83060, 
pexit_code=0x7ffeafc83050, user_errors=, options=2, 
str=0x7fa543801aef ".runstdin", minst=0x55dc17e38b50) at ./psi/imainarg.c:1166
#13 swproc (minst=minst@entry=0x55dc17e38b50, arg=0x7ffeafc83060 "\001\017", 
pal=pal@entry=0x7ffeafc837a0) at ./psi/imainarg.c:367
#14 0x7fa5436f5543 in gs_main_init_with_args01 
(minst=minst@entry=0x55dc17e38b50, argc=7, argv=0x7ffeafc84318) at 
./psi/imainarg.c:224
#15 0x7fa5436f5739 in gs_main_init_with_args (minst=0x55dc17e38b50, 
argc=, argv=) at ./psi/imainarg.c:289
#16 0x55dc1650e1bc in main (argc=7, argv=0x7ffeafc84318) at 
./psi/dxmainc.c:86


[2] Pointer gets overwritten here:
Hardware watchpoint 1: *0x55dc1a95c680

Old value = (void *) 0x1
New value = (void *) 0x55dc17e6c188
__memmove_avx_unaligned_erms () at 
../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:419
419 ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: Datei oder 
Verzeichnis nicht gefunden.
1: x/i $pc
=> 0x7fa543294d50 <__memmove_avx_unaligned_erms+480>:   vmovdqa %ymm3,0x60(%rdi)
(rr) bt
#0  __memmove_avx_unaligned_erms () at 
../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:419
#1  0x7fa5437355d7 in memmove (__len=, __src=0x55dc1a95c888, 
__dest=0x55dc1a95c600) at 
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:40
#2  gc_objects_compact (gcst=0x7ffeafc81cf0, gcst=0x7ffeafc81cf0, 
cp=0x55dc1a7d1eb0) at ./psi/igc.c:1348
#3  gs_gc_reclaim (pspaces=, global=0) at ./psi/igc.c:481
#4  0x7fa543700eb5 in gs_vmreclaim (global=0, dmem=0x55dc17e6bea0) at 
./psi/ireclaim.c:165
#5  ireclaim (dmem=0x55dc17e6bea0, space=-1) at ./psi/ireclaim.c:80
#6  0x7fa5436fc3ed in interp_reclaim 
(pi_ctx_p=pi_ctx_p@entry=0x55dc17e38bf0, space=space@entry=-1) at 
./psi/interp.c:450
#7  0x7fa5436fe1e6 in interp (perror_object=, 
pref=, pi_ctx_p=) at ./psi/interp.c:1817
#8  gs_call_interp (pi_ctx_p=pi_ctx_p@entry=0x55dc17e38bf0, 
pref=pref@entry=0x7ffeafc82fa0, user_errors=user_errors@entry=1, 
pexit_code=pexit_code@entry=0x7ffeafc83050, perror_object=) at 
./psi/interp.c:520
#9  0x7fa5436fee08 in gs_interpret (pi_ctx_p=pi_ctx_p@entry=0x55dc17e38bf0, 
pref=pref@entry=0x7ffeafc82fa0, user_errors=user_errors@entry=1, 
pexit_code=pexit_code@entry=0x7ffeafc83050, perror_object=, 
perror_object@entry=0x7ffeafc83060) at ./psi/interp.c:477
#10 0x7fa5436f17de in gs_main_interpret (perror_object=0x7ffeafc83060, 
pexit_code=0x7ffeafc83050, user_errors=1, pref=0x7ffeafc82fa0, minst=) at ./psi/imain.c:927
#11 gs_main_run_string_end (minst=minst@entry=0x55dc17e38b50, 
user_errors=user_errors@entry=1, pexit_code=pexit_code@entry=0x7ffeafc83050, 
perror_object=perror_object@entry=0x7ffeafc83060) at ./psi/imain.c:927
#12 0x7fa5436f1871 in gs_main_run_string_with_length 
(perror_o

Bug#969253: Kernel trap at xfsettingsd

[Bernhard Übelacker]

Hello Jörg,
just a suspicion, but the "trap" might
point to a intentional process exit.

Is there something interesting near that
trap line visible in "journalctl -e"?

Otherwise if you have a coredump handler
like e.g. systemd-coredump installed, these
trap line should trigger a core to be collected.
E.g. "cordumpctl list" should show then some and
could be inspected by "coredumpctl gdb [pid]".

Kind regards,
Bernhard

https://wiki.debian.org/HowToGetABacktrace#Core_dump

Bug#970355: syslog-ng : segfault at 0 ip 00007fa46a2bf7b2 sp 00007ffed353fb30 error 6 in libsyslog-ng-3.19.so.0.0.0[7fa46a2a9000+5a000]

[Bernhard Übelacker]

On Wed, 16 Sep 2020 10:16:49 +0200 SZALAY Attila  wrote:
> Hi Jean-Marc,
> 
> Please check if a core file is available related to the segmentation
> fault. If there is any please make it available for me/us.
> 
> Also, can you run syslog-ng-debun with the -r parameter and send the
> generated report bundle?
> 
> Another question, is the segmentation fault reproducible? Is syslog-ng
> crashing frequently?



Dear Maintainer, hello Jean-Marc,
I tried to get some more information from the kernel message,
but found just that it points to this function [1].
There I assume that the argument s is a null pointer.

Bug I fear that without a proper backtrace this might not yet enough to fix the 
fault.

For getting a coredump or using gdb you might have a look at [2].
For the latter you might want to first install the package syslog-ng-dbg.

Kind regards,
Bernhard


[1] 
https://sources.debian.org/src/syslog-ng/3.19.1-5/lib/logproto/logproto-server.h/#L163

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


From submitter:
2020-09-15T08:25:53+02:00 s_dev_kernel_kmsg@asus-190 kernel: 
6,35313,87037029084,-;syslog-ng[10311]: segfault at 0 ip 7fa46a2bf7b2 sp 
7ffed353fb30 error 6 in libsyslog-ng-3.19.so.0.0.0[7fa46a2a9000+5a000]
2020-09-15T08:25:53+02:00 s_dev_kernel_kmsg@asus-190 kernel: 
6,35314,87037029092,-;Code: e8 c3 9b fe ff 4c 89 e7 e8 eb dc fe ff 48 89 c7 e8 
23 ca fe ff e9 15 ff ff ff 66 0f 1f 44 00 00 48 8b 83 f0 00 00 00 48 89 df  
00 00 00 00 00 48 83 c4 08 5b 5d 41 5c 41 5d e9 b9 fc ff ff 66


https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash


error 6:
0: no page found
1: write access
1: user-mode access


echo -n "find /b ..., ..., 0x" && \
echo "e8 c3 9b fe ff 4c 89 e7 e8 eb dc fe ff 48 89 c7 e8 23 ca fe ff e9 15 ff 
ff ff 66 0f 1f 44 00 00 48 8b 83 f0 00 00 00 48 89 df  00 00 00 00 00 48 83 
c4 08 5b 5d 41 5c 41 5d e9 b9 fc ff ff 66" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'






# Buster/stable amd64 qemu VM 2020-09-30


apt update
apt dist-upgrade


apt install systemd-coredump mc gdb syslog-ng syslog-ng-dbg


gdb -q

set width 0
set pagination off
file /usr/sbin/syslog-ng
tb main
run
find /b 0x77f37390, 0x77f8bf80, 0xe8, 0xc3, 0x9b, 0xfe, 0xff, 
0x4c, 0x89, 0xe7, 0xe8, 0xeb, 0xdc, 0xfe, 0xff, 0x48, 0x89, 0xc7, 0xe8, 0x23, 
0xca, 0xfe, 0xff, 0xe9, 0x15, 0xff, 0xff, 0xff, 0x66, 0x0f, 0x1f, 0x44, 0x00, 
0x00, 0x48, 0x8b, 0x83, 0xf0, 0x00, 0x00, 0x00, 0x48, 0x89, 0xdf, 0xc7, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x48, 0x83, 0xc4, 0x08, 0x5b, 0x5d, 0x41, 0x5c, 0x41, 
0x5d, 0xe9, 0xb9, 0xfc, 0xff, 0xff, 0x66
b * (0x77f48788 + 42)
disassemble /r 0x77f48788, 0x77f48788 + 62





benutzer@debian:~$ gdb -q
(gdb) set width 0
(gdb) set pagination off
(gdb) file /usr/sbin/syslog-ng
Reading symbols from /usr/sbin/syslog-ng...Reading symbols from 
/usr/lib/debug/.build-id/53/1963ce8fea48fe705285a1a6f41e34c1fedb6d.debug...done.
done.
(gdb) tb main
Temporary breakpoint 1 at 0x2310: file ../../syslog-ng/main.c, line 207.
(gdb) run
Starting program: /usr/sbin/syslog-ng 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Temporary breakpoint 1, main (argc=1, argv=0x7fffe618) at 
../../syslog-ng/main.c:207
207 ../../syslog-ng/main.c: Datei oder Verzeichnis nicht gefunden.
(gdb) info target
...
0x77f37390 - 0x77f8bf80 is .text in 
/usr/lib/syslog-ng/libsyslog-ng-3.19.so.0
...
(gdb) find /b 0x77f37390, 0x77f8bf80, 0xe8, 0xc3, 0x9b, 0xfe, 
0xff, 0x4c, 0x89, 0xe7, 0xe8, 0xeb, 0xdc, 0xfe, 0xff, 0x48, 0x89, 0xc7, 0xe8, 
0x23, 0xca, 0xfe, 0xff, 0xe9, 0x15, 0xff, 0xff, 0xff, 0x66, 0x0f, 0x1f, 0x44, 
0x00, 0x00, 0x48, 0x8b, 0x83, 0xf0, 0x00, 0x00, 0x00, 0x48, 0x89, 0xdf, 0xc7, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x48, 0x83, 0xc4, 0x08, 0x5b, 0x5d, 0x41, 0x5c, 
0x41, 0x5d, 0xe9, 0xb9, 0xfc, 0xff, 0xff, 0x66
0x77f48788 
1 pattern found.
(gdb) b * (0x77f48788 + 42)
Breakpoint 2 at 0x77f487b2: file ../../lib/logproto/logproto-server.h, line 
163.
(gdb) info b
Num Type   Disp Enb AddressWhat
2   breakpoint keep y   0x77f487b2 in 
log_proto_server_reset_error at ../../lib/logproto/logproto-server.h:163
(gdb) disassemble /r 0x77f48788, 0x77f48788 + 62
Dump of assembler code from 0x77f48788 to 0x77f487c6:
   0x77f48788 :   e8 c3 9b fe ff  
callq  0x77f32350 
   0x77f4878d :   4c 89 e7
mov%r12,%rdi
   0x77f48790 :   e8 eb dc fe ff  
callq  0x77f36480 
   0x77f48795 :   48 89 c7
mov%rax,%rdi
   0x77f48798 :   e8 23 ca fe ff  
callq  0x77f351c0 
   0x77f4879d :   e9 15 ff ff ff  
jmpq   0x77f486b7 
   0x77f487a2 :   66 0f 1f 44 00 00   
nopw   0x0(%rax,%rax,1)
   

Bug#968756: inkscape: Inkscape crash on multiple undo-redo actions

[Bernhard Übelacker]

Hello Jason,

> #0  0x7efbfb5f3204 n/a (libgtk-3.so.0)
> #1  0x7efbfb779a53 n/a (libgtk-3.so.0)
> #2  0x7efbfb779b11 n/a (libgtk-3.so.0)
> #3  0x7efbfb779ff1 n/a (libgtk-3.so.0)
> #4  0x7efbf96c38ee ffi_call_unix64 (libffi.so.6)
> ...

I assume you updated inkscape to current version 1.0-5~bpo10+1 ?

The above part of your backtrace would translate to this
when debug symbols are installed.

(gdb) bt
#0  0x7f5ab0050204 in _gtk_gesture_get_pointer_emulating_sequence () at 
../../../../gtk/gtkgesture.c:1811
#1  0x7f5ab01d6a53 in _gtk_widget_get_emulating_sequence () at 
../../../../gtk/gtkwidget.c:4183
#2  0x7f5ab01d6b11 in _gtk_widget_set_sequence_state_internal () at 
../../../../gtk/gtkwidget.c:4245
#3  0x7f5ab01d6ff1 in event_controller_sequence_state_changed () at 
../../../../gtk/gtkwidget.c:17330
#4  0x7f5aae1208ee in ffi_call_unix64 () from 
/lib/x86_64-linux-gnu/libffi.so.6
...

The instruction at this address originates from following location
and tries to read memory from the address the variable "data->event"
points to. The data variable is retrieved before by g_hash_table_iter_next.

https://sources.debian.org/src/gtk+3.0/3.24.5-1/gtk/gtkgesture.c/#L1811

Also this location is quite different from what the original segfault
lines in the first message was showing for the previous bpo version.


Unfortunately I guess this will not be sufficient for the maintainer
to find out the problem or create a fix.

If you receive such crashes multiple times, are the backtraces always
different? If yes you might consider to check for memory faults.

Also running inkscape through "valgrind --undef-value-errors=no inkscape"
might reveal something, but might be too slow to work long enough with it,
if there are no exact steps known to reproduce it.

Also you might add the debug symbols to your system to generate
backtraces with more information, like described here:

https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols

Kind regards,
Bernhard

Bug#969559: curl segmentation fauls on any https URL

[Bernhard Übelacker]

Dear Maintainer, hello Bruce Momjian,
with the last informations the issue is perfectly reproducible.

It looks like a use after free caused by statically stored
function pointers in libengine-pkcs11-openssl / libp11.

That led to following upstream bug:
  https://github.com/OpenSC/libp11/issues/328

This got fixed in this commit:
  
https://github.com/OpenSC/libp11/commit/e64496a198d4d2eb0310a22dc21be8b81367d319

This commit is not yet included in an upstream release tag.
Therefore this error is also visible in current testing.

I hope it is ok to reassign to libengine-pkcs11-openssl.

Kind regards,
Bernhard

Bug#969559: curl segmentation fauls on any https URL

[Bernhard Übelacker]

Hello Bruce Momjian,
thanks for the details and confirmation.


Am 05.09.20 um 17:32 schrieb Bruce Momjian,,,:
>   (gdb) print pmeth->init
>   $1 = (int (*)(EVP_PKEY_CTX *)) 0xf0e0d0c0b0a0908

>   gdb) print *pmeth
>   $8 = {pkey_id = 50462976, flags = 117835012, init = 0xf0e0d0c0b0a0908, 
> copy = 0x1716151413121110, cleanup = 0x1f1e1d1c1b1a1918, paramgen_init = 
> 0x98c476a19fc273a5, paramgen = 0x9cc072a593ce7fa9,

The pointer init copy and cleanup are really not looking like usual
pointers or random ...

> I am using a pkcs11 hardware crypto device, and perhaps it is
> misconfigured, but it probably shouldn't crash.  This might be a library
> bug, not sure.  I will check the pkcs11's configuration now, but it used
> to work.

But I have no knowledge about such crypto hardware, therefore
I am not sure if I can be of any more help. Maybe you could
provide the needed packages, libraries and configuration steps
that are needed to use such a device of yours when starting with
a fresh debian installation?

Kind regards,
Bernhard

Bug#969559: curl segmentation fauls on any https URL

[Bernhard Übelacker]

Dear Maintainer,
I tried to reproduce this fault, but did not get a segfault.

However, I think the backtrace points to these lines:

(gdb) bt
#0  0x7769dbce in int_ctx_new () at ../crypto/evp/pmeth_lib.c:160
#1  0x7769dcfa in EVP_PKEY_CTX_new () at 
../crypto/evp/pmeth_lib.c:245
#2  0x77698d44 in do_sigver_init () at ../crypto/evp/m_sigver.c:29
#3  0x77698eab in EVP_DigestVerifyInit () at 
../crypto/evp/m_sigver.c:97
#4  0x775bc7d2 in ASN1_item_verify () at 
../crypto/asn1/a_verify.c:148
#5  0x77722490 in X509_verify () at ../crypto/x509/x_all.c:26
...


https://sources.debian.org/src/openssl/1.1.1d-0+deb10u3/crypto/evp/pmeth_lib.c/#L160

159 if (pmeth->init) {
160 if (pmeth->init(ret) <= 0) {
161 ret->pmeth = NULL;

As there is a check for pmeth->init being non-null, I guess
it contains for some reason an invalid pointer.


@Bruce Momjian,
maybe you could install the following debug symbols packages
`curl-dbgsym libcurl4-dbgsym libssl1.1-dbgsym` from the dbgsym
repository described here:
https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols

Then run a new gdb session and when the segfault appears
please run these commands in gdb:
print pmeth->init
bt full 5


Kind regards,
Bernhard


# Buster/stable amd64 qemu VM


apt update
apt dist-upgrade


apt install systemd-coredump curl gdb


curl https://google.com


dpkg -l curl libc6 libcurl4 zlib1g libssl1.1
ii  curl7.64.0-4+deb10u1 amd64command line tool for 
transferring data with URL syntax
ii  libc6:amd64 2.28-10  amd64GNU C Library: Shared 
libraries
ii  libcurl4:amd64  7.64.0-4+deb10u1 amd64easy-to-use client-side URL 
transfer library (OpenSSL flavour)
ii  libssl1.1:amd64 1.1.1d-0+deb10u3 amd64Secure Sockets Layer toolkit 
- shared libraries
ii  zlib1g:amd641:1.2.11.dfsg-1  amd64compression library - runtime


benutzer@debian:~$ curl https://google.com

301 Moved
301 Moved
The document has moved
https://www.google.com/";>here.




gdb -q --args curl https://google.com
b ASN1_item_verify
y
run

disassemble ASN1_item_verify
b EVP_DigestVerifyInit
cont

...
generate-core-file /tmp/core


(gdb) bt
#0  0x7769dbce in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.1
#1  0x77698d44 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.1
#2  0x775bc7d2 in ASN1_item_verify () from 
/lib/x86_64-linux-gnu/libcrypto.so.1.1
#3  0x7771cfb4 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.1
#4  0x7771edd6 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.1
#5  0x7771f416 in X509_verify_cert () from 
/lib/x86_64-linux-gnu/libcrypto.so.1.1
#6  0x7782fb88 in ?? () from /lib/x86_64-linux-gnu/libssl.so.1.1
#7  0x778510f3 in ?? () from /lib/x86_64-linux-gnu/libssl.so.1.1
#8  0x778536c5 in ?? () from /lib/x86_64-linux-gnu/libssl.so.1.1
#9  0x7784d143 in ?? () from /lib/x86_64-linux-gnu/libssl.so.1.1
#10 0x77838f34 in SSL_do_handshake () from 
/lib/x86_64-linux-gnu/libssl.so.1.1
#11 0x77fa3240 in ?? () from /lib/x86_64-linux-gnu/libcurl.so.4
#12 0x77fa53f0 in ?? () from /lib/x86_64-linux-gnu/libcurl.so.4
#13 0x77fa61da in ?? () from /lib/x86_64-linux-gnu/libcurl.so.4
#14 0x77f4d462 in ?? () from /lib/x86_64-linux-gnu/libcurl.so.4
#15 0x77f6f6fe in ?? () from /lib/x86_64-linux-gnu/libcurl.so.4
#16 0x77f70aa9 in curl_multi_perform () from 
/lib/x86_64-linux-gnu/libcurl.so.4
#17 0x77f67642 in curl_easy_perform () from 
/lib/x86_64-linux-gnu/libcurl.so.4
#18 0x55569f30 in ?? ()
#19 0x5556b42a in ?? ()
#20 0xd8c4 in ?? ()
#21 0x77b5c09b in __libc_start_main (main=0xd770, argc=2, 
argv=0x7fffe608, init=, fini=, 
rtld_fini=, stack_end=0x7fffe5f8)
at ../csu/libc-start.c:308
#22 0xd9da in ?? ()



apt install curl-dbgsym libcurl4-dbgsym libssl1.1-dbgsym


gdb -q /usr/bin/curl --core /tmp/core

set width 0
set pagination off

(gdb) bt
#0  0x7769dbce in int_ctx_new (pkey=pkey@entry=0x55601a10, 
e=e@entry=0x0, id=, id@entry=-1) at ../crypto/evp/pmeth_lib.c:160
#1  0x7769dcfa in EVP_PKEY_CTX_new (pkey=pkey@entry=0x55601a10, 
e=e@entry=0x0) at ../crypto/evp/pmeth_lib.c:245
#2  0x77698d44 in do_sigver_init (ctx=ctx@entry=0x55601930, 
pctx=pctx@entry=0x0, type=type@entry=0x777d5fc0 , e=e@entry=0x0, 
pkey=pkey@entry=0x55601a10, ver=ver@entry=1) at ../crypto/evp/m_sigver.c:29
#3  0x77698eab in EVP_DigestVerifyInit (ctx=ctx@entry=0x55601930, 
pctx=pctx@entry=0x0, type=type@entry=0x777d5fc0 , e=e@entry=0x0, 
pkey=pkey@entry=0x55601a10) at ../crypto/evp/m_sigver.c:97
#4  0x775bc7d2 in ASN1_item_verify (it=0x777e7e80 , 
a=a@entry=0x555fda18, signature=signature@entry=0x555fda28, 
asn=asn

Bug#957812: slirp: ftbfs with GCC-10

[Bernhard Übelacker]

Dear Maintainer,
the patch "949003_explicit_extern_declaration.patch" attached in [1],
should help against the exact issue this bug is about.

Kind regards,
Bernhard

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

Bug#968756: Further Info

[Bernhard Übelacker]

Hello Jason,
thanks for the information, just some notes before.
You might want to  use reply all, otherwise the answer
might get through unnoticed.
And for some reason your email did not convert sufficiently
to plain text for some reason, so it appears kind of
short at https://bugs.debian.org/968756 .



On Sun, 23 Aug 2020 01:31:46 +0200 pub1...@gmx.com wrote:
> 
> Dear Maintainers,
> 
> @Mattia:
>  
> > Since you tried the AppImage and reproduced with that as well, could you
> > consider filing a bug report upstream directly at
> > https://gitlab.com/inkscape/inbox ?
>  
> Will do.
>  
> > Also, I'm uploading now 1.0-5 to backports, if you could see whether
> > that also triggers this crash it would be useful (1.0-2 disable a bunch
> > of asserts that might or might not be relevant)
>  
> Have just upgraded it now. I'll do my best at triggering the error again and
> keep you posted with strace info.
>  
> Regards,
> Jason
>  
>  
>  
> @Bernhard:
>  
> > one small additional note. The dmesg lines you provided would have been
> > followed by lines "Code:". With that line it would be possible to
> > find at least the current instruction and source code line when the
> > executables are from the debian archive and the package version is
> > known. So please do not strip these lines away.
>  
> Sorry, I didn't strip them on purpose, I just grep'd for 'inkscape'. My bad.
> Anyway, I dug into the dmesg log and isolated the info you requested:
>  
>  e9 c3 fc ff ff e8 05 45 5a ff 48 89 c3 e9 99 0a 69 ff 48 89 c3 e9 87 0a 69 ff
>  90 0f 1f 40 00 53 48 8d 87 48 01 00 00 48 89 fb <48> 39 87 48 01 00 00 74 3c
>  80 bb 39 01 00 00 00 74 0b 31 c0 5b c3
> 
> Regards,
> Jason
> 

This line points to function below.

But proper backtraces might still be needed to be able to find the reason.
You probably could install systemd-coredump - then minimal backtrace
should be visible in 'journalctl -e' after a chrash.
Plus a core would be generated for later inspection.

And if Thunar crashes too, are there also a segfault line?

Kind regards,
Bernhard



(gdb) info b
Num Type   Disp Enb AddressWhat
2   breakpoint keep y   0x778e55db in 
Avoid::Router::processTransaction() at /usr/include/c++/8/bits/stl_list.h:1063

(gdb) disassemble Avoid::Router::processTransaction
Dump of assembler code for function Avoid::Router::processTransaction():
   0x778e55d0 <+0>: push   %rbx
   0x778e55d1 <+1>: lea0x148(%rdi),%rax
   0x778e55d8 <+8>: mov%rdi,%rbx
-->0x778e55db <+11>:cmp%rax,0x148(%rdi)
   0x778e55e2 <+18>:je 0x778e5620 

   0x778e55e4 <+20>:cmpb   $0x0,0x139(%rbx)
...

benutzer@debian:~$ cat -n /usr/include/c++/8/bits/stl_list.h | grep 1063 -B7 -A2
  1056
  1057// [23.2.2.2] capacity
  1058/**
  1059 *  Returns true if the %list is empty.  (Thus begin() would equal
  1060 *  end().)
  1061 */
  1062bool
  1063empty() const _GLIBCXX_NOEXCEPT
  1064{ return this->_M_impl._M_node._M_next == &this->_M_impl._M_node; 
}
  1065



640 bool Router::processTransaction(void)
641 {
642 // If SimpleRouting, then don't update here.
643 if ((actionList.empty() && (m_hyperedge_rerouter.count() == 0) &&
644  (m_settings_changes == false)) || SimpleRouting)
645 {

https://gitlab.com/inkscape/inkscape/-/blob/INKSCAPE_1_0/src/3rdparty/adaptagrams/libavoid/router.cpp#L643







# Buster amd64 qemu VM 2020-08-24


apt update
apt dist-upgrade


# add backports and debug symbols from local approx cache:
deb  http://192.168.178.25:/debian-10-buster-security.debian.org/ 
buster/updates main
deb-src  http://192.168.178.25:/debian-10-buster-security.debian.org/ 
buster/updates main
deb  http://192.168.178.25:/debian-10-buster-debug.deb.debian.org/ 
buster-debug  main contrib non-free
deb  http://192.168.178.25:/debian-10-buster-debug.deb.debian.org/ 
buster-proposed-updates-debug main contrib non-free
deb  http://192.168.178.25:/debian-10-buster-debug.deb.debian.org/ 
buster-backports-debugmain contrib non-free

apt update


apt install systemd-coredump mc libstdc++-8-dev gdb inkscape/buster-backports
# Installs 1.0-5~bpo10+1 from two days ago ...

wget 
https://snapshot.debian.org/archive/debian/20200527T144641Z/pool/main/i/inkscape/inkscape_1.0-1%7Ebpo10%2B1_amd64.deb
wget 
https://snapshot.debian.org/archive/debian-debug/20200527T144324Z/pool/main/i/inkscape/inkscape-dbgsym_1.0-1%7Ebpo10%2B1_amd64.deb
dpkg -i inkscape_1.0-1~bpo10+1_amd64.deb inkscape-dbgsym_1.0-1~bpo10+1_amd64.deb



# https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash

echo -n "find /b ..., ..., 0x" && \
echo "e9 c3 fc ff ff e8 05 45 5a ff 48 89 c3 e9 99 0a 69 ff 48 89 c3 e9 87 0a 
69 ff 90 0f 1f 40 00

Bug#968816: tilix: Library load failed (librsvg-2.so.2): ... Illegal instruction

[Bernhard Übelacker]

Dear Maintainer,
my d knowledge is very limited, but it looks like a d runtime library
tries to do some destructor calls at process exit.
Unfortunately that tries to get a mutex lock, but that fails with
EOWNERDEAD, therefore then hits the assert(0) in maybe [1].
If that assert(0) just translates in d to a "ud2" instruction.

But this happens just if the build-depending library librsvg2 is not found.
Looks like that build dependency does not translate to a binary package
dependency, maybe because it gets dynamically loaded?

Kind regards,
Bernhard



[1] 
https://sources.debian.org/src/ldc/1:1.21.0-1/runtime/druntime/src/rt/monitor_.d/#L213

(gdb) disassemble 
_D2rt8monitor_9lockMutexFNbNiPS4core3sys5posixQk5types15pthread_mutex_tZv
Dump of assembler code for function 
_D2rt8monitor_9lockMutexFNbNiPS4core3sys5posixQk5types15pthread_mutex_tZv:
   0xb6cd2dd0 <+0>: push   %ebx
   0xb6cd2dd1 <+1>: sub$0x8,%esp
   0xb6cd2dd4 <+4>: call   0xb6cd2dd9 
<_D2rt8monitor_9lockMutexFNbNiPS4core3sys5posixQk5types15pthread_mutex_tZv+9>
   0xb6cd2dd9 <+9>: pop%ebx
   0xb6cd2dda <+10>:mov%eax,(%esp)
   0xb6cd2ddd <+13>:add$0x54227,%ebx
   0xb6cd2de3 <+19>:call   0xb6c86b60 
   0xb6cd2de8 <+24>:test   %eax,%eax
   0xb6cd2dea <+26>:jne0xb6cd2df1 
<_D2rt8monitor_9lockMutexFNbNiPS4core3sys5posixQk5types15pthread_mutex_tZv+33>
   0xb6cd2dec <+28>:add$0x8,%esp
   0xb6cd2def <+31>:pop%ebx
   0xb6cd2df0 <+32>:ret
=> 0xb6cd2df1 <+33>:ud2
End of assembler dump.

(gdb) 
0xb6c045de  467 return EOWNERDEAD;
1: x/i $pc
=> 0xb6c045de <__pthread_mutex_lock_full+446>:  ja 0xb6c044f0 
<__pthread_mutex_lock_full+208>
(gdb) bt
#0  0xb6c045de in __pthread_mutex_lock_full (mutex=0xb6d2f480 
<_D2rt9critical_3gcsOSQtQs18D_CRITICAL_SECTION+4>) at 
../nptl/pthread_mutex_lock.c:467
#1  0xb6cd2de8 in 
_D2rt8monitor_9lockMutexFNbNiPS4core3sys5posixQk5types15pthread_mutex_tZv () 
from /usr/lib/i386-linux-gnu/libdruntime-ldc-shared.so.91
#2  0xb6cc8641 in _d_criticalenter () from 
/usr/lib/i386-linux-gnu/libdruntime-ldc-shared.so.91
#3  0xb6cd6ca6 in _staticDtor_L376_C1 () from 
/usr/lib/i386-linux-gnu/libdruntime-ldc-shared.so.91
#4  0xb6cd2344 in rt.minfo.ModuleGroup.runTlsDtors() () from 
/usr/lib/i386-linux-gnu/libdruntime-ldc-shared.so.91
#5  0xb6cd4a44 in _d_dso_registry () from 
/usr/lib/i386-linux-gnu/libdruntime-ldc-shared.so.91
#6  0xb6c886e2 in ldc.register_dso () from 
/usr/lib/i386-linux-gnu/libdruntime-ldc-shared.so.91
#7  0xb7fe626a in _dl_fini () at dl-fini.c:138
#8  0xb6a4880e in __run_exit_handlers (status=1, listp=0xb6bf63fc 
<__exit_funcs>, run_list_atexit=true, run_dtors=true) at exit.c:108
#9  0xb6a489e1 in __GI_exit (status=1) at exit.c:139
#10 0xb6a2fe02 in __libc_start_main (main=0x4f1230 , argc=1, 
argv=0xb6e4, init=0x5f2c60 <__libc_csu_init>, fini=0x5f2cc0 
<__libc_csu_fini>, rtld_fini=0xb7fe6080 <_dl_fini>, stack_end=0xb6dc) at 
../csu/libc-start.c:342
#11 0x004e3061 in _start ()

Bug#968756: inkscape: Inkscape crash on multiple undo-redo actions

[Bernhard Übelacker]

Hello Jason,
one small additional note. The dmesg lines you provided would have been
followed by lines "Code:". With that line it would be possible to
find at least the current instruction and source code line when the
executables are from the debian archive and the package version is
known. So please do not strip these lines away.

Kind regards,
Bernhard

Bug#968372: sylpheed: crash on startup

[Bernhard Übelacker]

Dear Maintainer,
I could reproduce it inside a i386 VM and found the crash
happens in [1], when it tries to dereference the "state".

This state is retrieved from the renderer of type _PangoRendererPrivate.


I tried to follow where this state is last set and found
this memory is last written in location [2].

But here this memory is used as _GdkPangoRendererPrivate,
which looks quite different.


Kind regards,
Bernhard



[1]
(rr) bt
#0  0xb7391ebf in handle_line_state_change 
(part=PANGO_RENDER_PART_OVERLINE, renderer=0x10470c0) at 
../pango/pango-renderer.c:315
#1  pango_renderer_part_changed (renderer=0x10470c0, 
part=PANGO_RENDER_PART_OVERLINE) at ../pango/pango-renderer.c:1414
#2  0xb7392194 in pango_renderer_set_alpha (renderer=0x10470c0, 
part=PANGO_RENDER_PART_OVERLINE, alpha=0) at ../pango/pango-renderer.c:1357
#3  0xb7392335 in pango_renderer_default_prepare_run (renderer=0x10470c0, 
run=0xf55a98) at ../pango/pango-renderer.c:1525
#4  0xb756b7cd in gdk_pango_renderer_prepare_run (renderer=0x10470c0, 
run=0xf55a98) at ../../../../gdk/gdkpango.c:456
#5  0xb73925f9 in pango_renderer_prepare_run (run=0xf55a98, 
renderer=0x10470c0) at ../pango/pango-renderer.c:1435
#6  pango_renderer_draw_layout_line (renderer=0x10470c0, line=0xf50e08, 
x=34816, y=51200) at ../pango/pango-renderer.c:611
...

(rr) list
296 handle_line_state_change (PangoRenderer  *renderer,
297   PangoRenderPart part)
298 {
299   LineState *state = renderer->priv->line_state;
...
314
315   if (part == PANGO_RENDER_PART_OVERLINE &&
316   state->overline != PANGO_OVERLINE_NONE)
317 {


https://sources.debian.org/src/pango1.0/1.46.0-1/pango/pango-renderer.c/#L315


[2]
(rr) bt
#0  gdk_pango_renderer_prepare_run (renderer=0x10470c0, run=0xf55a98) at 
../../../../gdk/gdkpango.c:443
#1  0xb73925f9 in pango_renderer_prepare_run (run=0xf55a98, 
renderer=0x10470c0) at ../pango/pango-renderer.c:1435
#2  pango_renderer_draw_layout_line (renderer=0x10470c0, line=0xf50e08, 
x=34816, y=51200) at ../pango/pango-renderer.c:611
#3  0xb739301d in pango_renderer_draw_layout (renderer=0x10470c0, 
layout=0xf379f0, x=34816, y=37888) at ../pango/pango-renderer.c:197
...

(rr) list
441   if (embossed != gdk_renderer->priv->embossed)
442 {
443   gdk_renderer->priv->embossed = embossed;
444   changed = TRUE;
445 }

https://sources.debian.org/src/gtk+2.0/2.24.32-4/gdk/gdkpango.c/#L443

# Unstable i386 qemu VM 2020-08-14

apt update
apt dist-uprade


apt install systemd-coredump sddm xserver-xorg openbox xterm gdb git sylpheed 
sylpheed-dbgsym libgtk2.0-0-dbgsym libglib2.0-0-dbgsym libpango-1.0-0-dbgsym
apt build-dep rr


echo 1 > /proc/sys/kernel/perf_event_paranoid




mkdir /home/benutzer/source/libpango-1.0-0/orig -p
cd/home/benutzer/source/libpango-1.0-0/orig
apt source libpango-1.0-0
cd

mkdir /home/benutzer/source/libgtk2.0-0/orig -p
cd/home/benutzer/source/libgtk2.0-0/orig
apt source libgtk2.0-0
cd





$ export DISPLAY=:0
$ sylpheed 
Speicherzugriffsfehler (Speicherabzug geschrieben)


# dmesg
...
[   29.789450] sylpheed[992]: segfault at 2d ip b73e0ebf sp bf890760 error 4 in 
libpango-1.0.so.0.4600.0[b73bd000+29000]
[   29.789458] Code: c4 10 83 c4 1c 5b 5e 5f 5d c3 90 8b 4e 18 85 c9 7e 79 8b 
46 20 8b 78 44 85 ff 74 4f 83 fd 02 74 7a 83 fd 04 0f 85 b1 00 00 00 <8b> 47 2c 
89 44 24 08 85 c0 74 36 8b 4f 40 8b 57 30 c7 47 2c 00 00


# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Fri 2020-08-14 18:33:29 CEST992  1000  1000  11 present   /usr/bin/sylpheed

# coredumpctl gdb 992
   PID: 992 (sylpheed)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 11 (SEGV)
 Timestamp: Fri 2020-08-14 18:33:29 CEST (2min 10s ago)
  Command Line: sylpheed
Executable: /usr/bin/sylpheed
 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: 4c238d8aaaba40d19b8c886c81502ce0
Machine ID: 45f49504b47f4e5690bc479adf67aa5b
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.sylpheed.1000.4c238d8aaaba40d19b8c886c81502ce0.992.1597422809.zst
   Message: Process 992 (sylpheed) of user 1000 dumped core.

Stack trace of thread 992:
#0  0xb73e0ebf pango_renderer_part_changed 
(libpango-1.0.so.0 + 0x2debf)
#1  0xb73e1194 pango_renderer_set_alpha 
(libpango-1.0.so.0 + 0x2e194)
#2  0xb73e1335 n/a (libpango-1.0.so.0 + 0x2e335)
#3  0xb75ba7cd n/a (libgdk-x11-2.0.so.0 + 0x247cd)
#4  0xb73e15f9 pango_renderer_draw_layout_line 
(libpango-1.0.so.0 + 0x2e5f9)

Bug#961993: Undelivered Mail Returned to Sender

[Bernhard Übelacker]

Am 02.06.20 um 16:06 schrieb Mail Delivery System:
>The mail system
> 
> : host mx.wowway.com[64.8.71.111] said: 550 5.1.1 [R2]
> Recipient n...@wideopenwest.com does not exist here. (in reply to RCPT TO
> command)

My email could not be delivered to the submitter.

Bug#961993: gimp crashes on start up

[Bernhard Übelacker]

Hello nbi,
I am not involved in packaging gimp, but
this might be related to the debian-multimedia
packages you have installed:

> ii  libbabl-0.1-01:0.1.74-dmo1
> ii  libgegl-0.4-01:0.4.16-dmo1

Is this error also visible when using these packages
from the debian testing repository?
(Or is there at least for these two packages an update in the
debian-multimedia repo?)

Kind regards,
Bernhard

Bug#961926: rr: record fails on i386

[Bernhard Übelacker]

Hello Stephen,

Am 31.05.20 um 22:52 schrieb Stephen Kitt:
> On Sun, 31 May 2020 18:03:01 +0200, Bernhard Übelacker
>  wrote:
>> Unfortunately I found recording not working in a small test [1].
>>
>> A git bisect led to a helper function introduced by upstream in [2].
>> This helper uses a function parameter of type off_t.
>> But the pwrite64 from glibc uses off64_t.
>> Therefore offset values with the highest bit set get incorrectly
>> converted to the 64 bit type, e.g.: 0xb622 -> 0xb622
>> Therefore the write fails and rr stops.
>>
>> Attached patch makes rr work on i386 and passing most tests
>> in my test VM, except [3]. Have not tested for side effects at amd64.
>>
>> I am going to try to forward this to upstream too,
>> will update this bug then.
> 
> Ah, I assumed it would work, and I didn’t even test, let alone run the test
> suite.
> 
> Thanks for the patch, I’ll see if the failing tests mean anything to me...
> 
> Regards,
> 
> Stephen


I reported to upstream this issue:
   https://github.com/mozilla/rr/issues/2597
Let's see what they think about it.

The failing tests might be related to me using a VM maybe ...
To do the make test I had to link rr_page_* and rr_exec_stub from
rr-5.3.0/debian/rr/usr/lib/rr/ to rr-5.3.0/build/bin/../lib/rr/.
Therefore I don't know if the failures might be a result of
just some more files missing not found ...

Kind regards,
Bernhard

Bug#961095: mkvtoolnix-gui: mkvtoolnix does not start undefined symbol: _ZN11libmatroska22KaxVideoProjectionType10ClassInfosE

[Bernhard Übelacker]

> On Tue, 2020-05-19 at 22:05 -0300, Mauro Dionisi wrote:
> > Versions of packages mkvtoolnix-gui depends on:
> > ii  libebml4v5 1:1.3.9-dmo0+deb9u1
> > ii  libmatroska6v5 1:1.4.5-dmo1

Hello,
might this be related to the above packages being
from the debian multimedia repository?

Could the issue resolve if these packages get installed
in the buster version?

Kind regards,
Bernhard

Bug#959223: fcitx won't start anymore

[Bernhard Übelacker]

control: found -1 1:4.2.9.7-3
control: notfound -1 4.2.9.7-3



Dear Maintainer,
I tried to collect some more information form the backtrace at
the end of the information in the submitters linked diagnose.

Below are the source locations where the backtraces points to.

Kind regards,
Bernhard




0x5927 in OnException at ./src/core/errorhandler.c:173
0x7fa6ea4ca7e0 <__restore_rt>
0x77c188ef in std::__shared_ptr_access::_M_get() const at 
/usr/include/c++/9/bits/shared_ptr_base.h:1020
// might be near 
rime::ConfigData::ConvertFromYaml(YAML::Node const&, rime::ConfigCompiler*) at 
./src/rime/config/config_data.cc:251
0x77c19982 in 
rime::ConfigData::LoadFromFile(std::__cxx11::basic_string, std::allocator > const&, rime::ConfigCompiler*) 
at ./src/rime/config/config_data.cc:68
0x77cfce0d in rime::InstallationUpdate::Run(rime::Deployer*) at 
/usr/include/boost/filesystem/path.hpp:435
0x77bd61c3 in rime::Deployer::RunTask(std::__cxx11::basic_string, std::allocator > const&, boost::any) at 
./src/rime/deployer.cc:42
0x77bb67c6 in RimeStartMaintenance(Bool) at 
/usr/include/c++/9/ext/new_allocator.h:80
0x77fa5e16 in FcitxRimeStart at ./src/fcitx-rime.c:97
0x77fa64ac in FcitxRimeCreate at ./src/fcitx-rime.c:114
0x77fbb1ea in FcitxInstanceLoadIM at ./src/lib/fcitx/ime.c:329
0x77fbe388 in FcitxInstanceSwitchIMInternal at 
./src/lib/fcitx/ime.c:1183
0x77fbcca5 in FcitxInstanceUpdateCurrentIM at ./src/lib/fcitx/ime.c:1511
0x77fbd491 in FcitxInstanceUpdateIMList at ./src/lib/fcitx/ime.c:2027
0x77fbdf82 in FcitxInstanceLoadAllIM at ./src/lib/fcitx/ime.c:542
0x77fb412f in RunInstance at ./src/lib/fcitx/instance.c:279
0x77fb4b27 in FcitxInstanceRun at ./src/lib/fcitx/instance.c:140
0x52bf in main at ./src/core/fcitx.c:80
0x77dabe0b in __libc_start_main at ../csu/libc-start.c:308
0x533a <_start+36>


https://github.com/rime/librime/blob/master/src/rime/config/config_data.cc#L68
https://github.com/rime/librime/blob/master/src/rime/config/config_data.cc#L251

Bug#958408: etherape: crashes with "critical: read_all() failed on control socket"

[Bernhard Übelacker]

Dear Maintainer,
I could reproduce the issue on i386 and tried to collect
some more information.

It crashes with the backtrace below.

The crash seems to be caused by using the wrong data type
in the calls to variadic functions goo_canvas_ellipse_new
and goo_canvas_polyline_new.

The modifications below made it work at i386 too.
(Just changing integer to floating point values).
Tested it just shortly.

Kind regards,
Bernhard




(gdb) bt
#0  __strchr_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strchr-sse2-bsf.S:60
#1  0xb73243ce in g_param_spec_pool_lookup (pool=0x136e260, param_name=0x1 
, owner_type=26014064, 
walk_ancestors=1) at ../../../gobject/gparam.c:1071
#2  0xb731fbce in g_object_set_valist (object=, 
first_property_name=, var_args=0xbfb6a0b4 "") at 
../../../gobject/gobject.c:2289
#3  0xb7f6e4be in goo_canvas_ellipse_new (parent=0x1685848, center_x=0, 
center_y=0, radius_x=0, radius_y=0) at goocanvasellipse.c:214
#4  0x0044feea in check_new_node (canvas=0x1650380, node=0x14b1600) at 
diagram.c:935
#5  diagram_update_nodes (canvas=0x1650380) at diagram.c:541
#6  update_diagram (canvas=0x1650380) at diagram.c:735
#7  0x00450828 in update_diagram_callback (data=0x0) at diagram.c:1910
#8  0xb7076a51 in g_timeout_dispatch (source=0x14793c0, callback=0x450810 
, user_data=0x0) at ../../../glib/gmain.c:4667
#9  0xb7075e65 in g_main_dispatch (context=0x13b1fd0) at 
../../../glib/gmain.c:3182
#10 g_main_context_dispatch (context=0x13b1fd0) at ../../../glib/gmain.c:3847
#11 0xb7076269 in g_main_context_iterate (context=0x13b1fd0, 
block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
../../../glib/gmain.c:3920
#12 0xb7076609 in g_main_loop_run (loop=0x1478ea0) at ../../../glib/gmain.c:4116
#13 0xb799139e in gtk_main () at ../../../../gtk/gtkmain.c:1323
#14 0x0044049e in main (argc=, argv=) at 
main.c:316





--- etherape-0.9.18.orig/src/diagram.c
+++ etherape-0.9.18/src/diagram.c
@@ -939,7 +939,7 @@ static gint check_new_node(node_t * node
 0.0,
 "fill-color", "white",
 "stroke-color", "black",
-"line-width", 0,
+"line-width", 0.0,
  "visibility", GOO_CANVAS_ITEM_INVISIBLE,
  NULL);
   addref_canvas_obj(G_OBJECT(new_canvas_node->node_item));
@@ -1480,16 +1480,16 @@ static gint check_new_link(link_id_t * l
   /* set the lines position using groups positions */
   new_canvas_link->src_item =
 goo_canvas_polyline_new(rootgroup, TRUE, 2,
-0,0,
-1,1,
+0.0,0.0,
+1.0,1.0,
 "fill-color", "tan",
 NULL);
   g_object_ref(G_OBJECT (new_canvas_link->src_item));
 
   new_canvas_link->dst_item =
 goo_canvas_polyline_new(rootgroup, TRUE, 2,
-0,0,
-1,1,
+0.0,0.0,
+1.0,1.0,
 "fill-color", "tan",
 NULL);
   g_object_ref(G_OBJECT (new_canvas_link->dst_item));







PS.: Could not install etherape on a multiarch amd64/i386 system because
 it tells it depends on non-existing etherape-data:i386.

Buster i386 qemu VM 2020-04-27

apt update
apt dist-upgrade


apt install systemd-coredump sddm xserver-xorg openbox xterm mc fakeroot quilt 
strace valgrind gdb etherape etherape-dbgsym libgtk-3-0-dbgsym 
libglib2.0-0-dbgsym libgoocanvas-2.0-9-dbgsym
apt build-dep etherape




export DISPLAY=:0
export XAUTHORITY=/home/benutzer/.Xauthority
/usr/bin/etherape -n -i ens4


# /usr/bin/etherape -n -i ens4
EtherApe-INFO: 22:31:04.097: Protokoll sctp nicht unterstützt
EtherApe-INFO: 22:31:04.097: Protokoll ddp nicht unterstützt
EtherApe-INFO: 22:31:04.097: Protokoll ddp nicht unterstützt
EtherApe-INFO: 22:31:04.097: Protokoll ddp nicht unterstützt
EtherApe-INFO: 22:31:04.097: Protokoll ddp nicht unterstützt
EtherApe-INFO: 22:31:04.483: Ergebnis von get_interface: »«
EtherApe-INFO: 22:31:04.484: Verfügbare Schnittstellen für die Erfassung: 
usbmon1 nfqueue nflog lo any ens4
EtherApe-INFO: 22:31:04.550: Verweistyp ist Ethernet
EtherApe-INFO: 22:31:04.551: Diagramm gestartet
EtherApe-INFO: 22:31:04.793: Neuer Knoten: IP: 10.0.2.15. Anzahl der Knoten 1
EtherApe-INFO: 22:31:04.794: Neuer Knoten: IP: 10.0.2.2. Anzahl der Knoten 2
unexpected EOF in read_all()
critical: read_all() failed on control socket
Speicherzugriffsfehler (Speicherabzug geschrieben)



dmesg:
[  344.474571] etherape[918]: segfault at 0 ip b6da9726 sp bfb69ed8 error 4 in 
libc-2.28.so[b6d2a000+14

Bug#954901: ghostscript: runtime error: malloc(): invalid size (unsorted)

[Bernhard Übelacker]

Sorry, the file I attached in message #10 was for a
different bug, unrelated to this one.

Created upstream bug: https://bugs.ghostscript.com/show_bug.cgi?id=702346

Bug#955279: sysdig: undefined symbol: _ZN4grpc13ClientContextC1Ev

[Bernhard Übelacker]

Dear Maintainer,
I tried to have a look and it looks like being related
to the libgrpc++1 package.

The _ZN4grpc13ClientContextC1Ev symbol was included in
libgrpc++1 versions up to 1.17.2-1.
Since version 1.22.0-2 it is missing from that library.

Because 1.26.0-2 is the first version after 1.16.1-1,
which got uploaded to unstable (other versions just in
experimental), this issue got visible since 2020-03-21.

A local rebuild of sysdig against libgrpc++1 1.26.0-2
seems to work.

Therefore it looks like there was an ABI change in libgrpc++1.
I am not sure what actions on grpc side are needed,
but at least a rebuild of sysdig seems necessary.

Kind regards,
Bernhard


_ZN4grpc13ClientContextC1Ev

# https://demangler.com/
grpc::ClientContext::ClientContext()







https://buildd.debian.org/status/fetch.php?pkg=sysdig&arch=amd64&ver=0.26.4-1&stamp=1571110364&raw=0

+==+
| sysdig 0.26.4-1 (amd64)  Tue, 15 Oct 2019 03:28:26 + |
+==+






approx:
debian-11-bullseye-snapshot.debian.org  
https://snapshot.debian.org/archive/debian/20191016T00Z/

sources.list:
# snapshot
deb [check-valid-until=no] 
http://192.168.178.25:/debian-11-bullseye-snapshot.debian.org/ unstable main
deb-src [check-valid-until=no] 
http://192.168.178.25:/debian-11-bullseye-snapshot.debian.org/ unstable main
deb [check-valid-until=no] 
http://192.168.178.25:/debian-11-bullseye-debug-snapshot.debian.org/ 
unstable-debug main


# Unstable amd64 qemu VM as of date 2019-10-16

apt update
apt dist-upgrade


apt install systemd-coredump binutils sysdig


# dpkg -l | grep -E "sysdig|0.26.4-1"
ii  sysdig0.26.4-1 amd64
system-level exploration and troubleshooting tool
ii  sysdig-dkms   0.26.4-1 all  
system-level exploration and troubleshooting tool - kernel source


##


# for lib in `ldd /usr/bin/sysdig | grep -v -E 
"linux-vdso.so.1|/lib64/ld-linux-x86-64.so.2" | awk '{print $3}'`; do echo 
x $lib; nm -D $lib; done | grep -E "x|_ZN4grpc13ClientContextC1Ev"
...
x /lib/x86_64-linux-gnu/libgrpc++_unsecure.so.1
00026b60 T _ZN4grpc13ClientContextC1Ev
x /lib/x86_64-linux-gnu/libprotobuf.so.17
...

# dpkg -S /usr/lib/x86_64-linux-gnu/libgrpc++_unsecure.so.1
libgrpc++1:amd64: /usr/lib/x86_64-linux-gnu/libgrpc++_unsecure.so.1

# dpkg -l | grep -E "libgrpc|1.16.1-1+b1"
ii  libgrpc++1:amd64  1.16.1-1+b1  amd64
high performance general RPC framework
ii  libgrpc6:amd641.16.1-1+b1  amd64
high performance general RPC framework


##



wget 
https://snapshot.debian.org/archive/debian/20191119T213110Z/pool/main/g/grpc/libgrpc%2B%2B1_1.16.1-1%2Bb2_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20191119T213110Z/pool/main/g/grpc/libgrpc6_1.16.1-1%2Bb2_amd64.deb
dpkg -i *_1.16.1-1+b2_*

# nm -D /lib/x86_64-linux-gnu/libgrpc++_unsecure.so.1 | grep 
_ZN4grpc13ClientContextC1Ev
00026b70 T _ZN4grpc13ClientContextC1Ev



##



wget 
https://snapshot.debian.org/archive/debian/20200220T030240Z/pool/main/g/grpc/libgrpc%2B%2B1_1.16.1-1%2Bb3_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20181203T153211Z/pool/main/g/grpc/libgrpc6_1.16.1-1_amd64.deb
dpkg -i --force-depends *_1.16.1-1+b3_*

# nm -D /lib/x86_64-linux-gnu/libgrpc++_unsecure.so.1 | grep 
_ZN4grpc13ClientContextC1Ev
00026b80 T _ZN4grpc13ClientContextC1Ev



##



wget 
https://snapshot.debian.org/archive/debian/20181206T103113Z/pool/main/g/grpc/libgrpc%2B%2B1_1.17.0-1_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20181206T103113Z/pool/main/g/grpc/libgrpc7_1.17.0-1_amd64.deb
dpkg -i --force-depends *_1.17.0-1_*

# nm -D /lib/x86_64-linux-gnu/libgrpc++_unsecure.so.1 | grep 
_ZN4grpc13ClientContextC1Ev
00032da0 T _ZN4grpc13ClientContextC1Ev



##



wget 
https://snapshot.debian.org/archive/debian/20181217T091644Z/pool/main/g/grpc/libgrpc%2B%2B1_1.17.2-1_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20181217T091644Z/pool/main/g/grpc/libgrpc7_1.17.2-1_amd64.deb
dpkg -i --force-depends *_1.17.2-1_*

# nm -D /lib/x86_64-linux-gnu/libgrpc++_unsecure.so.1 | grep 
_ZN4grpc13ClientContextC1Ev
00032da0 T _ZN4grpc13ClientContextC1Ev



##


grpc 1.22.0-1, not available for amd64


##



wget 
https://snapshot.debian.org/archive/debian/20190811T045655Z/pool/main/g/grpc/libgrpc%2B%2B1_1.22.0-2_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20190811T045655Z/pool/main/g/grpc/libgrpc7_1.22.0-2_amd64.deb
dpkg -i --force-depends *_1.22.0-2_*

# nm -D /lib/x86_64-linux-gnu/libgrpc++_unsecure.so.1 | 

Bug#954901: ghostscript: runtime error: malloc(): invalid size (unsorted)

[Bernhard Übelacker]

Dear Maintainer,
I tried to collect some more information and might have found something.

The allocator aborts at the backtrace below.

A valgrind run points to the same function txt_add_fragment.

There is seems that in line 2121 the allocation takes place with
12 bytes total, then a memset is done with 12 bytes.
But in line 2126 the memcpy is done with 24 bytes.

This is because allocation is done with
penum->TextBufferIndex == 3, but the memcpy uses 
penum->text.size == 6. (For the given input file.)

The same pattern in lines 2134 to 2139.

But I have no clue if the variables are the
right ones, or contain wrong values.

It might be related to this upstream bug,
which touches the same lines:

  https://bugs.ghostscript.com/show_bug.cgi?id=701877

Kind regards,
Bernhard



https://sources.debian.org/src/ghostscript/9.52%7Edfsg-1/devices/vector/gdevtxtw.c/#L2121
https://git.ghostscript.com/?p=ghostpdl.git;a=blob;f=devices/vector/gdevtxtw.c;h=87f9355d8771e1fa546b4eb687ae4078ef2abdff;hb=HEAD#l2121

2121 penum->text_state->Widths = (float 
*)gs_malloc(tdev->memory->stable_memory,
2122 penum->TextBufferIndex, sizeof(float), "txtwrite alloc widths 
array");
2123 if (!penum->text_state->Widths)
2124 return gs_note_error(gs_error_VMerror);
2125 memset(penum->text_state->Widths, 0x00, penum->TextBufferIndex * 
sizeof(float));
2126 memcpy(penum->text_state->Widths, penum->Widths, penum->text.size * 
sizeof(float));





(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7fb706bae55b in __GI_abort () at abort.c:79
#2  0x7fb706c06ff8 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7fb706d13f3e "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x7fb706c0e39a in malloc_printerr (str=str@entry=0x7fb706d16010 
"malloc(): invalid size (unsorted)") at malloc.c:5339
#4  0x7fb706c11304 in _int_malloc (av=av@entry=0x7fb706d45b80 , 
bytes=bytes@entry=62) at malloc.c:3736
#5  0x7fb706c12a74 in __GI___libc_malloc (bytes=bytes@entry=62) at 
malloc.c:3058
#6  0x7fb7070a3445 in gs_heap_alloc_bytes (mem=0x5600c40c5c40, size=14, 
cname=0x7fb7072389c8 "txtwrite alloc sorted text buffer") at 
./base/gsmalloc.c:191
#7  0x7fb706fe88e1 in txt_add_fragment (penum=0x5600c45abea8, 
tdev=) at ./devices/vector/gdevtxtw.c:2141
#8  textw_text_process (pte=0x5600c45abea8) at ./devices/vector/gdevtxtw.c:2241
#9  0x7fb70717b8a0 in op_show_continue (i_ctx_p=0x5600c40f9778) at 
./psi/zchar.c:690
#10 op_show_continue (i_ctx_p=0x5600c40f9778) at ./psi/zchar.c:685
#11 0x7fb70715d739 in interp (perror_object=, 
pref=, pi_ctx_p=) at ./psi/interp.c:1300
#12 gs_call_interp (pi_ctx_p=pi_ctx_p@entry=0x5600c40c6590, 
pref=pref@entry=0x775a4350, user_errors=user_errors@entry=1, 
pexit_code=pexit_code@entry=0x775a43cc, perror_object=) at 
./psi/interp.c:520
#13 0x7fb70715ec7a in gs_interpret (pi_ctx_p=pi_ctx_p@entry=0x5600c40c6590, 
pref=pref@entry=0x775a4350, user_errors=user_errors@entry=1, 
pexit_code=pexit_code@entry=0x775a43cc, perror_object=, 
perror_object@entry=0x775a43d0) at ./psi/interp.c:477
#14 0x7fb70715153e in gs_main_interpret (perror_object=0x775a43d0, 
pexit_code=0x775a43cc, user_errors=1, pref=0x775a4350, minst=) at ./psi/imain.c:791
#15 gs_main_run_string_end (minst=minst@entry=0x5600c40c64f0, 
user_errors=user_errors@entry=1, pexit_code=pexit_code@entry=0x775a43cc, 
perror_object=perror_object@entry=0x775a43d0) at ./psi/imain.c:791
#16 0x7fb7071515d1 in gs_main_run_string_with_length (str=, 
length=, perror_object=0x775a43d0, 
pexit_code=0x775a43cc, user_errors=1, minst=0x5600c40c64f0) at 
./psi/imain.c:735
#17 gs_main_run_string_with_length (minst=0x5600c40c64f0, str=0x5600c41c2720 
"<6f75742e706466>.runfile", length=24, user_errors=1, 
pexit_code=0x775a43cc, perror_object=0x775a43d0) at ./psi/imain.c:721
#18 0x7fb7071534ef in run_string (minst=minst@entry=0x5600c40c64f0, 
str=str@entry=0x5600c41c2720 "<6f75742e706466>.runfile", 
options=options@entry=3, user_errors=user_errors@entry=1, 
pexit_code=0x775a43cc, pexit_code@entry=0x0, perror_object=0x775a43d0, 
perror_object@entry=0x0) at ./psi/imainarg.c:1119
#19 0x7fb7071537e6 in runarg (minst=minst@entry=0x5600c40c64f0, 
arg=arg@entry=0x775a4508 "out.pdf", post=post@entry=0x7fb70725cc5c 
".runfile", options=options@entry=3, user_errors=1, 
pexit_code=pexit_code@entry=0x0, perror_object=0x0, pre=0x7fb70723aced "") at 
./psi/imainarg.c:1088
#20 0x7fb707153904 in argproc (arg=0x775a4508 "out.pdf", 
minst=0x5600c40c64f0) at ./psi/imainarg.c:1010
#21 argproc (minst=0x5600c40c64f0, arg=0x775a4508 "out.pdf") at 
./psi/imainarg.c:995
#22 0x7fb707155010 in gs_main_init_with_args01 
(minst=minst@entry=0x5600c40c64f0, argc=7, argv=0x775a5038) at 
./psi/imainarg.c:241
#23 0x7fb7071552b9 in gs_main_init_with_args (minst=0x5600c40c64f0, 
argc=, argv=) at ./psi/imainarg.c:

Bug#954203: Client splash and exit after login in

[Bernhard Übelacker]

Hello Gulfstream,


> Thanks for your reply! My next question is How to connect the xrdp server 
> using remmina client? I don't find where to set the glyph cache.

in the previous mentioned upstream link to the remmina bug
tracker in comment [1] is written that they added such flags,
but I guess the version in buster does not yet contain it.

My best hint would be to check for it in the version
in buster-backports, as a workaround.


> ... And When will the bug be resolve?

This has to be answered by the xrdp maintainers.


Kind regards,
Bernhard

[1] https://gitlab.com/Remmina/Remmina/issues/1770#note_120907885

Bug#954203: Client splash and exit after login in

[Bernhard Übelacker]

Hello,
this seems to be caused by xrdp using glyph cache even
when the client does not advertise it.
Additionally freerdp does now stricter checks.

Upstream bugs are here [1].

A workaround could be to use xfreerdp like this:

xfreerdp +glyph-cache /relax-order-checks /v:hostname

Kind regards,
Bernhard


[1]
https://github.com/neutrinolabs/xrdp/issues/1266

https://gitlab.com/Remmina/Remmina/issues/1770

https://github.com/FreeRDP/FreeRDP/issues/5072
https://github.com/FreeRDP/FreeRDP/issues/5207

# Unstable amd64 qemu VM 2020-03-21

apt update
apt dist-upgrade

apt install systemd-coredump xserver-xorg sddm openbox xrdp remmina freerdp2-x11


reboot


adduser test


$ dpkg -l | grep -E "remmina|rdp"
ii  libfreerdp-client2-2:amd64   2.0.0~git20190204.1.2693389a+dfsg1-2 
amd64Free Remote Desktop Protocol library (client library)
ii  libfreerdp2-2:amd64  2.0.0~git20190204.1.2693389a+dfsg1-2 
amd64Free Remote Desktop Protocol library (core library)
ii  remmina  1.4.1+dfsg-1 
amd64GTK+ Remote Desktop Client
ii  remmina-common   1.4.1+dfsg-1 
all  Common files for Remmina
ii  remmina-plugin-rdp:amd64 1.4.1+dfsg-1 
amd64RDP plugin for Remmina
ii  remmina-plugin-secret:amd64  1.4.1+dfsg-1 
amd64Secret plugin for Remmina
ii  remmina-plugin-vnc:amd64 1.4.1+dfsg-1 
amd64VNC plugin for Remmina
ii  xorgxrdp 1:0.2.12-1   
amd64Remote Desktop Protocol (RDP) modules for X.org
ii  xrdp 0.9.12-1 
amd64Remote Desktop Protocol (RDP) server








export DISPLAY=:0








$ remmina
Remmina plugin glibsecret (type=Secret) has registered but not yet 
initialized/activated. Initialization order is 2000.

** (process:730): CRITICAL **: 11:38:54.435: 
secret_service_load_collections_sync: assertion 'paths != NULL' failed
[glibsecret] unable to get secret service: Unknown error.
StatusNotifier/Appindicator support: not supported by desktop. libappindicator 
will try to fallback to GtkStatusIcon/xembed
Warning: Remmina is running without a secret plugin. Passwords will be saved in 
a less secure way.

(org.remmina.Remmina:730): Gtk-WARNING **: 11:38:54.612: 
gtk_menu_attach_to_widget(): menu already attached to GtkMenuItem
  
  
  
  
[11:39:15:452] [730:764] [INFO][com.freerdp.client.common.cmdline] - loading 
channelEx cliprdr
[11:39:15:452] [730:764] [INFO][com.freerdp.client.common.cmdline] - loading 
channelEx drdynvc
[11:39:15:499] [730:764] [INFO][com.freerdp.gdi] - Local framebuffer format  
PIXEL_FORMAT_BGRX32
[11:39:15:499] [730:764] [INFO][com.freerdp.gdi] - Remote framebuffer format 
PIXEL_FORMAT_BGRA32
[11:39:15:499] [730:764] [INFO][com.freerdp.channels.drdynvc.client] - Loading 
Dynamic Virtual Channel rdpgfx
[11:39:15:499] [730:764] [INFO][com.freerdp.channels.drdynvc.client] - Loading 
Dynamic Virtual Channel disp
[11:39:15:526] [730:764] [ERROR][com.freerdp.core.update] - [0x03] Cache Glyph 
- SERVER BUG: The support for this feature was not announced! Use 
/relax-order-checks to ignore
[11:39:15:526] [730:764] [ERROR][com.freerdp.core.update] - order flags 03 
failed
[11:39:15:526] [730:764] [ERROR][com.freerdp.core.fastpath] - Fastpath update 
Orders [0] failed, status 0
[11:39:15:526] [730:764] [ERROR][com.freerdp.core.fastpath] - 
fastpath_recv_update_data: fastpath_recv_update() - -1
[11:39:15:526] [730:764] [ERROR][com.freerdp.core.fastpath] - 
fastpath_recv_update_data() fail
[11:39:15:526] [730:764] [ERROR][com.freerdp.core.transport] - 
transport_check_fds: transport->ReceiveCallback() - -3
[11:39:15:526] [730:764] [ERROR][com.freerdp.core] - freerdp_check_fds() failed 
- 0
[11:39:15:066] [730:764] [INFO][com.freerdp.channels.drdynvc.client] - Loading 
Dynamic Virtual Channel rdpgfx
[11:39:15:066] [730:764] [INFO][com.freerdp.channels.drdynvc.client] - Loading 
Dynamic Virtual Channel disp
[11:39:15:083] [730:764] [ERROR][com.freerdp.core.update] - [0x03] Cache Glyph 
- SERVER BUG: The support for this feature was not announced! Use 
/relax-order-checks to ignore
...

-> trying to connect over and over again








$ xfreerdp /v:localhost
[11:51:47:908] [715:716] [INFO][com.freerdp.client.common.cmdline] - loading 
channelEx cliprdr
[11:51:47:909] [715:716] [INFO][com.freerdp.client.x11] - No user name set. - 
Using login name: benutzer
[11:51:47:950] [715:716] [INFO][com.freerdp.gdi] - Local framebuffer format  
PIXEL_FORMAT_BGRX32
[11:51:47:950] [715:716] [INFO][com.freerdp.gdi] - Remote framebuffer format 
PIXEL_FORMAT_RGB16
[11:51:47:986] [715:716] [INFO][com.winpr.clipboard] - initialized POSIX local 
file subsystem
[11:51:47:991] [715:716] [ERROR][com.freerdp.core.update] - [0x03] Cache Glyp

Bug#950535: iptables-restore segfaults on nat table

[Bernhard Übelacker]

Dear Maintainer,
I tried to collect some more information and got
the following backtrace with the restore command
from the submitter.

It looks like "expr->ops" contains a null pointer
that gets dereferenced.

Unfortunately I still see the same crash after
upgrading to the versions in backports in my test VM.

Also this crash is still visible in a minimal
Bullseye/testing VM.

Kind regards,
Bernhard


(gdb) bt
#0  0x7fd480466793 in nftnl_expr_build_payload (nlh=0x7fd47fc7a178, 
expr=0x55fe70704f40) at expr.c:210
#1  0x7fd480461783 in nftnl_rule_nlmsg_build_payload (nlh=0x7fd47fc7a178, 
r=0x55fe70705650) at rule.c:320
#2  0x55fe6e793c66 in nft_compat_rule_batch_add (h=, 
type=, flags=, seq=, 
rule=) at nft.c:2579
#3  0x55fe6e79493e in nft_action (h=0x7fff14b33560, action=0) at nft.c:2673
#4  0x55fe6e790555 in xtables_restore_parse (h=h@entry=0x7fff14b33560, 
p=p@entry=0x7fff14b33540, cb=cb@entry=0x55fe6e7b8140 , 
argc=argc@entry=1, argv=argv@entry=0x7fff14b336e8) at xtables-restore.c:143
#5  0x55fe6e790f90 in xtables_restore_main (family=2, progname=, argc=1, argv=0x7fff14b336e8) at xtables-restore.c:474
#6  0x7fd47fcf709b in __libc_start_main (main=0x55fe6e78bfb0 , 
argc=1, argv=0x7fff14b336e8, init=, fini=, 
rtld_fini=, stack_end=0x7fff14b336d8) at ../csu/libc-start.c:308
#7  0x55fe6e78bfea in _start ()

(gdb) print expr
$3 = (struct nftnl_expr *) 0x55fe70704f40

(gdb) print expr->ops
$4 = (struct expr_ops *) 0x0

(gdb) list expr.c:210
205
206 void nftnl_expr_build_payload(struct nlmsghdr *nlh, struct nftnl_expr 
*expr)
207 {
208 struct nlattr *nest;
209
210 mnl_attr_put_strz(nlh, NFTA_EXPR_NAME, expr->ops->name);
211
212 if (!expr->ops->build)
213 return;
214

https://sources.debian.org/src/libnftnl/1.1.2-2/src/expr.c/#L210

# Buster/stable amd64 qemu VM 2020-02-11


apt update
apt dist-upgrade


apt install systemd-coredump mc git fakeroot strace gdb iptables-dbgsym 
libnftnl11-dbgsym
apt build-dep iptables libnftnl11



mkdir /home/benutzer/source/libnftnl11/orig -p
cd/home/benutzer/source/libnftnl11/orig
apt source libnftnl11
cd

mkdir /home/benutzer/source/iptables/orig -p
cd/home/benutzer/source/iptables/orig
apt source iptables
cd

mkdir /home/benutzer/source/iptables/git -p
cd/home/benutzer/source/iptables/git
git clone git://git.netfilter.org/iptables
cd





iptables-restore < *nat
> -F PREROUTING
> -A PREROUTING -i eth0 -p tcp --dport 22 -j REDIRECT --to-ports 1194
> -F PREROUTING
> -F POSTROUTING
> COMMIT
> EOF
Speicherzugriffsfehler (Speicherabzug geschrieben)


# journalctl --no-pager
Feb 11 13:34:26 debian kernel: iptables-restor[1104]: segfault at 0 ip 
7fd480466793 sp 7fff14b30530 error 4 in 
libnftnl.so.11.0.0[7fd48045b000+17000]
Feb 11 13:34:26 debian kernel: Code: 0c 25 28 00 00 00 75 05 48 83 c4 18 c3 e8 
b5 4a ff ff 0f 1f 44 00 00 41 54 55 48 89 fd 53 48 8b 46 18 48 89 f3 be 01 00 
00 00 <48> 8b 10 e8 b5 51 ff ff 48 8b 43 18 48 83 78 30 00 74 32 48 89 ef
Feb 11 13:34:26 debian systemd[1]: Created slice 
system-systemd\x2dcoredump.slice.
Feb 11 13:34:26 debian systemd[1]: Started Process Core Dump (PID 1105/UID 0).
Feb 11 13:34:26 debian systemd-coredump[1106]: Process 1104 (iptables-restor) 
of user 0 dumped core.
   
   Stack trace of thread 1104:
   #0  0x7fd480466793 n/a 
(libnftnl.so.11)
   #1  0x7fd480461783 
nftnl_rule_nlmsg_build_payload (libnftnl.so.11)
   #2  0x55fe6e79493e n/a 
(xtables-nft-multi)
   #3  0x55fe6e790555 n/a 
(xtables-nft-multi)
   #4  0x55fe6e790f90 n/a 
(xtables-nft-multi)
   #5  0x7fd47fcf709b 
__libc_start_main (libc.so.6)
   #6  0x55fe6e78bfea n/a 
(xtables-nft-multi)
Feb 11 13:34:26 debian systemd[1]: systemd-coredump@0-1105-0.service: Succeeded.



root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Tue 2020-02-11 13:34:26 CET1104 0 0  11 present   
/usr/sbin/xtables-nft-multi





root@debian:~# coredumpctl gdb 1104
   PID: 1104 (iptables-restor)
   UID: 0 (root)
   GID: 0 (root)
Signal: 11 (SEGV)
 Timestamp: Tue 2020-02-11 13:34:26 CET (2min 44s ago)
  Command Line: iptables-restore
Executable: /usr/sbin/xtables-nft-multi
 Control Group: /user.slice/user-1000.slice/session-1.scope
  Unit: session-1.scope
 Slice: user-1000.slice
   Session: 1
 Owner UID: 1000 (benutzer)
   Boot ID: 07b3a6dc70ab428eb2a3fb217276c015
Machine ID: 33f18f39d2a9438eb75b0ed52848afcd
  Hostname: debian
   Stora

Bug#945814: audacity: various segfaults of audacity on startup

[Bernhard Übelacker]

Control: reassign -1 zynaddsubfx-dssi 3.0.3-1
Control: affects -1 + audacity


Hello Tjeerd,

> Thanks for coming back, I'm not in a hurry...
> 
> The problem is that I can not trigger specific bugs (they seem to happen
> somewhat random). So a made some more valgrinds: valgrind.dat 

Because the error des not manifest each run in the same location
this might be thread related e.g. two threads are working on the
same memory.


> I had zynaddsubfx installed to try it out and see if I like it, but did
> not uninstall after the tries (sufficient diskspace luxury). I could
> uninstall zynadd, zynsaddsubfx and zynaddsubfx-dssi, the data package is
> depended on by the lmms-common package.

I tried to install some more lv2 plugins and bridges and after enabling
all in audacity I got the shared library loaded libzynaddsubfx_dssi.so
by just starting audacity - but still cannot reproduce a crash.
(Details attached.)


> And audacity runs without crashing (thanks for the hint) but still gives
> a lot of debug output: audacity_debug.dat

Most of the remaining output seems gui related - seems to be harmless.


> So at least the the source of all evil is now clear... and the bug
> "resolved". Do you have contact with the zynaddsubfx devs and file a bug
> there? Devs amongst each other might talk clearer? Otherwise I'm happy
> to do it.

It might not be that clear - depending on e.g. libzynaddsubfx_dssi.so
is intended to work multi threaded ...

When I did run audacity in my test environment I get some
"Possible data race" with valgrind's helgrind tool.

At least it might be related to some plugins, either direct or
via some bridges, therefore I hope it is ok to reassign.

Bringing the issue upstream might also not be a bad idea.

Kind regards,
Bernhard

# Buster/stable amd64 qemu VM 2020-01-27

apt update
apt dist-upgrade


apt install systemd-coredump xserver-xorg sddm openbox xterm mc strace valgrind 
gdb audacity jackd2 lmms zynadd zynaddsubfx-dssi liblv2dynparamhost1-1 
naspro-bridges audacity-dbgsym libstdc++6-8-dbg zynaddsubfx-dssi-dbgsym 
naspro-bridges-dbgsym libjack-jackd2-0-dbgsym libwxbase3.0-0v5-dbgsym 
libportaudio2-dbgsym libnabrit-dbg liblilv-0-0-dbgsym


reboot


# dpkg -l | grep -i -E "audacity|jack|zynaddsubfx|lmms"
ii  audacity   2.2.2-1+b1   amd64
fast, cross-platform audio editor
ii  audacity-data  2.2.2-1  all  
fast, cross-platform audio editor (data)
ii  audacity-dbgsym2.2.2-1+b1   amd64
debug symbols for audacity
ii  jackd  5+nmu1   all  
JACK Audio Connection Kit (default server package)
ii  jackd2 1.9.12~dfsg-2amd64
JACK Audio Connection Kit (server and example clients)
ii  jackd2-firewire1.9.12~dfsg-2amd64
JACK Audio Connection Kit (FFADO and FreeBoB backends)
ii  libjack-jackd2-0:amd64 1.9.12~dfsg-2amd64
JACK Audio Connection Kit (libraries)
ii  libjack-jackd2-0-dbgsym:amd64  1.9.12~dfsg-2amd64
debug symbols for libjack-jackd2-0
ii  lmms   1.1.3-8.1amd64
Linux Multimedia Studio
ii  lmms-common1.1.3-8.1all  
Linux Multimedia Studio - common files
ii  qjackctl   0.5.0-1  amd64
User interface for controlling the JACK sound server
ii  zynadd 1+git.20100609+dfsg0-4   amd64
ZynAddSubFX engines converted to LV2 plugin format
ii  zynaddsubfx3.0.3-1  amd64
Realtime software synthesizer for Linux
ii  zynaddsubfx-data   3.0.3-1  all  
Realtime software synthesizer for Linux (data)
ii  zynaddsubfx-dssi   3.0.3-1  amd64
dssi plugin of zynaddsubfx
ii  zynaddsubfx-dssi-dbgsym3.0.3-1  amd64
debug symbols for zynaddsubfx-dssi





export LANG=C
export DISPLAY=:0

qjackctl
# Start



audacity

# Select all new plugins and enable
# Close




gdb -q

set width 0
set pagination off
set breakpoint pending on
file /usr/bin/audacity
break _ZN3zyn10MiddleWare4tickEv
run
break 
_ZN3zyn4Bank9addtobankEiNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES6_
cont
break free
cont
generate /home/benutzer/core



(gdb) bt
#0  __GI___libc_free (mem=0x5652b0c0) at malloc.c:3083
#1  0x7fffe9511f3d in zyn::Bank::addtobank(int, 
std::__cxx11::basic_string, std::allocator 
>, std::__cxx11::basic_string, 
std::allocator >) () from /usr/lib/dssi/libzynaddsubfx_dssi.so
#2  0x7fffe95138a1 in zyn::Bank::loadbank(std::__cxx11::basic_string, std::allocator >) () from 
/usr/lib/dssi/libzynaddsubfx_dssi.so
#3  0x7fffe955b29c in ?? () from /usr/lib/dssi/libzynad

Bug#945814: Fwd: Bug#945814: audacity: various segfaults of audacity on startup

[Bernhard Übelacker]

Hello Tjeerd,
sorry for the delay.
I would have expected more output from catchsegv.

I guess the first valgrind run would have been better
placed in an attachement too.

The file audacity_coredumps.log points to
libzynaddsubfx_dssi.so that belongs to package zynaddsubfx-dssi.
That seems to be involved in the crash at least.

I guess this package is installed on purpose on your system?
If not uninstalling could be a workaround.

As I just tried to help triaging this issue and being not involved
in packaging I have not enough knowledge how to setup a system to
get this file loaded by audacity.

Therefore probably you could add what needs to be done
from a fresh installed system to reach a setup similar to yours.

And please add the output of following:
   dpkg -l | grep -i -E "audacity|jack|zynaddsubfx"

Kind regards,
Bernhard


Backtrace from audacity_coredumps.log what it should look like with debug 
symbols installed:
Stack trace of thread 11485:
#0  0x7f94d6a507bb __GI_raise (libc.so.6)
#1  0x7f94d6a3b535 __GI_abort (libc.so.6)
#2  0x7f94d6a92508 __libc_message (libc.so.6)
#3  0x7f94d6a98c1a malloc_printerr (libc.so.6)
#4  0x7f94d6a9a5d7 _int_free (libc.so.6)
#5  0x7f94cacf6f3d in __gnu_cxx::new_allocator::deallocate(char*, 
unsigned long) at /usr/include/c++/7/ext/new_allocator.h:125
   in zyn::Bank::addtobank(int, 
std::__cxx11::basic_string, std::allocator 
>, std::__cxx11::basic_string, 
std::allocator >)
#6  0x7f94cacf88a1 in zyn::Bank::loadbank(std::__cxx11::basic_string, std::allocator >) at ./src/Misc/Bank.cpp:267
#7  0x7f94cad4029c in zyn::MiddleWareImpl::loadPendingBank(int, zyn::Bank&) 
at ./src/Misc/MiddleWare.cpp:477
#8  0x7f94cade20ea in std::function::operator()(char const*, rtosc::RtData&) const at 
/usr/include/c++/7/bits/std_function.h:706
   in rtosc::Ports::dispatch(char const*, rtosc::RtData&, 
bool)
#9  0x7f94cad42959 in zyn::MiddleWareImpl::bToUhandle(char const*) at 
./src/Misc/MiddleWare.cpp:1905
#10 0x7f94cad42cbf in zyn::MiddleWareImpl::tick() at 
./src/Misc/MiddleWare.cpp:698
#11 0x7f94cacf43fd in DSSIaudiooutputoperator() at 
./src/Output/DSSIaudiooutput.cpp:635
#12 0x7f94d6e32b2f n/a (libstdc++.so.6)
#13 0x7f94d6f0efa3 in start_thread (arg=) at 
pthread_create.c:486
#14 0x7f94d6b124cf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

https://sources.debian.org/src/zynaddsubfx/3.0.3-1/src/Misc/Bank.cpp/#L506
https://sources.debian.org/src/zynaddsubfx/3.0.3-1/src/Misc/Bank.cpp/#L267

Bug#948876: kodi: FTBFS: something segfaults

[Bernhard Übelacker]

Dear Maintainer,
a short addition. I got some help that AddressSanitizer
and Valgrind could be squeezed to delay returning previously
free'd addresses from the allocator.

Then both tools point to the mentioned first allocation directly.

Kind regards,
Bernhard


AddressSanitizer: export ASAN_OPTIONS=quarantine_size_mb=1000


Valgrind: --freelist-vol=100
Result with unmodified Debian binaries:
valgrind --tool=memcheck --track-origins=yes --num-callers=100 
--freelist-vol=100 fontforge -script 
/home/benutzer/source/kodi/try1/kodi-17.6+dfsg1/debian/mergefonts.ff 
/usr/share/fonts/truetype/droid/DroidSansFallbackFull.ttf 
/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf 
/home/benutzer/source/kodi/try1/kodi-17.6+dfsg1/media/Fonts/arial.ttf
The glyph named Omega is mapped to U+03A9.
  But its name indicates it should be mapped to U+2126.
==74312== Invalid read of size 8
==74312==at 0x55F6B69: gv_len (tottfgpos.c:3838)
==74312==by 0x5601DC9: ttf_math_dump_glyphvariant (tottfgpos.c:3979)
==74312==by 0x5601DC9: otf_dump_math (tottfgpos.c:4139)
==74312==by 0x56134C9: initATTables (tottf.c:5316)
==74312==by 0x5615006: initTables (tottf.c:5792)
==74312==by 0x561552A: _WriteTTFFont (tottf.c:6143)
==74312==by 0x5615A49: WriteTTFFont (tottf.c:6171)
==74312==by 0x54F5413: _DoSave (savefont.c:845)
==74312==by 0x54F7DCF: GenerateScript (savefont.c:1269)
==74312==by 0x55103FB: bGenerate (scripting.c:2061)
==74312==by 0x5512F0A: docall (scripting.c:9632)
==74312==by 0x551359D: handlename (scripting.c:9745)
==74312==by 0x55147B2: term (scripting.c:9983)
==74312==by 0x5514B37: mul (scripting.c:10128)
==74312==by 0x5514D4D: add (scripting.c:10174)
==74312==by 0x55150B8: comp (scripting.c:10249)
==74312==by 0x5515340: _and (scripting.c:10293)
==74312==by 0x55154E2: _or (scripting.c:10325)
==74312==by 0x55154E2: assign (scripting.c:10358)
==74312==by 0x55122FC: expr (scripting.c:10436)
==74312==by 0x55122FC: ff_statement (scripting.c:10649)
==74312==by 0x5516110: ProcessNativeScript (scripting.c:10796)
==74312==by 0x5516744: _CheckIsScript (scripting.c:10890)
==74312==by 0x5516744: CheckIsScript (scripting.c:10927)
==74312==by 0x4A165B8: fontforge_main (startui.c:1099)
==74312==by 0x4C13BBA: (below main) (libc-start.c:308)
==74312==  Address 0x8f6e3600 is 0 bytes inside a block of size 40 free'd
==74312==at 0x48379AB: free (vg_replace_malloc.c:540)
==74312==by 0x55C7B19: SplineCharFreeContents (splineutil.c:5963)
==74312==by 0x55C7B7D: SplineCharFree (splineutil.c:5974)
==74312==by 0x55C7B7D: SplineCharFree (splineutil.c:5970)
==74312==by 0x55CA66D: SplineFontFree (splineutil.c:6535)
==74312==by 0x55CA66D: SplineFontFree (splineutil.c:6491)
==74312==by 0x542E147: _MergeFont (fvfonts.c:1161)
==74312==by 0x542E147: __MergeFont (fvfonts.c:1179)
==74312==by 0x542E147: MergeFont (fvfonts.c:1261)
==74312==by 0x5512F0A: docall (scripting.c:9632)
==74312==by 0x551359D: handlename (scripting.c:9745)
==74312==by 0x55147B2: term (scripting.c:9983)
==74312==by 0x5514B37: mul (scripting.c:10128)
==74312==by 0x5514D4D: add (scripting.c:10174)
==74312==by 0x55150B8: comp (scripting.c:10249)
==74312==by 0x5515340: _and (scripting.c:10293)
==74312==by 0x55154E2: _or (scripting.c:10325)
==74312==by 0x55154E2: assign (scripting.c:10358)
==74312==by 0x55122FC: expr (scripting.c:10436)
==74312==by 0x55122FC: ff_statement (scripting.c:10649)
==74312==by 0x5516110: ProcessNativeScript (scripting.c:10796)
==74312==by 0x5516744: _CheckIsScript (scripting.c:10890)
==74312==by 0x5516744: CheckIsScript (scripting.c:10927)
==74312==by 0x4A165B8: fontforge_main (startui.c:1099)
==74312==by 0x4C13BBA: (below main) (libc-start.c:308)
==74312==  Block was alloc'd at
==74312==at 0x4838B65: calloc (vg_replace_malloc.c:762)
==74312==by 0x5486A1B: ttf_math_read_gvtable (parsettfatt.c:5317)
==74312==by 0x5491113: ttf_math_read_variants (parsettfatt.c:5473)
==74312==by 0x5491113: _otf_read_math (parsettfatt.c:5515)
==74312==by 0x5491113: _otf_read_math (parsettfatt.c:5493)
==74312==by 0x54A87D4: readttf (parsettf.c:5673)
==74312==by 0x54A87D4: _SFReadTTF (parsettf.c:6327)
==74312==by 0x556808E: _ReadSplineFont (splinefont.c:1141)
==74312==by 0x5569238: LoadSplineFont (splinefont.c:1379)
==74312==by 0x550B0E2: bMergeFonts (scripting.c:5600)
==74312==by 0x5512F0A: docall (scripting.c:9632)
==74312==by 0x551359D: handlename (scripting.c:9745)
==74312==by 0x55147B2: term (scripting.c:9983)
==74312==by 0x5514B37: mul (scripting.c:10128)
==74312==by 0x5514D4D: add (scripting.c:10174)
==74312==by 0x55150B8: comp (scripting.c:10249)
==74312==by 0x5515340: _and (scripting.c:10293)
==74312==by 0x55154E2: _or (scripting.c:10325)
==74312==by 0x55154E2: assign (scripting.c:10358)
==74312==

Bug#948876: kodi: FTBFS: something segfaults

[Bernhard Übelacker]

Dear Maintainer,
I tried to look into this issue without being involved
in packaging fontforge.
I found it most reproducible when building with
"-fsanitize=address", and then always failing on accessing
the same address. [1]


As far as I see this is what happens:

- Address 0x6048a210 gets returned by the allocator [2],
  and stored in "sf->glyphs[49391]->vert_variants".

- Memory gets freed below SplineFontFree while still
  stored below "sf->..." [3].


- Address 0x6048a210 gets returned a second time.
  This is returned as the previous allocation by AddressSanitizer [1].

- And freed again.


- The first pointer gets further copied around (See attached file.)

- Now in gv_len this address is again accessed and causes the crash. [1]


(Is there a way to force AddressSanitizer to return unique memory addresses?)
The line numbers of the AddressSanitizer outputs do not
completely match because of some added fprintf's.


A temporary workaround could be to disable the call to
SplineFontFree in _MergeFont. Then no crash happens.


Kind regards,
Bernhard




[1]
==111281==ERROR: AddressSanitizer: heap-use-after-free on address 
0x6048a210 at pc 0x7fc246fb1ea9 bp 0x7fff40ed9800 sp 0x7fff40ed97f8
READ of size 8 at 0x6048a210 thread T0
#0 0x7fc246fb1ea8 in gv_len ./fontforge/tottfgpos.c:3838
#1 0x7fc246fcce1f in ttf_math_dump_glyphvariant ./fontforge/tottfgpos.c:3979
#2 0x7fc246fcce1f in otf_dump_math ./fontforge/tottfgpos.c:4139
#3 0x7fc246fff7f0 in initATTables ./fontforge/tottf.c:5316
#4 0x7fc24700297e in initTables ./fontforge/tottf.c:5792
#5 0x7fc247003737 in _WriteTTFFont ./fontforge/tottf.c:6143
#6 0x7fc2470040b1 in WriteTTFFont ./fontforge/tottf.c:6171
#7 0x7fc246d09d1b in _DoSave ./fontforge/savefont.c:845
#8 0x7fc246d0ec2b in GenerateScript ./fontforge/savefont.c:1269
#9 0x7fc246d5d592 in bGenerate ./fontforge/scripting.c:2061
#10 0x7fc246d63b7d in docall ./fontforge/scripting.c:9632
#11 0x7fc246d64be1 in handlename ./fontforge/scripting.c:9745
#12 0x7fc246d67aa1 in term ./fontforge/scripting.c:9983
#13 0x7fc246d684fb in mul ./fontforge/scripting.c:10128
#14 0x7fc246d68a0b in add ./fontforge/scripting.c:10174
#15 0x7fc246d6943c in comp ./fontforge/scripting.c:10249
#16 0x7fc246d69b10 in _and ./fontforge/scripting.c:10293
#17 0x7fc246d6a04a in _or ./fontforge/scripting.c:10325
#18 0x7fc246d6a04a in assign ./fontforge/scripting.c:10358
#19 0x7fc246d620d9 in expr ./fontforge/scripting.c:10436
#20 0x7fc246d620d9 in ff_statement ./fontforge/scripting.c:10649
#21 0x7fc246d6bddd in ProcessNativeScript ./fontforge/scripting.c:10796
#22 0x7fc246d6c944 in _CheckIsScript ./fontforge/scripting.c:10890
#23 0x7fc246d6c944 in CheckIsScript ./fontforge/scripting.c:10927
#24 0x7fc2477c8643 in fontforge_main ./fontforgeexe/startnoui.c:122
#25 0x7fc24762cbba in __libc_start_main ../csu/libc-start.c:308
#26 0x5568a79b80c9 in _start 
(/home/benutzer/source/libfontforge3/try2/fontforge-20190801~dfsg/debian/fontforge-nox/usr/bin/fontforge+0x10c9)

0x6048a210 is located 0 bytes inside of 35-byte region 
[0x6048a210,0x6048a233)
freed by thread T0 here:
#0 0x7fc2478d4277 in __interceptor_free 
(/lib/x86_64-linux-gnu/libasan.so.5+0x107277)
#1 0x7fc246fe6564 in dumpglyph ./fontforge/tottf.c:1331

previously allocated by thread T0 here:
#0 0x7fc2478d4628 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x107628)
#1 0x7fc246fe6336 in dumpglyph ./fontforge/tottf.c:1316




[2]
# Alloction 1
(gdb) print gv
$1 = (struct glyphvariants *) 0x6048a210
(gdb) bt
#0  0x769adb01 in ttf_math_read_gvtable (ttf=ttf@entry=0x6160002bfb80, 
info=info@entry=0x7fffc3c0, start=, 
justinuse=justinuse@entry=git_normal, basesc=basesc@entry=0x613002af2800, 
isv=isv@entry=1) at ././fontforge/parsettfatt.c:5318
#1  0x769c7653 in ttf_math_read_variants (justinuse=git_normal, 
start=47440, info=0x7fffc3c0, ttf=0x6160002bfb80) at 
././fontforge/parsettfatt.c:5474
#2  0x769c7653 in _otf_read_math (justinuse=git_normal, info=, ttf=0x6160002bfb80) at ././fontforge/parsettfatt.c:5518
#3  0x769c7653 in _otf_read_math (ttf=0x6160002bfb80, info=, justinuse=git_normal) at ././fontforge/parsettfatt.c:5496
#4  0x76a08515 in readttf (filename=, info=, ttf=0x6020004fd210) at ././fontforge/parsettf.c:5673
#5  0x76a08515 in _SFReadTTF (ttf=ttf@entry=0x6160002bfb80, 
flags=flags@entry=0, openflags=openflags@entry=(unknown: 0), 
filename=filename@entry=0x60470690 
"/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf", 
chosenname=chosenname@entry=0x0, fd=fd@entry=0x0) at 
././fontforge/parsettf.c:6327
#6  0x76c08d80 in _ReadSplineFont (file=, 
file@entry=0x0, filename=filename@entry=0x60470650 
"/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf", 
openflags=openflags@entry=(unknown: 0)) at ././fontforge/splinefont.c:1141
#7  0x76c0a3ac in ReadSplineFont 

Bug#949257: xserver-xorg-core: Segmentation fault w/ 1.20.7

[Bernhard Übelacker]

Hello Jamie Heilman,
I just tried to retrieve some line information from the backtrace.
Unfortunately I could not match the addresses with the
binary from the debian repository.
Was this backtrace by any chance built with a local
rebuild of the xserver-xorg-core package?

Kind regards,
Bernhard

Bug#948388: navit: fails to connect to gpsd

[Bernhard Übelacker]

Hello Bernd,
I could further isolate the cmake failing issue.
It starts failing when the package qtbase5-dev is installed.
This gets installed as build dependency for libgps26.

A workaround would be to temporarily uninstall qtbase5-dev.

Maybe better would be to add following to navit to
allow building while qtbase5-dev is installed.
Building that way produces equal .deb packages.

Kind regards,
Bernhard


--- navit-0.5.3+dfsg.1.orig/debian/rules2018-09-01 12:16:52.0 +0200
+++ navit-0.5.3+dfsg.1/debian/rules2020-01-15 23:57:58.840074000 +0100
@@ -75,6 +75,9 @@ CMAKEFLAGS += -Dsupport/shapefile=TRUE
 # Enable libspeechd
 CMAKEFLAGS += -Dspeech/speech_dispatcher=TRUE
 
+# Disable Qt explicitly to allow building while qtbase5-dev is installed
+CMAKEFLAGS += -DDISABLE_QT=TRUE
+
 # Avoid floating point calculation for armel
 ifeq ($(DEB_HOST_ARCH), armel)
   CMAKEFLAGS += -DAVOID_FLOAT=TRUE

Bug#948388: navit: fails to connect to gpsd

[Bernhard Übelacker]

Hello Bernd,
my navit know-how is also limited, but I remebered I saw this
while having build-deps of navit and libgps installed.
Below are the packages which got installed additionally in
a minimal test VM on top of navit's build-deps.

If there are just build-deps's of navit installed the build runs fine
until the compile error given in message 18.
For this I made this (to be checked) change:
   -priv->fix_time = data->fix.time;
   +priv->fix_time = data->fix.time.tv_sec;

Kind regards,
Bernhard

apt build-dep libgps26 
  asciidoc asciidoc-base asciidoc-common bc dh-apparmor dh-buildinfo dh-exec 
dh-python docbook-xml docbook-xsl libbluetooth-dev libbluetooth3 
libdouble-conversion3 libegl-dev libegl-mesa0 libegl1
  libevdev2 libgbm1 libgudev-1.0-0 libinput-bin libinput10 libmtdev1 
libncurses-dev libpython3-all-dbg libpython3-all-dev libpython3-dbg 
libpython3-dev libpython3.7-dbg libpython3.7-dev libpython3.8
  libpython3.8-dbg libpython3.8-dev libpython3.8-minimal libpython3.8-stdlib 
libqt5concurrent5 libqt5core5a libqt5dbus5 libqt5gui5 libqt5network5 
libqt5printsupport5 libqt5sql5 libqt5test5 libqt5widgets5
  libqt5xml5 libusb-1.0-0-dev libvulkan-dev libvulkan1 libwacom-common 
libwacom2 libwayland-client0 libwayland-server0 libxcb-icccm4 libxcb-image0 
libxcb-keysyms1 libxcb-randr0 libxcb-render-util0
  libxcb-shape0 libxcb-util0 libxcb-xfixes0 libxcb-xinerama0 libxcb-xinput0 
libxcb-xkb1 libxkbcommon-x11-0 libxkbcommon0 libxslt1.1 makedev pps-tools 
python3-all python3-all-dbg python3-all-dev
  python3-dbg python3-dev python3.7-dbg python3.7-dev python3.8 python3.8-dbg 
python3.8-dev python3.8-minimal qt5-qmake qt5-qmake-bin qtbase5-dev 
qtbase5-dev-tools qtchooser scons sgml-base sgml-data
  xml-core xsltproc

Bug#945814: audacity: various segfaults of audacity on startup

[Bernhard Übelacker]

Hello Tjeerd,
If this issue still exists on your system, you might try
to rename $HOME/.audacity-data to test if it depends on
some settings stored there.

If it still crashes then you might start it by following
and forward the output:
$ catchsegv audacity

Better would be if you could install the packages:
systemd-coredump gdb valgrind audacity-dbgsym
The last one is in a different repository described here [1].

Then some more information should appear after
a crash in 'journalctl --no-pager'.

Also running audacity by following could give some pointer:
$ valgrind audacity

Kind regards,
Bernhard

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

Bug#945814: Fwd: Bug#945814: audacity: various segfaults of audacity on startup

[Bernhard Übelacker]

Sorry, forget the right email.


 Forwarded Message 
Betreff: Re: Bug#945814: audacity: various segfaults of audacity on startup
Datum: Tue, 14 Jan 2020 11:46:06 +0100
Von: Bernhard Übelacker 
An: 945...@bugs.debian.org

Hello Tjeerd,
If this issue still exists on your system, you might try
to rename $HOME/.audacity-data to test if it depends on
some settings stored there.

If it still crashes then you might start it by following
and forward the output:
$ catchsegv audacity

Better would be if you could install the packages:
systemd-coredump gdb valgrind audacity-dbgsym
The last one is in a different repository described here [1].

Then some more information should appear after
a crash in 'journalctl --no-pager'.

Also running audacity by following could give some pointer:
$ valgrind audacity

Kind regards,
Bernhard

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

Bug#948491: centengine crashes regulary

[Bernhard Übelacker]

   || ...634 
<+260>:   pop%rbp
   || ...635 
<+261>:   pop%r12
   || ...637 
<+263>:   pop%r13
      ...639 
<+265>:   pop%r14
  ...63b 
<+267>:   retq   

Description: Change argument by reference to pointer to avoid crash
 GCC seems to expect always valid references, therefore removes
 in optimized builds null checks of references.

Author: Bernhard Übelacker 
Bug-Debian: https://bugs.debian.org/948491
Bug: https://github.com/centreon/centreon-engine/issues/338
Forwarded: no
Last-Update: 2020-01-10

--- centreon-engine-18.10.0.orig/inc/com/centreon/engine/retention/dump.hh
+++ centreon-engine-18.10.0/inc/com/centreon/engine/retention/dump.hh
@@ -39,7 +39,7 @@ namespace retention {
 std::ostream& comments(std::ostream& os);
 std::ostream& contact(std::ostream& os, contact_struct const& obj);
 std::ostream& contacts(std::ostream& os);
-std::ostream& customvariables(std::ostream& os, customvariablesmember_struct const& obj);
+std::ostream& customvariables(std::ostream& os, customvariablesmember_struct const* obj);
 std::ostream& downtime(std::ostream& os, scheduled_downtime_struct const& obj);
 std::ostream& downtimes(std::ostream& os);
 std::ostream& header(std::ostream& os);
--- centreon-engine-18.10.0.orig/src/retention/dump.cc
+++ centreon-engine-18.10.0/src/retention/dump.cc
@@ -92,7 +92,7 @@ std::ostream& dump::contact(std::ostream
 "modified_service_attributes=" << (obj.modified_service_attributes & ~config->retained_contact_service_attribute_mask()) << "\n"
 "service_notification_period=" << (obj.service_notification_period ? obj.service_notification_period : "") << "\n"
 "service_notifications_enabled=" << obj.service_notifications_enabled << "\n";
-  dump::customvariables(os, *obj.custom_variables);
+  dump::customvariables(os, obj.custom_variables);
   os << "}\n";
   return (os);
 }
@@ -120,8 +120,8 @@ std::ostream& dump::contacts(std::ostrea
  */
 std::ostream& dump::customvariables(
 std::ostream& os,
-customvariablesmember_struct const& obj) {
-  for (customvariablesmember const* member(&obj);
+customvariablesmember_struct const* obj) {
+  for (customvariablesmember const* member = obj;
member;
member = member->next)
 if (member->variable_name)
@@ -261,7 +261,7 @@ std::ostream& dump::host(std::ostream& o
 os << (x > 0 ? "," : "") << obj.state_history[(x + obj.state_history_index) % MAX_STATE_HISTORY_ENTRIES];
   os << "\n";
 
-  dump::customvariables(os, *obj.custom_variables);
+  dump::customvariables(os, obj.custom_variables);
   os << "}\n";
   return (os);
 }
@@ -451,7 +451,7 @@ std::ostream& dump::service(std::ostream
 os << (x > 0 ? "," : "") << obj.state_history[(x + obj.state_history_index) % MAX_STATE_HISTORY_ENTRIES];
   os << "\n";
 
-  dump::customvariables(os, *obj.custom_variables);
+  dump::customvariables(os, obj.custom_variables);
   os << "}\n";
   return (os);
 }

Bug#948491: centengine crashes regulary

[Bernhard Übelacker]

Hello Pascal,
now I see one thing that would be even better:

  coredumpctl gdb
info reg
thread apply all bt full

Sorry for not saying this sooner.

Kind regards,
Bernhard

Bug#948491: centengine crashes regulary

[Bernhard Übelacker]

Am 09.01.20 um 22:18 schrieb Pascal Vibet - ADACIS:
> @Bernhard : I install 'systemd-coredump' and 'centreon-engine-dbgsym'
> packages. I restart centengine. What information do you need? When
> centengine process crashes ? Or i run a program in same time ? What do
> you want me to do?

Great. Just wait for the next crash and then look at the end of
the command "journalctl --no-pager".
There should be a line with the known 'segfault at'.
This line and the following at nearly the same time would be
interesting, if you could forward them to this bug?

Kind regards,
Bernhard

Bug#948491: centengine crashes regulary

[Bernhard Übelacker]

Dear Maintainer,
I just tried to get some more info from the
dmesg line, which seems to point to:
   file ./src/retention/dump.cc, line 127. [1]


@Pascal: More information could maybe retrieved from the journal
if 'systemd-coredump' could be installed, even better if additionally
package 'centreon-engine-dbgsym' would be installed [1].


Kind regards,
Bernhard


[1] 
https://sources.debian.org/src/centreon-engine/18.10.0-4/src/retention/dump.cc/#L127
[2] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols



dmesg submitter:
[ 5321.507438] centengine[26832]: segfault at 0 ip 55c4d2403868 sp 
7ffd605fa390 error 4 in centengine[55c4d22e+134000]
[ 5321.507456] Code: 89 c2 4c 89 ee 4c 89 e7 e8 35 d0 ed ff ba 01 00 00 00 48 
8d 35 03 94 01 00 4c 89 e7 e8 21 d0 ed ff 48 8b 5b 18 48 85 db 74 58 <48> 83 3b 
00 74 f1 ba 01 00 00 00 48 8d 35 07 9a 01 00 48 89 ef e8
  0  1  2  3  4  5  6  7  8  9 10  1  2  3  4  5  6  7  8  
9 20  1  2  3  4  5  6  7  8  9 30  1  2  3  4  5  6  7  8  9 40  1  42




# Buster/stable amd64 qemu VM 2020-01-09


apt update
apt dist-upgrade


apt install systemd-coredump gdb centreon-engine centreon-engine-dbgsym


gdb -q --args /usr/sbin/centengine

set width 0
set pagination off
b main
run
dele 1



(gdb) info target
...
Local exec file:
`/usr/sbin/centengine', file type elf64-x86-64.
...
0x555ef050 - 0x55721701 is .text
...




(gdb) find /b 0x555ef050, 0x55721701, 0x89, 0xc2, 0x4c, 0x89, 
0xee, 0x4c, 0x89, 0xe7, 0xe8, 0x35, 0xd0, 0xed, 0xff, 0xba, 0x01, 0x00, 0x00, 
0x00, 0x48, 0x8d, 0x35, 0x03, 0x94, 0x01, 0x00, 0x4c, 0x89, 0xe7, 0xe8, 0x21, 
0xd0, 0xed, 0xff, 0x48, 0x8b, 0x5b, 0x18, 0x48, 0x85, 0xdb, 0x74, 0x58, 0x48, 
0x83, 0x3b, 0x00, 0x74, 0xf1, 0xba, 0x01, 0x00, 0x00, 0x00, 0x48, 0x8d, 0x35, 
0x07, 0x9a, 0x01, 0x00, 0x48, 0x89, 0xef, 0xe8
0x5571183e 

1 pattern found.


(gdb) b *(0x5571183e + 42)
Breakpoint 3 at 0x55711868: file ./src/retention/dump.cc, line 127.
(gdb) info b
Num Type   Disp Enb AddressWhat
3   breakpoint keep y   0x55711868 in 
com::centreon::engine::retention::dump::customvariables(std::ostream&, 
customvariablesmember_struct const&) at ./src/retention/dump.cc:127



89 c2 4c 89 ee 4c 89 e7 e8 35 d0 ed ff ba 01 00 00 00 48 8d 35 03 94 01 00 4c 
89 e7 e8 21 d0 ed ff 48 8b 5b 18 48 85 db 74 58 <48> 83 3b 00 74 f1 ba 01 00 00 
00 48 8d 35 07 9a 01 00 48 89 ef e8
 0  1  2  3  4  5  6  7  8  9 10  1  2  3  4  5  6  7  8  9 20  1  2  3  4  5  
6  7  8  9 30  1  2  3  4  5  6  7  8  9 40  1   2

0x89, 0xc2, 0x4c, 0x89, 0xee, 0x4c, 0x89, 0xe7, 0xe8, 0x35, 0xd0, 0xed, 0xff, 
0xba, 0x01, 0x00, 0x00, 0x00, 0x48, 0x8d, 0x35, 0x03, 0x94, 0x01, 0x00, 0x4c, 
0x89, 0xe7, 0xe8, 0x21, 0xd0, 0xed, 0xff, 0x48, 0x8b, 0x5b, 0x18, 0x48, 0x85, 
0xdb, 0x74, 0x58, 0x48, 0x83, 0x3b, 0x00, 0x74, 0xf1, 0xba, 0x01, 0x00, 0x00, 
0x00, 0x48, 0x8d, 0x35, 0x07, 0x9a, 0x01, 0x00, 0x48, 0x89, 0xef, 0xe8



(gdb) disassemble /r 0x5571183e,0x5571183e+62
Dump of assembler code from 0x5571183e to 0x5571187c:
   0x5571183e 
:89 c2   mov   
 %eax,%edx
   0x55711840 
:4c 89 eemov   
 %r13,%rsi
   0x55711843 
:4c 89 e7mov   
 %r12,%rdi
   0x55711846 
:e8 35 d0 ed ff  callq 
 0x555ee880 
<_ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l@plt>
   0x5571184b 
:ba 01 00 00 00  mov   
 $0x1,%edx
   0x55711850 
:48 8d 35 03 94 01 00lea   
 0x19403(%rip),%rsi# 0x5572ac5a
   0x55711857 
:4c 89 e7mov   
 %r12,%rdi
   0x5571185a 
:e8 21 d0 ed ff  callq 
 0x555ee880 
<_ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l@plt>
   0x5571185f 
:48 8b 5b 18 mov   
 0x18(%rbx),%rbx
   0x55711863 
:48 85 dbtest  
 %rbx,%rbx
   0x55711866 
:74 58   je
 0x557118c0 

>> 0x55711868 
>> > customvariablesmember_struct const&)+168>:48 83 3b 00 
>> cmpq   $0x0,(%rbx)
   0x5571186c 
:74 f1   je
 0x5571185f 

   0x5571186e 
:ba 01 00 00 00  mov   
 $0x1,%edx
   0x55711873 
:48 8d 35 07 9a 01 00lea   
 0x19a07(%rip),%rsi# 0x5572b281
   0x5571187a 
:48 89 efmov   
 %rbp,%rdi
End of assembler dump.




root@debian:~# dpkg -l | grep centreon
ii  centreon-engine   18.10.0-4   amd64
Network, system, applicative supervision and monitoring - engine
ii  centreon-engine-dbgsym18.10.0-4   amd64
debug symbols for centreon-engine
ii  libcentreon-clib  18.10

Bug#948268: Crashes after startup

[Bernhard Übelacker]

Dear Maintainer,
just as a side note, a similar bug was submitted
against the basilisk2 package.

https://bugs.debian.org/922323

Another user of slirp is qemu, which had some changes in
that area, which seems to have evolved into this library:

https://gitlab.freedesktop.org/slirp/libslirp
https://gitlab.freedesktop.org/slirp/libslirp/blob/master/src/ip.h#L214

Kind regards,
Bernhard

Bug#947237: gnome-software: Crashes on click over any software icon

[Bernhard Übelacker]

Dear Maintainer,
the given valgrind backtrace should translate to something
like below (which did not crash for me).

The crashing instruction tries to read memory pointed by register $rdi,
that held in my test the address in parameters "v" / "key" / "name".

So I assume for some reason this register $rdi and
parameter "v" / "key" / "name" contain a null pointer
leading to the crash seen by definetti.

Kind regards,
Bernhard


(gdb) bt
#0  0x77df6e20 in g_str_hash (v=0x7fffdc38d780) at 
../../../glib/ghash.c:2324
#1  0x77df5eff in g_hash_table_lookup_node (hash_return, 
key=0x7fffdc38d780, hash_table) at ../../../glib/ghash.c:473
#2  0x77df5eff in g_hash_table_lookup (hash_table, 
key=key@entry=0x7fffdc38d780) at ../../../glib/ghash.c:1509
#3  0x708f9389 in store_snap_cache_lookup (need_details, 
name=0x7fffdc38d780 "notepad-plus-plus", plugin) at 
../plugins/snap/gs-plugin-snap.c:204
#4  0x708f9389 in get_store_snap (plugin, name=0x7fffdc38d780 
"notepad-plus-plus", need_details, cancellable, error) at 
../plugins/snap/gs-plugin-snap.c:520
#5  0x708f9d2d in gs_plugin_add_alternates (plugin, app, list, 
cancellable, error) at ../plugins/snap/gs-plugin-snap.c:592
#6  0x555cca3f in gs_plugin_loader_call_vfunc (helper, plugin, app, 
app@entry, list, list@entry, refine_flags, refine_flags@entry, cancellable, 
error) at ../lib/gs-plugin-loader.c:651
#7  0x555ccc62 in gs_plugin_loader_run_results (helper, cancellable, 
error) at ../lib/gs-plugin-loader.c:1084
#8  0x555cdac5 in gs_plugin_loader_process_thread_cb (task, object, 
task_data, cancellable) at ../lib/gs-plugin-loader.c:3040
#9  0x77c92bae in g_task_thread_pool_thread (thread_data, pool_data) at 
../../../gio/gtask.c:1410
#10 0x77e31404 in g_thread_pool_thread_proxy (data) at 
../../../glib/gthreadpool.c:308
#11 0x77e30d0d in g_thread_proxy (data) at ../../../glib/gthread.c:805
#12 0x76fcdfb7 in start_thread (arg) at pthread_create.c:486
#13 0x76eff2df in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

(gdb) display/i $pc
2: x/i $pc
=> 0x77df6e20 : movsbl (%rdi),%eax
(gdb) print/x $rdi
$5 = 0x7fffdc38d780

Bug#947400: hkl FTBFS on arm64: sirius segfaults

[Bernhard Übelacker]

Dear Maintainer,
I tried to have a look and might have found something.

The crash happens because coroutine_stack_init returns NULL.
This is because of a buffer size check.

Building a package with doubled "DEFAULT_STATE_SIZE" went
through without crash (just tested on aarch64).
However, I am unfamiliar with that package, therefore cannot
estimate other consequences of that change.

Kind regards,
Bernhard


(gdb) bt
#0  0xe0e16e30 in generator_new_ (fn=fn@entry=0xe0e18ed8 
, retsize=48, retsize@entry=40) at 
generator/generator.c:36
#1  0xe0e194c0 in trajectory_gen (tconfig=...) at hkl2.c:250
#2  0xe0e19574 in Trajectory_solve (tconfig=..., gconfig=..., 
sconfig=..., move=1) at hkl2.c:292
#3  0xe0e18168 in main_1 () at sirius.c:161
#4  0xe0dee47c in main () at sirius.c:246

# Buster aarch64 qemu VM 2019-12-28 (running at a raspberry 3)


apt update
apt dist-upgrade


apt install systemd-coredump fakeroot htop git gdb
apt build-dep hkl



mkdir /home/benutzer/source/hkl/orig -p
cd/home/benutzer/source/hkl/orig
apt source hkl
cd


cd/home/benutzer/source/hkl
cp orig try1 -a
cd try1/hkl-5.0.0.2569
script -a "../dpkg-buildpackage_$(date +%Y-%m-%d_%H-%M-%S).log" -c 
"dpkg-buildpackage"



dmesg
journalctl --no-pager
coredumpctl list

coredumpctl gdb 9919

set width 0
set pagination off
bt
display/i $pc
info reg





make[4]: Entering directory 
'/home/benutzer/source/hkl/try1/hkl-5.0.0.2569/Documentation/figures'
gcc -DHAVE_CONFIG_H -I. -I../..  -Wextra -D_DEFAULT_SOURCE -I../.. -I../../hkl 
-I/usr/include/glib-2.0 -I/usr/lib/aarch64-linux-gnu/glib-2.0/include 
-I/usr/include/glib-2.0 -I/usr/lib/aarch64-linux-gnu/glib-2.0/include 
-I/usr/include -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
-fdebug-prefix-map=/home/benutzer/source/hkl/try1/hkl-5.0.0.2569=. 
-fstack-protector-strong -Wformat -Werror=format-security -c -o sirius.o 
sirius.c
sirius.c:244:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
  244 | main(void)
  | ^~~~
/bin/bash ../../libtool  --tag=CC   --mode=link gcc  -g -O2 
-fdebug-prefix-map=/home/benutzer/source/hkl/try1/hkl-5.0.0.2569=. 
-fstack-protector-strong -Wformat -Werror=format-security 
-Wl,--whole-archive,../../hkl/.libs/libhkl.a,--no-whole-archive -Wl,-z,relro 
-Wl,-z,now -Wl,--as-needed -o sirius sirius.o ../../hkl/libhkl.la 
../../hkl/api2/libhkl2.la -lglib-2.0 -lgobject-2.0 -lglib-2.0 
-L/usr/lib/aarch64-linux-gnu -lgsl -lgslcblas -lm -lyaml 
libtool: link: gcc -g -O2 
-fdebug-prefix-map=/home/benutzer/source/hkl/try1/hkl-5.0.0.2569=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,--whole-archive 
-Wl,../../hkl/.libs/libhkl.a -Wl,--no-whole-archive -Wl,-z -Wl,relro -Wl,-z 
-Wl,now -Wl,--as-needed -o .libs/sirius sirius.o  ../../hkl/.libs/libhkl.so 
../../hkl/api2/.libs/libhkl2.a -lgobject-2.0 -lglib-2.0 
-L/usr/lib/aarch64-linux-gnu -lgsl -lgslcblas -lm -lyaml
cd . && ./sirius
make[4]: *** [Makefile:739: sirius-stamp] Segmentation fault (core dumped)
make[4]: Leaving directory 
'/home/benutzer/source/hkl/try1/hkl-5.0.0.2569/Documentation/figures'
make[3]: *** [Makefile:459: all-recursive] Error 1
make[3]: Leaving directory 
'/home/benutzer/source/hkl/try1/hkl-5.0.0.2569/Documentation'
make[2]: *** [Makefile:559: all-recursive] Error 1
make[2]: Leaving directory '/home/benutzer/source/hkl/try1/hkl-5.0.0.2569'
make[1]: *** [Makefile:443: all] Error 2
make[1]: Leaving directory '/home/benutzer/source/hkl/try1/hkl-5.0.0.2569'
dh_auto_build: make -j4 returned exit code 2
make: *** [debian/rules:10: build] Error 255
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
Script done, file is ../dpkg-buildpackage_2019-12-28_15-26-39.log






root@debian:~# journalctl --no-pager
...
Dec 28 15:36:32 debian systemd[1]: Started Process Core Dump (PID 9933/UID 0).
Dec 28 15:36:34 debian systemd-coredump[9934]: Process 9919 (sirius) of user 
1000 dumped core.
   
   Stack trace of thread 9919:
   #0  0xe0e16e30 n/a 
(/home/benutzer/source/hkl/try1/hkl-5.0.0.2569/Documentation/figures/.libs/sirius
 + 0x40e30)
   #1  0xe0e16e28 n/a 
(/home/benutzer/source/hkl/try1/hkl-5.0.0.2569/Documentation/figures/.libs/sirius
 + 0x40e28)
   #2  0xe0e194c0 n/a 
(/home/benutzer/source/hkl/try1/hkl-5.0.0.2569/Documentation/figures/.libs/sirius
 + 0x434c0)
   #3  0xe0e19574 n/a 
(/home/benutzer/source/hkl/try1/hkl-5.0.0.2569/Documentation/figures/.libs/sirius
 + 0x43574)
   #4  0xe0e18168 n/a 
(/home/benutzer/source/hkl/try1/hkl-5.0.0.2569/Documentation/figures/.libs/sirius
 + 0x42168)
   #5  0xe0dee47c n/a 
(/home/benut

Bug#942737: libapache2-mod-gnutls: mod_gnutls consumes 100% cpu

[Bernhard Übelacker]

Dear Maintainer,
tried to reconstruct the given backtrace with debug symbols
in a gdb session and came to following, maybe it could be
of some help.
(Still a proper backtrace with dbgsym packages
installed would be better.)

Kind regards,
Bernhard


Reconstructed:
#0  0x7f78b4cfb92f in gnutls_assert_val_int at ../../lib/errors.h:139 from 
libgnutls.so.30
#1  0x7f78b4cfdf7c in _gnutls_recv_int at ../../lib/record.c:1773 from 
libgnutls.so.30
   in gnutls_record_recv at ../../lib/record.c:2281
#2  0x7f78b4e90f38 in gnutls_io_input_read at gnutls_io.c:246 from 
mod_gnutls.so
#3  0x7f78b4e91ad2 in gnutls_io_input_getline at gnutls_io.c:342 from 
mod_gnutls.so
   in mgs_filter_input at gnutls_io.c:595
   in ap_get_brigade at util_filter.c:553
#4  0x55c220cd08e1 in ap_rgetline_core at protocol.c:246
#5  0x55c220cd336c in read_request_line at protocol.c:682
   in ap_read_request at protocol.c:1322
#6  0x55c220cfe7a8 in ap_process_http_sync_connection at http_core.c:192
#7  0x55c220cf38b0 in ap_run_process_connection at connection.c:42
   in ap_process_connection at connection.c:219
#8  0x7f78b3bd23df in child_main at prefork.c:615 from mod_mpm_prefork.so
#9  0x7f78b3bd26d4 in make_child at prefork.c:717 from mod_mpm_prefork.so
#10 0x7f78b3bd272f in startup_children at prefork.c:735 from 
mod_mpm_prefork.so
#11 0x7f78b3bd32f3 in prefork_run at prefork.c:897 from mod_mpm_prefork.so
#12 0x55c220ccc67e in ap_run_mpm at mpm_common.c:94
#13 0x55c220cc4f57 in main at main.c:819

Bug#946639: iwd 1.2-1 is crashing making WiFi access impossible

[Bernhard Übelacker]

Control: tags -1 + upstream fixed-upstream patch


Dear Maintainer,
I tried to have a look at this crash
and I guess I found something.

The "Code:" sequence points to src/scan.c:1706.

There it seems like variable sr got a null pointer
and therefore the assignment crashes.

(gdb) list src/scan.c:1700,src/scan.c:1710
1700case NL80211_CMD_TRIGGER_SCAN:
1701if (active_scan)
1702sc->state = SCAN_STATE_ACTIVE;
1703else
1704sc->state = SCAN_STATE_PASSIVE;
1705
1706sr->start_time_tsf = start_time_tsf;   

1707
1708break;
1709
1710case NL80211_CMD_SCAN_ABORTED:


Upstream git [1] has a fix committed.


Kind regards,
Bernhard


https://git.kernel.org/pub/scm/network/wireless/iwd.git/commit/src/scan.c?id=d2556a48b7d65eb670fb0ce20e3f929bf9839a20

Bug#946639: iwd 1.2-1 is crashing making WiFi access impossible

[Bernhard Übelacker]

(Forgot to attach some more debugging details.)


From submitter
Dec 12 09:40:11 lambda kernel: [55486.381334] iwd[202645]: segfault at 38 ip 
55b1995e2056 sp 7ffc966c5360 error 6 in iwd[55b1995c4000+84000]
Dec 12 09:40:11 lambda kernel: [55486.381374] Code: 48 83 c4 20 e9 58 fe ff ff 
0f 1f 00 3c 21 0f 85 70 ff ff ff 31 c0 80 7c 24 10 00 0f 95 c0 83 c0 01 41 89 
47 08 48 8b 44 24 18 <49> 89 46 38 e9 51 ff ff ff 90 41 8b 77 08 85 f6 0f 84 44 
ff ff ff





/*
 * Page fault error code bits:
 *
 *   bit 0 ==0: no page found   1: protection fault
 *   bit 1 ==0: read access 1: write access
 *   bit 2 ==0: kernel-mode access  1: user-mode access
 *   bit 3 ==   1: use of reserved bit detected
 *   bit 4 ==   1: fault was an instruction fetch
 *   bit 5 ==   1: protection keys block access
 */
enum x86_pf_error_code {

PF_PROT =   1 << 0,
PF_WRITE=   1 << 1,
PF_USER =   1 << 2,
PF_RSVD =   1 << 3,
PF_INSTR=   1 << 4,
PF_PK   =   1 << 5,
};

arch/x86/mm/fault.c:
printk("%s%s[%d]: segfault at %lx ip %px sp %px error %lx",


"error 6" == 0x6 == 0b110

bit 0 == 0: no page found
bit 1 == 1: write access
bit 2 == 1: user-mode access
bit 3 == 0: 
bit 4 == 0: 
bit 5 == 0: 



#



# Bullseye/testing amd64 qemu VM 2019-12-12


apt update
apt dist-upgrade


apt install systemd-coredump mc gdb iwd iwd-dbgsym

apt build-dep iwd




mkdir /home/benutzer/source/iwd/orig -p
cd/home/benutzer/source/iwd/orig
apt source iwd
cd




gdb -q --args /usr/libexec/iwd


set width 0
set pagination off
directory /home/benutzer/source/iwd/orig/iwd-1.2
b main
run
dele 1


(gdb) info target
...
0xe830 - 0x555e1001 is .text
...


(gdb) find /b 0xe830, 0x555e1001, 0x48, 0x83, 0xc4, 0x20, 
0xe9, 0x58, 0xfe, 0xff, 0xff, 0x0f, 0x1f, 0x00, 0x3c, 0x21, 0x0f, 0x85, 0x70, 
0xff, 0xff, 0xff, 0x31, 0xc0, 0x80, 0x7c, 0x24, 0x10, 0x00, 0x0f, 0x95, 0xc0, 
0x83, 0xc0, 0x01, 0x41, 0x89, 0x47, 0x08, 0x48, 0x8b, 0x44, 0x24, 0x18, 0x49, 
0x89, 0x46, 0x38, 0xe9, 0x51, 0xff, 0xff, 0xff, 0x90, 0x41, 0x8b, 0x77, 0x08, 
0x85, 0xf6, 0x0f, 0x84, 0x44, 0xff, 0xff, 0xff
0x5557c02c 
1 pattern found.


(gdb) b *0x5557c02c+42
Breakpoint 2 at 0x5557c056: file src/scan.c, line 1706.
(gdb) info b
Num Type   Disp Enb AddressWhat
2   breakpoint keep y   0x5557c056 in scan_notify at 
src/scan.c:1706


(gdb) disassemble /r scan_notify
Dump of assembler code for function scan_notify:
   0x5557be50 <+0>: 41 57   push   %r15
...
   0x5557c027 <+471>:   e8 d4 ae 03 00  callq  0x555b6f00 

   0x5557c02c <+476>:   48 83 c4 20 add$0x20,%rsp
   0x5557c030 <+480>:   e9 58 fe ff ff  jmpq   0x5557be8d 

   0x5557c035 <+485>:   0f 1f 00nopl   (%rax)
   0x5557c038 <+488>:   3c 21   cmp$0x21,%al
   0x5557c03a <+490>:   0f 85 70 ff ff ff   jne0x5557bfb0 

   0x5557c040 <+496>:   31 c0   xor%eax,%eax
   0x5557c042 <+498>:   80 7c 24 10 00  cmpb   $0x0,0x10(%rsp)
   0x5557c047 <+503>:   0f 95 c0setne  %al
   0x5557c04a <+506>:   83 c0 01add$0x1,%eax
   0x5557c04d <+509>:   41 89 47 08 mov%eax,0x8(%r15)
   0x5557c051 <+513>:   48 8b 44 24 18  mov0x18(%rsp),%rax
   0x5557c056 <+518>:   49 89 46 38 mov%rax,0x38(%r14)  
<
   0x5557c05a <+522>:   e9 51 ff ff ff  jmpq   0x5557bfb0 

   0x5557c05f <+527>:   90  nop
   0x5557c060 <+528>:   41 8b 77 08 mov0x8(%r15),%esi
   0x5557c064 <+532>:   85 f6   test   %esi,%esi
   0x5557c066 <+534>:   0f 84 44 ff ff ff   je 0x5557bfb0 

   0x5557c06c <+540>:   41 0f b6 47 58  movzbl 0x58(%r15),%eax
...
   0x5557c2ff <+1199>:  e8 4c 1f fe ff  callq  0xe250 
<__stack_chk_fail@plt>
End of assembler dump.


(gdb) list src/scan.c:1700,src/scan.c:1710
1700case NL80211_CMD_TRIGGER_SCAN:
1701if (active_scan)
1702sc->state = SCAN_STATE_ACTIVE;
1703else
1704sc->state = SCAN_STATE_PASSIVE;
1705
1706sr->start_time_tsf = start_time_tsf;   

1707
1708break;
1709
1710case NL80211_CMD_SCAN_ABORTED:


(gdb) ptype struct scan_request
type = struct scan_request {

Bug#944017: libsoxr: autopkgtest regression: segmentation fault

[Bernhard Übelacker]

Hello Adrian, hello Paul,
I could reproduce the issue in a minimal
revertable Unstable qemu VM with this command:

/usr/bin/autopkgtest libsoxr -- null


As far as I see the test is called this way:

src/debian/tests/inst-check
  src/inst-check
src/inst-check-soxr
  $gen# line 43, generates test data
  $tmp/3-options-input-fn # line 43, run test

In the end it runs:

dd if=/dev/urandom count=1000 | /tmp/tmp.bQI47Dtfhv/4-split-channels   7 6 
2 2 3

Unfortunately the "inst-check" runs just in the
autopkgtest, but not at build time.


All debugging attempts led me to the location below.
And the lines soxr.c:664 and soxr.c:786 point to
the fix-unaligned-access.patch introduced in bug #942746.

When a packages are installed without this patch the
autopkgtest gets not segfault.

Kind regards,
Bernhard


Thread 1 received signal SIGTRAP, Trace/breakpoint trap.
0x0485210a in lsx_rint16_clip_dither_f (seed0=0x4c51500, n=6735, 
src=0x4ca4270, dest0=0x4c241a0) at ./src/rint-clip.h:67
67  DO_16;
(gdb) bt
#0  0x0485210a in lsx_rint16_clip_dither_f (seed0=0x4c51500, n=6735, 
src=0x4ca4270, dest0=0x4c241a0) at ./src/rint-clip.h:67
#1  _soxr_interleave_f (data_type=, dest0=0x4c241a0, 
src=, n=6735, ch=1, seed=0x4c51500) at ./src/data-io.c:213
#2  0x0484d60f in soxr_output_1ch (p=p@entry=0x4c513e0, i=0, 
dest=dest@entry=0x4c24100, len=, len@entry=6923, 
separated=separated@entry=true) at ./src/soxr.c:664
#3  0x0484d8cc in soxr_process._omp_fn.0 () at ./src/soxr.c:786
#4  0x04bcaa42 in GOMP_parallel (fn=0x484d830 , 
data=0x1fff000800, num_threads=4, flags=0) at 
../../../src/libgomp/parallel.c:171
#5  0x0484ef78 in soxr_process (p=0x4c513e0, in=0x4c24150, 
ilen0=, idone0=0x0, out=0x4c24100, olen=6923, 
odone0=0x1fff0008a8) at ./src/soxr.c:781
#6  0x00109fd8 in main (n=0, arg=0x1fff000b28) at 4-split-channels.c:142

# Unstable amd64 qemu VM 2019-12-12

apt update
apt dist-upgrade


apt install systemd-coredump mc autopkgtest quilt gdb rr valgrind 
libgomp1-dbgsym libsoxr0-dbgsym
apt build-dep libsoxr



##


root@debian:~# autopkgtest libsoxr -- null
...
/tmp/tmp.LScD5ODKNY/3-options-input-fn no error; 0 clips; I/O: no error (cr32s)
Segmentation fault (core dumped)
autopkgtest [00:22:20]: test inst-check: ---]
autopkgtest [00:22:21]: test inst-check:  - - - - - - - - - - results - - - - - 
- - - - -
inst-check   FAIL non-zero exit status 139
autopkgtest [00:22:21]: test inst-check:  - - - - - - - - - - stderr - - - - - 
- - - - -
Segmentation fault (core dumped)
...




root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Thu 2019-12-12 00:22:20 CET2744 0 0  11 present   
/tmp/tmp.LScD5ODKNY/4-split-channels



root@debian:~# journalctl --no-pager
Dez 12 00:22:20 debian kernel: 4-split-channel[2745]: segfault at 0 ip 
7f17b31ec10a sp 7f17b2e79c50 error 6 in 
libsoxr.so.0.1.2[7f17b31e7000+28000]
Dez 12 00:22:20 debian kernel: Code: d0 48 89 94 24 d0 00 00 00 49 c1 e8 06 41 
83 e0 1f 44 29 c7 f2 0f 2a c7 f2 0f 59 c1 f2 0f 58 c2 f2 0f 11 44 24 08 dd 44 
24 08 <41> df 1e 48 89 c7 66 0f ef c0 66 0f ef d2 49 89 d0 48 c1 ef 09 49
Dez 12 00:22:20 debian systemd[1]: Created slice 
system-systemd\x2dcoredump.slice.
Dez 12 00:22:20 debian systemd[1]: Started Process Core Dump (PID 2756/UID 0).
Dez 12 00:22:20 debian su[2651]: pam_unix(su:session): session closed for user 
root
Dez 12 00:22:20 debian systemd-coredump[2757]: Process 2744 (4-split-channel) 
of user 0 dumped core.
   
   Stack trace of thread 2745:
   #0  0x7f17b31ec10a n/a 
(libsoxr.so.0 + 0x910a)
   #1  0x7f17b31e760f n/a 
(libsoxr.so.0 + 0x460f)
   #2  0x7f17b31e78cc n/a 
(libsoxr.so.0 + 0x48cc)
   #3  0x7f17b2ec0946 n/a 
(libgomp.so.1 + 0x1a946)
   #4  0x7f17b2e88fb7 
start_thread (libpthread.so.0 + 0x8fb7)
   #5  0x7f17b311d2df __clone 
(libc.so.6 + 0xfa2df)
   
   Stack trace of thread 2753:
   #0  0x7f17b2ec32aa n/a 
(libgomp.so.1 + 0x1d2aa)
   #1  0x7f17b2ec0952 n/a 
(libgomp.so.1 + 0x1a952)
   #2  0x7f17b2e88fb7 
start_thread (libpthread.so.0 + 0x8fb7)
   #3  0x7f17b311d2df __clone 
(libc.so.6 + 0xfa2df)
   

Bug#946405: nextcloud-desktop: Nextcloud desktop client crash when trying to enter login/password

[Bernhard Übelacker]

Hello Ludovic,
I tried to collect some more information from your crash dump.
With debug symbols this backtrace should look like below.

I guess you are running a nvidia graphics card
with the nouveau drivers?

As a workaround it may work if you start the client
from a terminal by following:

export LIBGL_ALWAYS_SOFTWARE=1
nextcloud

Or maybe this:

export QT_XCB_FORCE_SOFTWARE_OPENGL=1
nextcloud


Maybe you can confirm my findings, and forward the output of
following commands to this bug:

lspci | grep VGA
glxinfo | grep -i -E "GLX_MESA_query_renderer.:" -A5


Kind regards,
Bernhard



  From submitter  |
Reconstructed
 #0  0x7fe16d9b6bde  | 0x7f1811853bde 

 #1  0x7fe16d9b6cf0  | 0x7f1811853cf0 

 #2  0x7fe16d9b7327  | 0x7f1811854327 

 #3  0x7fe166ea4840  | 0x7f180ad41840 
<__restore_rt+0>: mov$0xf,%rax
 #4  0x7fe152142a8c  | 0x7f17f754ca8c 
in list_del at ../src/util/list.h:91
 #5  0x7fe152142c87  | 0x7f17f754cc87 
in nouveau_fence_update at ../src/gallium/drivers/nouveau/nouveau_fence.c:128
 #6  0x7fe152142f83  | 0x7f17f754cf83 
in nouveau_fence_wait at ../src/gallium/drivers/nouveau/nouveau_fence.c:219
 #7  0x7fe1523cf490  | 0x7f17f77d9490 
in st_finish (st=st@entry=0x562393326c90) at 
../src/mesa/state_tracker/st_cb_flush.c:69
 #8  0x7fe1523cf4e0  | 0x7f17f77d94e0 
in st_glFinish (ctx=) at 
../src/mesa/state_tracker/st_cb_flush.c:104
 #9  0x7fe166a5f156  | 0x7f180a8fc156 
in QQuickWidgetPrivate::render (this=0x562392ccb0b0, needsSync=) 
at qquickwidget.cpp:295
 #10 0x7fe166a5f2b6  | 0x7f180a8fc2b6 
in QQuickWidgetPrivate::renderSceneGraph (this=0x562392ccb0b0) at 
qquickwidget.cpp:339
 #11 0x7fe1675e509b QObject::event()  | 0x7f180b48209b 
in QObject::event (this=this@entry=0x5623930a2130, e=e@entry=0x7ffcf1848bb0) at 
kernel/qobject.cpp:1232
 #12 0x7fe167f7496b QWidget::event()  | 0x7f180be1196b 
in QWidget::event (this=this@entry=0x5623930a2130, 
event=event@entry=0x7ffcf1848bb0) at kernel/qwidget.cpp:9353
 #13 0x7fe166a62e5d QQuickWidget::event() | 0x7f180a8ffe5d 
in QQuickWidget::event (this=0x5623930a2130, e=0x7ffcf1848bb0) at 
qquickwidget.cpp:1525
 #14 0x7fe17207cb50  | 0x7f1815f19b50 
in QtWebEngineCore::RenderWidgetHostViewQtDelegateWidget::event(QEvent*) () 
from /lib/x86_64-linux-gnu/libQt5WebEngineWidgets.so.5
 #15 0x7fe167f364c1 QApplicationPrivate::notify_helper()  | 0x7f180bdd34c1 
in QApplicationPrivate::notify_helper (this=this@entry=0x562392919dd0, 
receiver=receiver@entry=0x5623930a2130, e=e@entry=0x7ffcf1848bb0) at 
kernel/qapplication.cpp:3726
 #16 0x7fe167f3d970 QApplication::notify()| 0x7f180bdda970 
in QApplication::notify (this=0x7ffcf1848ef0, receiver=0x5623930a2130, 
e=0x7ffcf1848bb0) at kernel/qapplication.cpp:3485
 #17 0x7fe1675bb4f9 QCoreApplication::notifyInternal2()   | 0x7f180b4584f9 
in QCoreApplication::notifyInternal2 (receiver=0x5623930a2130, 
event=event@entry=0x7ffcf1848bb0) at 
../../include/QtCore/5.11.3/QtCore/private/../../../../../src/corelib/thread/qthread_p.h:307
  | 0x7f180b4a8ba8 
in QCoreApplication::sendEvent (event=0x7ffcf1848bb0, receiver=) 
at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:234
  | 0x7f180b4a8ba8 
in QTimerInfoList::activateTimers (this=0x562392954560) at 
kernel/qtimerinfo_unix.cpp:643
  | 0x7f180b4a943c 
in timerSourceDispatch (source=) at 
kernel/qeventdispatcher_glib.cpp:182
  | 0x7f180b4a943c 
in idleTimerSourceDispatch (source=) at 
kernel/qeventdispatcher_glib.cpp:229
 #18 0x7fe16760bba8 QTimerInfoList::activateTimers()  | 0x7f180b4a8ba8 
in QTimerInfoList::activateTimers (this=0x562392954560) at 
kernel/qtimerinfo_unix.cpp:643
 #19 0x7fe16760c404  | 0x7f180b4a9404 
in timerSourceDispatch (source=) at 
kernel/qeventdispatcher_glib.cpp:182
 #20 0x7fe166ab9f2e g_main_context_dispatch   | 0x7f180a956f2e 
in g_main_dispatch (context=0x7f17f8004ff0) at ../../../glib/gmain.c:3182
  | 0x7f180a956f2e 
in g_main_context_dispatch (context=context@entry=0x7f17f8004ff0) at 
../../../glib/gmain.c:3847
 #21 0x7fe166aba1c8  | 0x7f180a9571c8 
in g_main_context_iterate (context=context@entry=0x

Bug#946242: fatal: privsep_preauth: preauth child terminated by signal 31

[Bernhard Übelacker]

Am 07.12.19 um 18:20 schrieb Colin Watson:
> On Sat, Dec 07, 2019 at 04:52:19PM +0100, Bernhard Übelacker wrote:
>> I could reproduce the issue in a i386 qemu VM with
>> a downgraded 3.16-3-686-pae kernel.
>> Attached file contains a debug session.
>>
>> At the sysenter instruction in function shmdt
>> the signal SIGSYS is received.
> 
> Since you're building it locally already, it would be helpful if you
> could follow the debugging instructions in a comment near the top of
> sandbox-seccomp-filter.c (either the auditctl approach, or if that
> doesn't work on such an old kernel, the ""uncomment this macro"
> approach).

Really I had not rebuilt it locally, just used the dbgsym packages and
downloaded sources.

Attached are the lines added to /var/log/audit/audit.log, after
"auditctl -a task,always -F uid=0" and a failing ssh attempt.

The uncomment-approach did not work for me as I received several
compile errors.

Kind regards,
Bernhard


debugging_auditctl-approach.txt.gz
Description: application/gzip

Bug#946242: fatal: privsep_preauth: preauth child terminated by signal 31

[Bernhard Übelacker]

Dear Maintainer,
I could reproduce the issue in a i386 qemu VM with
a downgraded 3.16-3-686-pae kernel.
Attached file contains a debug session.

At the sysenter instruction in function shmdt
the signal SIGSYS is received.

Kind regards,
Bernhard


(gdb) bt
#0  shmdt (shmaddr=0xb774) at ../sysdeps/unix/sysv/linux/shmdt.c:33
#1  0xb748c35a in cleanup_shm () at ../crypto/rand/rand_unix.c:370
#2  0xb7460fb3 in OPENSSL_cleanup () at ../crypto/init.c:519
#3  OPENSSL_cleanup () at ../crypto/init.c:497
#4  0xb6fdfae0 in __run_exit_handlers (status=0, listp=0xb71883fc 
<__exit_funcs>, run_list_atexit=true, run_dtors=true) at exit.c:108
#5  0xb6fdfc01 in __GI_exit (status=0) at exit.c:139
#6  0xb774da25 in main (ac=, av=) at 
../../sshd.c:2257

Buster/stable i386 qemu VM 2019-12-07

apt update
apt dist-ugprade


apt install dropbear mc gdb openssh-server-dbgsym libssl1.1-dbgsym
apt build-dep openssh-server



mkdir /home/benutzer/source/openssh-server/orig -p
cd/home/benutzer/source/openssh-server/orig
apt source openssh-server
cd

mkdir /home/benutzer/source/libssl1.1/orig -p
cd/home/benutzer/source/libssl1.1/orig
apt source libssl1.1
cd



wget 
https://snapshot.debian.org/archive/debian/20141013T184415Z/pool/main/l/linux/linux-image-3.16-3-686-pae_3.16.5-1_i386.deb
dpkg -i linux-image-3.16-3-686-pae_3.16.5-1_i386.deb


reboot
# to kernel 3.16


# to have another ssh available
dropbear -p 80




# failed login attempt

Dez 07 15:42:55 debian kernel: audit: type=1326 audit(1575729775.309:3): 
auid=4294967295 uid=104 gid=65534 ses=4294967295 pid=5227 comm="sshd" 
exe="/usr/sbin/sshd" sig=31 syscall=117 compat=0 ip=0xb76fed4c code=0x0
Dez 07 15:42:55 debian sshd[5226]: Accepted password for benutzer from 10.0.2.2 
port 48382 ssh2
Dez 07 15:42:55 debian sshd[5226]: fatal: privsep_preauth: preauth child 
terminated by signal 31







gdb -q --pid $(pidof sshd)

set width 0
set pagination off
directory /home/benutzer/source/openssh-server/orig/openssh-7.9p1/debian/po
directory /home/benutzer/source/libssl1.1/orig/openssl-1.1.1d/crypto
b fork
b shmget
b shmat
b shmdt
set follow-fork-mode child
cont
bt
info proc

# try to ssh, wait for password prompt, not enter it yet

finish
info proc
bt
cont
info proc
bt
cont
info proc
bt
cont

# enter password

info proc
bt
display/i $pc





root@debian:~# gdb -q --pid $(pidof sshd)
Attaching to process 701
Reading symbols from /usr/sbin/sshd...Reading symbols from 
/usr/lib/debug/.build-id/e1/d218f3aad351129f185477cd07fa0217f1648f.debug...done.
done.
Reading symbols from /lib/i386-linux-gnu/libwrap.so.0...(no debugging symbols 
found)...done.
Reading symbols from /lib/i386-linux-gnu/libaudit.so.1...(no debugging symbols 
found)...done.
Reading symbols from /lib/i386-linux-gnu/libpam.so.0...(no debugging symbols 
found)...done.
Reading symbols from /lib/i386-linux-gnu/libselinux.so.1...(no debugging 
symbols found)...done.
Reading symbols from /lib/i386-linux-gnu/libsystemd.so.0...(no debugging 
symbols found)...done.
Reading symbols from /usr/lib/i386-linux-gnu/libcrypto.so.1.1...Reading symbols 
from 
/usr/lib/debug/.build-id/fa/b89eb04abddd217b9dcbac3092b22b3316bc85.debug...done.
done.
Reading symbols from /lib/i386-linux-gnu/libutil.so.1...Reading symbols from 
/usr/lib/debug/.build-id/00/f2ffae5a7d102f8d638567d0ebbf4a50fe8909.debug...done.
done.
Reading symbols from /lib/i386-linux-gnu/libz.so.1...(no debugging symbols 
found)...done.
Reading symbols from /lib/i386-linux-gnu/libcrypt.so.1...Reading symbols from 
/usr/lib/debug/.build-id/1a/00e365b7690f55dd90ace5de35843ce25d6b35.debug...done.
done.
Reading symbols from /usr/lib/i386-linux-gnu/libgssapi_krb5.so.2...(no 
debugging symbols found)...done.
Reading symbols from /usr/lib/i386-linux-gnu/libkrb5.so.3...(no debugging 
symbols found)...done.
Reading symbols from /lib/i386-linux-gnu/libcom_err.so.2...(no debugging 
symbols found)...done.
Reading symbols from /lib/i386-linux-gnu/libc.so.6...Reading symbols from 
/usr/lib/debug/.build-id/44/72898f10b8f6e536025fe764b9245186520cef.debug...done.
done.
Reading symbols from /lib/i386-linux-gnu/libnsl.so.1...Reading symbols from 
/usr/lib/debug/.build-id/e7/ef24c10b8f675406ad572c03bb03453a69670c.debug...done.
done.
Reading symbols from /lib/i386-linux-gnu/libcap-ng.so.0...(no debugging symbols 
found)...done.
Reading symbols from /lib/i386-linux-gnu/libdl.so.2...Reading symbols from 
/usr/lib/debug/.build-id/0a/eba38648f88f71c49aff5cc91e5a696e8ba0ef.debug...done.
done.
Reading symbols from /lib/i386-linux-gnu/libpcre.so.3...(no debugging symbols 
found)...done.
Reading symbols from /lib/ld-linux.so.2...Reading symbols from 
/usr/lib/debug/.build-id/75/c5f4b3fd81f62a7f2fea8f1c091f3aabf81693.debug...done.
done.
Reading symbols from /lib/i386-linux-gnu/librt.so.1...Reading symbols from 
/usr/lib/debug/.build-id/c4/8f25812a51319cbd05b8102b3ce4be0c89266c.debug...done.
done.
Reading symbols from /lib/i386-linux-gnu/liblzma.so.5...(no debugging symbols 
found)...done.
Reading 

Bug#945864: unhide[208429]: segfault at 7ffd06cfec58 ip 000055c15aa077d3 sp 00007ffd06cfec60 error 6 in unhide-linux[55c15aa07000+6000]

[Bernhard Übelacker]

Control: tags -1 + upstream patch


Dear Maintainer,
I tried to have a look into this issue and guess I found something.

It looks like the application is exhausting its stack by
allocation an integer array with maxpid elements.
At least in my test VM this leads to 16 MB array size,
while stack has just a size of 8 MB.

Attached patch allocates two such arrays from the heap.
With this "unhide brute" could finish without crash.

Another workaround would be to increase stacksize
by "ulimit -s 40960" before running unhide.

Kind regards,
Bernhard




dmesg by submitter:
Nov 30 01:39:48 heisenberg kernel: unhide[208429]: segfault at 7ffd06cfec58 ip 
55c15aa077d3 sp 7ffd06cfec60 error 6 in unhide-linux[55c15aa07000+6000]
Nov 30 01:39:48 heisenberg kernel: Code: 00 48 89 45 c8 31 c0 48 63 05 5d 98 00 
00 48 8d 04 85 0f 00 00 00 48 83 e0 f0 48 29 c4 48 89 65 98 48 29 c4 31 c0 48 
89 65 90  d8 3e 00 00 31 c0 66 0f 1f 44 00 00 48 8b 4d 98 48 8b 55 90 c7



/*
 * Page fault error code bits:
 *
 *   bit 0 ==0: no page found   1: protection fault
 *   bit 1 ==0: read access 1: write access
 *   bit 2 ==0: kernel-mode access  1: user-mode access
 *   bit 3 ==   1: use of reserved bit detected
 *   bit 4 ==   1: fault was an instruction fetch
 *   bit 5 ==   1: protection keys block access
 */
enum x86_pf_error_code {

PF_PROT =   1 << 0,
PF_WRITE=   1 << 1,
PF_USER =   1 << 2,
PF_RSVD =   1 << 3,
PF_INSTR=   1 << 4,
PF_PK   =   1 << 5,
};

arch/x86/mm/fault.c:
printk("%s%s[%d]: segfault at %lx ip %px sp %px error %lx",


"error 6" == 0x6 == 0b110

bit 0 == 0: no page found
bit 1 == 1: write access
bit 2 == 1: user-mode access
bit 3 == 0: 
bit 4 == 0: 
bit 5 == 0: 





# Bullseye/testing amd64 qemu VM 2019-12-03

apt update
apt dist-upgrade

apt install systemd-coredump mc devscripts dpkg-dev gdb unhide unhide-dbgsym


mkdir /home/benutzer/source/unhide/orig -p
cd/home/benutzer/source/unhide/orig
apt source unhide
cd



gdb -q --args unhide

set width 0
set pagination off
directory /home/benutzer/source/unhide/orig/unhide-20130526
b main
run
dele 1

info target

find /b 0x63e0, 0xb001, 0x00, 0x48, 0x89, 0x45, 0xc8, 
0x31, 0xc0, 0x48, 0x63, 0x05, 0x5d, 0x98, 0x00, 0x00, 0x48, 0x8d, 0x04, 0x85, 
0x0f, 0x00, 0x00, 0x00, 0x48, 0x83, 0xe0, 0xf0, 0x48, 0x29, 0xc4, 0x48, 0x89, 
0x65, 0x98, 0x48, 0x29, 0xc4, 0x31, 0xc0, 0x48, 0x89, 0x65, 0x90, 0xe8, 0xd8, 
0x3e, 0x00, 0x00, 0x31, 0xc0, 0x66, 0x0f, 0x1f, 0x44, 0x00, 0x00, 0x48, 0x8b, 
0x4d, 0x98, 0x48, 0x8b, 0x55, 0x90, 0xc7



root@debian:~# gdb -q --args unhide
Reading symbols from unhide...
Reading symbols from 
/usr/lib/debug/.build-id/41/d7d39535f738606ad3acf0611a8397925762b3.debug...
(gdb) set width 0
(gdb) set pagination off
(gdb) directory /home/benutzer/source/unhide/orig/unhide-20130526
Source directories searched: 
/home/benutzer/source/unhide/orig/unhide-20130526:$cdir:$cwd
(gdb) b main
Breakpoint 1 at 0x23e0: file /usr/include/x86_64-linux-gnu/bits/stdio2.h, line 
107.
(gdb) run
Starting program: /usr/sbin/unhide 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, main (argc=1, argv=0x7fffed18) at 
/usr/include/x86_64-linux-gnu/bits/stdio2.h:107
warning: Source file is more recent than executable.
107   return __printf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, __va_arg_pack 
());
(gdb) dele 1
(gdb) info target
Symbols from "/usr/sbin/unhide-linux".
Native process:
Using the running image of child Thread 0x77de5740 (LWP 13520).
While running this, GDB does not access memory from...
Local exec file:
`/usr/sbin/unhide-linux', file type elf64-x86-64.
Entry point: 0x6660
...
0x63e0 - 0xb001 is .text
...
(gdb) find /b 0x63e0, 0xb001, 0x00, 0x48, 0x89, 0x45, 
0xc8, 0x31, 0xc0, 0x48, 0x63, 0x05, 0x5d, 0x98, 0x00, 0x00, 0x48, 0x8d, 0x04, 
0x85, 0x0f, 0x00, 0x00, 0x00, 0x48, 0x83, 0xe0, 0xf0, 0x48, 0x29, 0xc4, 0x48, 
0x89, 0x65, 0x98, 0x48, 0x29, 0xc4, 0x31, 0xc0, 0x48, 0x89, 0x65, 0x90, 0xe8, 
0xd8, 0x3e, 0x00, 0x00, 0x31, 0xc0, 0x66, 0x0f, 0x1f, 0x44, 0x00, 0x00, 0x48, 
0x8b, 0x4d, 0x98, 0x48, 0x8b, 0x55, 0x90, 0xc7
0x67a9 
1 pattern found.

(gdb) b *(0x67a9 + 42)
Breakpoint 3 at 0x67d3: file unhide-linux-bruteforce.c, line 73.

(gdb) x/10xb 0x67d3
0x67d3 :  0xe80xd80x3e0x000x000x31
0xc00x66
0x67db :  0x0f0x1f

(gdb) info b
Num Type   Disp Enb AddressWhat
3   breakpoint keep y   0x67d3 in brute at 
unhide-linux-br

Bug#944431: Segfault on startup

[Bernhard Übelacker]

Hello Markus, hello Enrico,
I am sorry to be late, but I guess I have found the issue.
The function SetThreadPriority does not return properly
therefore the following function gets executed which writes
to somewhere, that causes later the crash below.

The build logs show a warning for this issue:

tmp/compat_mini.cpp: In function ‘int SetThreadPriority(THREAD_HANDLE, 
int)’:
tmp/compat_mini.cpp:106:1: warning: no return statement in function 
returning non-void [-Wreturn-type]
  106 | }
  | ^

Attached patch adds return statements for all functions
currently triggering this warning.

Kind regards,
Bernhard


(gdb) bt
#0  0x562c7679292e in flip () at komat/Berusky3d_ini.cpp:46
#1  0x562c767ea5e4 in ddxPublish () at tmp/compat.cpp:196
#2  0x562c767ea6a9 in DisplayFrame () at tmp/compat.cpp:120
#3  0x562c76737374 in RunMenu (p_File_Name=p_File_Name@entry=0x562c76888c8b 
"mainmenu.txt", hWnd=hWnd@entry=0x0, p_ad=, cpu=cpu@entry=8304) 
at kofola/Menu.cpp:5810
#4  0x562c767771b7 in winmain_Game_Run (p_Level_Name=0x562c76bf3148 
 "") at kofola/game_main.cpp:252
#5  0x562c7671b293 in main (argc=, argv=) at 
komat/Berusky3d_ini.cpp:360
Description: Avoid 'no return statement in function returning non-void'
Author: Bernhard Übelacker 

Bug-Debian: https://bugs.debian.org/944431
Forwarded: no
Last-Update: 2019-11-18

--- berusky2-0.10.orig/src/tmp/compat_mini.cpp
+++ berusky2-0.10/src/tmp/compat_mini.cpp
@@ -92,7 +92,7 @@ THREAD_HANDLE CreateThread(void *lpThrea
 
 int CloseHandle(THREAD_HANDLE handle)
 {
-
+  return 1;
 }
 
 void ExitThread(dword dwExitCode)
@@ -103,10 +103,12 @@ void ExitThread(dword dwExitCode)
 
 int SetThreadPriority(THREAD_HANDLE hThread, int nPriority)
 {
+  return 1;
 }
 
 int GetThreadPriority(THREAD_HANDLE hThread)
 {
+  return 0/*THREAD_PRIORITY_NORMAL*/;
 }
 
 int GetExitCodeThread(THREAD_HANDLE hThread, dword *lpExitCode)

# Buster/stable amd64 qemu VM 2019-11-15


apt update
apt dist-upgrade


apt install systemd-coredump dpkg-dev devscripts xserver-xorg lightdm openbox 
xterm gdb valgrind rr berusky2 berusky2-dbgsym
apt build-dep berusky2

reboot

echo 1 > /proc/sys/kernel/perf_event_paranoid


mkdir /home/benutzer/source/berusky2/orig -p
cd/home/benutzer/source/berusky2/orig
apt source berusky2
cd



export DISPLAY=:0
export LANG=C


berusky2
# crashes

rr berusky2
# does not crash

valgrind berusky2
# crashes

valgrind --track-origins=yes berusky2
# crashes

gdb -q --args berusky2
# crashes




$ berusky2 
Berusky 2 v.0.10 (C) Anakreon 2011, http://www.anakreon.cz/
...
Kofola: - Load bitmap pro herni menu
--Total load time 0.2 s -
APAK: font_en.pak
Velikost AFAT: 2.6KB
Velikost Archivu: 0.4MB
Souboru: 7
Adresaru: 0
Uzlu: 2
b2_2d_font.pTTable = 0x563f6ddc1160
set font = font_en.pak
APAK: font_system_en.pak
Velikost AFAT: 2.6KB
Velikost Archivu: 0.1MB
Souboru: 7
Adresaru: 0
Uzlu: 2
b2_2d_font.pTTable = 0x563f70bd40f0
set font = font_system_en.pak
Segmentation fault (core dumped)


#


Nov 15 17:22:58 debian systemd-coredump[647]: Process 627 (berusky2) of user 
1000 dumped core.
  
  Stack trace of thread 627:
  #0  0x563f6b62b92e n/a 
(berusky2)
  #1  0x563f6b6835e4 n/a 
(berusky2)
  #2  0x563f6b6836a9 n/a 
(berusky2)
  #3  0x563f6b5d0374 n/a 
(berusky2)
  #4  0x563f6b6101b7 n/a 
(berusky2)
  #5  0x563f6b5b4293 main 
(berusky2)
  #6  0x7f2f6423a09b 
__libc_start_main (libc.so.6)
  #7  0x563f6b5b450a n/a 
(berusky2)
  
  Stack trace of thread 642:
  #0  0x7f2f64304819 __poll 
(libc.so.6)
  #1  0x7f2f63bdd9af n/a 
(libasound.so.2)
  #2  0x7f2f63bddccb 
snd_pcm_wait (libasound.so.2)
  #3  0x7f2f6498d2ff n/a 
(libopenal.so.1)
  #4  0x7f2f6499bb67 n/a 
(libopenal.so.1)
  #5  0x7f2f64701fa3 
start_thread (libpthread.so.0)
  #6  0x7f2f6430f4cf __clone 
(libc.so.6)
  
  Stack trace of thread 643:
  #0  0x7f2f6470a896 
do_futex_wait.constprop.1 (libpthread.so.0)
   

Bug#944658: mailavenger: FTBFS on i386

[Bernhard Übelacker]

Dear Maintainer,
I tried to find out what happens and I think it is
related to the changes from #928467.
Because of these the configure script searches now
for libdb-5.3.a in directory /usr/lib/i686-linux-gnu
(in configure "$dir/lib/${host_cpu}-${host_os}").

Unfortunately that library lives in /usr/lib/i386-linux-gnu.

Changing in debian/rules the --host and --build arguments
to DEB_..._MULTIARCH would make the package build in i386,
but I cannot say if that would defeat the whole purpose
of the change in #928467, therefore I hope its ok CCing
to Helmut Grohne.

Kind regards,
Bernhard

Bug#939754: gimp: Crashes when I try to open an image or create a new one

[Bernhard Übelacker]

Control: forcemerge 939754 939768 939876 939977 939985 940008 940011 940042 
940044 940088 940174 940177 940285 940472 940525 940561 940610


Hello,
I hope it is ok to merge all such bugs.
All of them show gimp_gegl_mask_is_empty at an
instruction address ending in 411.

Now that gegl 0.4.14-2 transitioned to testing,
gimp 2.10.8-2+b1 should work as expected in testing.
(User confirmation in [1].)

If there is nothing that could be done in gimp to avoid
such situations (fxied version dependency to gegl?),
I guess this bugs can be closed?

Kind regards,
Bernhard

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

Bug#940190: gegl: FTBFS on mips64el and mipsel while it did built before

[Bernhard Übelacker]

Hello,
I have created a new upstream issue:
https://gitlab.gnome.org/GNOME/gegl/issues/206

Kind regards,
Bernhard