Bug#982661: mame: Crash on startup

[Bernhard Übelacker]

Hello Celelibi,
does this happen with current version
in testing 0.228+dfsg.1-1, too?

Kind regards,
Bernhard

Bug#983153: calendar: Segmentation fault

[Bernhard Übelacker]

Dear Maintainer,
this crash happens because this executable is expecting
at command line a parameter month and year.
Doing so produces a calendar at stdout in postscript format.

Kind regards,
Bernhard

(gdb) bt
#0  __GI_strtol_l_internal (nptr=0x0, endptr=0x0, base=10, group=0, 
loc=0x7f3181dc04a0 <_nl_global_locale>) at ../stdlib/strtol_l.c:292
#1  0x5629626651b4 in atoi (__nptr=) at 
/usr/include/stdlib.h:363
#2  main (argc=1, argv=0x7ffe5c59e508) at calendar.cpp:621

https://sources.debian.org/src/pluto-lunar/0.0~git20180825.e34c1d1-1/calendar.cpp/#L621

# Bullseye/testing amd64 qemu VM 2021-03-07


apt update
apt dist-upgrade


apt install systemd-coredump gdb pluto-lunar pluto-lunar-dbgsym



benutzer@debian:~$ /usr/lib/pluto/lunar/calendar
Speicherzugriffsfehler (Speicherabzug geschrieben)



root@debian:~# journalctl -e
Mär 07 16:05:51 debian kernel: calendar[1010]: segfault at 0 ip 
7f3181c41518 sp 7ffe5c59e380 error 4 in 
libc-2.31.so[7f3181c26000+14b000]
Mär 07 16:05:51 debian kernel: Code: 41 54 45 31 e4 55 53 48 83 ec 28 48 89 74 
24 08 85 c9 0f 85 c2 02 00 00 83 ff 01 0f 84 81 01 00 00 83 ff 24 0f 87 78 01 
00 00 <49> 0f be 55 00 49 8b 48 68 4c 89 eb 48 89 d0 f6 44 51 01 20 74 15
Mär 07 16:05:51 debian systemd[1]: Created slice 
system-systemd\x2dcoredump.slice.
Mär 07 16:05:51 debian systemd[1]: Started Process Core Dump (PID 1011/UID 0).
Mär 07 16:05:51 debian systemd-coredump[1012]: Process 1010 (calendar) of user 
1000 dumped core.

Stack trace of thread 1010:
#0  0x7f3181c41518 n/a 
(libc.so.6 + 0x40518)
#1  0x5629626651b4 n/a 
(calendar + 0x21b4)
#2  0x7f3181c27d0a 
__libc_start_main (libc.so.6 + 0x26d0a)
#3  0x56296266541a n/a 
(calendar + 0x241a)





root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Sun 2021-03-07 16:05:51 CET1010  1000  1000  11 present   
/usr/lib/pluto/lunar/calendar

root@debian:~# coredumpctl gdb 1010
...
Core was generated by `/usr/lib/pluto/lunar/calendar'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  __GI_strtol_l_internal (nptr=0x0, endptr=0x0, base=10, group=0, 
loc=0x7f3181dc04a0 <_nl_global_locale>) at ../stdlib/strtol_l.c:292
292 ../stdlib/strtol_l.c: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0  __GI_strtol_l_internal (nptr=0x0, endptr=0x0, base=10, group=0, 
loc=0x7f3181dc04a0 <_nl_global_locale>) at ../stdlib/strtol_l.c:292
#1  0x5629626651b4 in ?? ()
#2  0x7f3181c27d0a in __libc_start_main (main=0x562962665190, argc=1, 
argv=0x7ffe5c59e508, init=, fini=, 
rtld_fini=, stack_end=0x7ffe5c59e4f8) at ../csu/libc-start.c:308
#3  0x56296266541a in ?? ()


root@debian:~# export DEBUGINFOD_URLS="https://debuginfod.debian.net;
root@debian:~# coredumpctl gdb 1010

(gdb) bt
#0  __GI_strtol_l_internal (nptr=0x0, endptr=0x0, base=10, group=0, 
loc=0x7f3181dc04a0 <_nl_global_locale>) at ../stdlib/strtol_l.c:292
#1  0x5629626651b4 in atoi (__nptr=) at 
/usr/include/stdlib.h:363
#2  main (argc=1, argv=0x7ffe5c59e508) at calendar.cpp:621

https://sources.debian.org/src/pluto-lunar/0.0~git20180825.e34c1d1-1/calendar.cpp/#L621



/usr/lib/pluto/lunar/calendar 03 2021 > test.ps

Bug#983242: wine-development recent upgrade (5.6-1?) broke levelator.exe

[Bernhard Übelacker]

Dear Maintainer,
this issue might be following upstream bug [1].

Because of that winepath "emits DOS-style instead of
UNIX-style line endings".

Therefore the carriage return character got part of
the filename and could therefore not be found.

This got fixed already in upstream wine-5.7.

Kind regards,
Bernhard

[1] https://bugs.winehq.org/show_bug.cgi?id=48937

# Bullseye/testing amd64 qemu VM 2021-03-07


dpkg --add-architecture i386
apt update
apt dist-upgrade


apt install systemd-coredump sddm xserver-xorg openbox mc ffmpeg sshfs dos2unix



http://www.conversationsnetwork.org/levelator
wget http://cdn.conversationsnetwork.org/LevelatorSetup-2.1.1.exe
md5sum LevelatorSetup-2.1.1.exe 
55b968fc015c11b210be6c1395796d26  LevelatorSetup-2.1.1.exe




apt install wine




export DISPLAY=:0
wine --version
# 5.0.3-3
wine wineboot
wineserver -k

wine LevelatorSetup-2.1.1.exe
wineserver -k


ffmpeg -f lavfi -i "sine=frequency=1000:duration=20" test.wav

WINEPATH=$(winepath --windows /home/benutzer/test.wav)
wine "c:/Program Files (x86)/Levelator/levelator.exe" $WINEPATH
# wine c:/Program Files (x86)/Levelator/levelator.exe Z:\home\benutzer\test.wav
wineserver -k




dpkg --purge wine libwine:amd64 libwine:i386 fonts-wine wine32:i386 wine64
# activate unstable in sources.list
apt update
apt install wine-development






wine --version
wine-5.6 (Debian 5.6-1)
wine wineboot
wineserver -k

WINEPATH=$(winepath --windows /home/benutzer/test.wav)
wine "c:/Program Files (x86)/Levelator/levelator.exe" $WINEPATH
# wine c:/Program Files (x86)/Levelator/levelator.exe Z:\home\benutzer\test.wav

Message Box:
The Conversati...twork Levelator
Can't open the source file: Z:\home\benutzer\test.wav

wineserver -k

winepath --windows /home/benutzer/test.wav | hexdump -C
  5a 3a 5c 68 6f 6d 65 5c  62 65 6e 75 74 7a 65 72  |Z:\home\benutzer|
0010  5c 74 65 73 74 2e 77 61  76 0d 0a |\test.wav..|
001b






dpkg --purge fonts-wine libwine-development:amd64 libwine-development:i386 
wine-development wine32-development:i386 wine64-development





# Cached packages from upstream wine: 
https://dl.winehq.org/wine-builds/debian/dists/buster
mkdir /wine-bin
sshfs -o allow_other,uid=1000,gid=1000 bernhard@...:/wine-bin /wine-bin

mkdir -p /home/bernhard/data/entwicklung/2021/wine
ln -s /wine-bin/wine-git /home/bernhard/data/entwicklung/2021/wine/wine-git


ln -s /wine-bin $HOME/
export PATH_ORIG=$PATH



export 
PATH="$HOME/wine-bin/winehq-devel/winehq-devel_5.5~buster_amd64/opt/wine-devel/bin:$PATH_ORIG"
wine --version
wine-5.5
wine wineboot
wineserver -k
WINEPATH=$(winepath --windows /home/benutzer/test.wav)
wine "c:/Program Files (x86)/Levelator/levelator.exe" $WINEPATH
--> seems to work



export 
PATH="$HOME/wine-bin/winehq-devel/winehq-devel_5.6~buster_amd64/opt/wine-devel/bin:$PATH_ORIG"
wine --version
wine-5.6
wine wineboot
wineserver -k
WINEPATH=$(winepath --windows /home/benutzer/test.wav)
wine "c:/Program Files (x86)/Levelator/levelator.exe" $WINEPATH
--> Can't open the source file: Z:\home\benutzer\test.wav

winepath --windows /home/benutzer/test.wav | hexdump -C
  5a 3a 5c 68 6f 6d 65 5c  62 65 6e 75 74 7a 65 72  |Z:\home\benutzer|
0010  5c 74 65 73 74 2e 77 61  76 0d 0a |\test.wav..|
001b
winepath --windows /home/benutzer/test.wav | dos2unix | hexdump -C
  5a 3a 5c 68 6f 6d 65 5c  62 65 6e 75 74 7a 65 72  |Z:\home\benutzer|
0010  5c 74 65 73 74 2e 77 61  76 0a|\test.wav.|
001a



export 
PATH="$HOME/wine-bin/winehq-devel/winehq-devel_5.7~buster_amd64/opt/wine-devel/bin:$PATH_ORIG"
wine --version
wine-5.7
wine wineboot
wineserver -k
WINEPATH=$(winepath --windows /home/benutzer/test.wav)
wine "c:/Program Files (x86)/Levelator/levelator.exe" $WINEPATH
--> seems to work

winepath --windows /home/benutzer/test.wav | hexdump -C
  5a 3a 5c 68 6f 6d 65 5c  62 65 6e 75 74 7a 65 72  |Z:\home\benutzer|
0010  5c 74 65 73 74 2e 77 61  76 0a|\test.wav.|
001a


https://bugs.winehq.org/show_bug.cgi?id=48937

Bug#982966: python3-pygame: Using pygame 1.9.6 crashes Wayland (hard) and X

[Bernhard Übelacker]

Control: reassign -1 gnome-shell 3.38.3-3
Control: affects -1 python3-pygame


Hello Richard,
wonderful, thanks, thats a great backtrace.
It is highly similar to that one in upstream bug [3491]
and still quite similar to [3785].
Some commits entered the upstream 3.38 branch to fix the first bug,
for the second bug there is still a merge request open.

I hope it is ok to reassign this bug to gnome-shell.

Kind regards,
Bernhard

[3491] https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3491
[3785] https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3785



Am 07.03.21 um 12:29 schrieb Richard Duivenvoorde:

(gdb) bt full
#0  g_type_check_instance 
(type_instance=type_instance@entry=0x) at 
../../../gobject/gtype.c:4133
#1  0x7fe88cf50883 in g_signal_handler_disconnect 
(instance=0x, handler_id=0) at ../../../gobject/gsignal.c:2718
#2  0x7fe88cf42eef in weak_refs_notify (data=0x55a3a5500fe0) at 
../../../gobject/gobject.c:2946
#3  0x7fe88ce2dfae in g_data_set_internal (datalist=0x55a3a5fcd1b0, key_id=, new_data=, new_destroy_func=, dataset=0x0) at 
../../../glib/gdataset.c:407
#4  0x7fe88cf440a3 in g_object_unref (_object=) at 
../../../gobject/gobject.c:3465
#5  g_object_unref (_object=0x55a3a5fcd1a0) at ../../../gobject/gobject.c:3395
#6  0x7fe88d1c1df8 in shell_app_dispose (object=0x55a3a18908f0 [ShellApp]) 
at ../src/shell-app.c:1561
#7  0x7fe88cf440a3 in g_object_unref (_object=) at 
../../../gobject/gobject.c:3465
#8  g_object_unref (_object=0x55a3a18908f0) at ../../../gobject/gobject.c:3395

Bug#982966: python3-pygame: Using pygame 1.9.6 crashes Wayland (hard) and X

[Bernhard Übelacker]

Hello Richard,
thanks for the new information, but really
the dbgsym packages were meant.
They are available in a separate repository.

Nevertheless, if adding this repository is not possible,
then there is another way, but that would download
unknown size of files into directory "$HOME/.cache/debuginfod_client",
but might be more convenient:

  export DEBUGINFOD_URLS="https://debuginfod.debian.net;
  coredumpctl gdb 18825

Kind regards,
Bernhard

Bug#982966: python3-pygame: Using pygame 1.9.6 crashes Wayland (hard) and X

[Bernhard Übelacker]

Hello Richard,
thanks for the fast response.
I failed to tell you the -b0 means the current boot,
therefore if you rebooted with -b-1 might the boot that
contains the crash.

But maybe you could improve the output of coredumpctl
quite a bit.
Could you please add the debug symbol package repository
like in [1] and install these packages?

gdb libglib2.0-0-dbgsym gnome-shell-dbgsym libgjs0g-dbgsym 
libmozjs-78-0-dbgsym libmutter-7-0-dbgsym

Then you could again invoke 'coredumpctl gdb 18825',
that should print mostly the same information but give
you a "(gdb)" prompt, where you could issue the command
'bt full' and forward this output again?

Kind regards,
Bernhard

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

Bug#980516: Bug:980516: mate-power-manager: Crashes soon after startup

[Bernhard Übelacker]

Dear Maintainer,
I tried to get some more information from the kernel message.

This led me to this line:
  at 0x5556ee99: file gpm-engine.c, line 540.

There the array is dereferenced unconditionally:
  
https://sources.debian.org/src/mate-power-manager/1.24.2-1/src/gpm-engine.c/#L540
  539   array = up_client_get_devices2 (engine->priv->client);
  540   for (i=0;ilen;i++) {

Therefore the assertion message just before the segfault
seems related:
  up_client_get_devices2: assertion 'UP_IS_CLIENT (client)' failed

That points to this line in upower:
  https://cgit.freedesktop.org/upower/tree/libupower-glib/up-client.c#n117
  117   g_return_val_if_fail (UP_IS_CLIENT (client), NULL);

And therefore the "array" seems to have received the NULL pointer.

Therefore the value given to function up_client_get_devices2
seems already suspicious.


Unfortunately I have not found any related
entry in upstream bug trackers.
Details in attached file.

Kind regards,
Bernhard

# Bullseye/testing amd64 qemu VM 2021-03-06


apt update
apt dist-upgrade


systemd-coredump mate xserver-xorg lightdm gdb mate-power-manager-dbgsym


reboot




https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash

From submitter:
[  349.205142] mate-power-mana[3580]: segfault at 8 ip 5641ef93ae99 sp 
7ffcb468bf60 error 4 in mate-power-manager[5641ef928000+1a000]
[  349.205154] Code: 00 49 8b 44 24 18 31 db 48 8b 78 20 e8 b0 01 ff ff 4c 89 
e7 e8 68 f5 ff ff 49 8b 44 24 18 48 8b 78 08 e8 fa e3 fe ff 48 89 c5 <8b> 40 08 
85 c0 74 1a 48 8b 45 00 89 da 4c 89 e7 83 c3 01 48 8b 34

error 4 == 0b0100:
- 0: no page found
- 0: read access
- 0: kernel-mode access

echo -n "find /b ..., ..., 0x" && \
echo "00 49 8b 44 24 18 31 db 48 8b 78 20 e8 b0 01 ff ff 4c 89 e7 e8 68 f5 ff 
ff 49 8b 44 24 18 48 8b 78 08 e8 fa e3 fe ff 48 89 c5 <8b> 40 08 85 c0 74 1a 48 
8b 45 00 89 da 4c 89 e7 83 c3 01 48 8b 34" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'

find /b ..., ..., 0x00, 0x49, 0x8b, 0x44, 0x24, 0x18, 0x31, 0xdb, 0x48, 0x8b, 
0x78, 0x20, 0xe8, 0xb0, 0x01, 0xff, 0xff, 0x4c, 0x89, 0xe7, 0xe8, 0x68, 0xf5, 
0xff, 0xff, 0x49, 0x8b, 0x44, 0x24, 0x18, 0x48, 0x8b, 0x78, 0x08, 0xe8, 0xfa, 
0xe3, 0xfe, 0xff, 0x48, 0x89, 0xc5, 0x8b, 0x40, 0x08, 0x85, 0xc0, 0x74, 0x1a, 
0x48, 0x8b, 0x45, 0x00, 0x89, 0xda, 0x4c, 0x89, 0xe7, 0x83, 0xc3, 0x01, 0x48, 
0x8b, 0x34




gdb -q
set width 0
set pagination off
file /usr/bin/mate-power-manager
tb main
run

info target
...
0xd760 - 0x55575a11 is .text
...


find /b 0xd760, 0x55575a11, 0x00, 0x49, 0x8b, 0x44, 0x24, 
0x18, 0x31, 0xdb, 0x48, 0x8b, 0x78, 0x20, 0xe8, 0xb0, 0x01, 0xff, 0xff, 0x4c, 
0x89, 0xe7, 0xe8, 0x68, 0xf5, 0xff, 0xff, 0x49, 0x8b, 0x44, 0x24, 0x18, 0x48, 
0x8b, 0x78, 0x08, 0xe8, 0xfa, 0xe3, 0xfe, 0xff, 0x48, 0x89, 0xc5, 0x8b, 0x40, 
0x08, 0x85, 0xc0, 0x74, 0x1a, 0x48, 0x8b, 0x45, 0x00, 0x89, 0xda, 0x4c, 0x89, 
0xe7, 0x83, 0xc3, 0x01, 0x48, 0x8b, 0x34
0x5556ee6f 
1 pattern found.

b * (0x5556ee6f + 42)
Breakpoint 2 at 0x5556ee99: file gpm-engine.c, line 540.

info b
Num Type   Disp Enb AddressWhat
2   breakpoint keep y   0x5556ee99 in 
gpm_engine_coldplug_idle_cb at gpm-engine.c:540

disassemble /r 0x5556ee6f, 0x5556ee6f + 62
Dump of assembler code from 0x5556ee6f to 0x5556eead:
   0x5556ee6f : 00 49 8badd 
   %cl,-0x75(%rcx)
   0x5556ee72 : 44 24 18
rex.R and $0x18,%al
   0x5556ee75 : 31 db   xor 
   %ebx,%ebx
   0x5556ee77 : 48 8b 78 20 mov 
   0x20(%rax),%rdi
   0x5556ee7b : e8 b0 01 ff ff  
call   0xf030 
   0x5556ee80 : 4c 89 e7mov 
   %r12,%rdi
   0x5556ee83 : e8 68 f5 ff ff  
call   0x5556e3f0 
   0x5556ee88 :49 8b 44 24 18  mov 
   0x18(%r12),%rax
   0x5556ee8d :48 8b 78 08 mov 
   0x8(%rax),%rdi
   0x5556ee91 :e8 fa e3 fe ff  
call   0xd290 
   0x5556ee96 :48 89 c5mov 
   %rax,%rbp
***0x5556ee99 :8b 40 08mov 
   0x8(%rax),%eax
   0x5556ee9c :85 c0   
test   %eax,%eax
   0x5556ee9e :74 1a   je  
   0x5556eeba 
   0x5556eea0 :48 8b 45 00 mov 
   0x0(%rbp),%rax
   0x5556eea4 :89 da   mov 
   %ebx,%edx
   0x5556eea6 :4c 89 e7mov 
   %r12,%rdi
   0x5556eea9 :83 c3 01add 
   $0x1,%ebx
   0x5556eeac :48 8b 34 d0 mov 
   (%rax,%rdx,8),%rsi
End of assembler dump.




mate-power-manager-dbgsym_1.24.2-1_amd64.deb
https://sources.debian.org/src/mate-power-manager/1.24.2-1/src/gpm-engine.c/#L540
for (i=0;ilen;i++) {

https://git.mate-desktop.org/mate-power-manager/tree/src/gpm-engine.c#n538

https://cgit.freedesktop.org/upower/tree/libupower-glib/up-client.c#n117


(gdb) ptype /o GPtrArray
type = struct _GPtrArray {
/*0  | 

Bug#982966: python3-pygame: Using pygame 1.9.6 crashes Wayland (hard) and X

[Bernhard Übelacker]

Hello Richard,
I tried the steps below [1] but it did not trigger
a crash inside a gnome/wayland test VM.

Maybe you could install the package systemd-coredump, trigger
the crash once more and retrieve the logging from the current
boot by 'journalctl -b0 > journalctl.txt' and forward the
lines related to the crash to this bug?

More informations on retrieving a backtrace could be found in [2].

Kind regards,
Bernhard


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

[1] apt install systemd-coredump gnome python3-pygame git

mkdir flappybird
cd flappybird
git clone https://github.com/clear-code-projects/FlappyBird_Python
cd FlappyBird_Python
sed -i 's/04B_19.ttf/04B_19.TTF/g' flappy_update.py
python3 flappy_update.py

Bug#983031: konqueror segfaults on starting

[Bernhard Übelacker]

Hello Joe,
this information might not be sufficient for the maintainer.

Could you try following to collect some more informations?

- install packages:
gdb psmisc konqueror-dbgsym

- stop all running instances of konqueror:
killall konqueror

- then start konqueror inside a debugger:
gdb -q -ex 'set pagination off' -ex 'run' -ex 'bt' -ex 'detach' -ex 'quit' 
--args konqueror


When the crash happens, a backtrace should be printed.
Please forward this output to this bug.

More debugging hints can be found here [1].

Kind regards,
Bernhard

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

Bug#983934: linux-image-5.3.0-3-amd64: guest kernel fails inside qemu VM with qxl displays (BUG: unable to handle page fault)

[Bernhard Übelacker]

Dear Maintainer,
I investigated a bit further and came across this document [1].
There it is stated that in Linux usually a single qxl device with
multiple outputs [2] is used and in Windows multiple qxl devices with
a single output each [3].

Using with a Linux guest the suggested multiple outputs of a single
qxl device does not produce the kernel oops and works perfect.

This kernel issue is just visible with multiple qxl devices and a Linux guest,
therefore is kind of an unusual setup, nevertheless was not causing
this kernel oops up until 5.2 and fails afterwards.

Kind regards,
Bernhard

[1] https://www.spice-space.org/multiple-monitors.html, paragraph "Spice 
Protocol"

[2] QEmu parameter: "... -device qxl-vga,max_outputs=4,... ..."
[3] QEmu parameter: "... -device qxl-vga   -device qxl ..."



As a side note:
In my tests with multiple qxl devices and watching the Linux guest
with remote-viewer the mouse pointer was always stuck at one position.

Debugging remote-viewer/Qemu shows that if multiple qxl devices are used,
the mouse mode gets set to "server", therefore no absolute
but just relative mouse movements get sent to the VM.
My guess is that the guest qxl driver on Linux does
currently not implement that mode.
spice-0.14.3/server/reds.c:640, reds_update_mouse_mode:
SPICE_MOUSE_MODE_CLIENT / SPICE_MOUSE_MODE_SERVER

Bug#984593: libmutter-7-0: gnome-shell segfaults because monitor_mode contains null pointer.

[Bernhard Übelacker]

Package: libmutter-7-0
Version: 3.38.3-2
Severity: normal
X-Debbugs-Cc: bernha...@mailbox.org

Dear Maintainer,
I tried to replicate #982572, therefore
setup a qemu VM with two qxl devices [1].

This is currently running a kernel 5.2 due to #983934.

Inside I have trouble with mouse input,
therefore activated remote access by keyboard.
(Unfortunately can just access one of the
two screens with this method.)

On that screen I did some resolution changes and
window moves, then gnome-shell crashed.
I have not yet tried to reproduce this or cannot
say if this happens because of this special setup.
Found also no other down- or any upstream bug about this.

It seems that we get in [3] a nullpointer for "monitor_mode",
that gets dereferenced later.

In [2] are the last frames of the backtrace, complete
in attached file.

Kind regards,
Bernhard


[3] 
https://sources.debian.org/src/mutter/3.38.3-3/src/backends/meta-renderer.c/#L228

[2]
(gdb) bt
#0  meta_monitor_mode_foreach_crtc (monitor=monitor@entry=0x55c936bd45a0, 
mode=0x0, func=func@entry=0x7fbadddaf010 , 
user_data=user_data@entry=0x7fff8032e9e0, error=error@entry=0x0) at 
../src/backends/meta-monitor.c:1912
#1  0x7fbadddaefe5 in meta_renderer_real_get_views_for_monitor 
(renderer=, monitor=0x55c936bd45a0) at 
../src/backends/meta-renderer.c:228
#2  0x7fbadde3190f in is_redraw_queued (monitor_src=0x7fbacc039150) at 
../src/backends/meta-screen-cast-monitor-stream-src.c:210
#3  sync_cursor_state (monitor_src=0x7fbacc039150) at 
../src/backends/meta-screen-cast-monitor-stream-src.c:228
#4  0x7fbadeab80a2 in g_closure_invoke (closure=0x55c9376dd460, 
return_value=return_value@entry=0x0, n_param_values=1, 
param_values=param_values@entry=0x7fff8032ebd0, 
invocation_hint=invocation_hint@entry=0x7fff8032eb50) at 
../../../gobject/gclosure.c:810
#5  0x7fbadeaca602 in signal_emit_unlocked_R 
(node=node@entry=0x55c936648d40, detail=detail@entry=0, 
instance=instance@entry=0x7fbac0002280, 
emission_return=emission_return@entry=0x0, 
instance_and_params=instance_and_params@entry=0x7fff8032ebd0) at 
../../../gobject/gsignal.c:3809
#6  0x7fbadead06cf in g_signal_emit_valist (instance=, 
signal_id=, detail=, 
var_args=var_args@entry=0x7fff8032ed50) at ../../../gobject/gsignal.c:3495
#7  0x7fbadead0c3f in g_signal_emit (instance=, 
signal_id=, detail=) at ../../../gobject/gsignal.c:3551
#8  0x7fbadde4cdba in meta_wayland_pointer_set_focus (pointer=0x55c936be7820, 
surface=) at ../src/wayland/meta-wayland-pointer.c:973
#9  0x7fbadde4d40d in repick_for_event (pointer=0x55c936be7820, 
for_event=) at ../src/wayland/meta-wayland-pointer.c:640
...

[1] -spice port=5930,addr=$LOCALIP,disable-ticketing -device 
qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1
 -device 
qxl,id=video1,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1




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

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libmutter-7-0 depends on:
ii  adwaita-icon-theme 3.38.0-1
ii  gsettings-desktop-schemas  3.38.0-2
ii  libatk1.0-02.36.0-2
ii  libc6  2.31-9
ii  libcairo-gobject2  1.16.0-5
ii  libcairo2  1.16.0-5
ii  libcanberra0   0.30-7
ii  libdrm22.4.104-1
ii  libegl11.3.2-1
ii  libfontconfig1 2.13.1-4.2
ii  libfribidi01.0.8-2
ii  libgbm120.3.4-1
ii  libgdk-pixbuf-2.0-02.42.2+dfsg-1
ii  libgl1 1.3.2-1
ii  libglib2.0-0   2.66.7-1
ii  libgnome-desktop-3-19  3.38.4-1
ii  libgraphene-1.0-0  1.10.4+dfsg1-1
ii  libgtk-3-0 3.24.24-1
ii  libgudev-1.0-0 234-1
ii  libice62:1.0.10-1
ii  libinput10 1.16.4-3
ii  libjson-glib-1.0-0 1.6.2-1
ii  libpango-1.0-0 1.46.2-3
ii  libpangocairo-1.0-01.46.2-3
ii  libpangoft2-1.0-0  1.46.2-3
ii  libpipewire-0.3-0  0.3.19-4
ii  libsm6 2:1.2.3-1
ii  libstartup-notification0   0.12-6+b1
ii  libsystemd0247.3-1
ii  libudev1   247.3-1
ii  libwacom2  1.8-2
ii  libwayland-server0 1.18.0-2~exp1.1
ii  libx11-6   2:1.7.0-2
ii  libx11-xcb12:1.7.0-2
ii  libxau61:1.0.9-1
ii  libxcb-randr0  1.14-3
ii  libxcb-res01.14-3
ii  libxcb11.14-3
ii  

Bug#980443: dovecot-imapd: segfault at 8 ip 000055c38b20f97c sp 00007ffe4baaaa40 error 4 in imap[55c38b1f7000+24000]

[Bernhard Übelacker]

Dear Maintainer,
I tried to have a look at the kernel message and if I could
retrieve some more information with the help of the dbgsym
package, like described in [1].


And I came up with the following location:

at 0x5557997c: file imap-notify.c, line 305.

   0x55579976 :41 bc ff ff ff ff   
mov$0x,%r12d
***0x5557997c :48 8b 78 08 
mov0x8(%rax),%rdi
   0x55579980 :e8 8b 77 ff ff  callq 
 0x55571110 

This would match the "at 8" and the "ip ...97c" from the kernel output.

And would lead to this source location [2].

A "blame" from the github page shows this commit fixing
a crash [3], which might be what happened here too.


Kind regards,
Bernhard

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

[2] 
https://sources.debian.org/src/dovecot/1:2.3.4.1-5+deb10u6/src/imap/imap-notify.c/#L305
(From the deb10u6 because deb10u5 is not there any more.)

[3] 
https://github.com/dovecot/core/commit/49daa901338a7b4749a48f0b34e199e2f6644f67


https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash

From submitter:
Jan  6 14:55:54 uggla kernel: [145284.855936] imap[18530]: segfault at 8 ip 
55c38b20f97c sp 7ffe4b40 error 4 in imap[55c38b1f7000+24000]
Jan  6 14:55:54 uggla kernel: [145284.855945] Code: 5d 41 5c 41 5d e9 2b ca fe 
ff 0f 1f 40 00 45 89 ec 48 89 df 48 39 eb 75 bd 48 8b 45 00 48 8d 35 da f4 00 
00 41 bc ff ff ff ff <48> 8b 78 08 e8 8b 77 ff ff 48 83 c4 08 44 89 e0 5b 5d 41 
5c 41 5d

error 4 == 0b100
- 0: no page found
- 0: read access
- 1: user-mode access



# echo -n "find /b ..., ..., 0x" && \
> echo "5d 41 5c 41 5d e9 2b ca fe ff 0f 1f 40 00 45 89 ec 48 89 df 48 39 eb 75 
> bd 48 8b 45 00 48 8d 35 da f4 00 00 41 bc ff ff ff ff <48> 8b 78 08 e8 8b 77 
> ff ff 48 83 c4 08 44 89 e0 5b 5d 41 5c 41 5d" \
>  | sed 's/[<>]//g' | sed 's/ /, 0x/g'
find /b ..., ..., 0x5d, 0x41, 0x5c, 0x41, 0x5d, 0xe9, 0x2b, 0xca, 0xfe, 0xff, 
0x0f, 0x1f, 0x40, 0x00, 0x45, 0x89, 0xec, 0x48, 0x89, 0xdf, 0x48, 0x39, 0xeb, 
0x75, 0xbd, 0x48, 0x8b, 0x45, 0x00, 0x48, 0x8d, 0x35, 0xda, 0xf4, 0x00, 0x00, 
0x41, 0xbc, 0xff, 0xff, 0xff, 0xff, 0x48, 0x8b, 0x78, 0x08, 0xe8, 0x8b, 0x77, 
0xff, 0xff, 0x48, 0x83, 0xc4, 0x08, 0x44, 0x89, 0xe0, 0x5b, 0x5d, 0x41, 0x5c, 
0x41, 0x5d




# Buster/stable amd64 qemu VM 2021-03-04


apt update
apt dist-upgrade

apt install gdb dovecot-imapd-dbgsym



# dpkg -l | grep 2.3.4.1-5+deb10u
ii  dovecot-core  1:2.3.4.1-5+deb10u6  amd64
secure POP3/IMAP server - core files
ii  dovecot-imapd 1:2.3.4.1-5+deb10u6  amd64
secure POP3/IMAP server - IMAP daemon
ii  dovecot-imapd-dbgsym  1:2.3.4.1-5+deb10u6  amd64
debug symbols for dovecot-imapd

wget 
https://snapshot.debian.org/archive/debian-security/20210104T152436Z/pool/updates/main/d/dovecot/dovecot-core_2.3.4.1-5%2Bdeb10u5_amd64.deb
wget 
https://snapshot.debian.org/archive/debian-security/20210104T152436Z/pool/updates/main/d/dovecot/dovecot-imapd_2.3.4.1-5%2Bdeb10u5_amd64.deb
wget 
https://snapshot.debian.org/archive/debian-debug/20210110T023633Z/pool/main/d/dovecot/dovecot-imapd-dbgsym_2.3.4.1-5%2Bdeb10u5_amd64.deb

dpkg -i dovecot-core_2.3.4.1-5+deb10u5_amd64.deb 
dovecot-imapd-dbgsym_2.3.4.1-5+deb10u5_amd64.deb 
dovecot-imapd_2.3.4.1-5+deb10u5_amd64.deb


gdb -q 
set width 0
set pagination off
file /usr/lib/dovecot/imap
tb main
run 
...
info target

0x55562c50 - 0x55584251 is .text

find /b 0x55562c50, 0x55584251, 0x5d, 0x41, 0x5c, 0x41, 0x5d, 
0xe9, 0x2b, 0xca, 0xfe, 0xff, 0x0f, 0x1f, 0x40, 0x00, 0x45, 0x89, 0xec, 0x48, 
0x89, 0xdf, 0x48, 0x39, 0xeb, 0x75, 0xbd, 0x48, 0x8b, 0x45, 0x00, 0x48, 0x8d, 
0x35, 0xda, 0xf4, 0x00, 0x00, 0x41, 0xbc, 0xff, 0xff, 0xff, 0xff, 0x48, 0x8b, 
0x78, 0x08, 0xe8, 0x8b, 0x77, 0xff, 0xff, 0x48, 0x83, 0xc4, 0x08, 0x44, 0x89, 
0xe0, 0x5b, 0x5d, 0x41, 0x5c, 0x41, 0x5d

0x55579952 
1 pattern found.

b * (0x55579952 + 42)

Breakpoint 2 at 0x5557997c: file imap-notify.c, line 305.

info b

Num Type   Disp Enb AddressWhat
2   breakpoint keep y   0x5557997c in imap_client_notify_more 
at imap-notify.c:305

disassemble /r 0x55579952, 0x55579952 + 62

Dump of assembler code from 0x55579952 to 0x55579990:
   0x55579952 :5d  
pop%rbp
   0x55579953 :41 5c   
pop%r12
   0x55579955 :41 5d   
pop%r13
   0x55579957 :e9 2b ca fe ff  
jmpq   0x55566387 <__x86_return_thunk>
   0x5557995c :0f 1f 40 00 
nopl   0x0(%rax)
   0x55579960 :45 89 ec
mov%r13d,%r12d
   0x55579963 :48 89 df
mov%rbx,%rdi
   0x55579966 :48 39 eb
cmp%rbp,%rbx
   0x55579969 :75 bd   
jne   

Bug#982388: d1x-rebirth: Crashes when I try to start a new or load a saved game

[Bernhard Übelacker]

Hello Mikael,
maybe you could install systemd-coredump and look into output
of "journalctl -e" after such a crash happened again.

For more information please have a look at [1] about several
ways to collect some more information that might help the
maintainers.

Kind regards,
Bernhard

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

Bug#982804: libvirt_node_get_cpu_stats segmentation fault

[Bernhard Übelacker]

Dear Maintainer,
I tried to reproduce this issue and received a backtrace like in [1].

This looks like being fixed upstream in commit [2].
A package built with this patch does not crash any more.

The reason seems to be because this macro defines a variable
in a block local scope while it should be more visible.

Due to upstream moved the macro to a different file before that patch,
it has to applied to src/libvirt-php.h instead of src/util.h like in
attached file.

Kind regards,
Bernhard


[2] 
https://github.com/libvirt/libvirt-php/commit/587235c523b88de431f348902792c1a77e049f06

[1]
Program received signal SIGSEGV, Segmentation fault.
0x7f1d823a6d0e in zend_hash_real_init_mixed_ex (ht=ht@entry=0x7f1d7dba2a94 
<__FUNCTION__.28782+4>) at ./Zend/zend_hash.c:131
131 ht->nTableMask = HT_SIZE_TO_MASK(nSize);
1: x/i $pc
=> 0x7f1d823a6d0e :   mov
%ecx,0xc(%rdi)
(rr) bt
#0  0x7f1d823a6d0e in zend_hash_real_init_mixed_ex 
(ht=ht@entry=0x7f1d7dba2a94 <__FUNCTION__.28782+4>) at ./Zend/zend_hash.c:131
#1  zend_hash_real_init_mixed (ht=ht@entry=0x7f1d7dba2a94 
<__FUNCTION__.28782+4>) at ./Zend/zend_hash.c:260
#2  0x7f1d823a8168 in _zend_hash_str_add_or_update_i (flag=1, pData=0x7ffe46f16380, 
h=9223378990555402118, len=6, str=0x55c4dcbd6ac0 "kernel", ht=0x7f1d7dba2a94 
<__FUNCTION__.28782+4>) at ./Zend/zend_hash.c:740
#3  zend_hash_str_update (ht=ht@entry=0x7f1d7dba2a94 <__FUNCTION__.28782+4>, 
str=str@entry=0x55c4dcbd6ac0 "kernel", len=len@entry=6, 
pData=pData@entry=0x7ffe46f16380) at ./Zend/zend_hash.c:848
#4  0x7f1d8239d038 in zend_symtable_str_update (pData=0x7ffe46f16380, len=6, 
str=0x55c4dcbd6ac0 "kernel", ht=0x7f1d7dba2a94 <__FUNCTION__.28782+4>) at 
./Zend/zend_hash.h:501
#5  add_assoc_long_ex (arg=arg@entry=0x7ffe46f16400, key=key@entry=0x55c4dcbd6ac0 
"kernel", key_len=6, n=) at ./Zend/zend_API.c:1359
#6  0x7f1d7db837f5 in zif_libvirt_node_get_cpu_stats 
(execute_data=, return_value=0x7f1d8101c0a0) at 
../../src/libvirt-php.c:2356
#7  0x7f1d8241cdf7 in ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER () at 
./Zend/zend_vm_execute.h:694
#8  execute_ex (ex=0x7f1d7dba2a94 <__FUNCTION__.28782+4>) at 
./Zend/zend_vm_execute.h:55503
#9  0x7f1d824229b7 in zend_execute 
(op_array=op_array@entry=0x7f1d747fd760, return_value=0x0, 
return_value@entry=0x7f1d8101c030) at ./Zend/zend_vm_execute.h:60935
#10 0x7f1d8239b603 in zend_execute_scripts (type=type@entry=8, 
retval=0x7f1d8101c030, retval@entry=0x0, file_count=file_count@entry=3) at 
./Zend/zend.c:1568
#11 0x7f1d8233bb58 in php_execute_script 
(primary_file=primary_file@entry=0x7ffe46f18a60) at ./main/main.c:2637
#12 0x7f1d82424be2 in php_handler (r=) at 
./sapi/apache2handler/sapi_apache2.c:699
#13 0x55c4dbefda40 in ap_run_handler (r=r@entry=0x7f1d7db6b0a0) at 
config.c:170
#14 0x55c4dbefdfd6 in ap_invoke_handler (r=r@entry=0x7f1d7db6b0a0) at 
config.c:444
#15 0x55c4dbf16463 in ap_process_async_request (r=0x7f1d7db6b0a0) at 
http_request.c:453
#16 0x55c4dbf165ce in ap_process_request (r=r@entry=0x7f1d7db6b0a0) at 
http_request.c:488
#17 0x55c4dbf1283d in ap_process_http_sync_connection 
(c=0x7f1d7db6f290) at http_core.c:210
#18 ap_process_http_connection (c=0x7f1d7db6f290) at http_core.c:251
#19 0x55c4dbf078b0 in ap_run_process_connection 
(c=c@entry=0x7f1d7db6f290) at connection.c:42
#20 0x55c4dbf07e10 in ap_process_connection (c=c@entry=0x7f1d7db6f290, 
csd=) at connection.c:219
#21 0x7f1d825a33df in child_main (child_num_arg=child_num_arg@entry=0, 
child_bucket=child_bucket@entry=0) at prefork.c:615
#22 0x7f1d825a366b in make_child (s=0x7f1d8284e4a0, slot=slot@entry=0) 
at prefork.c:653
#23 0x7f1d825a4840 in prefork_run (_pconf=, 
plog=0x7f1d82849028, s=0x7f1d8284e4a0) at prefork.c:866
#24 0x55c4dbee067e in ap_run_mpm (pconf=0x7f1d82cca028, 
plog=0x7f1d82849028, s=0x7f1d8284e4a0) at mpm_common.c:94
#25 0x55c4dbed8f57 in main (argc=, argv=) 
at main.c:819


# Buster/stable amd64 qemu VM 2021-03-01


apt update
apt dist-upgrade


apt install systemd-coredump mc rr gdb quilt libvirt-daemon-system apache2 
virtinst libapache2-mod-php php-libvirt-php libapache2-mod-php7.3-dbgsym 
php-libvirt-php-dbgsym apache2-bin-dbgsym
apt build-dep php-libvirt-php



mkdir /home/benutzer/source/libapache2-mod-php7.3/orig -p
cd/home/benutzer/source/libapache2-mod-php7.3/orig
apt source libapache2-mod-php7.3
cd

mkdir /home/benutzer/source/php-libvirt-php/orig -p
cd/home/benutzer/source/php-libvirt-php/orig
apt source php-libvirt-php
cd




adduser www-data libvirt

virsh net-start default
virt-install -n empty-test --ram=512 --vcpus=2 --graphics none --disk none --pxe
virsh --connect qemu:///system list --all




a2enmod php7.3


tail -n0 -f /var/log/apache2/*
journalctl -f




cat < /var/www/html/test-libvirt.php

EOF




echo 1 > 

Bug#982454: lvm2: vgremove segfaults in libc-2.24.so

[Bernhard Übelacker]

Dear Maintainer,
I tried to reproduce the issue and got a segfault [2]
when trying to vgremove inside a i386 qemu VM
with version lvm2 2.02.168-2.
Attached file contains the steps taken.

This upstream commit sounds related. [1]

Kind regards,
Bernhard


[1] lvmetad: fix segfault on i386

https://sourceware.org/git/?p=lvm2.git;a=commit;h=46b735c937ce68e72d08997635321bf30240325d

https://sourceware.org/git/?p=lvm2.git;a=patch;h=46b735c937ce68e72d08997635321bf30240325d


[2]
(gdb) bt
#0  __strchr_sse2_bsf () at 
../sysdeps/i386/i686/multiarch/strchr-sse2-bsf.S:97
#1  0x0050b29f in config_make_nodes_v (cft=0x64fae0, parent=0x0, pre_sib=0x64fd48, 
ap=0xb92c "\365\nP") at config-util.c:248
#2  0x0050c5f7 in daemon_request_extend_v (r=..., ap=0xb90c 
"\354\224U") at daemon-client.c:218
#3  0x004fe622 in _lvmetad_send (cmd=0x606840, id=) at 
cache/lvmetad.c:435
#4  0x00500b6c in lvmetad_vg_remove_pending (vg=0x66aa28) at 
cache/lvmetad.c:1304
#5  0x004b366c in vg_remove_direct (vg=0x66aa28) at metadata/metadata.c:571
#6  0x004b3d3c in vg_remove (vg=0x66aa28) at metadata/metadata.c:634
#7  0x00455815 in vgremove_single (cmd=0x606840, vg_name=0x648978 "raid1", 
vg=0x66aa28, handle=0x648980) at vgremove.c:79
#8  0x004488b1 in _process_vgnameid_list (process_single_vg=0x455660 
, handle=0x648980, arg_tags=0xbb10, 
arg_vgnames=0xbb18, vgnameids_to_process=0xbb28, read_flags=1048576, 
cmd=0x606840) at toollib.c:1964
#9  process_each_vg (cmd=, argc=, argv=, 
one_vgname=, use_vgnames=, read_flags=1048576, include_internal=, handle=0x648980, process_single_vg=) at toollib.c:2277
#10 0x00455949 in vgremove (cmd=, argc=, 
argv=) at vgremove.c:112
#11 0x004337ee in lvm_run_command (cmd=, argc=, 
argv=) at lvmcmdline.c:1723
#12 0x0043455d in lvm2_main (argc=2, argv=0xbdf4) at lvmcmdline.c:2249
#13 0x0041a537 in main (argc=2, argv=0xbdf4) at lvm.c:22

# Stretch/oldstable i386 qemu VM 2021-02-28


apt update
apt dist-upgrade

apt install gdb lvm2 lvm2-dbgsym
apt build-dep lvm2




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






dd if=/dev/zero of=test0 bs=100M count=1
dd if=/dev/zero of=test1 bs=100M count=1

losetup loop0 test0
losetup loop1 test1

pvcreate /dev/loop0
pvcreate /dev/loop1

pvdisplay


mkdir /dev/testvg
mknod /dev/testvg/group c 128 0x
vgcreate raid1 /dev/loop0 /dev/loop1
vgremove raid1




root@debian:~# vgremove raid1
Speicherzugriffsfehler

root@debian:~# gdb -q --args vgremove raid1
Reading symbols from vgremove...(no debugging symbols found)...done.
(gdb) run
Starting program: /sbin/vgremove raid1
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
__strchr_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strchr-sse2-bsf.S:97
97  ../sysdeps/i386/i686/multiarch/strchr-sse2-bsf.S: Datei oder 
Verzeichnis nicht gefunden.
(gdb) bt
#0  __strchr_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strchr-sse2-bsf.S:97
#1  0x0050b29f in config_make_nodes_v ()
#2  0x0050c5f7 in daemon_request_extend_v ()
#3  0x004fe622 in ?? ()
#4  0x00500b6c in lvmetad_vg_remove_pending ()
#5  0x004b366c in vg_remove_direct ()
#6  0x004b3d3c in vg_remove ()
#7  0x00455815 in ?? ()
#8  0x004488b1 in process_each_vg ()
#9  0x00455949 in vgremove ()
#10 0x004337ee in lvm_run_command ()
#11 0x0043455d in lvm2_main ()
#12 0x0041a537 in main ()







root@debian:~# gdb -q --args vgremove raid1
Reading symbols from vgremove...Reading symbols from 
/usr/lib/debug/.build-id/e2/859cb481b1f0a843f9d2667c790dba3f2fc901.debug...done.
done.
(gdb) run
Starting program: /sbin/vgremove raid1
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
__strchr_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strchr-sse2-bsf.S:97
97  ../sysdeps/i386/i686/multiarch/strchr-sse2-bsf.S: Datei oder 
Verzeichnis nicht gefunden.
(gdb) set width 0
(gdb) set pagination off
(gdb) directory /home/benutzer/source/lvm2/orig/lvm2-2.02.168/libdaemon/client
Source directories searched: 
/home/benutzer/source/lvm2/orig/lvm2-2.02.168/libdaemon/client:$cdir:$cwd
(gdb) directory /home/benutzer/source/lvm2/orig/lvm2-2.02.168/lib
(gdb) bt
#0  __strchr_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strchr-sse2-bsf.S:97
#1  0x0050b29f in config_make_nodes_v (cft=0x64fae0, parent=0x0, 
pre_sib=0x64fd48, ap=0xb92c "\365\nP") at config-util.c:248
#2  0x0050c5f7 in daemon_request_extend_v (r=..., ap=0xb90c "\354\224U") at 
daemon-client.c:218
#3  0x004fe622 in _lvmetad_send (cmd=0x606840, id=) at 
cache/lvmetad.c:435
#4  0x00500b6c in lvmetad_vg_remove_pending (vg=0x66aa28) at 
cache/lvmetad.c:1304
#5  0x004b366c in vg_remove_direct (vg=0x66aa28) at metadata/metadata.c:571
#6  0x004b3d3c in 

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)

--- 

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);
 
@@ -226,6 +226,7 @@ voi

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#968606: vte: Racy NULL-ptr segfault in vte::terminal::update_repeat_timeout()

[Bernhard Übelacker]

Control: fixed -1 vte2.91/0.62.1-1


Hello,
marking fixed as mentioned in message by submitter to upstream bug [1].

Kind regards,
Bernhard

[1] https://gitlab.gnome.org/GNOME/vte/-/issues/270#note_1037042

Bug#981128: libgmsh4: SIGABRT in dolfinx demo from gmsh polynomialBasis via Eigen::compute_inverse

[Bernhard Übelacker]

Am 14.02.21 um 11:37 schrieb Drew Parsons:
The dolfinx comments go on to say you might want to set 64 for 
user-compilation on AVX-512 systems. Would that AVX comment apply to 
your specific system?



Hello Drew,
my specific system is an amd64 kvm/qemu VM running at a AMD Ryzen 1700.
So as far as I see there is no avx512, just avx and avx 2 from lscpu.

But by using dpkg-buildpackage I was under the impression that the produced
binaries are for Debian baseline and not optimized for my CPU.
Also there is no -march visible when building with dpkg-buildpackage.


So from python side the abort happens here:
(gdb) py-bt
Traceback (most recent call first):
  File "/usr/lib/python3/dist-packages/gmsh.py", line 2256, in 
getElementProperties
api_wantedOrientations_, api_wantedOrientations_n_,
  File "/usr/share/dolfinx/demo-python/gmsh/demo_gmsh.py", line 39, in 
name, dim, order, num_nodes, local_coords, num_first_order_nodes = 
model.mesh.getElementProperties(element_types[0])


I tested also to build libgmsh4 with this change:
-DEIGEN_INC:STRING="/usr/include/eigen3" \
-DEIGEN_MAX_ALIGN_BYTES=32

Then demo_gmsh.py gets over line 39 but still gives later
another python backtrace in line 62.


So from my limited point of view (as I don't really know much about these 
packages),
I still guess either all (might not just affect gmsh and dolphinx?)
have to build with the same alignment or
somehow allocation and deallocation have to take place
at the same side of the shared library boundary.

Kind regards,
Bernhard

Bug#981128: libgmsh4: SIGABRT in dolfinx demo from gmsh polynomialBasis via Eigen::compute_inverse

[Bernhard Übelacker]

This flag is already in use, see https://salsa.debian.org/science-team/gmsh/-/
blob/master/debian/rules#L34




Hello everyone,
the ENABLE_SYSTEM_CONTRIB=1 seems not to be sufficient.

The build log shows this line:
-- Found Eigen
With this include given to c++:
-I/home/benutzer/source/libgmsh4/try2/gmsh-4.7.1+ds1/contrib/eigen

But in CMakeLists.txt we find these lines:
if(ENABLE_SYSTEM_CONTRIB)
find_path(EIGEN_INC "Eigen/Dense" HINTS eigen3)
if(EIGEN_INC)
include_directories(${EIGEN_INC})
set_config_option(HAVE_EIGEN "Eigen[system]")
endif()
endif()
if(NOT HAVE_EIGEN)
include_directories(contrib/eigen)
set_config_option(HAVE_EIGEN "Eigen")
endif()

Therefore it seems if it is not found in the system
and therefore it falls back to contrib.


Adding following to debian/rules:
-DEIGEN_INC:STRING="/usr/include/eigen3"

Would show this with an attempt to dpkg-buildpackage:
-- Found Eigen[system]
With this include given to c++:
-I/usr/include/eigen3


If its not desired to give the path directly maybe somehow retrieved by:
$ pkg-config --cflags eigen3
-I/usr/include/eigen3




But I built a package with that change, but the error remained.

So I rebuilt also dolfinx and saw that it gives to c++ this parameter:
"-DEIGEN_MAX_ALIGN_BYTES=32"
This define might change EIGEN_DEFAULT_ALIGN_BYTES,
and this controls how allocation is done inside
aligned_malloc/aligned_free.

Shouldn't either both have to override the default here
or both stay to the default?


Kind regards,
Bernhard

Bug#981128: libgmsh4: SIGABRT in dolfinx demo from gmsh polynomialBasis via Eigen::compute_inverse

[Bernhard Übelacker]

Am 12.02.21 um 16:06 schrieb Drew Parsons:


That could be the mismatch, if gmsh used its own copy of eigen different 
from 3.3.9.  Alternatively if libdolfinx-dev was built against an older 
version of eigen then it might make a discrepancy.


Dolfinx has just been updated in unstable. Bernhard, you could check if 
the rebuild for this new version fixes your problem.  But likely we'll 
want to apply Christophe's flag to the gmsh build.


Drew




Hello Drew,
I updated just all dolfinx packages to 2019.2.0~git20210130.c14cb0a-3.
(That drew updates for libbasix0 and libpetsc.)

But the fault does appear there too.

Kind regards,
Bernhard




# dpkg -l | grep -E "dolfinx|eigen3|gmsh" | LANG=C sort -k3b,3b -k2b,2b
ii  dolfinx-doc2019.2.0~git20210130.c14cb0a-3 all   
   Documentation and demo programs for DOLFIN
ii  libdolfinx-dev 2019.2.0~git20210130.c14cb0a-3 all   
   Shared links and header files for DOLFIN
ii  libeigen3-dev  3.3.9-2all   
   lightweight C++ template library for linear algebra
ii  gmsh   4.7.1+ds1-2amd64 
   Three-dimensional finite element mesh generator


$ python3 /usr/share/dolfinx/demo-python/gmsh/demo_gmsh.py
double free or corruption (out)
[debian:89745] *** Process received signal ***

(rr) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7f5a72be4537 in __GI_abort () at abort.c:79
#2  0x7f5a72c3d768 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7f5a72d4be31 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x7f5a72c44a5a in malloc_printerr (str=str@entry=0x7f5a72d4e210 "double free 
or corruption (out)") at malloc.c:5347
#4  0x7f5a72c46088 in _int_free (av=0x7f5a72d7db80 , p=0x1df8070, 
have_lock=) at malloc.c:4314
#5  0x7f5a6304fad8 in Eigen::internal::aligned_free (ptr=) 
at ./contrib/eigen/Eigen/src/Core/util/Memory.h:177
#6  Eigen::internal::conditional_aligned_free (ptr=) at 
./contrib/eigen/Eigen/src/Core/util/Memory.h:230
#7  Eigen::internal::conditional_aligned_delete_auto (size=, ptr=) at ./contrib/eigen/Eigen/src/Core/util/Memory.h:416
#8  Eigen::DenseStorage::~DenseStorage (this=0x7ffc1434ab18, 
__in_chrg=) at ./contrib/eigen/Eigen/src/Core/DenseStorage.h:542

Bug#981128: libgmsh4: SIGABRT in dolfinx demo from gmsh polynomialBasis via Eigen::compute_inverse

[Bernhard Übelacker]

Am 12.02.21 um 12:12 schrieb Drew Parsons:

Version mismatch could cause problems.

Bernhard, can you provide the versions of each of the packages you're 
reporting on

(dolfinx, eigen3, gmsh) ?


Hello,
these are the versions I have used in this test VM.

Would it be possible that libgmsh should use
the Memory.h below /usr instead of ./contrib ?

Kind regards,
Bernhard


# dpkg -l | grep -E "dolfinx|eigen3|gmsh" | LANG=C sort -k3b,3b -k2b,2b
ii  dolfinx-doc2019.2.0~git20201109.17bda9f-6 all   
   Documentation and demo programs for DOLFIN
ii  libdolfinx-dev 2019.2.0~git20201109.17bda9f-6 all   
   Shared links and header files for DOLFIN
ii  libdolfinx-real-dev:amd64  2019.2.0~git20201109.17bda9f-6 amd64 
   Shared links and header files for DOLFIN (real numbers)
ii  libdolfinx-real2019.2-dbgsym:amd64 2019.2.0~git20201109.17bda9f-6 amd64 
   debug symbols for libdolfinx-real2019.2
ii  libdolfinx-real2019.2:amd642019.2.0~git20201109.17bda9f-6 amd64 
   Shared libraries for DOLFIN
ii  python3-dolfinx-real   2019.2.0~git20201109.17bda9f-6 amd64 
   Python interface for DOLFIN (Python 3)
ii  python3-dolfinx:amd64  2019.2.0~git20201109.17bda9f-6 amd64 
   Python interface for DOLFIN (Python 3)
ii  libeigen3-dev  3.3.9-2all   
   lightweight C++ template library for linear algebra
ii  gmsh   4.7.1+ds1-2amd64 
   Three-dimensional finite element mesh generator
ii  gmsh-doc   4.7.1+ds1-2all   
   Three-dimensional finite element mesh generator documentation
ii  libgmsh4-dbgsym:amd64  4.7.1+ds1-2amd64 
   debug symbols for libgmsh4
ii  libgmsh4:amd64 4.7.1+ds1-2amd64 
   Three-dimensional finite element mesh generator shared library
ii  python3-gmsh   4.7.1+ds1-2all   
   Three-dimensional finite element mesh generator Python 3 wrapper

Bug#981128: libgmsh4: SIGABRT in dolfinx demo from gmsh polynomialBasis via Eigen::compute_inverse

[Bernhard Übelacker]

Dear Maintainer,
I tried to have a look at this issue and I saw
that the allocation takes place inside libdolfinx_real.so.2019.2,
inside /usr/include/eigen3/Eigen/src/Core/util/Memory.h.

But the failing free is done in libgmsh.so.4.7,
which uses ./contrib/eigen/Eigen/src/Core/util/Memory.h.

There seem to be a disagreement if the allocator is
already returning aligned addresses,
therefore one uses handmade_aligned_malloc,
but the free uses directly std::free() instead handmade_aligned_free.

Might this cause the issue?

Kind regards,
Bernhard


Allocation:
(rr) bt
#0  0x7f2860acc19d in __GI___libc_malloc (bytes=) at 
malloc.c:3082
#1  0x7f285e7d2bdb in Eigen::internal::handmade_aligned_malloc 
(size=16) at /usr/include/eigen3/Eigen/src/Core/util/Memory.h:88
#2  Eigen::internal::aligned_malloc (size=16) at 
/usr/include/eigen3/Eigen/src/Core/util/Memory.h:164
#3  Eigen::internal::conditional_aligned_malloc (size=16) at 
/usr/include/eigen3/Eigen/src/Core/util/Memory.h:214
#4  Eigen::internal::conditional_aligned_new_auto (size=4) at 
/usr/include/eigen3/Eigen/src/Core/util/Memory.h:374
#5  Eigen::DenseStorage::resize (rows=4, size=4, 
this=0x7ffe74198f58) at /usr/include/eigen3/Eigen/src/Core/DenseStorage.h:557
...

Free:
(rr) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7f2860a67537 in __GI_abort () at abort.c:79
#2  0x7f2860ac0768 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7f2860bcee31 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x7f2860ac7a5a in malloc_printerr (str=str@entry=0x7f2860bd1210 "double 
free or corruption (out)") at malloc.c:5347
#4  0x7f2860ac9088 in _int_free (av=0x7f2860c00b80 , p=0x23cb2f0, 
have_lock=) at malloc.c:4314
#5  0x7f2851183ad8 in Eigen::internal::aligned_free (ptr=) at ./contrib/eigen/Eigen/src/Core/util/Memory.h:177
#6  Eigen::internal::conditional_aligned_free (ptr=) 
at ./contrib/eigen/Eigen/src/Core/util/Memory.h:230
#7  Eigen::internal::conditional_aligned_delete_auto (size=, ptr=) at ./contrib/eigen/Eigen/src/Core/util/Memory.h:416
#8  Eigen::DenseStorage::~DenseStorage (this=0x7ffe74198f58, 
__in_chrg=) at ./contrib/eigen/Eigen/src/Core/DenseStorage.h:542
...


# Bullseye amd64 qemu VM 2021-02-11


apt update
apt dist-upgrade


apt install systemd-coredump valgrind mc rr gdb dolfinx-doc python3-gmsh
apt build-dep libc6
apt install libgmsh4-dbgsym libdolfinx-real2019.2-dbgsym

echo 1 > /proc/sys/kernel/perf_event_paranoid






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

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







$ rr record python3 /usr/share/dolfinx/demo-python/gmsh/demo_gmsh.py
rr: Saving execution to trace directory 
`/home/benutzer/.local/share/rr/python3-0'.
double free or corruption (out)

Loguru caught a signal: SIGABRT
Abgebrochen



$ rr replay python3-0
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
Copyright (C) 2021 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/python3.9...
(No debugging symbols found in /usr/bin/python3.9)
Really redefine built-in command "restart"? (y or n) [answered Y; input not 
from terminal]
Remote debugging using 127.0.0.1:22636
Reading symbols from /lib64/ld-linux-x86-64.so.2...
Reading symbols from 
/usr/lib/debug/.build-id/5b/e47e85c990f390b0dccb6ca9dc3e70f410dc6a.debug...
0x7f2860de8090 in _start () from /lib64/ld-linux-x86-64.so.2
(rr) directory /home/benutzer/source/libc6/orig/glibc-2.31/malloc
Source directories searched: 
/home/benutzer/source/libc6/orig/glibc-2.31/malloc:$cdir:$cwd
(rr) directory /home/benutzer/source/libgmsh4/orig/gmsh-4.7.1+ds1
Source directories searched: 
/home/benutzer/source/libgmsh4/orig/gmsh-4.7.1+ds1:/home/benutzer/source/libc6/orig/glibc-2.31/malloc:$cdir:$cwd
(rr) set width 0
(rr) set pagination off
(rr) cont
Continuing.
double free or corruption (out)
[New Thread 10825.10830]
[New Thread 10825.10831]

Thread 1 received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50return ret;
(rr) when
Current event: 16792
(rr) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  

Bug#980103: smb4k no more starting

[Bernhard Übelacker]

Hello Hans,
great that it works.



So I suppose, we should and could safely close this bug.


This can be achieved by sending the
mail to 980103-d...@bugs.debian.org.
(I hope this is ok with smb4k maintainers.)



Best regards, thank you very much again and stay healthy!


Thank you, the same to you.

Kind regards,
Bernhard

Bug#980103: smb4k no more starting

[Bernhard Übelacker]

Hello Hans,

However, no icon. Smb4k is starting, then crashing. There is also no 
process running which is named smb4k or similar.


Ah, ok, from the description I was under the impression the process is 
running but not showing a window.


So what does it write to the konsole when started from the command line?

Is there some output added to dmesg when the process is gone:
# dmesg -T | tail

Further steps could be to install systemd-coredump and look
at the end of the journal when the process is gone - it could
contain already a backtrace.
# journalctl -e

There are several ways to get more or improved
information described here:
https://wiki.debian.org/HowToGetABacktrace

Kind regards,
Bernhard

Bug#980103: smb4k no more starting

[Bernhard Übelacker]

Hello Hans,
(please leave the bug address in the CC field
to add the information in the bug too.)


I did not mean in the taskbar, I meant the systemtray near the clock.
Please see the green marks in the picture below.

Kind regards,
Bernhard






Am 06.02.21 um 13:03 schrieb Hans:

Am Samstag, 6. Februar 2021, 11:46:25 CET schrieben Sie:
Hi Bernhard,

tried as you told, but sorry: No icon in te taskbar.
The aplication is just stopping at start.

Please remember, I am running debian/testing, so maybe it is a problem with
some environmemt (newer libs or the change to python3 whatever).

Tried to start smb4k with strace, but also got no usefull information.

Best regards

Hans

Bug#980103: smb4k no more starting

[Bernhard Übelacker]

Hello Hans,
I had also used smb4k some months/years ago, so I tried to start it now.

I also got no entry in the window list, but I got a symbol in the system 
tray near the clock. It was kind of hidden as there are already plenty 
icons I had to extend the system tray via the triangle (plasma desktop).
Clicking there on the smb4k icon made the main window visible and the 
entry in the window list appear. Clicking again on that symbol makes the 
window hide and the entry disappears from the window list.


Could you try if this is the issue in your case too?

Kind regards,
Bernhard

Bug#980946: qemu-system-x86: qemu VM with vga virtio fails spice assertion at reboot, sometimes

[Bernhard Übelacker]

Package: qemu-system-x86
Version: 1:5.2+dfsg-3
Severity: normal
X-Debbugs-Cc: bernha...@mailbox.org

Dear Maintainer,
I was playing around with a qemu VM with a virtio vga to see
how far I could get with accelerated graphics inside a VM.
I was watching the VM via remote-viewer.

But on several reboots of the VM I received this message:

qemu-system-x86_64: Spice: red-qxl.c:706:spice_qxl_gl_scanout: condition 
`qxl_state->gl_draw_cookie == GL_DRAW_COOKIE_INVALID' failed

Then the VM aborts in spice_logv.

I attached then a debugger before that point and got the
following stack where we reach that assert.
(The spice_backtrace function did output nothing.)

Below is the used command of qemu and remote-viewer.

When I tried to reboot without a remote-viewer attached I
did not receive that assert on a few reboots.

Kind regards,
Bernhard






(gdb) bt
#0  spice_backtrace () at backtrace.c:126
#1  0x7fc8b87d2653 in spice_logv (log_domain=0x7fc8b8838291 "Spice", args=0x7f080ba0, format=0x7fc8b8839160 
"condition `%s' failed", function=0x7fc8b8842010 <__FUNCTION__.6> "spice_qxl_gl_scanout", 
strloc=0x7fc8b8841eaf "red-qxl.c:706", log_level=G_LOG_LEVEL_CRITICAL, log_domain=0x7fc8b8838291 "Spice") at 
log.c:55
#2  spice_log (log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, strloc=strloc@entry=0x7fc8b8841eaf 
"red-qxl.c:706", function=function@entry=0x7fc8b8842010 <__FUNCTION__.6> 
"spice_qxl_gl_scanout", format=format@entry=0x7fc8b8839160 "condition `%s' failed") at log.c:69
#3  0x7fc8b87a0861 in spice_qxl_gl_scanout (qxl=qxl@entry=0x55aed2cbf0e8, 
fd=fd@entry=-1, width=width@entry=0, height=height@entry=0, 
stride=stride@entry=0, format=format@entry=0, y_0_top=0) at red-qxl.c:706
#4  0x55aed05643ac in qemu_spice_gl_scanout_disable (dcl=0x55aed2cbf0a8) at 
../../ui/spice-display.c:919
#5  0x55aed04ea4d1 in virtio_gpu_virgl_reset (g=g@entry=0x55aed25eee40) at 
../../hw/display/virtio-gpu-3d.c:601
#6  0x55aed063cac8 in virtio_gpu_reset (vdev=0x55aed25eee40) at 
../../hw/display/virtio-gpu.c:1154
#7  0x55aed07ddcf2 in virtio_reset (opaque=0x55aed25eee40) at 
../../hw/virtio/virtio.c:2001
#8  0x55aed05dafa7 in virtio_bus_reset (bus=bus@entry=0x55aed25de108) at 
../../hw/virtio/virtio-bus.c:95
#9  0x55aed06b1b50 in virtio_pci_reset (qdev=) at 
../../hw/virtio/virtio-pci.c:1870
#10 0x55aed05e5a1f in virtio_vga_base_reset (dev=0x55aed25d6000) at 
../../hw/display/virtio-vga.c:164
#11 0x55aed0934be2 in resettable_phase_hold (obj=0x55aed25d6000, opaque=, type=) at ../../hw/core/resettable.c:182
#12 0x55aed092faa4 in bus_reset_child_foreach (obj=, 
cb=0x55aed0934b00 , opaque=0x0, type=RESET_TYPE_COLD) at 
../../hw/core/bus.c:97
#13 0x55aed0934b9c in resettable_child_foreach (type=RESET_TYPE_COLD, opaque=0x0, 
cb=0x55aed0934b00 , obj=0x55aed2199e40, 
rc=0x55aed17343f0) at ../../hw/core/resettable.c:96
#14 resettable_phase_hold (obj=0x55aed2199e40, opaque=, 
type=RESET_TYPE_COLD) at ../../hw/core/resettable.c:173
#15 0x55aed093215b in device_reset_child_foreach (obj=, 
cb=0x55aed0934b00 , opaque=0x0, type=RESET_TYPE_COLD) at 
../../hw/core/qdev.c:376
#16 0x55aed0934b9c in resettable_child_foreach (type=RESET_TYPE_COLD, opaque=0x0, 
cb=0x55aed0934b00 , obj=0x55aed2198dd0, 
rc=0x55aed16f3db0) at ../../hw/core/resettable.c:96
#17 resettable_phase_hold (obj=0x55aed2198dd0, opaque=, 
type=RESET_TYPE_COLD) at ../../hw/core/resettable.c:173
#18 0x55aed092faa4 in bus_reset_child_foreach (obj=, 
cb=0x55aed0934b00 , opaque=0x0, type=RESET_TYPE_COLD) at 
../../hw/core/bus.c:97
#19 0x55aed0934b9c in resettable_child_foreach (type=RESET_TYPE_COLD, opaque=0x0, 
cb=0x55aed0934b00 , obj=0x55aed189a720, 
rc=0x55aed17f1710) at ../../hw/core/resettable.c:96
#20 resettable_phase_hold (obj=obj@entry=0x55aed189a720, 
opaque=opaque@entry=0x0, type=type@entry=RESET_TYPE_COLD) at 
../../hw/core/resettable.c:173
#21 0x55aed0934f21 in resettable_assert_reset 
(obj=obj@entry=0x55aed189a720, type=type@entry=RESET_TYPE_COLD) at 
../../hw/core/resettable.c:60
#22 0x55aed09354d0 in resettable_reset (type=RESET_TYPE_COLD, 
obj=0x55aed189a720) at ../../hw/core/resettable.c:45
#23 resettable_cold_reset_fn (opaque=0x55aed189a720) at 
../../hw/core/resettable.c:269
#24 0x55aed093450d in qemu_devices_reset () at ../../hw/core/reset.c:69
#25 0x55aed06edf8b in pc_machine_reset (machine=) at 
../../hw/i386/pc.c:1615
#26 0x55aed0864e4d in qemu_system_reset 
(reason=reason@entry=SHUTDOWN_CAUSE_GUEST_RESET) at ../../softmmu/vl.c:1405
#27 0x55aed0865039 in main_loop_should_exit () at ../../softmmu/vl.c:1640
#28 0x55aed086574c in qemu_main_loop () at ../../softmmu/vl.c:1674
#29 0x55aed04bf29e in main (argc=, argv=, 
envp=) at ../../softmmu/main.c:50
(gdb)

(gdb) print qxl_state
$1 = (QXLState *) 0x55aed34b96f0
(gdb) print *qxl_state
$2 = {qxl_worker = {minor_version = 3, major_version = 3, wakeup = 0x7fc8b879fb00 , oom = 0x7fc8b879fb60 , start = 0x7fc8b879fce0 
, stop 

Bug#974937: evince: crashes then runs

[Bernhard Übelacker]

Dear Maintainer,
I am sorry but I missed the offset of 42 in the kernel output,
which shows 42 bytes before the crashing instruction marked with "< >".
The location where the crash happened would therefore
not be in line 351, instead it would be in 355.

   0x00438186 <+102>:   push   0x14(%ebp)

That matches also the last three digits in ip value in the kernel output.

Then, based on the 0x14, the assumption would be that the priv
pointer might have contained an invalid value.
The segfaulting address is at 0xfdd4 kind of near 0.
Therefore might here private pointer "below" the ev_recent_view pointer by 
0x240,
and ev_recent_view be a null pointer in this crash?

But still a proper backtrace would be helpful.

Kind regards,
Bernhard


https://gitlab.gnome.org/GNOME/evince/-/blob/master/shell/ev-recent-view.c#L355

355 gnome_desktop_thumbnail_factory_save_thumbnail 
(priv->thumbnail_factory,
356 thumbnail, data->uri, 
data->mtime);

(gdb) print &((EvRecentViewPrivate *)0)->thumbnail_factory
$2 = (GnomeDesktopThumbnailFactory **) 0x14

Bug#974937: evince: crashes then runs

[Bernhard Übelacker]

Dear Maintainer,
from the dmesg line from the submitter I think the crash happens
save_thumbnail_in_cache_thread in [1], between the calls to
cairo_image_surface_get_height and -width.

Tried to reach that function just showing some random PDF
but did not get there.

@Nicolas: I assume Simon asked for a backtrace of the crash.
There are several ways described in the link in his last mail.
The easiest might be to install systemd-coredump and when
the next crash happens look at the end of the output
of 'journalctl --no-pager'.

Kind regards,
Bernhard

[1] 
https://gitlab.gnome.org/GNOME/evince/-/blob/master/shell/ev-recent-view.c#L351


# Bullseye/testing i386 qemu VM 2020-12-18


apt update
apt dist-upgrade


apt install systemd-coredump gnome gdb evince libgdk-pixbuf2.0-0


systemctl stop sddm
systemctl start sddm


wget 
https://snapshot.debian.org/archive/debian/20201013T145646Z/pool/main/e/evince/evince_3.38.0-2_i386.deb
wget 
https://snapshot.debian.org/archive/debian/20201013T145646Z/pool/main/e/evince/evince-common_3.38.0-2_all.deb
wget 
https://snapshot.debian.org/archive/debian/20201013T145646Z/pool/main/e/evince/libevdocument3-4_3.38.0-2_i386.deb
wget 
https://snapshot.debian.org/archive/debian/20201013T145646Z/pool/main/e/evince/libevview3-3_3.38.0-2_i386.deb
wget 
https://snapshot.debian.org/archive/debian-debug/20201013T145001Z/pool/main/e/evince/evince-dbgsym_3.38.0-2_i386.deb
wget 
https://snapshot.debian.org/archive/debian/20201013T145646Z/pool/main/e/evince/gir1.2-evince-3.0_3.38.0-2_i386.deb
dpkg -i *.deb

cd Dokumente/
wget https://www.debian.org/doc/manuals/debian-faq/debian-faq.de.pdf



https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash



nov. 16 20:33:38 nicolas.home kernel: pool-evince[16278]: segfault at fdd4 
ip 004de186 sp afbfa034 error 5 in evince[4cd000+3a000]
nov. 16 20:33:38 nicolas.home kernel: Code: 89 34 24 89 44 24 1c e8 b8 08 ff ff 
8b 54 24 1c 89 14 24 50 6a 00 6a 00 56 e8 06 19 ff ff 83 c4 20 ff 77 08 ff 77 
04 89 c6 50  75 14 e8 52 06 ff ff 89 34 24 e8 b2 3f ff ff 58 5a 6a 01 ff 74

"error 5" == 0b0101 == 
 *   bit 0 ==1: protection fault
 *   bit 1 ==0: read access
 *   bit 2 ==1: user-mode access


benutzer@debian:~$  echo -n "find /b ..., ..., 0x" && \
echo "89 34 24 89 44 24 1c e8 b8 08 ff ff 8b 54 24 1c 89 14 24 50 6a 00 6a 00 
56 e8 06 19 ff ff 83 c4 20 ff 77 08 ff 77 04 89 c6 50  75 14 e8 52 06 ff ff 
89 34 24 e8 b2 3f ff ff 58 5a 6a 01 ff 74" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'
find /b ..., ..., 0x89, 0x34, 0x24, 0x89, 0x44, 0x24, 0x1c, 0xe8, 0xb8, 0x08, 
0xff, 0xff, 0x8b, 0x54, 0x24, 0x1c, 0x89, 0x14, 0x24, 0x50, 0x6a, 0x00, 0x6a, 
0x00, 0x56, 0xe8, 0x06, 0x19, 0xff, 0xff, 0x83, 0xc4, 0x20, 0xff, 0x77, 0x08, 
0xff, 0x77, 0x04, 0x89, 0xc6, 0x50, 0xff, 0x75, 0x14, 0xe8, 0x52, 0x06, 0xff, 
0xff, 0x89, 0x34, 0x24, 0xe8, 0xb2, 0x3f, 0xff, 0xff, 0x58, 0x5a, 0x6a, 0x01, 
0xff, 0x74


gdb -q
set width 0
set pagination off
set environment DISPLAY=:0
file /usr/bin/evince
tb main
run
info target
...
0x0042c150 - 0x00460924 is .text
...

(gdb) find /b 0x0042c150, 0x00460924, 0x89, 0x34, 0x24, 0x89, 0x44, 0x24, 0x1c, 
0xe8, 0xb8, 0x08, 0xff, 0xff, 0x8b, 0x54, 0x24, 0x1c, 0x89, 0x14, 0x24, 0x50, 
0x6a, 0x00, 0x6a, 0x00, 0x56, 0xe8, 0x06, 0x19, 0xff, 0xff, 0x83, 0xc4, 0x20, 
0xff, 0x77, 0x08, 0xff, 0x77, 0x04, 0x89, 0xc6, 0x50, 0xff, 0x75, 0x14, 0xe8, 
0x52, 0x06, 0xff, 0xff, 0x89, 0x34, 0x24, 0xe8, 0xb2, 0x3f, 0xff, 0xff, 0x58, 
0x5a, 0x6a, 0x01, 0xff, 0x74
0x43815c 
1 pattern found.

(gdb) b *0x43815c
Breakpoint 2 at 0x43815c: file ../shell/ev-recent-view.c, line 351.
(gdb) info b
Num Type   Disp Enb AddressWhat
2   breakpoint keep y   0x0043815c in save_thumbnail_in_cache_thread at 
../shell/ev-recent-view.c:351


(gdb) disassemble save_thumbnail_in_cache_thread
Dump of assembler code for function save_thumbnail_in_cache_thread:
   0x00438120 <+0>: push   %ebp
   0x00438121 <+1>: push   %edi
   0x00438122 <+2>: push   %esi
   0x00438123 <+3>: push   %ebx
   0x00438124 <+4>: call   0x42c780 <__x86.get_pc_thunk.bx>
   0x00438129 <+9>: add$0x57a2f,%ebx
   0x0043812f <+15>:sub$0x1c,%esp
   0x00438132 <+18>:mov0x38(%esp),%edi
   0x00438136 <+22>:call   0x42af10 
   0x0043813b <+27>:mov0x181c(%ebx),%ebp
   0x00438141 <+33>:sub$0x8,%esp
   0x00438144 <+36>:add0x3c(%esp),%ebp
   0x00438148 <+40>:push   %eax
   0x00438149 <+41>:push   0x14(%edi)
   0x0043814c <+44>:call   0x427df0 
   0x00438151 <+49>:mov0x4c(%eax),%esi
   0x00438154 <+52>:mov%esi,(%esp)
   0x00438157 <+55>:call   0x42aa00 
   0x0043815c <+60>:mov%esi,(%esp)

   0x0043815f <+63>:mov%eax,0x1c(%esp)
   0x00438163 <+67>:call   0x428a20 
   0x00438168 <+72>:mov0x1c(%esp),%edx
   0x0043816c <+76>:mov%edx,(%esp)
   0x0043816f <+79>:push   %eax
   0x00438170 

Bug#976102: a2ps 32-bit segfaults on startup

[Bernhard Übelacker]

Am 15.12.20 um 23:00 schrieb Mack Stanley:

Dear Bernhard,

Thanks so much for your interest and your message.  I very recently 
realized that my bug report is in error and hoped that I would be able 
to correct or withdraw it before troubling anyone.


Here is how to reproduce the segfault I observed (in wither 32 or 64 bit 
debian a2ps):


Near the top of /etc/a2ps-site.cfg comment out one or both of the lines
_

Options: --encoding=latin1
Options: --medium=libpaper
_

Then just execute

a2ps

The result will be a crash with simply

Segmentation Fault

---

I am very sorry to have filed a false bug report.  I had tried two 32 
bit installations and one 64 bit.  Evidently I made the same mistake in 
both 32 bit installations: I must have installed with an old Fedora 
a2ps-site.cfg already in /etc/ , which the Debian installation politely 
refused to overwrite.  The default Fedora a2ps-site.cfg  has those two 
lines as


#Options: --encoding=latin1
Options: --medium=_glibc

After removing "#" from the first line, the debian build a2ps complains 
helpfully about the second line.  But with the "#" it just segfaults.


I am sorry it took me so long to find this mistake.  It wasn't till I 
built 32 bit a2ps from the GNU source that I saw the problem 
(http://ftp.gnu.org/gnu/a2ps/a2ps-4.14.tar.gz./configure --prefix=/usr 
--with-gnu-gettext --with-medium=letter ).


It would be nice if a2ps itself had been more forthcoming about my 
mistake rather than segfaulting.  But it was just that---my mistake.


Again, my apologies for wasting your time and my thanks for your interest.

Best regards, Mack




Hello Mack,
no problem, with these great details I could collect these backtraces:


# With: #Options: --encoding=latin1

(gdb) bt
#0  __strlen_sse2_bsf () at 
../sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S:50
#1  0x0050bfcc in strlower (string=0x0) at routines.c:95
#2  0x005096cd in get_encoding_by_alias (job=0x57bc50, alias=0x0) at 
encoding.c:1207
#3  0x0050aa50 in a2ps_job_finalize (job=0x57bc50) at jobs.c:305
#4  0x004ef980 in main (argc=, argv=) at 
main.c:1025
(gdb)


# With: #Options: --medium=libpaper

(gdb) bt
#0  __strcasecmp_l_sse4_2 () at 
../sysdeps/i386/i686/multiarch/strcmp-sse4.S:229
#1  0x0050e22a in a2ps_get_medium (job=0xb1ec50, name=0x0) at media.c:164
#2  0x0050ea6c in a2ps_job_finalize (job=0xb1ec50) at jobs.c:312
#3  0x004f3980 in main (argc=, argv=) at 
main.c:1025
(gdb)


As you mentioned some relation to fedora I made a short
search and it looks like there are some patches used,
which are not yet upstreamed.

https://src.fedoraproject.org/rpms/a2ps/tree/
https://git.savannah.gnu.org/cgit/a2ps.git/log/

Especially the a2ps-4.13b-encoding.patch and
a2ps-4.13-glibcpaper.patch seem related.

Kind regards,
Bernhard



apt install systemd-coredump gdb a2ps a2ps-dbgsym
zcat /usr/share/doc/a2ps/README.gz | a2ps
coredumpctl list
coredumpctl gdb 2478

https://sources.debian.org/src/a2ps/1:4.14-5/lib/jobs.c/#L305

Bug#975977: tor generates invalid adress for hiddenservice when runninf on armv5tel architectures

[Bernhard Übelacker]

Hello Peter,

Am 16.12.20 um 11:08 schrieb Peter Palfrader:

Hi Bernhard!



Can you try to rebuild tor with __attribute__((aligned(8))) for the
keccak_state as suggested in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975977#44
and then let us know if the issue is still there?



I rebuilt the tor package with this change [1] below (I hope I
placed it correctly).

With this I found "disassemble /r keccak_finalize" produces the
exact same instructions, but now the pointer given to keccak_finalize
seems to be aligned at a 8 byte boundary.

Now the strd placed at armv5tel the same sequence as
on armv7 to the "a" member [3].

And I guess hostname contains now the expected value:

$ cat hs/hostname
upxkcswnvepfls7vcy5vuixy54hlugfjnzhvl5ygfbjtm7znkyahcvad.onion

Kind regards,
Bernhard





[1]
diff --git a/src/ext/keccak-tiny/keccak-tiny.h 
b/src/ext/keccak-tiny/keccak-tiny.h
index a9c8ed6..dd26386 100644
--- a/src/ext/keccak-tiny/keccak-tiny.h
+++ b/src/ext/keccak-tiny/keccak-tiny.h
@@ -21,7 +21,7 @@ typedef struct keccak_state {
   size_t offset;
 
   uint8_t finalized : 1;

-} keccak_state;
+} __attribute__((aligned(8))) keccak_state;
 
 /* Initialize a Keccak instance suitable for SHA-3 hash functions. */

 int keccak_digest_init(keccak_state *s, size_t bits);



[2]
(gdb) bt
#0  0x005c4ac4 in xorin8 (len=136, src=, dst=) at 
../src/ext/keccak-tiny/keccak-tiny-unrolled.c:21
#1  keccak_finalize (s=s@entry=0xbeffef98) at 
../src/ext/keccak-tiny/keccak-tiny-unrolled.c:189



[3]
(gdb) stepi
0x005c4ac0  21return _le64toh(r);
1: x/i $pc
=> 0x5c4ac0 :  strdr2, [r4]
(gdb) x/8xb &((keccak_state *) 0xbeffef98)->a
0xbeffef98: 0x000x000x000x000x000x000x000x00
(gdb) stepi
0x005c4ac4  21return _le64toh(r);
1: x/i $pc
=> 0x5c4ac4 :  bhi 0x5c4a90 
(gdb) x/8xb &((keccak_state *) 0xbeffef98)->a
0xbeffef98: 0x2e0x6f0x6e0x690x6f0x6e0x200x63
(gdb) display/x $r2
2: /x $r2 = 0x696e6f2e
(gdb) display/x $r4
3: /x $r4 = 0xbeffef98

Bug#975640: fdupes: segfault when using -d -I options

[Bernhard Übelacker]

Hello Otto,
if you still can reproduce the segfault then it might
also be possible to install the package systemd-coredump.

That way a backtrace should show up in 'journalctl -e' giving
some more details of where the segfault happens.

This should get more informative if the fdupes-dbgsym gets
installed. This would be another repo described in [1].

Kind regards,
Bernhard

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

Bug#975244: xwayland: Xwayland coredump on SIGABRT in wl_proxy_destroy

[Bernhard Übelacker]

Dear Maintainer,
I tried to get a backtrace containing the source line
information from the core provided by the submitter.
It shows the backtrace below.

This backtrace leads to some upstream issues. Some
of them showing "proxy" being a null pointer.
In this case it shows 0x1 which seems causing the segfault.

Kind regards,
Bernhard


(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7f62f4bf3535 in __GI_abort () at abort.c:79
#2  0x555c2f9052ea in OsAbort () at ../../../../os/utils.c:1351
#3  0x555c2f90ae13 in AbortServer () at ../../../../os/log.c:879
#4  0x555c2f90bc79 in FatalError (f=f@entry=0x555c2f92f0d0 "Caught signal %d 
(%s). Server aborting\n") at ../../../../os/log.c:1017
#5  0x555c2f902701 in OsSigHandler (unused=, sip=, signo=11) at ../../../../os/osinit.c:156
#6  OsSigHandler (signo=11, sip=, unused=) at 
../../../../os/osinit.c:110
#7  
#8  0x7f62f5b05be1 in wl_proxy_destroy (proxy=0x1) at 
../src/wayland-client.c:523
#9  0x555c2f7ac366 in wl_callback_destroy (wl_callback=) at 
/usr/include/wayland-client-protocol.h:1154
#10 xwl_present_sync_callback (data=0x555c31bae990, callback=, 
time=) at ../../../../../hw/xwayland/xwayland-present.c:284
#11 0x7f62f4af28ee in ffi_call_unix64 () at ../src/x86/unix64.S:76
#12 0x7f62f4af22bf in ffi_call (cif=cif@entry=0x7ffec69edd30, fn=, 
rvalue=, rvalue@entry=0x0, avalue=avalue@entry=0x7ffec69ede00) at 
../src/x86/ffi64.c:525
#13 0x7f62f5b0928d in wl_closure_invoke (closure=closure@entry=0x555c317a1750, 
flags=flags@entry=1, target=, target@entry=0x555c31b9b5c0, 
opcode=opcode@entry=0, data=) at ../src/connection.c:1006
#14 0x7f62f5b05ac9 in dispatch_event (display=display@entry=0x555c3122e730, 
queue=) at ../src/wayland-client.c:1427
#15 0x7f62f5b06f94 in dispatch_queue (queue=0x555c3122e7f8, 
display=0x555c3122e730) at ../src/wayland-client.c:1573
#16 wl_display_dispatch_queue_pending (display=0x555c3122e730, 
queue=0x555c3122e7f8) at ../src/wayland-client.c:1815
#17 0x7f62f5b06fec in wl_display_dispatch_pending (display=) 
at ../src/wayland-client.c:1878
#18 0x555c2f7a1bdb in xwl_read_events (xwl_screen=0x555c3122a8c0) at 
../../../../../hw/xwayland/xwayland.c:826
#19 0x555c2f9030b1 in ospoll_wait (ospoll=0x555c3121ff90, timeout=) at ../../../../os/ospoll.c:651
#20 0x555c2f8fc0e3 in WaitForSomething (are_ready=0) at 
../../../../os/WaitFor.c:208
#21 0x555c2f8cc4bc in Dispatch () at ../../../../include/list.h:220
#22 0x555c2f8d06f6 in dix_main (argc=12, argv=0x7ffec69eede8, envp=) at ../../../../dix/main.c:276
#23 0x7f62f4bf509b in __libc_start_main (main=0x555c2f7a11c0 , argc=12, 
argv=0x7ffec69eede8, init=, fini=, rtld_fini=, stack_end=0x7ffec69eedd8) at ../csu/libc-start.c:308
#24 0x555c2f7a11fa in _start ()
(gdb)


Maybe related bugs:
https://bugs.debian.org/927852  (At least the last message from the submitter)

https://gitlab.freedesktop.org/xorg/xserver/-/issues/645
https://gitlab.freedesktop.org/xorg/xserver/-/issues/672
https://gitlab.freedesktop.org/xorg/xserver/-/issues/843


# Buster/stable amd64 qemu VM 2020-12-15


apt update
apt dist-upgrade


apt install gdb xwayland xwayland-dbgsym libwayland-client0-dbgsym


wget 
"https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=975244;filename=core.gz;msg=5;
 -O core.gz
gunzip --keep core.gz


gdb -q --core core
Core was generated by `/usr/bin/Xwayland :0 -rootless -terminate -accessx -core 
-listen 4 -listen 5 -d'.


gdb -q --core core /usr/bin/Xwayland


wget 
http://192.168.178.25:/debian-10-buster-deb.debian.org/pool/main/x/xorg-server/xwayland_1.20.4-1+deb10u1_amd64.deb
wget 
http://192.168.178.25:/debian-10-buster-deb.debian.org/pool/main/x/xorg-server/xserver-common_1.20.4-1+deb10u1_all.deb
wget 
http://192.168.178.25:/debian-10-buster-debug.deb.debian.org/pool/main/x/xorg-server/xwayland-dbgsym_1.20.4-1+deb10u1_amd64.deb
dpkg -i *.deb


benutzer@debian:~$ gdb -q --core core /usr/bin/Xwayland
Reading symbols from /usr/bin/Xwayland...(no debugging symbols found)...done.
[New LWP 10820]
[New LWP 10824]
[New LWP 10821]
[New LWP 10823]
[New LWP 10822]
[New LWP 10825]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/Xwayland :0 -rootless -terminate -accessx -core 
-listen 4 -listen 5 -d'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht 
gefunden.
[Current thread is 1 (Thread 0x7f62f40c2a80 (LWP 10820))]
(gdb) set width 0
(gdb) set pagination off
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7f62f4bf3535 in __GI_abort () at abort.c:79
#2  0x555c2f9052ea in OsAbort ()
#3  0x555c2f90ae13 in ?? ()
#4  0x555c2f90bc79 in FatalError ()
#5  0x555c2f902701 

Bug#975736: siege crashes when one of the URLs in a file contains a trailing dollar sign

[Bernhard Übelacker]

Dear Maintainer,
this crash shows the following backtrace
and leads to this upstream issue:

https://github.com/JoeDog/siege/issues/104

Kind regards,
Bernhard


(gdb) bt
#0  0x7f6066705b51 in __GI_getenv (name=name@entry=0x0) at getenv.c:39
#1  0x559b8b01a190 in evaluate (hash=hash@entry=0x559b8b8c0220, buf=0x559b8b8ad340 
"https://www.example.com/$;, buf@entry=0x559b8b8c3d20 "\220\002\214\213\233U") 
at eval.c:70
#2  0x559b8b018493 in read_cfg_file (l=l@entry=0x559b8b8c3d50, 
filename=filename@entry=0x559b8b0365dc  "a") at cfg.c:144
#3  0x559b8b011600 in __urls_setup () at main.c:375
#4  main (argc=3, argv=0x7ffeb5a66dd8) at main.c:403


# Bullseye/testing amd64 qemu VM 2020-12-15


apt update
apt dist-upgrade


apt install systemd-coredump gdb siege siege-dbgsym


cat < a
https://www.example.com/$
EOF
siege -f a



benutzer@debian:~$ siege -f a
New configuration template added to /home/benutzer/.siege
Run siege -C to view the current settings in that file
Speicherzugriffsfehler (Speicherabzug geschrieben)


root@debian:~# journalctl -e
Dez 15 15:22:54 debian kernel: siege[679]: segfault at 0 ip 7f6066705b51 sp 
7ffeb5a5bea0 error 4 in libc-2.31.so[7f60666ed000+14b000]
Dez 15 15:22:54 debian kernel: Code: ff 0f 1f 84 00 00 00 00 00 41 57 41 56 41 
55 41 54 55 53 48 83 ec 08 48 8b 05 6b 03 18 00 48 8b 18 48 85 db 0f 84 af 00 
00 00 <0f> b6 07 49 89 fd 84 c0 0f 8>
Dez 15 15:22:54 debian systemd[1]: Created slice 
system-systemd\x2dcoredump.slice.
Dez 15 15:22:54 debian systemd[1]: Started Process Core Dump (PID 684/UID 0).
Dez 15 15:22:54 debian systemd-coredump[685]: Process 679 (siege) of user 1000 
dumped core.
  
  Stack trace of thread 679:
  #0  0x7f6066705b51 getenv 
(libc.so.6 + 0x3db51)
  #1  0x559b8b01a190 n/a (siege 
+ 0x10190)
  #2  0x559b8b018493 n/a (siege 
+ 0xe493)
  #3  0x559b8b011600 n/a (siege 
+ 0x7600)
  #4  0x7f60666eed0a 
__libc_start_main (libc.so.6 + 0x26d0a)
  #5  0x559b8b0117aa n/a (siege 
+ 0x77aa)
Dez 15 15:22:54 debian systemd[1]: systemd-coredump@0-684-0.service: Succeeded.



root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Tue 2020-12-15 15:22:54 CET 679  1000  1000  11 present   /usr/bin/siege

root@debian:~# coredumpctl gdb
   PID: 679 (siege)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 11 (SEGV)
 Timestamp: Tue 2020-12-15 15:22:54 CET (1min 21s ago)
  Command Line: siege -f a
Executable: /usr/bin/siege
 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: 91f425ef4f7b47899256cfd68acbe13d
Machine ID: 33f18f39d2a9438eb75b0ed52848afcd
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.siege.1000.91f425ef4f7b47899256cfd68acbe13d.679.160804217400.zst
   Message: Process 679 (siege) of user 1000 dumped core.

Stack trace of thread 679:
#0  0x7f6066705b51 getenv (libc.so.6 + 0x3db51)
#1  0x559b8b01a190 n/a (siege + 0x10190)
#2  0x559b8b018493 n/a (siege + 0xe493)
#3  0x559b8b011600 n/a (siege + 0x7600)
#4  0x7f60666eed0a __libc_start_main (libc.so.6 + 0x26d0a)
#5  0x559b8b0117aa n/a (siege + 0x77aa)

...
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `siege -f a'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f6066705b51 in __GI_getenv (name=0x0) at getenv.c:39
39  getenv.c: Datei oder Verzeichnis nicht gefunden.
(gdb) set width 0
(gdb) set pagination off
(gdb) bt
#0  0x7f6066705b51 in __GI_getenv (name=0x0) at getenv.c:39
#1  0x559b8b01a190 in ?? ()
#2  0x559b8b018493 in ?? ()
#3  0x559b8b011600 in ?? ()
#4  0x7f60666eed0a in __libc_start_main (main=0x559b8b010a10, argc=3, 
argv=0x7ffeb5a66dd8, init=, fini=, 
rtld_fini=, stack_end=0x7ffeb5a66dc8) at ../csu/libc-start.c:308
#5  0x559b8b0117aa in ?? ()
(gdb)

# with dbgsym

(gdb) bt
#0  0x7f6066705b51 in __GI_getenv (name=name@entry=0x0) at getenv.c:39
#1  0x559b8b01a190 in evaluate (hash=hash@entry=0x559b8b8c0220, 
buf=0x559b8b8ad340 "https://www.example.com/$;, buf@entry=0x559b8b8c3d20 
"\220\002\214\213\233U") at eval.c:70
#2  0x559b8b018493 in read_cfg_file (l=l@entry=0x559b8b8c3d50, 
filename=filename@entry=0x559b8b0365dc  "a") at cfg.c:144
#3  0x559b8b011600 in __urls_setup () at main.c:375
#4  

Bug#977323: nouveau: The X session is closed, return to login screen

[Bernhard Übelacker]

Dear Maintainer,
due to having in the backtrace the same offsets from function
nouveau_pushbuf_data, I assume this is similar to the bug #975990,
which is currently assigned to the xorg package and contains now
the line information I added with the help of the dbgsym packages.

Kind regards,
Bernhard

Bug#975990: xorg: X server stop working

[Bernhard Übelacker]

Dear Maintainer,
I tried to reconstruct the line number information with
the dbgsym packages from the backtrace provided by the submitter.

This points to the assert in this line of code: [1]

There are already some other references showing a similar assert below:
  ../nouveau/pushbuf.c:723: nouveau_pushbuf_data: Assertion `kref' failed.

It might be helpful to see the related dmesg output.

Kind regards,
Bernhard



Backtrace: 
Reconstructed:
 0: Xorg (OsLookupColor+0x138) [0x5566d2ec4e88] 
0: 0x5570bd78 in OsSigHandler at ../../../../os/osinit.c:135
 1: libpthread.so.0 (funlockfile+0x50) [0x7fd0e1dfc18f] 1: 
0x7748f140 <__restore_rt>
 2: libc.so.6 (gsignal+0x141) [0x7fd0e1c5cc41]  
2: 0x772efc41 in __GI_raise at 
../sysdeps/unix/sysv/linux/internal-signals.h:86
 3: libc.so.6 (abort+0x123) [0x7fd0e1c46537]
3: 0x772d9537 in __GI_abort at abort.c:79
 4: libc.so.6 (?+0x0) [0x7fd0e1c46400]  
4: 0x772d9400 in __assert_fail_base at assert.c:83
 5: libc.so.6 (__assert_fail+0x42) [0x7fd0e1c555c2] 
5: 0x772e85c2 in __GI___assert_fail at assert.c:101
 6: libdrm_nouveau.so.2 (nouveau_pushbuf_data+0xff) [0x7fd0da9ba4df]
6: 0x7061d4df in nouveau_pushbuf_data at ../nouveau/pushbuf.c:723
 7: libdrm_nouveau.so.2 (nouveau_pushbuf_data+0x63) [0x7fd0da9ba443]
7: 0x7061d443 in nouveau_pushbuf_data at ../nouveau/pushbuf.c:715
 8: libdrm_nouveau.so.2 (nouveau_pushbuf_data+0x17f) [0x7fd0da9ba65f]   
8: 0x7061d55f in pushbuf_submit at ../nouveau/pushbuf.c:326
 9: libdrm_nouveau.so.2 (nouveau_pushbuf_data+0x597) [0x7fd0da9baed7]   
9: 0x7061d977 in pushbuf_flush at ../nouveau/pushbuf.c:401
10: libdrm_nouveau.so.2 (nouveau_pushbuf_space+0x359) [0x7fd0da9bb709] 
10: 0x7061e459 in pushbuf_refn at ../nouveau/pushbuf.c:471
11: nouveau_dri.so (nouveau_drm_screen_create+0x2053f) [0x7fd0e040ad6f]
11: 0x7608695f in PUSH_AVAIL or PUSH_REFN at 
../src/gallium/drivers/nouveau/nvc0/nvc0_winsys.h:45
12: nouveau_dri.so (nouveau_drm_screen_create+0xc87a3) [0x7fd0e055b293]
12: 0x7612ebc3 in nvc0_constbufs_validate at 
../src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c:599
13: nouveau_dri.so (nouveau_drm_screen_create+0xcb33e) [0x7fd0e05608fe]
13: 0x7613175e in nvc0_state_validate at 
../src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c:980
14: nouveau_dri.so (nouveau_drm_screen_create+0xcb477) [0x7fd0e0560ce7]
14: 0x76131897 in nvc0_state_validate_3d at 
../src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c:998
15: nouveau_dri.so (nouveau_drm_screen_create+0xccb2e) [0x7fd0e05638be]
15: 0x76132f4e in nvc0_draw_vbo at 
../src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c:1006
16: nouveau_dri.so (__driDriverGetExtensions_zink+0x233c8) [0x7fd0dfc65f48]
16: 0x758ded58 in st_draw_vbo at ../src/mesa/state_tracker/st_draw.c:266
17: nouveau_dri.so (__driDriverGetExtensions_zink+0x2621f4) [0x7fd0e00e3d04]   
17: 0x75b1db84 in _mesa_draw_arrays at ../src/mesa/main/draw.c:367
18: libglamoregl.so (glamor_create_gc+0xdff8) [0x7fd0e12d2448] 
18: 0x76f27758 in glamor_poly_fill_rect_gl at 
../../../../glamor/glamor_rects.c:148
19: Xorg (DamageRegionAppend+0x19be) [0x5566d2e49c9e]  
19: 0x5568f35e in damagePolyFillRect at 
../../../../../miext/damage/damage.c:1224
20: libglamoregl.so (glamor_pixmap_exchange_fbos+0x78d) [0x7fd0e12cf05d]   
20: 0x76f319ad in glamor_solid_boxes at 
../../../../glamor/glamor_utils.c:51
21: libglamoregl.so (glamor_pixmap_exchange_fbos+0x653) [0x7fd0e12ceaf3]   
21: 0x76f31873 in glamor_composite_rectangles at 
../../../../glamor/glamor_compositerects.c:244
22: Xorg (AddTraps+0x34af) [0x5566d2e3e71f]
22: 0x5568230f in ProcRenderFillRectangles at 
../../../../render/render.c:1414
23: Xorg (SendErrorToClient+0x354) [0x5566d2d67964]
23: 0x555ae904 in Dispatch at ../../../../dix/dispatch.c:478
24: Xorg (InitFonts+0x3b4) [0x5566d2d6b914]
24: 0x555b28d4 in dix_main at ../../../../dix/main.c:276
25: libc.so.6 (__libc_start_main+0xea) [0x7fd0e1c47cca]
25: 0x772dacca in __libc_start_main at ../csu/libc-start.c:308
26: Xorg (_start+0x2a) [0x5566d2d5573a]26: 
0x5559c73a <_start+42>



[1]
  https://sources.debian.org/src/libdrm/2.4.103-2/nouveau/pushbuf.c/#L723

[2]
  https://bugs.debian.org/977323

  Maybe similar:
  https://bugs.debian.org/929130
  

Bug#975580: packagekit: segfault at 8 ip 000055afca94a631 sp 00007fff94cece20 error 4 in packagekitd[55afca948000+24000]

[Bernhard Übelacker]

Control: forcemerge 974826 975580


Dear Maintainer,
I just noticed this issue on some devices here too,
and found it leads to the same upstream as #974826 does.
So I hope it is ok to merge them.

As far as I see this error message path triggers the segfault
because "error" is a null pointer.
The upstream links are already in #974826.

Kind regards,
Bernhard


(gdb) bt
#0  0x55f543929631 in pk_dbus_get_uid (dbus=0x55f54473c520, 
sender=sender@entry=0x7f16d4007030 ":1.42") at ../src/pk-dbus.c:81
#1  0x55f543942d5d in pk_engine_is_proxy_unchanged (pac=0x55f544738990 "", no_proxy=0x55f5447959a0 "", 
proxy_socks=0x55f5447912f0 "", proxy_ftp=0x0, proxy_https=0x55f544795820 "", proxy_http=0x0, 
sender=0x7f16d4007030 ":1.42", engine=0x55f5447121a0) at ../src/pk-engine.c:598
#2  pk_engine_set_proxy (context=0x55f54473a330, pac=, no_proxy=, proxy_socks=, proxy_ftp=0x0, proxy_https=, 
proxy_http=0x0, engine=0x55f5447121a0) at ../src/pk-engine.c:686
#3  pk_engine_daemon_method_call (connection_=, sender=sender@entry=0x7f16d4007030 ":1.42", 
object_path=object_path@entry=0x7f16d400af60 "/org/freedesktop/PackageKit", 
interface_name=interface_name@entry=0x7f16d400b780 "org.freedesktop.PackageKit", 
method_name=method_name@entry=0x7f16d4009490 "SetProxy", parameters=parameters@entry=0x7f16d4009760, 
invocation=0x55f54473a330, user_data=0x55f5447121a0) at ../src/pk-engine.c:1438
#4  0x7f16e2acef1e in call_in_idle_cb (user_data=) at 
../../../gio/gdbusconnection.c:4890
#5  0x7f16e2c4dadf in g_main_dispatch (context=0x55f54470fd30) at 
../../../glib/gmain.c:3325
#6  g_main_context_dispatch (context=0x55f54470fd30) at 
../../../glib/gmain.c:4043
#7  0x7f16e2c4de88 in g_main_context_iterate (context=0x55f54470fd30, 
block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
../../../glib/gmain.c:4119
#8  0x7f16e2c4e17b in g_main_loop_run (loop=loop@entry=0x55f54470fe20) at 
../../../glib/gmain.c:4317
#9  0x55f543928d21 in main (argc=, argv=) at 
../src/pk-main.c:242
(gdb)

(gdb) display/i $pc
1: x/i $pc
=> 0x55f543929631 :mov0x8(%rax),%r8

(gdb) print/x $rax
$1 = 0x0

(gdb) print error
$2 = (GError_autoptr) 0x0

Bug#976102: a2ps 32-bit segfaults on startup

[Bernhard Übelacker]

Hello Mack Stanley,
I am not involved in packaging a2ps, but I guess there are some more
information needed to even start investigating.

I tried several files in a VM to send to a2ps and I could
not observe a crash.

Therefore could you supply to this bug which command line is used
to trigger the crash?

If possible a link to or if small enough attaching the input you
give to a2ps?

A crash should at least have a trace in dmesg output,
could you add this?

And possibly you could install the package "systemd-cordump".
That way some more information should be written
to the journal - e.g. visible in 'journalctl -e'.

Kind regards,
Bernhard

Bug#975242: segfault on all architectures if recompiled as of today

[Bernhard Übelacker]

Dear Maintainer,
I tried to have a look and could reproduce the crash.

As far as I see a virtual method is called through a shared library
boundary and somehow returns with a wrong value in the $sp register.
Therefore an instruction in memory without executable mapping is
tried to be executed, which results in this "segfault at ... error 15".

In the same area I found following warning, which I assume is
responsible for this stackpointer error:

ProcessingMode.cxx: In member function ‘virtual int 
OpenJade_DSSSL::ProcessingMode::RootRule::compareSpecificity(const 
OpenJade_DSSSL::ProcessingMode::Rule&) const’:
ProcessingMode.cxx:332:1: warning: no return statement in function 
returning non-void [-Wreturn-type]
  332 | }
  | ^

Attached patch attempts to fill in return statements to silence these
type of warnings, but they have to be double checked. With
these patch applied the example openjade call went through without crash.

Kind regards,
Bernhard


(gdb) bt
#0  0x55b539708b08 in ?? ()
#1  0x7ff0311eaf84 in OpenJade_DSSSL::ProcessingMode::addRootRule 
(this=0x55b539708b08, expr=..., 
ruleType=OpenJade_DSSSL::ProcessingMode::constructionRule, loc=..., interp=...) 
at ProcessingMode.cxx:376
#2  0x7ff0311f25a7 in OpenJade_DSSSL::SchemeParser::doRoot 
(this=0x7ffe734576c0) at SchemeParser.cxx:484
#3  0x7ff0311f9b91 in OpenJade_DSSSL::SchemeParser::parse 
(this=this@entry=0x7ffe734576c0) at SchemeParser.cxx:190
#4  0x7ff0311ff573 in OpenJade_DSSSL::StyleEngine::parseSpec 
(this=this@entry=0x55b5395edc30, specParser=..., charset=..., id=..., mgr=..., 
defVars=...) at StyleEngine.cxx:166
#5  0x7ff03117f61a in OpenJade_DSSSL::DssslApp::processSysid 
(this=0x7ffe73457970, sysid=...) at DssslApp.cxx:138
#6  0x7ff030c5bc7f in OpenSP::EntityApp::processArguments(int, char**) () 
from /lib/libosp.so.5
#7  0x7ff030c4b39b in OpenSP::CmdLineApp::run(int, char**) () from 
/lib/libosp.so.5
#8  0x55b538874a3b in main (argc=15, argv=0x7ffe73458088) at jade.cxx:206
From 1dbae3ee5a83418d9d590895ad73b76f900d9ab0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
Date: Mon, 14 Dec 2020 18:01:01 +0100
Subject: Fix some warnings.

warning: control reaches end of non-void function [-Wreturn-type]
warning: no return statement in function returning non-void [-Wreturn-type]

Debian-Bug: https://bugs.debian.org/975242
---
 style/FlowObj.cxx| 1 +
 style/Interpreter.cxx| 9 +
 style/ProcessingMode.cxx | 2 +-
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/style/FlowObj.cxx b/style/FlowObj.cxx
index 49b09e9..2894e00 100644
--- a/style/FlowObj.cxx
+++ b/style/FlowObj.cxx
@@ -2958,6 +2958,7 @@ private:
   AcceptFlags af(fo.acceptFlags(context));
   if (af & afTableCell)
 	return true;
+  return false;
 }
 bool charsValid(size_t, const Location , ProcessContext ) {
   Interpreter  = *context.vm().interp;
diff --git a/style/Interpreter.cxx b/style/Interpreter.cxx
index 63b3022..8c8af4e 100644
--- a/style/Interpreter.cxx
+++ b/style/Interpreter.cxx
@@ -2572,6 +2572,7 @@ bool MaybeIntegerCharPropValues::setDefault(const StringC ,
   interp.message(InterpreterMessages::charPropertyNotIntegerOrFalse,
 		 StringMessageArg(name),
 		 ELObjMessageArg(obj, interp));
+  return true;
 }
 
 bool MaybeIntegerCharPropValues::setValue(const StringC ,
@@ -2692,28 +2693,34 @@ bool PublicIdCharPropValues::setValue(const StringC ,
 
 ELObj *PublicIdCharPropValues::value(Char, Interpreter &) const
 {
+  return NULL;
 }
 
 ELObj *PublicIdCharPropValues::defaultValue(Interpreter &) const
 {
+  return NULL;
 }
 
 bool SymbolCharPropValues::setDefault(const StringC &, const Location &,
 		  ELObj *, Interpreter &)
 {
+  return true;
 }
 
 bool SymbolCharPropValues::setValue(const StringC &, const StringC &, const Location &,
 		ELObj *,Interpreter &)
 {
+  return true;
 }
 
 ELObj *SymbolCharPropValues::value(Char, Interpreter &) const
 {
+  return NULL;
 }
 
 ELObj *SymbolCharPropValues::defaultValue(Interpreter &) const
 {
+  return NULL;
 }
 
 bool ELObjCharPropValues::setDefault(const StringC &, const Location &,
@@ -2722,6 +2729,7 @@ bool ELObjCharPropValues::setDefault(const StringC &, const Location &,
   ASSERT(obj);
   interp.makePermanent (obj);
   def_ = obj;
+  return true;
 }
 
 bool ELObjCharPropValues::setValue(const StringC &, const StringC ,
@@ -2732,6 +2740,7 @@ bool ELObjCharPropValues::setValue(const StringC &, const StringC ,
   interp.makePermanent (obj);
   for(size_t i = 0; i < chars.size(); ++i)
 map_.setChar(chars[i], obj);
+  return true;
 }
 
 ELObj *ELObjCharPropValues::value(Char ch, Interpreter &) const
diff --git a/style/ProcessingMode.cxx b/style/ProcessingMode.cxx
index 1a36996..dc25761 100644
--- a/style/ProcessingMode.cxx
+++ b/style/ProcessingMode.cxx
@@ -328,7 +328,7 @@ ProcessingMode::RootRule::RootRule(const Ptr )
 
 int ProcessingMode::RootRule::compareSpecificity(const Rule ) const
 

Bug#975977: tor generates invalid adress for hiddenservice when runninf on armv5tel architectures

[Bernhard Übelacker]

Dear Maintainer,
I tried to collect some more information and compared this
situation on real hardware armv5tel with an armv7 and
it looks like in keccak_finalize the following instruction
stores different data to memory depending on the arm hardware:

   0x005c4ac0 :f0 20 c4 e1 strdr2, [r4]

In the failing case this is stored:
(gdb) x/8xb &((keccak_state *) 0xbeffef5c)->a
0xbeffef5c: 0x6f0x6e0x200x630x000x000x000x00

And in the good case this:
(gdb) x/8xb &((keccak_state *) 0xbeffef5c)->a
0xbeffef5c: 0x2e0x6f0x6e0x690x6f0x6e0x200x63

While on both the registers r2 and r3 contain:
r2 0x696e6f2e  1768845102
r3 0x63206e6f  1663069807

In the attached files are some more details leading to the above result.

Kind regards,
Bernhard


(gdb) bt
#0  0x7f719ac4 in xorin8 (len=136, src=, dst=) at 
../src/ext/keccak-tiny/keccak-tiny-unrolled.c:21
#1  keccak_finalize (s=0xbeffef5c) at 
../src/ext/keccak-tiny/keccak-tiny-unrolled.c:189
#2  0x7f71a410 in hash (out=0xbefff1a8 "", outlen=32, in=, 
inlen=48, bits=256, delim=6 '\006') at ../src/ext/keccak-tiny/keccak-tiny-unrolled.c:353
#3  0x7f71a640 in sha3_256 (out=out@entry=0xbefff1a8 "", outlen=outlen@entry=32,
in=in@entry=0xbefff15c ".onion 
checksum\243\356\241Jͩ\036U\313\365\026;Z\"\370\357\016\272\030\251nOU\367\006(S6\177-V",
 inlen=inlen@entry=48)
at ../src/ext/keccak-tiny/keccak-tiny-unrolled.c:389
#4  0x7f6fb5e8 in crypto_digest256 (digest=digest@entry=0xbefff1a8 "", m=m@entry=0xbefff15c 
".onion 
checksum\243\356\241Jͩ\036U\313\365\026;Z\"\370\357\016\272\030\251nOU\367\006(S6\177-V",
len=len@entry=48, algorithm=algorithm@entry=DIGEST_SHA3_256) at 
../src/lib/crypt_ops/crypto_digest.c:153
#5  0x7f651948 in build_hs_checksum (key=key@entry=0x7f837df4, version=version@entry=3 
'\003', checksum_out=checksum_out@entry=0xbefff1a8 "") at 
../src/feature/hs/hs_common.c:748
#6  0x7f6530b0 in hs_build_address (key=key@entry=0x7f837df4, version=, 
addr_out=addr_out@entry=0x7f837da0 "") at ../src/feature/hs/hs_common.c:1001
...

# Buster armel chroot 2020-12-13 on another Buster armel

# uname -a
Linux qnap119 4.19.0-12-marvell #1 Debian 4.19.152-1 (2020-10-18) armv5tel 
GNU/Linux

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

Hardware: Marvell Kirkwood (Flattened Device Tree)
Revision: 

# chroot/bin/busybox mount -o rbind /dev  chroot/dev
# chroot/bin/busybox mount -o rbind /proc chroot/proc
# chroot/bin/busybox mount -o rbind /sys  chroot/sys

# cd debian-10-buster-armel-chroot
# env -i TERM=xterm LANG=de_DE.UTF-8 /usr/sbin/chroot chroot /bin/su -

# apt install openssl tor
# dpkg -l tor
...
ii  tor0.3.5.12-1   armelanonymizing overlay network for TCP
# exit

# unshare -n /bin/bash
# env -i TERM=xterm LANG=de_DE.UTF-8 /usr/sbin/chroot chroot /bin/su -l benutzer

$ mkdir hs
$ chmod go-rwx -R hs
$ echo 
'PT0gZWQyNTUxOXYxLXNlY3JldDogdHlwZTAgPT0AAACg6zoxlQ2hy7C6fUoTgIa0GLMk/YdVs2ic6jUDCzztZeLWcfqwCQ5/KoPk9v99cuWKO5mNpVrDtbOc27UUyC7e'
 | base64 -d > hs/hs_ed25519_secret_key

$ echo '6bff2f57fcd69049091dcfa42b08fb84919d60dac919cbb16e3df1d960bb7843  
./hs/hs_ed25519_secret_key' | sha256sum -c
./hs/hs_ed25519_secret_key: OK

$ cat < torrc
HiddenServiceDir /home/benutzer/hs
HiddenServicePort 80 127.0.0.1:8080
EOF

$ /usr/sbin/tor -f torrc Log 'info stdout'
...
^C

$ cat hs/hostname 
upxkcswnvepfls7vcy5vuixy54hlugfjnzhvl5ygfbjtm7znkyac43yd.onion




# apt build-dep tor
# apt install gdb tor-dbgsym

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


$ rm hs/hostname 
$ gdb -q --args /usr/sbin/tor -f torrc Log 'info stdout'
(gdb) set width 0
(gdb) set pagination off
(gdb) directory /home/benutzer/source/tor/orig/tor-0.3.5.12/src
(gdb) b build_hs_checksum
(gdb) run

(gdb) print sizeof(*key)
$3 = 32
(gdb) x/32xb key
0x6e2de4:   0xa30xee0xa10x4a0xcd0xa90x1e0x55
0x6e2dec:   0xcb0xf50x160x3b0x5a0x220xf80xef
0x6e2df4:   0x0e0xba0x180xa90x6e0x4f0x550xf7
0x6e2dfc:   0x060x280x530x360x7f0x2d0x560x00

(gdb) next
(gdb) next
(gdb) next
748   crypto_digest256((char *) checksum_out, data, sizeof(data),

(gdb) print sizeof(data)
$4 = 48
(gdb) x/48xb data
0xbefff17c: 0x2e0x6f0x6e0x690x6f0x6e0x200x63
0xbefff184: 0x680x650x630x6b0x730x750x6d0xa3
0xbefff18c: 0xee0xa10x4a0xcd0xa90x1e0x550xcb
0xbefff194: 0xf50x160x3b0x5a0x220xf80xef0x0e
0xbefff19c: 0xba0x180xa90x6e

Bug#971088: xserver-xorg-core: Backtraces print wrong instruction pointers

[Bernhard Übelacker]

Dear Maintainer,
the patches got accepted upstream hit now testing
with xserver-xorg-core 2:1.20.10-1.

I made a test similar to the initial attached file and
function addresses printed by gdb match now xservers backtrace.
Therefore I guess this bug can then be closed?

Kind regards,
Bernhard

Bug#973441: obs-studio: Adding the noise canceling filter causes a segmentation fault

[Bernhard Übelacker]

Dear Maintainer,
I tried to have a look at this crash and could it reproduce it
inside a minimal testing amd64 VM.

A backtrace with full debug symbols in [1].

The crash itself happens because of a stack exhaustion, because in
_celt_autocorr a 2015 MB array should be constructed.

But this seems to be just a consequence of function compute_frame_features
calling function pitch_downsample, which is unfortunately first found by
the dynamic linker in libcodec2.so.0.9 instead of obs-filters.so.
And the function signatures are quite different.

Therefore a cheap workaround currently might be to start obs-studio with
obs-filters preloaded. That way at least the denoise filter can be added.

LD_PRELOAD=/usr/lib/x86_64-linux-gnu/obs-plugins/obs-filters.so obs

But might break when libcodec2.so.0.9 wants to call its function 
pitch_downsample.
Another more reliable option might be to rename
that and the other common functions.
The last part of the attached file shows all common function
between obs-filters.so and libcodec2.so.0.9.

Kind regards,
Bernhard


[1]
(gdb) bt
#0  0x7f1bee6e4b71 in _celt_autocorr (x=x@entry=0x7f1aacfee8e8, 
ac=ac@entry=0x7f1aacfee7c0, window=window@entry=0x0, overlap=overlap@entry=0, 
lag=lag@entry=4, n=n@entry=-1392576048) at ./lpcnet/src/celt_lpc.c:216
#1  0x7f1bee6e4d2a in pitch_downsample (x_lp=x_lp@entry=0x7f1aacfee8e8, 
len=len@entry=-1392576048) at ./lpcnet/src/pitch.c:160
#2  0x7f1b30293006 in compute_frame_features (in=0x7f1aacfeeac0, 
features=0x7f1aacfeea10, Exp=0x7f1aacfee9b0, Ep=0x7f1aacfee950, 
Ex=0x7f1aacfee8f0, P=0x7f1aacff2560, X=0x7f1aacff1650, st=0x562d5f38cff0) at 
./plugins/obs-filters/rnnoise/src/denoise.c:326
#3  rnnoise_process_frame (st=0x562d5f38cff0, out=, 
in=) at ./plugins/obs-filters/rnnoise/src/denoise.c:471
#4  0x7f1b302a5f4c in process_rnnoise (ng=0x562d5f373f40) at 
./plugins/obs-filters/noise-suppress-filter.c:343
#5  process (ng=) at 
./plugins/obs-filters/noise-suppress-filter.c:392
#6  noise_suppress_filter_audio (data=0x562d5f373f40, audio=) at ./plugins/obs-filters/noise-suppress-filter.c:468
#7  0x7f1bf1beab8b in filter_async_audio (in=, 
source=0x562d5f26bf00) at ./libobs/obs-source.c:3068
#8  obs_source_output_audio (source=0x562d5f26bf00, 
audio=audio@entry=0x7f1aacff81f0) at ./libobs/obs-source.c:3246
#9  0x7f1bcc002774 in _alsa_listen (attr=0x7f1be000dc20) at 
./plugins/linux-alsa/alsa-input.c:574
#10 0x7f1bf0c26ea7 in start_thread (arg=) at 
pthread_create.c:477
#11 0x7f1bf0b56d4f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95


# Bullseye/testing amd64 qemu VM 2020-11-14


apt update
apt dist-upgrade


apt install systemd-coredump mc htop psmisc net-tools strace xdm xserver-xorg 
openbox xterm gdb obs-studio obs-studio-dbgsym obs-plugins-dbgsym 
libobs0-dbgsym libcodec2-0.9-dbgsym
apt build-dep libcodec2-0.9
apt build-dep obs-studio


reboot




mkdir /home/benutzer/source/libcodec2-0.9/orig -p
cd/home/benutzer/source/libcodec2-0.9/orig
apt source libcodec2-0.9
cd

mkdir /home/benutzer/source/obs-studio/orig -p
cd/home/benutzer/source/obs-studio/orig
apt source obs-studio
cd






export LANG=C
export DISPLAY=:0

obs

- Cancel autoconfiguration
- Sources: Add source, Audio Capture Device Alsa
- Sources: Right click new entry - "Filters"
- Audio Filters: Add "Noise suppresion"





benutzer@debian:~$ obs
...
info: alsa-input: PCM 'default' rate set to 44100
info: alsa-input: PCM 'default' channels set to 2
info: User added source 'Audio Capture Device (ALSA)' (alsa_input_capture) to 
scene 'Scene'
info: adding 64 milliseconds of audio buffering, total audio buffering is now 
64 milliseconds (source: Audio Capture Device (ALSA))

info: User added filter 'Noise Suppression' (noise_suppress_filter_v2) to 
source 'Audio Capture Device (ALSA)'
Segmentation fault (core dumped)




root@debian:~# journalctl --no-pager
...
Nov 14 14:37:13 debian kernel: obs[891]: segfault at 7f1bf902fff8 ip 
7f1bee6e4b71 sp 7f1bf903 error 6 in 
libcodec2.so.0.9[7f1bee6b4000+38000]
Nov 14 14:37:13 debian kernel: Code: d9 00 00 00 48 8d 35 8e 01 01 00 48 8d 3d 
0b 02 01 00 e8 12 f4 ff ff ba d8 00 00 00 48 8d 35 76 01 01 00 48 8d 3d dd 01 
01 00  fa f3 ff ff e8 95 fa fc ff 0f 1f 44 00 00 48 b8 00 00 00 00 01
Nov 14 14:37:13 debian systemd[1]: Created slice 
system-systemd\x2dcoredump.slice.
Nov 14 14:37:13 debian systemd[1]: Started Process Core Dump (PID 896/UID 0).
Nov 14 14:37:15 debian kernel: snd_hda_intel :00:05.0: IRQ timing 
workaround is activated for card #0. Suggest a bigger bdl_pos_adj.
Nov 14 14:37:17 debian systemd-coredump[897]: [] Process 705 (obs) of user 
1000 dumped core.
  
  Stack trace of thread 891:
  #0  0x7f1bee6e4b71 
_celt_autocorr (libcodec2.so.0.9 + 0x3cb71)

Bug#973044: posh: segfaults when getcwd fails

[Bernhard Übelacker]

Dear Maintainer,
this is a backtrace of the crash:

(gdb) bt
#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
#1  0x55a9f3c9e5d0 in set_current_wd (path=) at 
../path.c:235
#2  0x55a9f3c906b7 in main (argc=1, argv=0x7fffa8fcd4b8) at 
../main.c:196

It seems that in main variable pwdx intentionally is set to NULL (main.c:195).
But function set_current_wd is not prepared to receive that.

Kind regards,
Bernhard


https://sources.debian.org/src/posh/0.14.1/path.c/#L235
https://sources.debian.org/src/posh/0.14.1/main.c/#L196

191 if (!ISABSPATH(pwd)
192 || stat(pwd, _pwd) < 0 || stat(".", _dot) < 0
193 || s_pwd.st_dev != s_dot.st_dev
194 || s_pwd.st_ino != s_dot.st_ino)
195 pwdx = (char *) 0;
196 set_current_wd(pwdx);

Bug#972949: Acknowledgement (minicom: Segmentation fault logging in RouterOS 6.47.6)

[Bernhard Übelacker]

Dear Maintainer,
I tried to have a look at the core file.

If a dbgsym package would be available I would be more
confident about the following information.
Please consider to build the dbgsym package.


The crash seems to happen in the stack below.

It seems the function mc_clear_window_simple gets called with
parameter w being a null pointer, which gets dereferenced in line 1498.

This null pointer seems to originate from the static variable us_alternate.

Kind regards,
Bernhard


(gdb) bt
#0  0x...11b in mc_clear_window_simple at window.c:1498 
https://sources.debian.org/src/minicom/2.7.2%7E20200725-3/src/window.c/#L1498
#1  0x...3a8 in dec_mode at vt100.c:735 
https://sources.debian.org/src/minicom/2.7.2%7E20200725-3/src/vt100.c/#L735
#2  0x...e21 in state3 at vt100.c:783   
https://sources.debian.org/src/minicom/2.7.2%7E20200725-3/src/vt100.c/#L783
#3  0x...d4a in do_terminal at main.c:964   
https://sources.debian.org/src/minicom/2.7.2%7E20200725-3/src/main.c/#L964
#4  0x...a55 in main at minicom.c:1622  
https://sources.debian.org/src/minicom/2.7.2%7E20200725-3/src/minicom.c/#L1622
#5  0x...cca in __libc_start_main (main=0x5639900c08b0, argc=7, argv=0x7fff270d9178, 
init=, fini=, rtld_fini=, 
stack_end=0x7fff270d9168) at ../csu/libc-start.c:308
#6  0x...64a in ?? ()


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


apt update
apt dist-upgrade


apt install systemd-coredump mc fakeroot gdb minicom
# no minicom-dbgsym available ???
apt build-dep minicom



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


wget 
"https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=972949;filename=core-minicom.3018805.transient.1603721766.gz;msg=10;
 -O core-minicom.3018805.transient.1603721766.gz
gunzip core-minicom.3018805.transient.1603721766.gz


gdb -q /usr/bin/minicom --core core-minicom.3018805.transient.1603721766









benutzer@debian:~$ gdb -q /usr/bin/minicom --core 
core-minicom.3018805.transient.1603721766
Reading symbols from /usr/bin/minicom...
(No debugging symbols found in /usr/bin/minicom)
[New LWP 3018805]
Core was generated by `minicom -c on -b 115200 -D /dev/ttyUSB0'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x5639900d611b in ?? ()
(gdb) set width 0
(gdb) set pagination off
(gdb) bt
#0  0x5639900d611b in ?? ()
#1  0x5639900c43a8 in ?? ()
#2  0x5639900c4e21 in ?? ()
#3  0x5639900dbd4a in ?? ()
#4  0x5639900c1a55 in ?? ()
#5  0x7faa497facca in __libc_start_main (main=0x5639900c08b0, argc=7, 
argv=0x7fff270d9178, init=, fini=, 
rtld_fini=, stack_end=0x7fff270d9168) at ../csu/libc-start.c:308
#6  0x5639900c364a in ?? ()

(gdb) disassemble 0x5639900d60f7,0x5639900d6124
Dump of assembler code from 0x5639900d60f7 to 0x5639900d6124:
   0x5639900d60f7:  callq  0x5639900c0850 <__sprintf_chk@plt>
   0x5639900d60fc:  mov%rbp,%rdi
   0x5639900d60ff:  mov$0x1,%esi
   0x5639900d6104:  xor%ebp,%ebp
   0x5639900d6106:  lea-0x2c1d(%rip),%rdx# 0x5639900d34f0
   0x5639900d610d:  callq  0x5639900c0090 
   0x5639900d6112:  xor%esi,%esi
   0x5639900d6114:  xor%edi,%edi
   0x5639900d6116:  callq  0x5639900d31f0
=> 0x5639900d611b:  mov0x1c(%r12),%eax
   0x5639900d6120:  test   %eax,%eax
   0x5639900d6122:  jns0x5639900d6155
End of assembler dump.

(gdb) print/x $r12
$1 = 0x0



Comparing with a local rebuild with debugging information:

(gdb) disassemble 0x5556f0f7,0x5556f124
Dump of assembler code from 0x5556f0f7 to 0x5556f124:
   0x5556f0f7 : callq  0x9850 
<__sprintf_chk@plt>
   0x5556f0fc : mov%rbp,%rdi
   0x5556f0ff : mov$0x1,%esi
   0x5556f104 : xor%ebp,%ebp
   0x5556f106 : lea
-0x2c1d(%rip),%rdx# 0x5556c4f0 
   0x5556f10d : callq  0x9090 

   0x5556f112 : xor%esi,%esi
   0x5556f114 : xor%edi,%edi
   0x5556f116 : callq  0x5556c1f0 
<_gotoxy>
   0x5556f11b : mov0x1c(%r12),%eax
   0x5556f120 : test   %eax,%eax
   0x5556f122 : jns0x5556f155 

End of assembler dump.

(gdb) print 0x1c
$1 = 28
(gdb) ptype /o WIN
type = struct _win {
/*0  | 4 */int x1;
/*4  | 4 */int y1;
/*8  | 4 */int x2;
/*   12  | 4 */int y2;
/*   16  | 4 */int sy1;
/*   20  | 4 */int sy2;
/*   24  | 4 */int xs;
/*   28  | 4 */int ys;
/*   32  | 1 */char border;
...

(gdb) list window.c:1492,1503
1492
1493void mc_clear_window_simple(WIN *w)
1494{
1495  int x = 0, y = 0;
1496  _colson(us->color);
1497  _gotoxy(0, 0);
1498  for (; y <= w->ys; ++y)

Bug#932250: random segfaults

[Bernhard Übelacker]

Hello Paul,
is it possible to install the package systemd-coredump on
the systems showing this crash?

Then after the next crash in the output of 'journalctl --no-pager'
should the segfault appear followed by a backtrace
that you could forward to this bug.

This should clarify which function calls lead to the crash.

More information on improving that information additionally
are here: https://wiki.debian.org/HowToGetABacktrace

Kind regards,
Bernhard

Bug#973894: rr: Improve reproducibility

[Bernhard Übelacker]

Hello Chris,
thanks for the pointers.

By enabling fixfilepath [1] the build it is automatically using 
-ffile-prefix-map.
This seems also the case for the reproducible-builds.org results already [2].
Therefore I assume the compilation of the .c* files is already good.
And the -ffile-prefix-map part is superfluous in my initial patch.

The remaining files embedding the build path have all a .S file ending.
When I tested to add dpkg-buildflags's CFLAGS to the command line for such a .S 
file,
the build path still ended up in the .S.o file.
Therefore the attempt to use of "-Wa,--debug-prefix-map,${CMAKE_SOURCE_DIR}=.".

This leads to the question if /usr/bin/cc is on fault and should forward
the option -ffile-prefix-map as --debug-prefix-map to /usr/bin/as?
Or does dpkg provide other flags for assembly files?

Kind regards,
Bernhard


[1]
export DEB_BUILD_OPTIONS="reproducible=+fixfilepath"
dpkg-buildpackage -uc

[2] 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/rr.html
 DEB_BUILD_OPTIONS="buildinfo=+all reproducible=+all parallel=15"

[3]
$ pwd
/home/benutzer/source/rr/try3/rr-5.4.0/build
$ find -iname "*.o" | xargs -d\\n grep try3 -c | grep -v -E ":0$" | sort
./build/CMakeFiles/cpuid_32.dir/32/x86/cpuid_loop.S.o:3
./build/CMakeFiles/rraudit_32.dir/32/preload/raw_syscall.S.o:3
./build/CMakeFiles/rraudit.dir/src/preload/raw_syscall.S.o:3
./build/CMakeFiles/rrpreload_32.dir/32/preload/raw_syscall.S.o:3
./build/CMakeFiles/rrpreload_32.dir/32/preload/syscall_hook.S.o:3
./build/CMakeFiles/rrpreload.dir/src/preload/raw_syscall.S.o:3
./build/CMakeFiles/rrpreload.dir/src/preload/syscall_hook.S.o:3

Bug#973894: rr: Improve reproducibility

[Bernhard Übelacker]

Am 07.11.20 um 11:00 schrieb Chris Lamb:

Hi Bernhard,


I guess attached patch would at least remove the embedded
build path from the files, which is mentioned in [2] too.


Thanks for working on this. Looking at your solution though, I believe
it implies that CFLAGS set by the dpkg-buildflags mechanism are not
being used in rr's build system.

Fixing this more general problem would resolve the reproducibility
issue, as it would imply -ffile-prefix-map and friends. It would also
solve other future problems too, so I don't think this patch is ready
to be applied as it stands.

IIRC CMake can be a bit of a pain with respecting flags, so just in
case it helps, there is some info here:

   https://wiki.debian.org/Hardening


Regards,



Hell Chris,
thanks for looking into it. As I am not really sure what the hardening flags
have to look like in our case below some more details.


Are they at amd64 just what is returned by e.g. `dpkg-buildflags --get CFLAGS` 
[1] ?


If yes, then they are already applied to the compilation of the .c files
and to the linking step (Command lines from a build inside amd64 testing [2]).
For these I added the -ffile-prefix-map additionally to the -fdebug-prefix-map.
That raises the question if the -fdebug should be replaced by -ffile
in the hardening flags globally? [5]

This might be needed here because __FILE__ is concatenated
with some other string constants [4].
Using -ffile-prefix-map without the -fdebug-prefix-map makes the
embedded build path disappear, too.


The other part is the compilation of the .S files.
I assume they are using e.g. -fno-stack-protector on purpose, therefore
using the hardening flags on them might break them?
Therefore I just tried adding the -Wa,--debug-prefix-map and
the embedded build path disappeared.


Kind regards,
Bernhard







[1]
benutzer@debian:~/source/rr/try1/rr-5.4.0$ dpkg-buildflags --get CPPFLAGS
-Wdate-time -D_FORTIFY_SOURCE=2
benutzer@debian:~/source/rr/try1/rr-5.4.0$ dpkg-buildflags --get CFLAGS
-g -O2 -fdebug-prefix-map=/home/benutzer/source/rr/try1/rr-5.4.0=. 
-fstack-protector-strong -Wformat -Werror=format-security
benutzer@debian:~/source/rr/try1/rr-5.4.0$ dpkg-buildflags --get CXXFLAGS
-g -O2 -fdebug-prefix-map=/home/benutzer/source/rr/try1/rr-5.4.0=. 
-fstack-protector-strong -Wformat -Werror=format-security
benutzer@debian:~/source/rr/try1/rr-5.4.0$ dpkg-buildflags --get LDFLAGS
-Wl,-z,relro


[2]
benutzer@debian:~/source/rr/try1/rr-5.4.0$ script -a ../build.log -c 
"dpkg-buildpackage -uc"
...
cd build && cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None 
-DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var 
-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_INSTALL_RUNSTATEDIR=/run -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON "-GUnix 
Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu ..
...
/usr/bin/cc -DRR_VERSION=\"5.4.0\" -Drrpreload_EXPORTS 
-I/home/benutzer/source/rr/try1/rr-5.4.0/include 
-I/home/benutzer/source/rr/try1/rr-5.4.0/third-party/proc-service 
-I/home/benutzer/source/rr/try1/rr-5.4.0/third-party/brotli/include 
-I/home/benutzer/source/rr/try1/rr-5.4.0/build -fPIC -Wall -Wextra -UDEBUG -DNDEBUG 
-fno-stack-protector -g3 -U_FORTIFY_SOURCE -o 
CMakeFiles/rrpreload.dir/src/preload/syscall_hook.S.o -c 
/home/benutzer/source/rr/try1/rr-5.4.0/src/preload/syscall_hook.S
/usr/bin/cc -DRR_VERSION=\"5.4.0\" -Drrpreload_EXPORTS 
-I/home/benutzer/source/rr/try1/rr-5.4.0/include 
-I/home/benutzer/source/rr/try1/rr-5.4.0/third-party/proc-service 
-I/home/benutzer/source/rr/try1/rr-5.4.0/third-party/brotli/include 
-I/home/benutzer/source/rr/try1/rr-5.4.0/build -g -O2 
-fdebug-prefix-map=/home/benutzer/source/rr/try1/rr-5.4.0=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -D__USE_LARGEFILE64 
-pthread -msse2 -D__MMX__ -D__SSE__ -D__SSE2__ -Wstrict-prototypes -std=gnu11  -pthread 
-fPIC -Wall -Wextra -UDEBUG -DNDEBUG -fno-stack-protector -g3 -U_FORTIFY_SOURCE -o 
CMakeFiles/rrpreload.dir/src/preload/syscallbuf.c.o -c 
/home/benutzer/source/rr/try1/rr-5.4.0/src/preload/syscallbuf.c
/usr/bin/cc -DRR_VERSION=\"5.4.0\" -Drrpreload_EXPORTS 
-I/home/benutzer/source/rr/try1/rr-5.4.0/include 
-I/home/benutzer/source/rr/try1/rr-5.4.0/third-party/proc-service 
-I/home/benutzer/source/rr/try1/rr-5.4.0/third-party/brotli/include 
-I/home/benutzer/source/rr/try1/rr-5.4.0/build -fPIC -Wall -Wextra -UDEBUG -DNDEBUG 
-fno-stack-protector -g3 -U_FORTIFY_SOURCE -o 
CMakeFiles/rrpreload.dir/src/preload/raw_syscall.S.o -c 
/home/benutzer/source/rr/try1/rr-5.4.0/src/preload/raw_syscall.S
/usr/bin/cc -DRR_VERSION=\"5.4.0\" -Drrpreload_EXPORTS 
-I/home/benutzer/source/rr/try1/rr-5.4.0/include 
-I/home/benutzer/source/rr/try1/rr-5.4.0/third-party/proc-service 
-I/home/benutzer/source/rr/try1/rr-5.4.0/third-party/brotli/include 

Bug#973894: rr: Improve reproducibility

[Bernhard Übelacker]

Package: rr
Version: 5.4.0-1
Severity: wishlist


Dear Maintainer,
I came to the reproducible build page [1] and saw
latest version was not reproducible.

I guess attached patch would at least remove the embedded
build path from the files, which is mentioned in [2] too.
Maybe that is already enough.

Kind regards,
Bernhard

[1] https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/rr.html
[2] 
https://salsa.debian.org/reproducible-builds/reproducible-notes/-/commit/925d9e5f6


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

Kernel: Linux 5.9.0-1-amd64 (SMP w/16 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rr depends on:
ii  libc6   2.31-4
ii  libc6-i386  2.31-4
ii  libcapnp-0.7.0  0.7.0-7
ii  libgcc-s1   10.2.0-16
ii  libstdc++6  10.2.0-16
ii  python3 3.8.2-3
Description: Remove embedded build paths

Author: Bernhard Übelacker 
Forwarded: no
Last-Update: 2020-11-06

Index: rr-5.4.0/CMakeLists.txt
===
--- rr-5.4.0.orig/CMakeLists.txt
+++ rr-5.4.0/CMakeLists.txt
@@ -81,7 +81,7 @@ endif()
 # Base settings for debug and release/unspecified builds.
 # Use -Werror for debug builds because we assume a developer is building, not a user.
 set(RR_FLAGS_DEBUG "-Wall -Wextra -DDEBUG -UNDEBUG")
-set(RR_FLAGS_RELEASE "-Wall -Wextra -UDEBUG -DNDEBUG")
+set(RR_FLAGS_RELEASE "-Wall -Wextra -UDEBUG -DNDEBUG -ffile-prefix-map=${CMAKE_SOURCE_DIR}=. -Wa,--debug-prefix-map,${CMAKE_SOURCE_DIR}=.")
 
 # The folowing settings are the defaults for the OTHER build type.
 # Flags used to build the preload library. MUST have debuginfo enabled. SHOULD be optimized.

Bug#963148: binutils-avr: avr-ld is broken on aarch64

[Bernhard Übelacker]

Dear Maintainer,
I could reproduce this issue with version 2.26.20160125+Atmel3.6.2-1.

Program terminated with signal SIGILL, Illegal instruction.
#0  0xe70f20e8 in e843419@0011_0103_e2c ()
(gdb) bt
#0  0xe70f20e8 in e843419@0011_0103_e2c ()
#1  0xe70f1ff8 in ldfile_add_arch (in_name=0xe719e318 "") at 
./ldfile.c:630
#2  0xe70d50b8 in main (argc=, argv=) 
at ./ldmain.c:288
(gdb) disassemble
Dump of assembler code for function e843419@0011_0103_e2c:
=> 0xe70f20e8 <+0>: 00 00 00 00 .inst   0x ; 
undefined
   0xe70f20ec <+4>: c7 ff ff 17 b   0xe70f2008 

End of assembler dump.


Current version 2.26.20160125+Atmel3.6.2-2 seems not affected anymore.

Kind regards,
Bernhard


# Bullseye/testing aarch64 qemu VM 2020-11-05


apt update
apt dist-upgrade


apt install systemd-coredump devscripts gdb binutils-avr binutils-avr-dbgsym
apt build-dep binutils-avr



mkdir /home/benutzer/source/binutils-avr/orig -p
cd/home/benutzer/source/binutils-avr/orig
dget 
https://snapshot.debian.org/archive/debian/20200112T150045Z/pool/main/b/binutils-avr/binutils-avr_2.26.20160125%2BAtmel3.6.2-1.dsc
cd



root@debian:~# dpkg -l | grep avr
ii  binutils-avr  2.26.20160125+Atmel3.6.2-2 arm64
Binary utilities supporting Atmel's AVR targets
root@debian:~# avr-ld
avr-ld: no input files


wget 
https://snapshot.debian.org/archive/debian/20200112T150045Z/pool/main/b/binutils-avr/binutils-avr_2.26.20160125%2BAtmel3.6.2-1_arm64.deb
wget 
https://snapshot.debian.org/archive/debian-debug/20200112T145651Z/pool/main/b/binutils-avr/binutils-avr-dbgsym_2.26.20160125%2BAtmel3.6.2-1_arm64.deb
dpkg -i binutils-avr_2.26.20160125+Atmel3.6.2-1_arm64.deb 
binutils-avr-dbgsym_2.26.20160125+Atmel3.6.2-1_arm64.deb


root@debian:~# dpkg -l | grep avr
ii  binutils-avr  2.26.20160125+Atmel3.6.2-1 arm64
Binary utilities supporting Atmel's AVR targets
root@debian:~# avr-ld
Illegal instruction (core dumped)


root@debian:~# journalctl -e
...
Nov 05 23:27:12 debian systemd[1]: Started Process Core Dump (PID 1728/UID 0).
Nov 05 23:27:15 debian systemd-coredump[1729]: Process 1727 (avr-ld) of user 0 
dumped core.
   
   Stack trace of thread 1727:
   #0  0xe70f20e8 n/a (ld + 
0x410e8)
   #1  0xe70f1ff8 n/a (ld + 
0x40ff8)
   #2  0xe7203000 n/a (ld + 
0x152000)
Nov 05 23:27:15 debian systemd[1]: systemd-coredump@0-1728-0.service: Succeeded.


root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Thu 2020-11-05 23:27:15 CET1727 0 0   4 present   
/usr/lib/avr/bin/ld


root@debian:~# coredumpctl gdb 1727
   PID: 1727 (avr-ld)
   UID: 0 (root)
   GID: 0 (root)
Signal: 4 (ILL)
 Timestamp: Thu 2020-11-05 23:27:12 CET (2min 15s ago)
  Command Line: avr-ld
Executable: /usr/lib/avr/bin/ld
 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: 3f56606be08f444d957581bc66c9453f
Machine ID: b26c6a7c3b16414d8985adaa2301400c
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.avr-ld.0.3f56606be08f444d957581bc66c9453f.1727.160461523200.zst
   Message: Process 1727 (avr-ld) of user 0 dumped core.

Stack trace of thread 1727:
#0  0xe70f20e8 n/a (ld + 0x410e8)
#1  0xe70f1ff8 n/a (ld + 0x40ff8)
#2  0xe7203000 n/a (ld + 0x152000)

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 "aarch64-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/lib/avr/bin/ld...
(No debugging symbols found in /usr/lib/avr/bin/ld)

warning: core file may not match specified executable file.
[New LWP 1727]
Core was generated by `avr-ld'.
Program terminated with signal SIGILL, Illegal instruction.
#0  0xe70f20e8 in ?? ()
(gdb) bt
#0  0xe70f20e8 in ?? ()
#1  

Bug#954273: simka: arm64 autopkgtest time out

[Bernhard Übelacker]

Dear Maintainer,
I tried to have a look at this hanging test and could
reproduce a hang at this backtrace [1].

The loop in [2] gets not left because the result of the fgetc call
gets stored in a variable of type char and later compared to EOF.
It seems to be an issue with not being explicit
about signed/unsigned char with this variable.

At least using the type int makes the test finish and pass,
when libgatbcore3 is built with attached patch.

Kind regards,
Bernhard


[1]
(gdb) bt
#0  gatb::core::system::impl::CommonFile::gets (this=0x55839ffbb0, 
s=, size=) at 
./gatb-core/src/gatb/system/impl/FileSystemCommon.hpp:103
#1  0x0076c633ee38 in gatb::core::bank::impl::BankAlbum::BankAlbum 
(this=this@entry=0x55839fc860, 
name="/tmp/autopkgtest.iSjXKJ/autopkgtest_tmp/simka_temp_output/simka_output_temp//input/A",
 deleteIfExists=deleteIfExists@entry=false, __in_chrg=, 
__vtt_parm=) at ./gatb-core/src/gatb/bank/impl/BankAlbum.cpp:64
#2  0x0076c633f6a4 in 
gatb::core::bank::impl::BankAlbumFactory::createBank (this=, 
uri="/tmp/autopkgtest.iSjXKJ/autopkgtest_tmp/simka_temp_output/simka_output_temp//input/A")
 at ./gatb-core/src/gatb/bank/impl/BankAlbum.cpp:343
#3  0x0076c633c1a8 in gatb::core::bank::impl::Bank::_open_ 
(this=this@entry=0x555bb42388 
, 
uri="/tmp/autopkgtest.iSjXKJ/autopkgtest_tmp/simka_temp_output/simka_output_temp//input/A")
 at ./gatb-core/src/gatb/bank/impl/Bank.cpp:150
#4  0x00555bb0b704 in gatb::core::bank::impl::Bank::open 
(uri="/tmp/autopkgtest.iSjXKJ/autopkgtest_tmp/simka_temp_output/simka_output_temp//input/A")
 at /usr/include/gatb/bank/impl/Bank.hpp:135
#5  SimkaAlgorithm<32ul>::isInputValid (this=0x7fd3195140) at 
/build/simka-C4DX5D/simka-1.5.2/src/core/SimkaAlgorithm.cpp:362
#6  0x00555baf9264 in SimkaPotaraAlgorithm<32ul>::execute 
(this=0x7fd3195140) at /build/simka-C4DX5D/simka-1.5.2/src/SimkaPotara.hpp:413
#7  0x00555badc9e4 in Functor<32ul>::operator() (this=, 
p=...) at /build/simka-C4DX5D/simka-1.5.2/src/SimkaPotara.cpp:111
#8  
gatb::core::tools::math::IntegerTemplate, 
mpl_::int_<64>, mpl_::int_<96>, mpl_::int_<128> > >::Apply, mpl_::int_<64>, mpl_::int_<96>, 
mpl_::int_<128> >, false>::execute (params=..., kmerSize=) at 
/usr/include/gatb/tools/math/Integer.hpp:463
#9  
gatb::core::tools::math::IntegerTemplate, 
mpl_::int_<64>, mpl_::int_<96>, mpl_::int_<128> > >::apply 
(params=..., kmerSize=) at 
/usr/include/gatb/tools/math/Integer.hpp:84
#10 SimkaPotara::execute (this=) at 
/build/simka-C4DX5D/simka-1.5.2/src/SimkaPotara.cpp:140
#11 0x0076c6428020 in gatb::core::tools::misc::impl::Tool::run 
(this=0x7fd31955d8, input=) at 
./gatb-core/src/gatb/tools/misc/impl/Tool.cpp:158
#12 0x0076c64277c8 in gatb::core::tools::misc::impl::Tool::run 
(this=0x7fd31955d8, argc=7, argv=0x7fd3195848) at 
./gatb-core/src/gatb/tools/misc/impl/Tool.cpp:112
#13 0x00555bad97bc in main (argc=7, argv=0x7fd3195848) at 
/usr/include/c++/10/ext/new_allocator.h:79


[2] 
https://sources.debian.org/src/gatb-core/1.4.2+dfsg-5/gatb-core/src/gatb/system/impl/FileSystemCommon.hpp/#L103

Description: Use int as return of fgetc

Author: Bernhard Übelacker 
Bug-Debian: https://bugs.debian.org/954273
Forwarded: no
Last-Update: 2020-11-03

Index: gatb-core-1.4.2+dfsg/gatb-core/src/gatb/system/impl/FileSystemCommon.hpp
===
--- gatb-core-1.4.2+dfsg.orig/gatb-core/src/gatb/system/impl/FileSystemCommon.hpp
+++ gatb-core-1.4.2+dfsg/gatb-core/src/gatb/system/impl/FileSystemCommon.hpp
@@ -100,7 +100,7 @@ public:
 result = strlen (tmp);
 
 /** we skip all characters until we reach the next '\n'. */
-if (result > 0)  {  for (char c = tmp[result-1];  c !='\n' &&  c!=EOF;  c = fgetc (getHandle()))  {}  }
+if (result > 0)  {  for (int c = tmp[result-1];  c !='\n' &&  c!=EOF;  c = fgetc (getHandle()))  {}  }
 }
 
 /** We return the result. */


# Unstable chroot 2020-11-03 running on Android/LineageOS kernel


root@localhost:~# lscpu
Architecture: aarch64
CPU op-mode(s):   32-bit, 64-bit
Byte Order:   Little Endian
CPU(s):   8
On-line CPU(s) list:  4,5
Off-line CPU(s) list: 0-3,6,7
Thread(s) per core:   1
Core(s) per socket:   2
Socket(s):1
Vendor ID:ARM
Model:1
Model name:   Cortex-A53
Stepping: r0p1
CPU max MHz:  1113,6000
CPU min MHz:  249,6000
Flags:fp asimd evtstrm aes pmull sha1 sha2 crc32
root@localhost:~# uname -a
Linux localhost 3.10.108-g5285e19 #1 SMP PREEMPT Fri Oct 26 18:55:56 CEST 2018 
aarch64 GNU/Linux


apt update
apt dist-upgrade


apt install mc htop psmisc net-tools strace quilt autopkgtest gdb valgrind 
simk

Bug#972928: claws-mail: Crash when attempted to enter IMAP folder

[Bernhard Übelacker]

Dear Maintainer,
I just came across this report and want to note that since ASLR
got quite common the addr2line method is unreliable.

Therefore I want to point to here [1], were another method is
described to find out the source line where a crash happened. 

Attached file contains this exercised for the given output
in the first message.
This would point to [3], folderview.c, line 2339.

The most convenient way I guess is to install a coredump collector,
and inspect that after a crash like in [2] you already mentioned.

Kind regards,
Bernhard


[1] https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash
[2] https://wiki.debian.org/HowToGetABacktrace
[3] https://sources.debian.org/src/claws-mail/3.17.3-2/src/folderview.c/#L2339



dmesg: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972928#5
[Mon Oct 26 10:23:55 2020] claws-mail[1879911]: segfault at 1f ip 
004a35bd sp 7ffe5872a4e0 error 4 in claws-mail[442000+23]
[Mon Oct 26 10:23:55 2020] Code: 30 85 c0 0f 84 a4 02 00 00 c7 05 3e f6 2e 00 
00 00 00 00 31 f6 48 89 df e8 c0 fc ff ff 49 8b 84 24 88 00 00 00 48 85 c0 74 
19 <48> 8b 00 31 f6 83 38 04 48 8b 43 50 40 0f 94 c6 48 8b 78 30 e8 5a


https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash

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


benutzer@debian:~$ echo -n "find /b ..., ..., 0x" && \
> echo "30 85 c0 0f 84 a4 02 00 00 c7 05 3e f6 2e 00 00 00 00 00 31 f6 48 89 df 
> e8 c0 fc ff ff 49 8b 84 24 88 00 00 00 48 85 c0 74 19 <48> 8b 00 31 f6 83 38 
> 04 48 8b 43 50 40 0f 94 c6 48 8b 78 30 e8 5a" \
>  | sed 's/[<>]//g' | sed 's/ /, 0x/g'
find /b ..., ..., 0x30, 0x85, 0xc0, 0x0f, 0x84, 0xa4, 0x02, 0x00, 0x00, 0xc7, 
0x05, 0x3e, 0xf6, 0x2e, 0x00, 0x00, 0x00, 0x00, 0x00, 0x31, 0xf6, 0x48, 0x89, 
0xdf, 0xe8, 0xc0, 0xfc, 0xff, 0xff, 0x49, 0x8b, 0x84, 0x24, 0x88, 0x00, 0x00, 
0x00, 0x48, 0x85, 0xc0, 0x74, 0x19, 0x48, 0x8b, 0x00, 0x31, 0xf6, 0x83, 0x38, 
0x04, 0x48, 0x8b, 0x43, 0x50, 0x40, 0x0f, 0x94, 0xc6, 0x48, 0x8b, 0x78, 0x30, 
0xe8, 0x5a
benutzer@debian:~$









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


apt update
apt dist-ugprade


apt install systemd-coredump gdb claws-mail claws-mail-dbgsym



gdb -q 
set width 0
set pagination off
file /usr/bin/claws-mail
tb main
run

info target

0x00448cb0 - 0x006715b1 is .text

(gdb) find /b 0x00448cb0, 0x006715b1, 0x30, 0x85, 0xc0, 0x0f, 
0x84, 0xa4, 0x02, 0x00, 0x00, 0xc7, 0x05, 0x3e, 0xf6, 0x2e, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x31, 0xf6, 0x48, 0x89, 0xdf, 0xe8, 0xc0, 0xfc, 0xff, 0xff, 0x49, 
0x8b, 0x84, 0x24, 0x88, 0x00, 0x00, 0x00, 0x48, 0x85, 0xc0, 0x74, 0x19, 0x48, 
0x8b, 0x00, 0x31, 0xf6, 0x83, 0x38, 0x04, 0x48, 0x8b, 0x43, 0x50, 0x40, 0x0f, 
0x94, 0xc6, 0x48, 0x8b, 0x78, 0x30, 0xe8, 0x5a
0x4a3593 
1 pattern found.

(gdb) b * (0x4a3593 + 42)
Breakpoint 2 at 0x4a35bd: file folderview.c, line 2339.
(gdb) info b
Num Type   Disp Enb AddressWhat
2   breakpoint keep y   0x004a35bd in folderview_selected at 
folderview.c:2339

(gdb) disassemble /r 0x4a3593, 0x4a3593 + 62
Dump of assembler code from 0x4a3593 to 0x4a35d1:
   0x004a3593 :30 85 c0 0f 84 a4   
xor%al,-0x5b7bf040(%rbp)
   0x004a3599 :02 00   
add(%rax),%al
   0x004a359b :00 c7   
add%al,%bh
   0x004a359d :05 3e f6 2e 00  
add$0x2ef63e,%eax
   0x004a35a2 :00 00   
add%al,(%rax)
   0x004a35a4 :00 00   
add%al,(%rax)
   0x004a35a6 :31 f6   
xor%esi,%esi
   0x004a35a8 :48 89 df
mov%rbx,%rdi
   0x004a35ab :e8 c0 fc ff ff  
callq  0x4a3270 
   0x004a35b0 :49 8b 84 24 88 00 00 00 
mov0x88(%r12),%rax
   0x004a35b8 :48 85 c0
test   %rax,%rax
   0x004a35bb :74 19   
je 0x4a35d6 
   0x004a35bd :   >>>  48 8b 00
mov(%rax),%rax
   0x004a35c0 :31 f6   
xor%esi,%esi
   0x004a35c2 :83 38 04
cmpl   $0x4,(%rax)
   0x004a35c5 :48 8b 43 50 
mov0x50(%rbx),%rax
   0x004a35c9 :40 0f 94 c6 
sete   %sil
   0x004a35cd :48 8b 78 30 
mov0x30(%rax),%rdi
End of assembler dump.
(gdb) print 0x88
$2 = 136


(gdb) ptype /o FolderView
type = struct _FolderView {
/*0  | 8 */GtkWidget *scrolledwin;
/*8  | 8 */GtkWidget *ctree;
/*   16  | 8 */GtkWidget *headerpopupmenu;
/*   24  | 8 */GHashTable *popups;
/*   32  | 8 */GtkCMCTreeNode *selected;
/*   40  | 8 */GtkCMCTreeNode *opened;
/*   48  | 4 */gboolean open_folder;
/*   52  |12 */

Bug#972715: atril: segfault on opening an epub file

[Bernhard Übelacker]

Dear Maintainer,
I could reproduce this issue and attached patch avoids the crash.
This makes it possible to view at least some pages.
But there is still another issue with referencing the pages
containing a space in their names, which got encoded in
content.opf to %20, and atril encodes again to %2520.
I guess upstream needs to have a look at this epub.

Kind regards,
Bernhard
Description: Avoid crash on certain epub files

Author: Bernhard Übelacker 
Bug-Debian: https://bugs.debian.org/972715
Forwarded: no
Last-Update: 2020-11-01

Index: atril-1.24.0/backend/epub/epub-document.c
===
--- atril-1.24.0.orig/backend/epub/epub-document.c
+++ atril-1.24.0/backend/epub/epub-document.c
@@ -1280,7 +1280,7 @@ setup_document_index(EpubDocument *epub_
 		xml_parse_children_of_node(navLabel,(xmlChar*)"text",NULL,NULL);
 linknode *newnode = g_new0(linknode,1);
 		newnode->linktext = NULL;
-		while (newnode->linktext == NULL) {
+		while (xmlretval && newnode->linktext == NULL) {
 		newnode->linktext = (gchar*)xml_get_data_from_node(xmlretval,XML_KEYWORD,NULL);
 			xmlretval = xmlretval->next;
 		}
@@ -1599,7 +1599,7 @@ page_set_function(linknode *Link, GList
 	contentListNode *pagedata;
 
 	guint flag=0;
-	while (!flag) {
+	while (listiter && !flag) {
 		pagedata = listiter->data;
 		if (link_present_on_page(Link->pagelink, pagedata->value)) {
 			flag=1;


# Bullseye/testing amd64 qemu VM 2020-11-01


apt update
apt dist-upgrade


apt install systemd-coredump mc htop psmisc net-tools fakeroot quilt lightdm 
xserver-xorg mate rr gdb atril-dbgsym libglib2.0-0-dbgsym libatrilview3-dbgsym 
libatrildocument3-dbgsym
apt build-dep atril


reboot

# for current rr
dpkg --purge rr
apt install sshfs
echo 1 > /proc/sys/kernel/perf_event_paranoid
mkdir -p /home/bernhard/data/entwicklung/2020/rr
sshfs -o allow_other,uid=1000,gid=1000 
bernhard@192.168.178.25:/home/bernhard/data/entwicklung/2020/rr 
/home/bernhard/data/entwicklung/2020/rr




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


wget 
"https://arkhamarchivist.com/ebook/The%20Complete%20Works%20of%20HP%20Lovecraft.epub;
 -O Lovecraft.epub


export DISPLAY=:0
LANG=C atril /tmp/Lovecraft.epub



benutzer@debian:~$ export DISPLAY=:0
benutzer@debian:~$ LANG=C atril /tmp/Lovecraft.epub
Speicherzugriffsfehler (Speicherabzug geschrieben)


root@debian:~# journalctl -e
Nov 01 00:26:12 debian kernel: EvJobScheduler[8349]: segfault at 18 ip 
7fad28609570 sp 7fad20bfb8f8 error 4 in 
libepubdocument.so[7fad28608000+7000]
Nov 01 00:26:12 debian kernel: Code: 48 85 f6 74 0d 4c 89 e7 e8 bd ed ff ff e9 
10 ff ff ff ba 05 00 00 00 48 8d 35 84 5d 00 00 e9 38 ff ff ff 0f 1f 80 00 00 
00 00 <48> 8b 77 18 48 8b 3d a5 9a 00>
Nov 01 00:26:12 debian systemd[1]: Created slice 
system-systemd\x2dcoredump.slice.
Nov 01 00:26:12 debian systemd[1]: Started Process Core Dump (PID 8350/UID 0).
Nov 01 00:26:13 debian systemd[1]: systemd-coredump@0-8350-0.service: Succeeded.


root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Sun 2020-11-01 00:26:13 CET8336  1000  1000  11 present   /usr/bin/atril




root@debian:~# cd /home/benutzer/source/atril/orig/atril-1.24.0/backend/epub
root@debian:/home/benutzer/source/atril/orig/atril-1.24.0/backend/epub# 
coredumpctl gdb 8336
   PID: 8336 (atril)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 11 (SEGV)
 Timestamp: Sun 2020-11-01 00:26:12 CET (1min 37s ago)
  Command Line: atril /tmp/Lovecraft.epub
Executable: /usr/bin/atril
 Control Group: /user.slice/user-1000.slice/session-5.scope
  Unit: session-5.scope
 Slice: user-1000.slice
   Session: 5
 Owner UID: 1000 (benutzer)
   Boot ID: 6f6865f89dce40bd9780531de2826637
Machine ID: 33f18f39d2a9438eb75b0ed52848afcd
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.atril.1000.6f6865f89dce40bd9780531de2826637.8336.160418677200.zst
   Message: Process 8336 (atril) of user 1000 dumped core.

Stack trace of thread 8349:
#0  0x7fad28609570 n/a (libepubdocument.so + 0x3570)
#1  0x7fad2860a4d5 n/a (libepubdocument.so + 0x44d5)
#2  0x7fad3410e602 ev_document_load (libatrildocument.so.3 
+ 0x14602)
#3  0x7fad3411031b ev_document_factory_get_document 
(libatrildocument.so.3 + 0x1631b)
#4  0x7fad340c223c n/a (libatrilview.so.3 + 0x1f23c)
#5  0x7fad340c3242 n/a (libatrilview.so.3 + 0x20242)
#6  0x7fad3329ddbd n/a (libglib-2.0.so.0 + 0x7adbd)
#7  0x7fad330c5ea7 start_thread (libpthread.so.0 + 0x8ea7)
#8  0x7fad32ff5d4f __clone

Bug#973337: dh-runit: autopkgtest-virt-lxc failure on armel

[Bernhard Übelacker]

Hello Ryutaroh Matsumoto,
I just tried to reproduce this and got such a "Bus error" while
running an armhf testing chroot on a physical armv7l system,
unfortunately not running a stock debian kernel, instead
a lineageos kernel.

Here the "Bus error" is given because of an stmib instruction
operating on a unaligned memory address.
Unfortunately this happens inside something what looks like
stack swapping, therefore cannot point to the source of this
instruction.

Therefore you might have a look at 'cat /proc/cpu/alignment',
and maybe as a workaround change it temporarily
by 'echo 3 > /proc/cpu/alignment' and retest.

Attached file contains some debugging and a manual -v3 rebuild of
the testrunner showing the used compile and link parameters.

I guess this issue need some investigation of someone who
knows more about the ghc internals.

Kind regards,
Bernhard


=> 0xd0670: stmib   r1, {r9, lr}
(gdb) print/x $r1 % 4
$2 = 0x2


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


apt update
apt dist-upgrade


apt install mc htop psmisc net-tools strace sshfs wget gdb gdbserver 
autopkgtest dh-runit
apt build-dep dh-runint



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






mkdir /home/benutzer/source/dh-runit/orig -p
cd/home/benutzer/source/dh-runit/orig
apt source dh-runit
cd

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






autopkgtest dh-runit -- null
autopkgtest --shell-fail dh-runit -- null



benutzer@localhost:~$ autopkgtest dh-runit -- null
autopkgtest [16:04:08]: starting date: 2020-10-31
autopkgtest [16:04:08]: version 5.15
autopkgtest [16:04:08]: host localhost; command line: /usr/bin/autopkgtest 
dh-runit -- null
autopkgtest [16:04:08]: testbed dpkg architecture: armhf
autopkgtest [16:04:08]: testbed running kernel: Linux 3.4.113-g2fff5b1955c0 #1 
SMP PREEMPT Sun Mar 8 06:23:52 CST 2020
autopkgtest [16:04:08]:  apt-source dh-runit
gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/tmp/dpkg-verify-sig.Mw0OcQGe/trustedkeys.kbx': 
General error
gpgv: Signature made Di 21 Jul 2020 10:55:07 UTC
gpgv:using RSA key 92978A6E195E4921825F7FF0F34F09744E9F5DD9
gpgv: Can't check signature: No public key
dpkg-source: Warnung: Fehler beim Überprüfen der Signatur von 
./dh-runit_2.9.0.dsc
autopkgtest [16:04:10]: testing package dh-runit version 2.9.0
autopkgtest [16:04:10]: build not needed
autopkgtest [16:04:11]: test command1: preparing testbed
autopkgtest [16:04:11]: test command1: make autopkgtest
autopkgtest [16:04:11]: test command1: [---
ghc testrunner.hs
[1 of 1] Compiling Main ( testrunner.hs, testrunner.o )
Linking testrunner ...
AUTOPKGTEST=1 ./testrunner
Bus error
make: *** [Makefile:7: autopkgtest] Error 135
autopkgtest [16:04:29]: test command1: ---]
autopkgtest [16:04:29]: test command1:  - - - - - - - - - - results - - - - - - 
- - - -
command1 FAIL non-zero exit status 2
autopkgtest [16:04:29]: test command1:  - - - - - - - - - - stderr - - - - - - 
- - - -
Bus error
make: *** [Makefile:7: autopkgtest] Error 135
autopkgtest [16:04:29]:  summary
command1 FAIL non-zero exit status 2
benutzer@localhost:~$


benutzer@localhost:~/autopkgtest-dh-runit-output$ autopkgtest --shell-fail 
dh-runit -- null
autopkgtest [16:10:06]: starting date: 2020-10-31
autopkgtest [16:10:06]: version 5.15
autopkgtest [16:10:06]: host localhost; command line: /usr/bin/autopkgtest 
--shell-fail dh-runit -- null
autopkgtest [16:10:07]: testbed dpkg architecture: armhf
autopkgtest [16:10:07]: testbed running kernel: Linux 3.4.113-g2fff5b1955c0 #1 
SMP PREEMPT Sun Mar 8 06:23:52 CST 2020
autopkgtest [16:10:07]:  apt-source dh-runit
gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/tmp/dpkg-verify-sig.G8OGzlGp/trustedkeys.kbx': 
General error
gpgv: Signature made Di 21 Jul 2020 10:55:07 UTC
gpgv:  

Bug#972286: coreutils: Crash when using globs on a path with non-latin characters

[Bernhard Übelacker]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wall
uname output: Linux debian 5.9.0-1-amd64 #1 SMP Debian 5.9.1-1 (2020-10-17) 
x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 5.1
Patch Level: 0
Release Status: rc1



Description:

Dear Maintainer,
I tried to collect some more information for the bug described in [1]
and could reproduce the crash just by repeating the given commands
in a minimal debian testing qemu VM. Backtrace in [2].
The last bash version where the crash did not manifest was bash_5.0-7.

In #972672 the last message mentions also wdequote_pathname and
wcsrtombs, therefore I guess this might be related.

As wcsrtombs[3] is specified to set under certain circumstances *src to 
NULL,
I assume in this line [4] wpathname should not get dereferenced, or
at least just after being checked for a non-NULL value.

Kind regards,
Bernhard


Repeat-By:
mkdir ~/ಇಳಿಕೆಗಳು
touch ~/ಇಳಿಕೆಗಳು/{a,b}.txt
ls ~/ಇಳಿಕೆಗಳು/*.txt


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

[2]
(rr) bt
#0  0x5575f65a24fb in wdequote_pathname 
(pathname=pathname@entry=0x5575f798b870 "/home/benutzer/ಇಳಿಕೆಗಳು/") at 
../../.././lib/glob/glob.c:487
#1  0x5575f65a30eb in dequote_pathname (pathname=0x5575f798b870 
"/home/benutzer/ಇಳಿಕೆಗಳು/") at ../../.././lib/glob/glob.c:504
#2  glob_filename (pathname=pathname@entry=0x5575f7a733e0 
"/\\h\\o\\m\\e/\\b\\e\\n\\u\\t\\z\\e\\r/ಇಳಿಕೆಗಳು/*.txt", flags=0) at 
../../.././lib/glob/glob.c:1466
#3  0x5575f656dc2d in shell_glob_filename (pathname=, 
qflags=qflags@entry=8) at .././pathexp.c:470
#4  0x5575f655b3e6 in glob_expand_word_list (tlist=0x5575f7a62c20, 
eflags=31) at .././subst.c:11383
#5  0x5575f6568685 in expand_word_list_internal (eflags=31, 
list=) at .././subst.c:11983
#6  expand_words (list=) at .././subst.c:11331
#7  0x5575f653a5f3 in execute_simple_command 
(fds_to_close=0x5575f7a73280, async=0, pipe_out=-1, pipe_in=-1, 
simple_command=) at .././execute_cmd.c:4377
#8  execute_command_internal (command=0x5575f79af5c0, 
asynchronous=, pipe_in=-1, pipe_out=, 
fds_to_close=0x5575f7a73280) at .././execute_cmd.c:846
#9  0x5575f653b865 in execute_command (command=0x5575f79af5c0) at 
.././execute_cmd.c:395
#10 0x5575f65219db in reader_loop () at .././eval.c:170
#11 0x5575f6520668 in main (argc=1, argv=0x7ffc8d1bfda8, 
env=0x7ffc8d1bfdb8) at .././shell.c:811

[3] https://man7.org/linux/man-pages/man3/wcsrtombs.3.html

[4] https://sources.debian.org/src/bash/5.1%7Erc1-2/lib/glob/glob.c/#L487


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


apt update
apt dist-upgrade


apt install systemd-coredump mc htop psmisc net-tools gdb bash-dbgsym
apt build-dep bash

# for current rr
apt install systemd-coredump mc htop sshfs libcapnp-dev gdb
echo 1 > /proc/sys/kernel/perf_event_paranoid
mkdir -p /home/bernhard/data/entwicklung/2020/rr
sshfs -o allow_other,uid=1000,gid=1000 
bernhard@192.168.178.25:/home/bernhard/data/entwicklung/2020/rr 
/home/bernhard/data/entwicklung/2020/rr




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

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



dpkg-reconfigure locales
# add kn_IN.UTF-8


export LANG=kn_IN.UTF-8

mkdir ~/ಇಳಿಕೆಗಳು
touch ~/ಇಳಿಕೆಗಳು/{a,b}.txt
ls ~/ಇಳಿಕೆಗಳು/*.txt

benutzer@debian:~$ mkdir ~/ಇಳಿಕೆಗಳು
benutzer@debian:~$ touch ~/ಇಳಿಕೆಗಳು/{a,b}.txt
benutzer@debian:~$ ls ~/ಇಳಿಕೆಗಳು/*.txt
Connection to 127.0.254.89 closed.




journalctl -e
Okt 30 16:57:24 debian systemd[1]: Started Process Core Dump (PID 3129/UID 0).
Okt 30 16:57:24 debian sshd[2240]: Received disconnect from 10.0.2.2 port 
41368:11: disconnected by user
Okt 30 16:57:24 debian sshd[2240]: Disconnected from user benutzer 10.0.2.2 
port 41368
Okt 30 16:57:24 debian systemd[1]: session-3.scope: Succeeded.
Okt 30 16:57:24 debian sshd[2234]: pam_unix(sshd:session): session closed for 
user benutzer
Okt 30 16:57:24 debian systemd-logind[417]: Session 3 logged out. Waiting for 
processes to exit.
Okt 30 16:57:24 debian systemd-logind[417]: Removed session 3.
Okt 30 16:57:24 debian systemd-coredump[3130]: Process 2241 (bash) of user 1000 
dumped core.
   
   Stack trace of thread 2241:
   #0  0x7fdfef00afe7 kill 
(libc.so.6 + 0x3bfe7)
   #1  0x560e12312776 n/a (bash 
+ 0x7f776)
   #2  0x560e12312961 
termsig_sighandler (bash + 0x7f961)
   #3  0x7fdfef00acc0 n/a 
(libc.so.6 + 0x3bcc0)
   

Bug#955403: bedtools ftbfs, failing tests on armel, armhf, i386, mipsel

[Bernhard Übelacker]

Dear Maintainer,
I just tried to have a look at these failing tests "sample" and "slop",
and found both are caused by having variables of type long.
These have a sizeof of 4 on these 32 bit systems, while the usage
suggests they are expected to be 8 bytes.

Attached patch replaces the use of long by CHRPOS in the places where
they cause the tests to fail. With it applied they succeed when
building at i386 and armhf with current testing.

Kind regards,
Bernhard
Description: Use a variable type that is 8 bytes in size on 32 bit systems too.

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

Index: bedtools-2.29.2+dfsg/src/randomBed/randomBed.cpp
===
--- bedtools-2.29.2+dfsg.orig/src/randomBed/randomBed.cpp
+++ bedtools-2.29.2+dfsg/src/randomBed/randomBed.cpp
@@ -58,7 +58,7 @@ void BedRandom::Generate()
 // we need to combine two consective calls to rand()
 // because RAND_MAX is 2^31 (2147483648), whereas
 // mammalian genomes are obviously much larger.
-CHRPOS randStart = long) rand()) << 31) | rand()) % genomeSize;
+CHRPOS randStart = CHRPOS) rand()) << 31) | ((CHRPOS) rand())) % genomeSize;
 // use the above randomStart (e.g., for human 0..3.1billion) 
 // to identify the chrom and start on that chrom.
 pair location = _genome->projectOnGenome(randStart);
Index: bedtools-2.29.2+dfsg/src/slopBed/slopBed.cpp
===
--- bedtools-2.29.2+dfsg.orig/src/slopBed/slopBed.cpp
+++ bedtools-2.29.2+dfsg/src/slopBed/slopBed.cpp
@@ -67,7 +67,7 @@ void BedSlop::SlopBed() {
}
_bed->Close();
 }
-static inline long _normalize_coord(long size, long pos) {
+static inline CHRPOS _normalize_coord(CHRPOS size, CHRPOS pos) {
 	if(pos < 0) return 0;
 	if(size >= 0 && pos > size) return size;
 	return pos;
@@ -84,8 +84,8 @@ void BedSlop::AddSlop(BED ) {
 	}
 
 	bool should_swap = _forceStrand && bed.strand == "-";
-	long left_slop = should_swap ? (long)_rightSlop : (long)_leftSlop;
-	long right_slop = should_swap ? (long)_leftSlop : (long)_rightSlop;
+	CHRPOS left_slop = should_swap ? (CHRPOS)_rightSlop : (CHRPOS)_leftSlop;
+	CHRPOS right_slop = should_swap ? (CHRPOS)_leftSlop : (CHRPOS)_rightSlop;
 
 	bed.start -= left_slop;
 	bed.end += right_slop;

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#972499: cinnamon-control-center: SIGABRT while opening Graphics Tablet settings

[Bernhard Übelacker]

Dear Maintainer,
this issue seems to be reported upstream already.
There is also a workaround mentioned to modify a "Styli=@..." setting.

Kind regards,
Bernhard

https://github.com/linuxmint/cinnamon-control-center/issues/250
https://github.com/linuxmint/cinnamon-control-center/issues/245
https://github.com/linuxmint/cinnamon-control-center/issues/212
https://github.com/linuxmint/cinnamon-control-center/issues/212#issuecomment-681278552

Bug#972637: finch: crashes on startup with "illegal instruction"

[Bernhard Übelacker]

Hello Karsten,
thanks for the information - that explains why my emulated pentium
failed already at 0x...6bb because not supporting sse at all.

>From wikipedia [1] the pminud instruction at 0x...6fb got
introduced with sse4.1 which seem not supported from your
flags line (while on the other side intel says [2] it is a Penryn).
(Might there be a bios switch?)

Kind regards,
Bernhard

[1] https://en.wikipedia.org/wiki/SSE4
[2] 
https://ark.intel.com/content/www/de/de/ark/products/37253/intel-pentium-processor-t4300-1m-cache-2-10-ghz-800-mhz-fsb.html

Bug#972637: finch: crashes on startup with "illegal instruction"

[Bernhard Übelacker]

Hello Karsten,
I tried to collect some more information for the maintainer and
could reproduce this (or nearly) the same SIGILL with a qemu VM limited
to a pentium class CPU.

The instruction in question might these below:

   0xb78816bb <+75>:movd   0x4(%esi),%xmm2 (here I received the SIGILL)
   0xb78816fb <+139>:   pminud %xmm2,%xmm3 (thats from your backtrace 
the similar address offset 0x...6fb)

Both access a register xmm2/xmm3 which seems to be "just"
available on CPUs having the SSE extension.

Therefore it would be interesting to know with which CPU you
are getting this SIGILL (e.g. 'lscpu' or 'cat /proc/cpuinfo').

Otherwise finch seems not to depend directly from intel-media-va-driver,
and from the package description if your CPU is older than "Broadwell",
then you might even not benefit from this package. Therefore a
workaround might be to uninstall intel-media-va-driver if no
other dependencies require it?

Kind regards,
Bernhard


# Bullseye/testing i386 qemu VM 2020-10-26 (with -cpu pentium)


apt update
apt dist-upgrade


apt install systemd-coredump mc htop psmisc net-tools strace gdb 
intel-media-va-driver intel-media-va-driver-dbgsym coreutils-dbgsym


gdb -q
set width 0
set pagination off
file /bin/ls
b main
run

#b call_init
call __dlopen("/usr/lib/i386-linux-gnu/dri/iHD_drv_video.so", 4354)
bt
disassemble

0xb78816b9













benutzer@debian:~$ gdb -q
(gdb) set width 0
(gdb) set pagination off
(gdb) file /bin/ls
Reading symbols from /bin/ls...
Reading symbols from 
/usr/lib/debug/.build-id/00/695414aa5413c8667e62c2362d119cb233a504.debug...
(gdb) b main
Breakpoint 1 at 0x2770: file src/ls.c, line 1622.
(gdb) run
Starting program: /bin/ls 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".

Breakpoint 1, main (argc=1, argv=0xb744) at src/ls.c:1622
1622src/ls.c: Datei oder Verzeichnis nicht gefunden.
(gdb) call __dlopen("/usr/lib/i386-linux-gnu/dri/iHD_drv_video.so", 4354)

Program received signal SIGILL, Illegal instruction.
std::__cxx11::basic_string, std::allocator 
>::basic_string (__str=..., this=0x42fc50) at 
/usr/include/c++/10/bits/basic_string.h:569
569 /usr/include/c++/10/bits/basic_string.h: Datei oder Verzeichnis nicht 
gefunden.
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(__dlopen) will be abandoned.
When the function is done executing, GDB will silently stop.
(gdb) bt
#0  std::__cxx11::basic_string, 
std::allocator >::basic_string (__str=..., this=0x42fc50) at 
/usr/include/c++/10/bits/basic_string.h:569
#1  std::pair, 
std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)>::pair, std::allocator >, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*), true> (__p=..., this=0x42fc50) at 
/usr/include/c++/10/bits/stl_pair.h:373
#2  
__gnu_cxx::new_allocator, std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)> > 
>::construct, 
std::allocator > const, DdiMediaDecode* (*)(DDI_DECODE_CONFIG_ATTR*)>, 
std::pair, 
std::allocator >, DdiMediaDecode* (*)(DDI_DECODE_CONFIG_ATTR*)> > 
(this=0xb7ceb8b0 ::GetCreators[abi:cxx11]()::creators>, __p=0x42fc50) at 
/usr/include/c++/10/ext/new_allocator.h:150
#3  
__gnu_cxx::new_allocator, std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)> > 
>::construct, 
std::allocator > const, DdiMediaDecode* (*)(DDI_DECODE_CONFIG_ATTR*)>, 
std::pair, 
std::allocator >, DdiMediaDecode* (*)(DDI_DECODE_CONFIG_ATTR*)> > 
(__p=0x42fc50, this=0xb7ceb8b0 ::GetCreators[abi:cxx11]()::creators>) at 
/usr/include/c++/10/ext/new_allocator.h:148
#4  
std::allocator_traits, std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)> > > 
>::construct, 
std::allocator > const, DdiMediaDecode* (*)(DDI_DECODE_CONFIG_ATTR*)>, 
std::pair, 
std::allocator >, DdiMediaDecode* (*)(DDI_DECODE_CONFIG_ATTR*)> > 
(__p=0x42fc50, __a=...) at /usr/include/c++/10/bits/alloc_traits.h:512
#5  std::_Rb_tree, 
std::allocator >, std::pair, std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)>, 
std::_Select1st, std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)> >, std::less, std::allocator > >, 
std::allocator, std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)> > 
>::_M_construct_node, std::allocator >, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)> > (__node=0x42fc40, this=0xb7ceb8b0 
::GetCreators[abi:cxx11]()::creators>) at 
/usr/include/c++/10/bits/stl_tree.h:618
#6  std::_Rb_tree, 
std::allocator >, std::pair, std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)>, 
std::_Select1st, std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)> >, std::less, std::allocator > >, 
std::allocator, std::allocator > const, DdiMediaDecode* 

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#971645: sshfs: truncates timestamps to whole seconds

[Bernhard Übelacker]

Am 19.10.20 um 23:43 schrieb Adam Borowski:
> On Mon, Oct 19, 2020 at 10:52:45PM +0200, Bernhard Übelacker wrote:
>> Dear Maintainer,
>> tried to track where the time is set/retrieved for a remote file
>> and came up with this location [1].
>>
>> I am not sure if flag 
>> SSH_FILEXFER_ATTR_ACMODTIME/SSH2_FILEXFER_ATTR_ACMODTIME
>> is the only possible way ssh has to transfer the date, but at
>> least that way seems to just use 32 bits without the nano seconds.
>>
>> Unfortunately the "has no historic wire protocols" might not be
>> completely true because sshfs relies on ssh, which shows a similar
>> limitation also with sftp/scp.
> 
> Looks like I've misread something, and such historic wire protocols indeed
> exist for sftp (which sshfs uses).  On the other hand, they're long-expired
> drafts of the protocol.
> 
> The granularity was 1s up to Draft 03:
> https://tools.ietf.org/html/draft-ietf-secsh-filexfer-03
> then changed to 1ns if SSH_FILEXFER_ATTR_SUBSECOND_TIMES is defined, in
> Draft 04:
> https://tools.ietf.org/html/draft-ietf-secsh-filexfer-04
> 
> Thus, using that flag will stop timestamp truncation.  (Well, programs that
> can't cope with truncated timestamps are buggy, but...)
> 
> I have no idea if there are servers based on old drafts in the wild.
> 
> 
> Meow!
> 


Unfortunately I failed to find any appearance of SUBSECOND in
the openssh-server source.

Looking in openssh bug tracker this bug might be interesting
and specifically mentions SSHFS:
https://bugzilla.mindrot.org/show_bug.cgi?id=1555

It mentions that "the patch" got included, but that seems just right
for the "l...@openssh.com"/"hardl...@openssh.com" part of the patches.
But the attr extension patches seem not to have applied upstream.

Kind regards,
Bernhard

Bug#971645: sshfs: truncates timestamps to whole seconds

[Bernhard Übelacker]

Dear Maintainer,
tried to track where the time is set/retrieved for a remote file
and came up with this location [1].

I am not sure if flag SSH_FILEXFER_ATTR_ACMODTIME/SSH2_FILEXFER_ATTR_ACMODTIME
is the only possible way ssh has to transfer the date, but at
least that way seems to just use 32 bits without the nano seconds.

Unfortunately the "has no historic wire protocols" might not be
completely true because sshfs relies on ssh, which shows a similar
limitation also with sftp/scp.

Kind regards,
Bernhard


[1]
(rr) bt
#0  0x55c9a06ba46b in buf_get_attrs (buf=0x7f994b5d6b50, 
stbuf=, flagsp=) at ../sshfs.c:912
#1  0x55c9a06bfe66 in sshfs_getattr (path=, 
stbuf=0x7f994b5d6c80, fi=) at ../sshfs.c:3393
#2  0x55c9a06c184d in cache_getattr (fi=0x0, stbuf=0x7f994b5d6c80, 
path=0x7f993c000c30 "/.bash_history") at ../cache.c:272
#3  cache_getattr (path=0x7f993c000c30 "/.bash_history", 
stbuf=0x7f994b5d6c80, fi=0x0) at ../cache.c:266
#4  0x7f994c67a557 in lookup_path (f=0x55c9a07270e0, nodeid=1, 
name=0x7f994a9d5038 ".bash_history", path=, e=0x7f994b5d6c70, 
fi=) at ../lib/fuse.c:2537
#5  0x7f994c67a66b in fuse_lib_lookup (req=0x7f993c000b60, parent=1, 
name=) at ../lib/fuse.c:2725
#6  0x7f994c687a83 in fuse_session_process_buf_int (se=0x55c9a07274b0, 
buf=buf@entry=0x7f9944000b80, ch=) at ../lib/fuse_lowlevel.c:2666
#7  0x7f994c683393 in fuse_do_work (data=0x7f9944000b60) at 
../lib/fuse_loop_mt.c:163
#8  0x7f994c655ea7 in start_thread (arg=) at 
pthread_create.c:477
#9  0x7f994c456d4f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

866 if ((flags & SSH_FILEXFER_ATTR_ACMODTIME)) {
867 if (buf_get_uint32(buf, ) == -1 ||
868 buf_get_uint32(buf, ) == -1)
...
912 stbuf->st_ctime = stbuf->st_mtime = mtime;


[2]
benutzer@debian:~$ touch --date="2260-10-18 00:00:00.123456789" 
/tmp/future-test-a
benutzer@debian:~$ scp -p benutzer@localhost:/tmp/future-test-a 
/tmp/future-test-c
benutzer@localhost's password: 
future-test-a   

 100%0 0.0KB/s   00:00
benutzer@debian:~$ sftp -p benutzer@localhost:/tmp/future-test-a 
/tmp/future-test-b
benutzer@localhost's password: 
Connected to localhost.
Fetching /tmp/future-test-a to /tmp/future-test-b
benutzer@debian:~$ ls -lisah --full-time /tmp/future-test*
70 0 -rw-r--r-- 1 benutzer benutzer 0 2260-10-18 00:00:00.123456789 +0200 
/tmp/future-test-a
74 0 -rw-r--r-- 1 benutzer benutzer 0 1988-08-04 11:03:28.0 +0200 
/tmp/future-test-b
73 0 -rw-r--r-- 1 benutzer benutzer 0 2260-10-18 00:00:00.0 +0200 
/tmp/future-test-c

Bug#951000: xfce4-panel: constant CPU consumption when displaying logout menu

[Bernhard Übelacker]

Dear Maintainer,
could reproduce this inside a minimal amd64 qemu VM in current testing.
In my test Xorg consumed on CPU completely, another thread 
xfce4/panel/wrapper-2.0
used 6% when this menu is opened.

It looked like this process triggers redrawing in a fast loop, which
seem most expensive on Xorg side.

Another thing that might be related is this logging message that is
constructed but never appears in any logfile as I see:


#0  __vasprintf_internal (result_ptr=result_ptr@entry=0x7ffd775615b0, 
format=0x7fe32cafc6e8 "State %u for %s %p doesn't match state %u set via 
gtk_style_context_set_state ()", format@entry=0x7ffd775615b0 "", 
args=0x7ffd775615d8, mode_flags=mode_flags@entry=2) at vasprintf.c:34
...
#5  0x7fe32c1274dd in g_log_structured_standard 
(log_domain=log_domain@entry=0x7fe32ca94047 "Gtk", 
log_level=log_level@entry=G_LOG_LEVEL_DEBUG, file=file@entry=0x7fe32cafc740 
"../../../../gtk/gtkstylecontext.c", line=, func=, message_format=) at ../../../glib/gmessages.c:1976
#6  0x7fe32c990a64 in gtk_style_context_push_state 
(context=context@entry=0x5601349a9150, state=state@entry=GTK_STATE_FLAG_NORMAL) 
at ../../../../gtk/gtkstylecontext.c:525
...


Kind regards,
Bernhard


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


apt update
apt dist-upgrade


apt install systemd-coredump mc htop psmisc net-tools gdb xfce4 
libxfce4panel-2.0-4-dbgsym libglib2.0-0-dbgsym xserver-xorg-core-dbgsym 
libpixman-1-0-dbgsym libgtk-3-0-dbgsym libx11-6-dbgsym libxcb1-dbgsym linux-perf
apt build-dep libxfce4panel-2.0-4


reboot


mkdir /home/benutzer/source/libxfce4panel-2.0-4/orig -p
cd/home/benutzer/source/libxfce4panel-2.0-4/orig
apt source libxfce4panel-2.0-4
cd


# Login
# Open "User menu"


taskset -pc 14 542
taskset -pc 15 876


root@debian:~# ps aux | grep -E "^USER|876|542"
USER PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
root 542 27.6  2.9 2628860 90952 tty7Rsl+ 21:54  10:10 
/usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp 
vt7 -novtswitch
benutzer 876  1.4  5.9 203028 182108 ?   Sl   21:54   0:31 
/usr/lib/x86_64-linux-gnu/xfce4/panel/wrapper-2.0 
/usr/lib/x86_64-linux-gnu/xfce4/panel/plugins/libactions.so 14 14680075 actions 
Aktionsknöpfe Abmelden, sperren oder andere Systemaktionen


perf record -p 876 -g
perf report


(gdb) bt
#0  __vasprintf_internal (result_ptr=result_ptr@entry=0x7ffd775615b0, 
format=0x7fe32cafc6e8 "State %u for %s %p doesn't match state %u set via 
gtk_style_context_set_state ()", format@entry=0x7ffd775615b0 "", 
args=0x7ffd775615d8, mode_flags=mode_flags@entry=2) at vasprintf.c:34
#1  0x7fe32c016238 in __vasprintf_chk 
(result_ptr=result_ptr@entry=0x7ffd775615b0, flag=flag@entry=1, 
format=format@entry=0x7ffd775615b0 "", ap=) at vasprintf_chk.c:36
#2  0x7fe32c16c47f in vasprintf (__ap=, __fmt=0x7ffd775615b0 
"", __ptr=0x7ffd775615b0) at /usr/include/x86_64-linux-gnu/bits/stdio2.h:213
#3  g_vasprintf (string=string@entry=0x7ffd775615b0, format=, 
args=args@entry=0x7ffd775615d8) at ../../../glib/gprintf.c:337
#4  0x7fe32c13f95d in g_strdup_vprintf (format=, 
args=args@entry=0x7ffd775615d8) at ../../../glib/gstrfuncs.c:519
#5  0x7fe32c1274dd in g_log_structured_standard 
(log_domain=log_domain@entry=0x7fe32ca94047 "Gtk", 
log_level=log_level@entry=G_LOG_LEVEL_DEBUG, file=file@entry=0x7fe32cafc740 
"../../../../gtk/gtkstylecontext.c", line=, func=, message_format=) at ../../../glib/gmessages.c:1976
#6  0x7fe32c990a64 in gtk_style_context_push_state 
(context=context@entry=0x5601349a9150, state=state@entry=GTK_STATE_FLAG_NORMAL) 
at ../../../../gtk/gtkstylecontext.c:525
#7  0x7fe32c991761 in gtk_style_context_get_property 
(context=0x5601349a9150, property=0x560133f65582 "background-color", 
state=GTK_STATE_FLAG_NORMAL, value=0x7ffd77561c00) at 
../../../../gtk/gtkstylecontext.c:840
#8  0x7fe32c991945 in gtk_style_context_get_valist 
(context=context@entry=0x5601349a9150, state=state@entry=GTK_STATE_FLAG_NORMAL, 
args=args@entry=0x7ffd77561cb0) at ../../../../gtk/gtkstylecontext.c:876
#9  0x7fe32c991c3a in gtk_style_context_get (context=0x5601349a9150, 
state=state@entry=GTK_STATE_FLAG_NORMAL) at 
../../../../gtk/gtkstylecontext.c:918
#10 0x560133f63ca3 in wrapper_plug_draw (widget=0x560134bd2470, 
cr=0x560134b9dc00) at wrapper-plug.c:221
#11 0x7fe32ca3c144 in gtk_widget_draw_internal 
(widget=widget@entry=0x560134bd2470, cr=cr@entry=0x560134b9dc00, 
clip_to_size=clip_to_size@entry=1) at ../../../../gtk/gtkwidget.c:7080
#12 0x7fe32ca45740 in gtk_widget_render 
(widget=widget@entry=0x560134bd2470, window=0x5601348f5900, region=) at ../../../../gtk/gtkwidget.c:17606
#13 0x7fe32c8e6798 in gtk_main_do_event (event=0x7ffd77561f50) at 
../../../../gtk/gtkmain.c:1843
#14 gtk_main_do_event (event=) at ../../../../gtk/gtkmain.c:1690
#15 0x7fe32c5d0775 in _gdk_event_emit (event=event@entry=0x7ffd77561f50) at 
../../../../gdk/gdkevents.c:73
#16 

Bug#961559: pcmanfm: Rename folder in left side pane directory tree crashes pcmanfm

[Bernhard Übelacker]

Dear Maintainer,
tried to reproduce but found pcmanfm not crashing.
Instead the process "just" exits without error or crash.

As we leave the main loop without error I tried setting a
breakpoint to g_main_loop_quit and it got hit multiple times.
I guess this last call to g_main_loop_quit is related, as it
received the same loop pointer as the g_main_loop_run is
operating on.

Kind regards,
Bernhard


Thread 1 "pcmanfm" hit Breakpoint 2, g_main_loop_quit (loop=0x5581b8a0) at 
../../../glib/gmain.c:4312
4312in ../../../glib/gmain.c
(gdb) bt
#0  g_main_loop_quit (loop=0x5581b8a0) at ../../../glib/gmain.c:4312
#1  0x773a110e in g_object_unref (_object=) at 
../../../gobject/gobject.c:3503
#2  g_object_unref (_object=0x5563a020) at ../../../gobject/gobject.c:3395
#3  0x7739c092 in g_closure_invoke (closure=, 
return_value=, n_param_values=, 
param_values=, invocation_hint=) at 
../../../gobject/gclosure.c:810
#4  0x773ae3e3 in signal_emit_unlocked_R 
(node=node@entry=0x557f1ad0, detail=detail@entry=0, 
instance=instance@entry=0x55847d40, 
emission_return=emission_return@entry=0x0, 
instance_and_params=instance_and_params@entry=0x7fffe070) at 
../../../gobject/gsignal.c:3738
#5  0x773b467f in g_signal_emit_valist (instance=, 
signal_id=, detail=, 
var_args=var_args@entry=0x7fffe1f0) at ../../../gobject/gsignal.c:3494
#6  0x773b4bef in g_signal_emit 
(instance=instance@entry=0x55847d40, signal_id=, 
detail=detail@entry=0) at ../../../gobject/gsignal.c:3550
#7  0x775f7930 in fm_job_emit_finished (job=0x55847d40) at 
job/fm-job.c:578
#8  on_idle_cleanup (unused=) at job/fm-job.c:578
#9  0x772f in g_main_dispatch (context=0x555d8180) at 
../../../glib/gmain.c:3325
#10 g_main_context_dispatch (context=0x555d8180) at 
../../../glib/gmain.c:4016
#11 0x772aae58 in g_main_context_iterate (context=0x555d8180, 
block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
../../../glib/gmain.c:4092
#12 0x772ab14b in g_main_loop_run (loop=0x5581b8a0) at 
../../../glib/gmain.c:4290
#13 0x77af512a in gtk_main () from 
/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#14 0x55569516 in main (argc=, argv=) at 
pcmanfm.c:282

Bug#966174: okular: none

[Bernhard Übelacker]

Dear Maintainer,
I could reproduce it with the state of Debian testing at 2020-07-24.

Upstream bugs seem to be these:
  https://bugs.kde.org/show_bug.cgi?id=407338
  https://gitlab.freedesktop.org/poppler/poppler/-/issues/766

The issue seems to be resolved since poppler 0.77 and above.

Kind regards,
Bernhard


(gdb) bt
#0  0x7f298027ad75 in SECMOD_ReferenceModule (module=0x0) at pk11util.c:874
#1  0x7f298027b2fc in SECMOD_AddModule (newModule=0x5568b72ec210) at 
pk11util.c:568
#2  SECMOD_AddModule (newModule=0x5568b72ec210) at pk11util.c:546
#3  0x7f298027b3a0 in SECMOD_AddNewModuleEx (moduleName=, 
dllPath=0x7f29805e2e8f "libnssckbi.so", defaultMechanismFlags=0, 
cipherEnableFlags=0, modparms=0x0, nssparms=) at pk11util.c:722
#4  0x7f2980597529 in SignatureHandler::SignatureHandler 
(this=0x7ffe3141cfb0, p7=0x5568b7595f70 
"0\202)\206\006\t*\206H\206\367\r\001\a\002\240\202)w0\202)s\002\001\001\061\v0\t\006\005+\016\003\002\032\005",
 p7_length=13815) at ./poppler/SignatureHandler.cc:136
#5  0x7f298048cf2c in FormFieldSignature::validateSignature 
(forceRevalidation=, validationTime=4294967295, 
doVerifyCert=true, this=0x5568b7580420) at ./poppler/Form.cc:1722
#6  FormFieldSignature::validateSignature (this=0x5568b7580420, 
doVerifyCert=, forceRevalidation=, 
validationTime=4294967295) at ./poppler/Form.cc:1689
#7  0x7f29806a8384 in Poppler::FormFieldSignature::validate 
(this=this@entry=0x5568b7580320, opt=opt@entry=1, validationTime=...) at 
./qt5/src/poppler-form.cc:681
#8  0x7f29806a88e0 in Poppler::FormFieldSignature::validate 
(this=0x5568b7580320, 
opt=opt@entry=Poppler::FormFieldSignature::ValidateVerifyCertificate) at 
./qt5/src/poppler-form.cc:674
#9  0x7f298070180b in PopplerFormFieldSignature::PopplerFormFieldSignature 
(this=0x5568b75807d0, field=std::unique_ptr 
= {...}) at /usr/include/c++/9/bits/unique_ptr.h:360
...


# Bullseye/testing amd64 qemu VM 2020-07-24


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


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



apt update
apt dist-upgrade


apt install systemd-coredump mc htop psmisc net-tools strace lightdm 
xserver-xorg openbox xterm gdb okular okular-dbgsym libkf5parts5-dbgsym 
libokular5core9-dbgsym libpoppler-qt5-1-dbgsym libpoppler82-dbgsym 
libnss3-dbgsym


wget https://www.boe.es/boe/dias/2018/04/26/pdfs/BOE-A-2018-5704.pdf


export DISPLAY=:0
okular BOE-A-2018-5704.pdf



benutzer@debian:~$ okular BOE-A-2018-5704.pdf
Icon theme "breeze" not found.
Icon theme "breeze" not found.
Speicherzugriffsfehler (Speicherabzug geschrieben)


root@debian:~# journalctl -e
Okt 17 11:31:01 debian kernel: okular[776]: segfault at 38 ip 7f298027ad75 
sp 7ffe3141ced0 error 4 in libnss3.so[7f2980233000+f2000]
Okt 17 11:31:01 debian kernel: Code: 84 fb ff 48 85 c0 74 0f 48 c7 00 00 00 00 
00 48 c7 40 08 00 00 00 00 48 83 c4 08 c3 66 0f 1f 84 00 00 00 00 00 41 54 49 
89 fc <48> 8b 7f 38 e8 12 9b fb ff 41 83 44 24 40 01 49 8b 7c 24 38 e8 b2
Okt 17 11:31:01 debian systemd[1]: Created slice 
system-systemd\x2dcoredump.slice.
Okt 17 11:31:01 debian systemd[1]: Started Process Core Dump (PID 811/UID 0).
Okt 17 11:31:02 debian systemd-coredump[812]: Process 776 (okular) of user 1000 
dumped core.
  
  Stack trace of thread 776:
  #0  0x7f298027ad75 
SECMOD_ReferenceModule (libnss3.so + 0x60d75)
  #1  0x7f298027b2fc n/a 
(libnss3.so + 0x612fc)
  #2  0x7f298027b3a0 
SECMOD_AddNewModuleEx (libnss3.so + 0x613a0)
  #3  0x7f2980597529 
_ZN16SignatureHandlerC2EPhi (libpoppler.so.82 + 0x228529)
  #4  0x7f298048cf2c 
_ZN18FormFieldSignature17validateSignatureEbbl (libpoppler.so.82 + 0x11df2c)
  #5  0x7f29806a8384 
_ZNK7Poppler18FormFieldSignature8validateEiRK9QDateTime (libpoppler-qt5.so.1 + 
0x48384)
  #6  0x7f29806a88e0 
_ZNK7Poppler18FormFieldSignature8validateENS0_15ValidateOptionsE 
(libpoppler-qt5.so.1 + 0x488e0)
  #7  0x7f298070180b n/a 
(okularGenerator_poppler.so + 0x2580b)
  #8  0x7f29806f5f94 

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 = _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#967079: gimp: After completing a batch conversion with David's Batch Processor, pressed Close button and got Crash message for the batch program and shortly after for GIMP itself.

[Bernhard Übelacker]

> #6  0x7f3e13f61730 in  () at 
> /lib/x86_64-linux-gnu/libpthread.so.0
> #7  0x7f3e1424ceba in g_type_check_value_holds () at 
> /lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #8  0x7f3e142526f9 in g_value_get_int () at 
> /lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #9  0x5604fd828b2b in plug_in_params_to_args ()
> #10 0x5604fd81d003 in gimp_plug_in_handle_message ()
> #11 0x5604fd81baa1 in  ()
> #12 0x7f3e14145dd8 in g_main_context_dispatch () at 
> /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #13 0x7f3e141461c8 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #14 0x7f3e141464c2 in g_main_loop_run () at 
> /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #15 0x5604fd584cb7 in app_run ()
> #16 0x5604fd5845b5 in main ()


Dear Maintainer,
the given backtrace might point to this upstream [1] and
another similar downstream [2] issue.

[1] https://gitlab.gnome.org/GNOME/gimp/-/issues/4064
[2] https://bugs.archlinux.org/task/60769

Kind regards,
Bernhard

Bug#968005: gimp: install the application well, it did not give any error but when executing it gave a serious error

[Bernhard Übelacker]

Dear Maintainer,
from the submitters attached log I guess
the part in [2] is relevant.

This led to the upstream bug in [1].

Downstream there seem to be also some duplicates:
  #953880, #953854, #953794, #954095, #954739

This seems to be fixed in testing since gimp 2.10.14-3,
but due to this report also stable seems to be affected.

Kind regards,
Bernhard


[1] https://gitlab.gnome.org/GNOME/gimp/-/issues/4392

[2] ...
#5  
#6  0x55d6ef753e3b in gimp_param_spec_layer_id ()
#7  0x55d6ef6777ed in gimp_pdb_compat_param_spec ()
#8  0x55d6ef684077 in gimp_plug_in_handle_message ()
#9  0x55d6ef692501 in gimp_plug_in_manager_call_query ()
#10 0x55d6ef68a5b8 in gimp_plug_in_manager_restore ()
...

Bug#971428: xloadimage: -rotate 0 exhausts memory

[Bernhard Übelacker]

Dear Maintainer,
in options.c:792 the modulus of the rotating degrees is checked to
be 0. But this is not triggered if degrees is already zero.
Attached patch should avoid this issue and make xloadimage ignore
the rotate request.

Kind regards,
Bernhard


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


apt update
apt dist-upgrade


apt install systemd-coredump mc htop fakeroot quilt lightdm xserver-xorg 
openbox xterm gdb xloadimage xloadimage-dbgsym
apt build-dep xloadimage


reboot



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




export DISPLAY=:0
ulimit -S -v 1000
cp /usr/share/obconf/video-display.png . -a
xloadimage -rotate 0 video-display.png




benutzer@debian:~$ ulimit -S -v 100
benutzer@debian:~$ xloadimage -rotate 0 video-display.png 
video-display.png is 124x128 PNG image, color type RGB_ALPHA, 8 bit
  Rotating image by 0 degrees...

Memory has been exhausted; operation cannot continue (sorry).







gdb -q --args xloadimage -rotate 0 video-display.png
set width 0
set pagination off
directory /home/benutzer/source/xloadimage/xloadimage-4.1
run


(gdb) bt
#0  __GI___libc_malloc (bytes=47616) at malloc.c:3031
#1  0x55565772 in lmalloc (size=) at new.c:218
#2  0x555659b4 in newTrueImage (width=, height=124) at 
new.c:184
#3  0x5556dc03 in rotate (simage=0x5562d6c0, degrees=4290703186, 
verbose=1) at rotate.c:110
#4  0x55575b2b in doProcessOnImage (image=0x5562d6c0, 
option=, verbose=) at xloadimage.c:110
#5  0x55575c40 in processImage (image=0x5562d6c0, 
global_options=, image_options=) at 
xloadimage.c:164
#6  0x9de6 in main (argc=4, argv=0x7fffe5a8) at xloadimage.c:417



Description: Fix memory exhaustion when rotating by zero degrees

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

Index: xloadimage-4.1/options.c
===
--- xloadimage-4.1.orig/options.c
+++ xloadimage-4.1/options.c
@@ -789,7 +789,7 @@ void processOptions(argc, argv, rglobal,
   if (++a >= argc)
 	optionUsage(ROTATE);
   newopt->info.rotate= getInteger(ROTATE, argv[a]);
-  if (newopt->info.rotate % 90) {
+  if (newopt->info.rotate % 90 || newopt->info.rotate == 0) {
 	fprintf(stderr, "Argument to %s must be a multiple of 90 (ignored)\n",
 		optionName(ROTATE));
 	newopt->type= OPT_IGNORE;

Bug#961434: baresip-core: stack smashing detected with evdev module

[Bernhard Übelacker]

Dear Maintainer,
I could reproduce a stack smashing using the evdev module and as far
as I see it is triggered because of the wrong memory size given to
an ioctl in [1] giving the backtrace in [3].

A brief read of [2] suggests to give instead of EV_MAX the size in bytes
really available. And a package built with attached patch does not
show the stack smashing anymore.

This stack smashing can also be seen in the current testing version.

Kind regards,
Bernhard


[1] https://github.com/baresip/baresip/blob/master/modules/evdev/print.c#L49

[2] 
https://stackoverflow.com/questions/14273129/smashed-stack-when-iterating-over-int-pointers

[3]
(gdb) bt
#0  0x77714427 in ioctl () at ../sysdeps/unix/syscall-template.S:78
#1  0x77fc4adf in print_events (fd=) at 
modules/evdev/print.c:49
#2  0x77fc492a in evdev_alloc (stp=0x77fca198 , 
dev=0x77fca100  "/dev/input/event0") at 
modules/evdev/evdev.c:251
#3  module_init () at modules/evdev/evdev.c:325
#4  0x77f93f82 in mod_load (mp=mp@entry=0x7fffd0d8, 
name=name@entry=0x7fffd0e0 "/usr/lib/baresip/modules/evdev.so") at 
src/mod/mod.c:137
#5  0x5556ce86 in load_module (modp=modp@entry=0x0, modpath=, name=0x7fffe120) at src/module.c:88
#6  0x5556cf9e in module_handler (val=, arg=) at src/module.c:105
#7  0x77f94811 in conf_apply (conf=conf@entry=0x555ac760, 
name=name@entry=0x555790c2 "module", ch=ch@entry=0x5556cf90 
, arg=arg@entry=0x7fffe380) at src/conf/conf.c:285
#8  0x5556d0c1 in module_init (conf=0x555ac760) at src/module.c:151
#9  0x55569950 in conf_modules () at src/conf.c:385
#10 0xf467 in main (argc=, argv=) at 
src/main.c:242
Description: Use right size for ioctl

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

--- baresip-0.6.1.orig/modules/evdev/print.c
+++ baresip-0.6.1/modules/evdev/print.c
@@ -46,7 +46,7 @@ void print_events(int fd)
 	int i;
 
 	memset(evtype_bitmask, 0, sizeof(evtype_bitmask));
-	if (ioctl(fd, EVIOCGBIT(0, EV_MAX), evtype_bitmask) < 0) {
+	if (ioctl(fd, EVIOCGBIT(0, sizeof(evtype_bitmask)), evtype_bitmask) < 0) {
 		warning("evdev: ioctl EVIOCGBIT (%m)\n", errno);
 		return;
 	}


# 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



mc -e /home/benutzer/.baresip/accounts
# configure account



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)
 

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 

Bug#969546: freecad: Freecad crashes when placing beam in Arch workbench

[Bernhard Übelacker]

Dear Maintainer,
I could reproduce this crash and first lines of the backtrace
with full debug symbols shows like in [1],
while trying to dereference a null pointer.

This might be a use after free because when trying to reverse execute
to the point where the memory holding the null pointer is last written,
we end in [2], which seems destroying the container pyObj=0x7f987942c7c0.

Full backtraces and starting from a minimal VM in attached file.

Kind regards,
Bernhard


[1]
(rr) bt
#0  0x7f98dcb21a5f in Shiboken::Object::cppPointers (pyObj=0x7f987942c7c0) 
at /usr/include/c++/9/bits/stl_vector.h:1040
#1  0x7f98dcc0f73a in Sbkshiboken2Module_getCppPointer (self=, pyArg=0x7f987942c7c0) at 
./pyside3_build/py3.8-qt5.14.2-64bit-relwithdebinfo/shiboken2/shibokenmodule/shiboken2/shiboken2_module_wrapper.cpp:278
#2  0x7f98e5fc1f06 in cfunction_vectorcall_O 
(func=func@entry=0x7f98dcba1450, args=0x7f9879a6bbc8, nargsf=nargsf@entry=1, 
kwnames=) at ../Objects/methodobject.c:482
#3  0x7f98e5f7e0bc in PyVectorcall_Call (callable=0x7f98dcba1450, 
tuple=, kwargs=) at ../Objects/call.c:199
#4  0x7f98e5f7e26f in PyObject_Call (callable=, 
args=, kwargs=) at ../Objects/call.c:227
#5  0x7f98e5f7edf1 in PyEval_CallObjectWithKeywords (callable=, args=, kwargs=kwargs@entry=0x0) at ../Objects/call.c:809
#6  0x7f98e5f7ee67 in PyObject_CallObject (callable=, 
args=) at ../Objects/call.c:817
#7  0x7f98e7041d07 in Py::Callable::apply (args=..., this=0x7ffdc1b3a8f0) 
at ./src/CXX/Python3/Objects.hxx:3156
#8  Gui::qt_getCppPointer (pyobject=..., shiboken=, 
unwrap=) at ./src/Gui/WidgetFactory.cpp:273
#9  0x7f98e6f72950 in Gui::TaskView::TaskDialogPython::TaskDialogPython 
(this=0x55dcb312bd10, o=...) at ./src/CXX/Python3/Objects.hxx:185
#10 0x7f98e6f72d0d in Gui::TaskView::ControlPy::showDialog (this=, args=...) at ./src/CXX/Python3/Objects.hxx:177
#11 0x7f98e6f736b1 in 
Py::PythonExtension::method_varargs_call_handler 
(_self_and_name_tuple=, _args=) at 
./src/CXX/Python3/Objects.hxx:177
#12 0x7f98e5f7d947 in cfunction_call_varargs (func=0x7f987943c590, 
args=, kwargs=) at ../Objects/call.c:757
#13 0x7f98e5f7e797 in _PyObject_MakeTpCall (callable=0x7f987943c590, 
args=, nargs=, keywords=0x0) at 
../Objects/call.c:159
#14 0x7f98e5f59cd3 in _PyObject_Vectorcall (kwnames=0x0, nargsf=, args=, callable=0x7f987943c590) at 
../Include/cpython/abstract.h:125
...


[2]
(rr) bt
#0  Shiboken::Object::destroy (self=0x7f987942c7c0, cppData=0x55dcaf4f8900) at 
./sources/shiboken2/libshiboken/basewrapper.cpp:1479
#1  0x7f98d4b17403 in QWidgetWrapper::~QWidgetWrapper (this=0x55dcaf4f8900, 
__in_chrg=) at 
./pyside3_build/py3.8-qt5.14.2-64bit-relwithdebinfo/pyside2/PySide2/QtWidgets/PySide2/QtWidgets/qwidget_wrapper.cpp:1794
#2  0x7f98d4b17429 in QWidgetWrapper::~QWidgetWrapper (this=0x55dcaf4f8900, 
__in_chrg=) at 
./pyside3_build/py3.8-qt5.14.2-64bit-relwithdebinfo/pyside2/PySide2/QtWidgets/PySide2/QtWidgets/qwidget_wrapper.cpp:1791
#3  0x7f98e55efb0e in QObjectPrivate::deleteChildren 
(this=this@entry=0x55dcaf320a10) at kernel/qobject.cpp:2123
#4  0x7f98e59f4ce6 in QWidget::~QWidget (this=0x55dcaf31d800, 
__in_chrg=) at kernel/qwidget.cpp:1530
#5  0x7f98e6f7da71 in QSint::TaskGroup::~TaskGroup (this=0x55dcaf31d800, 
__in_chrg=) at ./src/Gui/QSint/actionpanel/taskgroup_p.h:22
#6  QSint::TaskGroup::~TaskGroup (this=0x55dcaf31d800, __in_chrg=) at ./src/Gui/QSint/actionpanel/taskgroup_p.h:22
#7  0x7f98e55efb0e in QObjectPrivate::deleteChildren 
(this=this@entry=0x55dcaf312a30) at kernel/qobject.cpp:2123
#8  0x7f98e59f4ce6 in QWidget::~QWidget (this=0x55dcaf312980, 
__in_chrg=) at kernel/qwidget.cpp:1530
#9  0x7f98e6f6c8d9 in Gui::TaskView::TaskBox::~TaskBox 
(this=0x55dcaf312980, __in_chrg=) at 
./src/Gui/TaskView/TaskView.cpp:241
#10 0x7f98e6f6dab6 in Gui::TaskView::TaskDialog::~TaskDialog 
(this=0x55dcaf516440, __in_chrg=) at 
/usr/include/c++/9/bits/stl_iterator.h:819
#11 0x7f98e6f6eed4 in Gui::TaskView::TaskDialogPython::~TaskDialogPython 
(this=0x55dcaf516440, __in_chrg=) at 
./src/CXX/Python3/Objects.hxx:163
#12 0x7f98e6f6ef09 in Gui::TaskView::TaskDialogPython::~TaskDialogPython 
(this=0x55dcaf516440, __in_chrg=) at 
./src/Gui/TaskView/TaskDialogPython.cpp:314
#13 0x7f98e6f6a48b in Gui::TaskView::TaskView::removeDialog 
(this=0x55dcacf00840) at ./src/Gui/TaskView/TaskView.cpp:649
#14 0x7f98e6f6dfb2 in Gui::TaskView::ControlPy::closeDialog 
(this=) at ./src/Gui/Control.h:133
#15 0x7f98e6f736b1 in 
Py::PythonExtension::method_varargs_call_handler 
(_self_and_name_tuple=, _args=) at 
./src/CXX/Python3/Objects.hxx:177
#16 0x7f98e5f7d947 in cfunction_call_varargs (func=0x7f9879427900, 
args=, kwargs=) at ../Objects/call.c:757
#17 0x7f98e5f7e797 in _PyObject_MakeTpCall (callable=0x7f9879427900, 
args=, nargs=, keywords=0x0) at 
../Objects/call.c:159
#18 0x7f98e5f59cd3 in _PyObject_Vectorcall (kwnames=0x0, nargsf=, 

Bug#971054: winedbg --gdb does not work with 32-bit WINEPREFIX

[Bernhard Übelacker]

Dear Maintainer,
tried to have a look at it and found that this might be caused by
the wine binary being pointed to by Debians alternatives system.

Therefore winedbg does not find the loader shared object of the target
process and cannot map it (elf_read_wine_loader_dbg_info).
That module would be marked as "" and 'winedbg --gdb'
relies on finding that in function mod_loader_cb.
If it cannot be found windbg exits directly after dbg_get_debuggee_info [1],
unfortunately without any message.

This can be worked around by setting the path before like in [2].

Because upstream changed winedbg since 5.6 to not rely on knowing the loader,
I guess a "debianized" wine package from that version upwards should also
not show this issue. [3]

Kind regards,
Bernhard


[1]
Breakpoint 7, mod_loader_cb (mod_name=, base=, ctx=) at 
winedbg.c:429
429 if (!strcmp(mod_name, ""))
1: x/i $pc
=> 0x7fa056f4 :   mov$0xe,%ecx
(rr) bt
#0  mod_loader_cb (mod_name=, base=, ctx=) at winedbg.c:429
#1  0x7f978bc5 in enum_modW64_64 (name=0x139ef8, base=2141257728, 
user=0x32f140) at module.c:805
#2  0x7f97aa79 in SymEnumerateModulesW64 (hProcess=, 
EnumModulesCallback=, UserContext=) at 
module.c:838
#3  0x7f97ab66 in SymEnumerateModules64 (hProcess=0x2c, 
EnumModulesCallback=0x7fa056d0 , UserContext=0x32f294) at 
module.c:817
#4  0x7fa06284 in dbg_get_debuggee_info (hProcess=, imh_mod=) 
at winedbg.c:452
#5  0x7f9f5724 in gdb_remote (flags=, port=) at 
gdbproxy.c:1930
#6  0x7f9f7cc3 in gdb_main (argc=, argv=) at 
gdbproxy.c:2110
#7  0x7f9e75e1 in main () from 
/usr/lib/wine/../i386-linux-gnu/wine/winedbg.exe.so
#8  0x7fa0c8cd in __wine_spec_exe_entry (peb=) at exe_entry.c:64
#9  0x7b454882 in call_process_entry () from 
/usr/lib/wine/../i386-linux-gnu/wine/kernel32.dll.so
#10 0x7b454cfc in start_process (entry=, peb=) at 
process.c:153
#11 0x7b45488e in __wine_start_process () from 
/usr/lib/wine/../i386-linux-gnu/wine/kernel32.dll.so
#12 0x in ?? ()


[2]
export PATH=/usr/lib/wine:$PATH
wine winedbg --gdb notepad


[3]
https://source.winehq.org/git/wine.git/patch/86ed5e563dc75bc5dae30f9647eefa63efb132d5

# Bullseye/testing i386 qemu VM 2020-10-11


apt update
apt dist-upgrade


apt install systemd-coredump mc htop fakeroot quilt lightdm xserver-xorg 
openbox xterm sshfs libcapnp-dev gdb wine wine32-dbgsym libwine-dbgsym
apt build-dep wine

reboot


echo 1 > /proc/sys/kernel/perf_event_paranoid
# prebuilt rr:
mkdir -p /home/bernhard/data/entwicklung/2020/rr/2020-10-09
sshfs -o allow_other,uid=1000,gid=1000 
bernhard@192.168.178.25:/home/bernhard/data/entwicklung/2020/rr/2020-10-09 
/home/bernhard/data/entwicklung/2020/rr/2020-10-09




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



export DISPLAY=:0
export WINEPREFIX=~/.wine32
wine wineboot

wine winedbg --gdb notepad.exe







$ WINEDEBUG=+process 
/home/bernhard/data/entwicklung/2020/rr/2020-10-09/obj_i686/bin/rr wine winedbg 
--gdb notepad.exe
rr: Saving execution to trace directory `/home/benutzer/.local/share/rr/wine-4'.
...


benutzer@debian:~$ 
/home/bernhard/data/entwicklung/2020/rr/2020-10-09/obj_i686/bin/rr ps 
/home/benutzer/.local/share/rr/wine-4
PID PPIDEXITCMD
7243--  0   wine winedbg --gdb notepad.exe
724572430   /usr/lib/wine/wineserver
72467245-9  (forked without exec)
724772430   (forked without exec)
724872470   /usr/lib/wine/wine C:\windows\system32\wineboot.exe 
--init
724972480   (forked without exec)
725072490   /usr/lib/wine/wine 
C:\windows\system32\winemenubuilder.exe -a -r
725172480   (forked without exec)
72527251-9  /usr/lib/wine/wine C:\windows\system32\services.exe
725472520   (forked without exec)
72557254-9  /usr/lib/wine/wine C:\windows\system32\plugplay.exe
725672500   (forked without exec)
725772560   /usr/lib/wine/wine C:\windows\system32\explorer.exe 
/desktop
726372520   (forked without exec)
72647263-9  /usr/lib/wine/wine C:\windows\system32\winedevice.exe
727572520   (forked without exec)
72767275-9  /usr/lib/wine/wine C:\windows\system32\winedevice.exe
728272430   (forked without exec)
72837282-9  /usr/lib/wine/wine notepad.exe


benutzer@debian:~$ 
/home/bernhard/data/entwicklung/2020/rr/2020-10-09/obj_i686/bin/rr wine winedbg 
--gdb notepad.exe
rr: Saving execution to trace directory `/home/benutzer/.local/share/rr/wine-0'.
002c:002d: create process 'C:\windows\system32\notepad.exe'/0x1106b0 
@0x7fa19e50 (0<0>)
002c:002d: create thread I @0x7fa19e50
benutzer@debian:~$

002c:002d: create thread I @0x7fa19e50

Program received signal SIGKILL, Killed.
0x700e in ?? ()
1: x/i $pc
=> 0x700e:  ret
(rr) bt
#0  0x700e in ?? ()
#1  0xb7f06ef1 in _raw_syscall () at 

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 

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 

Bug#970520: wesnoth: Crash on starting wesnoth - stack smash detected

[Bernhard Übelacker]

Dear Maintainer,
I could reproduce this stack smashing inside a testing amd64 VM.

The stack canary gets overwritten in the stack below.

It looks like there is a disagreement of wesnoth and wolfssl in
the size of sha/hasher wc_Sha/WOLFSSL_SHA_CTX, the first allocates
112 bytes, the latter thinks it got a pointer to 128 bytes.

Because wesnoth got built against libwolfssl-dev 4.4.0+dfsg-2,
and this error manifests when run with libwolfssl24 4.5.0+dfsg-3,
I am still unsure if this might be a ABI break.

At least when installing 4.4.0+dfsg-2 in function wc_InitSha_ex
sizeof(*sha) shows also 112. And the game starts up.

@Felix Lechner: Hope it is ok to add you in CC?

Kind regards,
Bernhard


(rr) bt
#0  InitSha (sha=0x7f745aaf12a0) at wolfcrypt/src/sha.c:349
#1  wc_InitSha_ex (sha=sha@entry=0x7f745aaf12a0, heap=heap@entry=0x0, 
devId=devId@entry=-2) at wolfcrypt/src/sha.c:497
#2  0x7f7471e89bdc in wc_InitSha (sha=sha@entry=0x7f745aaf12a0) at 
wolfcrypt/src/sha.c:775
#3  0x7f7471f1a2c9 in wolfSSL_SHA_Init (sha=sha@entry=0x7f745aaf12a0) at 
src/ssl.c:15788
#4  0x7f7471f1a325 in wolfSSL_SHA1_Init (sha=sha@entry=0x7f745aaf12a0) at 
src/ssl.c:15832
#5  0x559c7d624553 in utils::sha1::sha1 (this=0x7f745aaf1530, 
str="/usr/share/games/wesnoth/1.14/data/cores.cfg TITLE_SCREEN 
WESNOTH_VERSION") at ./src/hash.cpp:130
#6  0x559c7d1d2404 in game_config::config_cache::read_cache 
(this=0x559c7ddd7360 , 
file_path="/usr/share/games/wesnoth/1.14/data/cores.cfg", cfg=...) at 
/usr/include/c++/9/bits/basic_string.h:1936
#7  0x559c7d1d347c in game_config::config_cache::load_configs 
(this=0x559c7ddd7360 , 
config_path="/usr/share/games/wesnoth/1.14/data/cores.cfg", cfg=...) at 
./src/config_cache.cpp:293
#8  0x559c7cefaa9e in game_config_manager::load_game_config 
(this=0x7ffed2e85470, force_reload=game_config_manager::NO_FORCE_RELOAD, 
classification=0x0) at /usr/include/c++/9/bits/basic_string.h:320
#9  0x559c7cf11be2 in std::function::operator()() const 
(this=0x7f745aaf1cb0) at /usr/include/c++/9/bits/std_function.h:683
#10 gui2::dialogs::loading_screen::display(std::function) (f=...) at 
./src/gui/dialogs/loading_screen.cpp:226
#11 0x559c7cef6e5e in game_config_manager::load_game_config_with_loadscreen 
(this=0x7ffed2e85470, force_reload=game_config_manager::NO_FORCE_RELOAD, 
classification=0x0) at /usr/include/c++/9/bits/std_function.h:87
#12 0x559c7cef799e in game_config_manager::init_game_config 
(this=0x7ffed2e85470, force_reload=game_config_manager::NO_FORCE_RELOAD) at 
./src/game_config_manager.cpp:90
#13 0x559c7cebcef4 in ::operator() (__closure=0x7ffed2e85258, 
__closure=0x7ffed2e85258) at ./src/wesnoth.cpp:701
#14 std::_Function_handler >&):: >::_M_invoke(const 
std::_Any_data &) (__functor=...) at /usr/include/c++/9/bits/std_function.h:300
#15 0x559c7cf108aa in std::function::operator()() const 
(this=) at /usr/include/c++/9/bits/std_function.h:683
#16 gui2::dialogs::loading_screenoperator() 
(__closure=0x559c7f41f338) at ./src/gui/dialogs/loading_screen.cpp:116
#17 
boost::detail::thread_data
 >::run(void) (this=0x559c7f41f200) at 
/usr/include/boost/thread/detail/thread.hpp:120
#18 0x7f7471e1bec7 in ?? () from 
/lib/x86_64-linux-gnu/libboost_thread.so.1.71.0
#19 0x7f74717c5ea7 in start_thread (arg=) at 
pthread_create.c:477
#20 0x7f74716f5eaf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

(rr) print sizeof(*sha)
$2 = 128
(rr) print sha
$5 = (wc_Sha *) 0x7f745aaf12a0
(rr) ptype /o sha
type = struct wc_Sha {
/*0  | 4 */word32 buffLen;
/*4  | 4 */word32 loLen;
/*8  | 4 */word32 hiLen;
/*   12  |64 */word32 buffer[16];
/*   76  |20 */word32 digest[5];
/*   96  | 8 */void *heap;
/*  104  | 4 */int devId;
/* XXX  4-byte hole  */
/*  112  | 8 */void *devCtx;
/*  120  | 4 */word32 flags;
/* XXX  4-byte padding  */

   /* total size (bytes):  128 */
 } *
https://sources.debian.org/src/wolfssl/4.5.0+dfsg-4/wolfssl/openssl/sha.h/#L40


(rr) print sizeof(hasher)
$3 = 112
(rr) print 
$4 = (SHA_CTX *) 0x7f745aaf12a0
(rr) ptype /o hasher
type = struct WOLFSSL_SHA_CTX {
/*0  |   112 */void *holder[14];

   /* total size (bytes):  112 */
 }
https://sources.debian.org/src/wesnoth-1.14/1:1.14.13-1/src/hash.cpp/#L130

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


apt update
apt dist-upgrade


apt install systemd-coredump mc sddm plasma-desktop sshfs gdb libcapnp-dev 
konsole tmux wesnoth wesnoth-1.14-core-dbgsym libwolfssl24-dbgsym


reboot


VM:
echo 1 > /proc/sys/kernel/perf_event_paranoid
mkdir -p /home/bernhard/data/entwicklung/2020/rr/2020-10-02-amd64
sshfs -o allow_other,uid=1000,gid=1000 
bernhard@192.168.178.25:/home/bernhard/data/entwicklung/2020/rr/2020-10-02-amd64
 

Bug#969087: lightdm-settings: does not open

[Bernhard Übelacker]

Hello John,
a short addition.

If you want to start it from a terminal I guess
following command might do what you want:

$ pkexec lightdm-settings

Kind regards,
Bernhard

Bug#969087: lightdm-settings: does not open

[Bernhard Übelacker]

Hello John,
I fear that the package gksu, which provided gksudo, is not
part of unstable, testing or buster.

   https://packages.debian.org/stretch/gksu

Therefore I assume this package is installed since quite some time
and was then removed from debian.

Does starting it from the application menu work?
Which desktop environment are you using?

Kind regards,
Bernhard

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#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#969887: scdoc: segfault in parse_text

[Bernhard Übelacker]

More details here: https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html
Some related discussion here: https://lists.sr.ht/~sircmpwn/public-inbox
An upstream patch here: 
https://git.sr.ht/~sircmpwn/scdoc/commit/26bbd972dd3bdc73baa9362a2794dfc3ec3ad085

Bug#971088: xserver-xorg-core: Backtraces print wrong instruction pointers

[Bernhard Übelacker]

Am 28.09.20 um 09:45 schrieb Michel Dänzer:
> Can you create an upstream merge request at
> https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests ?


Hello Michel,
thanks for looking at the issue.
I created this merge request:

https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/524

Kind regards,
Bernhard

Bug#971088: xserver-xorg-core: Backtraces print wrong instruction pointers

[Bernhard Übelacker]

Package: xserver-xorg-core
Version: 2:1.20.8-2
Severity: wishlist


Dear Maintainer,
in the past I was trying to make sense of some backtraces written
by Xorg, but failed, e.g. in #969739.

I did now some debugging and found that in function xorg_backtrace
the function begin retrieved by unw_get_proc_info in "pip.start_ip"
cannot always be used for calculations with "off".

This is because this "off" offset is calculated in unw_get_proc_name
from the nearest symbol, which does not necessarily match pip.start_ip.

Attached patch separately retrieves the instruction pointer by unw_get_reg
and uses that value for the output. A short in gdb wrote with this patch
applied the same addresses as the bt command.

What do you think?

Kind regards,
Bernhard


-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.


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

Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xserver-xorg-core depends on:
ii  keyboard-configuration  1.196
ii  libaudit1   1:2.8.5-3+b1
ii  libbsd0 0.10.0-1
ii  libc6   2.31-3
ii  libdbus-1-3 1.12.20-1
ii  libdrm2 2.4.102-1
ii  libegl1 1.3.2-1
ii  libepoxy0   1.5.4-1
ii  libgbm1 20.1.8-1
ii  libgcrypt20 1.8.6-2
ii  libgl1  1.3.2-1
ii  libpciaccess0   0.16-1
ii  libpixman-1-0   0.36.0-1
ii  libselinux1 3.1-2
ii  libsystemd0 246.6-1
ii  libudev1246.6-1
ii  libunwind8  1.3.2-2
ii  libxau6 1:1.0.8-1+b2
ii  libxdmcp6   1:1.1.2-3
ii  libxfont2   1:2.0.3-1
ii  libxshmfence1   1.3-1
ii  udev246.6-1
ii  xserver-common  2:1.20.8-2

Versions of packages xserver-xorg-core recommends:
ii  libgl1-mesa-dri  20.1.8-1
ii  libpam-systemd   246.6-1
>From 2c1cd5ebf5e9281c2e02b9fcaf4430b314a44909 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
Date: Sun, 27 Sep 2020 18:03:48 +0200
Subject: Do not mix the function begin address from unw_get_proc_info and the
 offset from unw_get_proc_name.

---
 os/backtrace.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/os/backtrace.c b/os/backtrace.c
index 619bf14..2aad0e3 100644
--- a/os/backtrace.c
+++ b/os/backtrace.c
@@ -45,6 +45,7 @@ xorg_backtrace(void)
 {
 unw_cursor_t cursor;
 unw_context_t context;
+unw_word_t ip;
 unw_word_t off;
 unw_proc_info_t pip;
 int ret, i = 0;
@@ -88,7 +89,9 @@ xorg_backtrace(void)
 procname[1] = 0;
 }
 
-if (dladdr((void *)(uintptr_t)(pip.start_ip + off), ) && dlinfo.dli_fname &&
+if (unw_get_reg (, UNW_REG_IP, ) < 0)
+  ip = pip.start_ip + off;
+if (dladdr((void *)(uintptr_t)(ip), ) && dlinfo.dli_fname &&
 *dlinfo.dli_fname)
 filename = dlinfo.dli_fname;
 else
@@ -96,7 +99,7 @@ xorg_backtrace(void)
 
 ErrorFSigSafe("%u: %s (%s%s+0x%x) [%p]\n", i++, filename, procname,
 ret == -UNW_ENOMEM ? "..." : "", (int)off,
-(void *)(uintptr_t)(pip.start_ip + off));
+(void *)(uintptr_t)(ip));
 
 ret = unw_step();
 if (ret < 0)
-- 
2.28.0


# Bullseye/testing amd64 qemu VM 2020-09-25

apt update
apt dist-upgrade





apt install ccache cmake make g++-multilib gdb pkg-config coreutils 
python3-pexpect manpages-dev git ninja-build capnproto libcapnp-dev

git clone https://github.com/mozilla/rr.git
mkdir obj && cd obj

cmake ../rr

make -j$(nproc)





apt install systemd-coredump psmisc mc fakeroot gdb xserver-xorg xterm openbox 
xserver-xorg-core-dbgsym libdbus-1-3-dbgsym libunwind8-dbgsym
apt build-dep xserver-xorg-core

echo 1 > /proc/sys/kernel/perf_event_paranoid


mkdir /home/benutzer/source/xserver-xorg-core/orig -p
cd/home/benutzer/source/xserver-xorg-core/orig
apt source xserver-xorg-core
cd xorg-server-1.20.8
mkdir x/x/x/x/x/x/x/x -p
cd

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











# apt install pstack
wget 
https://snapshot.debian.org/archive/debian/20170317T095121Z/pool/main/p/pstack/pstack_1.3.1-1%2Bb1_amd64.deb
dpkg -i pstack_1.3.1-1+b1_amd64.deb

root@debian:~# pstack 37009

37009: mc -e ./os/backtrace.c
(No symbols found)
crawl: Input/output error
Error tracing through process 37009
0x7f2b9826e926: root@debian:~# 

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










/home/benutzer/obj/bin/rr 

Bug#969739: Segmentation fault on startup

[Bernhard Übelacker]

Dear Maintainer,
I could not reproduce the crash, but I could modify the process under
gdb to reach a point of execution, which prints a similar backtrace.

Therefore I guess the crash described in Christophe's first message
is really located in [1], caused by "xf86_platform_devices[i].pdev"
containing a null pointer.

[1] 
https://sources.debian.org/src/xorg-server/2:1.20.9-1/hw/xfree86/common/xf86platformBus.c/#L367


But second and more fundamentally, I guess too that the backtrace
generating function in Xorg seems not to be reliable.

If I am right the following backtraces should show the same addresses, but for
some reason the Xorg output seems to be kind of misleading on some frames.
Would that be worth to track in a separate bug?

Kind regards,
Bernhard

With debug symbols:
#0  0x5560ae10 in xf86MergeOutputClassOptions () at 
../../../../../../hw/xfree86/common/xf86platformBus.c:367
#1  0x555ee197 in xf86CollectOptions () at 
../../../../../../hw/xfree86/common/xf86Option.c:83
#2  0x76993d2e in PreInit () at 
../../../../../../../hw/xfree86/drivers/modesetting/driver.c:972
#3  0x555f185e in InitOutput () at 
../../../../../../hw/xfree86/common/xf86Init.c:522
#4  0x555b331c in dix_main () at ../../../../dix/main.c:193
#5  0x772dbcca in __libc_start_main () at ../csu/libc-start.c:308
#6  0x5559cc9a in _start ()

Without debug symbols:
#0  0x5560ae10 in ?? ()
#1  0x555ee197 in xf86CollectOptions ()
#2  0x76993d2e in ?? () from 
/usr/lib/xorg/modules/drivers/modesetting_drv.so
#3  0x555f185e in InitOutput ()
#4  0x555b331c in ?? ()
#5  0x772dbcca in __libc_start_main () at ../csu/libc-start.c:308
#6  0x5559cc9a in _start ()

>From Xorg:
(EE) Backtrace:
(EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x135) [0x55712f35]
(EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x50) 
[0x7749018f]
(EE) 2: /usr/lib/xorg/Xorg (xf86PlatformMatchDriver+0x5c0) [0x5560b2b0]
(EE) 3: /usr/lib/xorg/Xorg (xf86CollectOptions+0x77) [0x555ee197]
(EE) unw_get_proc_name failed: no unwind info found [-10]
(EE) 4: /usr/lib/xorg/modules/drivers/modesetting_drv.so (?+0x0) 
[0x76993940]
(EE) 5: /usr/lib/xorg/Xorg (InitOutput+0x9ae) [0x555f185e]
(EE) 6: /usr/lib/xorg/Xorg (InitFonts+0x1cc) [0x555b335c]
(EE) 7: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xea) 
[0x772dbcca]
(EE) 8: /usr/lib/xorg/Xorg (_start+0x2a) [0x5559cc9a]
(EE) 
(EE) Segmentation fault at address 0x124

# Unstable amd64 qemu VM 2020-09-23

apt update
apt dist-upgrade


apt install systemd-coredump gdb xserver-xorg xterm openbox


/usr/bin/Xorg








root@debian:~# gdb -q -ex 'set width 0' -ex 'set pagination off' -ex 'display/i 
$pc' -ex 'b *xf86MergeOutputClassOptions+31' -ex 'run' -ex 'print/x $edx' -ex 
'set $edx = 1' -ex 'b *xf86MergeOutputClassOptions+288' -ex 'cont' -ex 'print/x 
$rdx' -ex 'set $rdx=0' -ex 'generate-core /tmp/xorg-core' -ex 'bt' -ex 'detach' 
-ex 'quit' --args /usr/lib/xorg/Xorg 
Reading symbols from /usr/lib/xorg/Xorg...
Reading symbols from 
/usr/lib/debug/.build-id/86/86f2627d86f090b258bc6477b49359b2475a83.debug...
1: x/i $pc

Breakpoint 1 at 0xb6d0f: file 
../../../../../../hw/xfree86/common/xf86platformBus.c, line 361.
Starting program: /usr/lib/xorg/Xorg 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

X.Org X Server 1.20.9
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.19.0-10-amd64 x86_64 Debian
Current Operating System: Linux debian 5.8.0-1-amd64 #1 SMP Debian 5.8.7-1 
(2020-09-05) x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.8.0-1-amd64 
root=UUID=c9e90f0f-a043-45af-bda9-4a7fb7b42490 ro quiet
Build Date: 31 August 2020  03:49:48PM
xorg-server 2:1.20.9-1 (https://www.debian.org/support) 
Current version of pixman: 0.36.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Wed Sep 23 22:02:12 2020
(==) Using system config directory "/usr/share/X11/xorg.conf.d"

Breakpoint 1, 0x5560ad0f in xf86MergeOutputClassOptions (entityIndex=0, 
options=options@entry=0x55800f90) at 
../../../../../../hw/xfree86/common/xf86platformBus.c:361
361 ../../../../../../hw/xfree86/common/xf86platformBus.c: Datei oder 
Verzeichnis nicht gefunden.
1: x/i $pc
=> 0x5560ad0f : cmp$0x1,%edx
$1 = 0x3
Breakpoint 2 at 0x5560ae10: file 
../../../../../../hw/xfree86/common/xf86platformBus.c, line 367.
Continuing.

Breakpoint 2, 0x5560ae10 in 

Bug#969890: cmake: segfaults in dl-lookup.c:158 check_match() "UI_set_result"

[Bernhard Übelacker]

On Tue, 8 Sep 2020 15:26:14 +0100 Claude Heiland-Allen  
wrote:
> I resolved these problems with
> sudo apt install --reinstall libssl1.1
> no clue why/how it was damaged
> sorry for the noise

Hello Claude Heiland-Allen,
you might want to let a memory checker run
to exclude that as the source of the issue.

Kind regards,
Bernhard

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#970113: Network scanning fails without proper permissions

[Bernhard Übelacker]

Dear Maintainer,
the issue reported in #950646 might be a similar or the same.

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#950597: git-gui "Show History Context" raises "Application Error"

[Bernhard Übelacker]

Control: fixed -1 1:2.26.0-1


Dear Maintainer,
I tried to have a look and found that it
showed the message: Error: can't read "::main_status": no such variable

But starting with version 1:2.26.0-1 I could not see
this message anymore.

Therefore I guess this bug could be closed?

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, 

Bug#962627: eboard: playing against crafty causes "*** buffer overflow detected ***: eboard terminated"

[Bernhard Übelacker]

Dear Maintainer,
this buffer is caused by a variable of length 256 being
snprintf'ed to with a length of 512.

This got fixed upstream in [1] and was also reported here [2].

This issue is visible in the build log [3] with this warning:
  at proto_xboard.cc:1086:13:
  ... specified bound 512 exceeds destination size 256 ...

There is another location in the build log with a similar warning:
  at util.cc:785:15:
  ...specified bound 1024 exceeds destination size 280 ...

Kind regards,
Bernhard


[1] 
https://github.com/fbergo/eboard/commit/ed33049aff2cefd7508bcda8ab738b8ec871c948

[2] https://bugs.launchpad.net/ubuntu/+source/eboard/+bug/1306419

[3] 
https://buildd.debian.org/status/fetch.php?pkg=eboard=amd64=1.1.3-0.3=1558101455=0


(rr) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7fd306ea0537 in __GI_abort () at abort.c:79
#2  0x7fd306ef9828 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7fd307007c28 "*** %s ***: terminated\n") at 
../sysdeps/posix/libc_fatal.c:155
#3  0x7fd306f88712 in __GI___fortify_fail (msg=msg@entry=0x7fd307007bbe 
"buffer overflow detected") at fortify_fail.c:26
#4  0x7fd306f87110 in __GI___chk_fail () at chk_fail.c:28
#5  0x7fd306f86d45 in ___snprintf_chk (s=s@entry=0x557098bb5664 
"~/.eboard/eng-out", maxlen=maxlen@entry=512, flag=flag@entry=1, 
slen=slen@entry=256, format=format@entry=0x557097beb6bc "%s/.eboard/craftylog") 
at snprintf_chk.c:29
#6  0x557097bd3a8c in snprintf (__fmt=0x557097beb6bc 
"%s/.eboard/craftylog", __n=512, __s=0x557098bb5664 "~/.eboard/eng-out") at 
/usr/include/x86_64-linux-gnu/bits/stdio2.h:67
#7  CraftyProtocol::readDialog() (this=0x557098bb5410) at proto_xboard.cc:1086
#8  0x557097bd3780 in XBoardProtocol::run() (this=0x557098bb5410) at 
proto_xboard.cc:450
...


# Bullseye/testing amd64 qemu VM 2020-09-04


apt update
apt dist-upgrade


apt install systemd-coredump lightdm xserver-xorg openbox xterm ccache cmake 
make g++-multilib gdb pkg-config coreutils python3-pexpect manpages-dev git 
ninja-build capnproto libcapnp-dev fakeroot mc gdb eboard eboard-dbgsym 
libgtk2.0-0-dbgsym libglib2.0-0-dbgsym
apt build-dep eboard

reboot

echo 1 > /proc/sys/kernel/perf_event_paranoid



mkdir /home/benutzer/source/rr/git -p
cd/home/benutzer/source/rr/git
git clone https://github.com/mozilla/rr.git
cd

cd /home/benutzer/source/rr/git/
mkdir obj && cd obj
cmake ../rr
make -j4



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







export DISPLAY=:0
/home/benutzer/source/rr/git/obj/bin/rr eboard

/home/benutzer/source/rr/git/obj/bin/rr replay 
/home/benutzer/.local/share/rr/eboard-1

set width 0
set pagination off
directory /home/benutzer/source/eboard/orig/eboard-1.1.3
cont





benutzer@debian:~$ /home/benutzer/source/rr/git/obj/bin/rr eboard
rr: Saving execution to trace directory 
`/home/benutzer/.local/share/rr/eboard-1'.
*** buffer overflow detected ***: terminated
Abgebrochen





benutzer@debian:~$ /home/benutzer/source/rr/git/obj/bin/rr replay 
/home/benutzer/.local/share/rr/eboard-1
...
(rr) cont
Continuing.
*** buffer overflow detected ***: terminated

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht 
gefunden.
(rr) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7fd306ea0537 in __GI_abort () at abort.c:79
#2  0x7fd306ef9828 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7fd307007c28 "*** %s ***: terminated\n") at 
../sysdeps/posix/libc_fatal.c:155
#3  0x7fd306f88712 in __GI___fortify_fail (msg=msg@entry=0x7fd307007bbe 
"buffer overflow detected") at fortify_fail.c:26
#4  0x7fd306f87110 in __GI___chk_fail () at chk_fail.c:28
#5  0x7fd306f86d45 in ___snprintf_chk (s=, maxlen=, flag=, slen=, format=) at 
snprintf_chk.c:29
#6  0x557097bd3a8c in ?? ()
#7  0x557097bd3780 in ?? ()
#8  0x557097bab471 in ?? ()
#9  0x7fd3074a6fd2 in g_closure_invoke () from 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#10 0x7fd3074ba784 in ?? () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#11 0x7fd3074c554f in g_signal_emit_valist () from 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#12 0x7fd3074c5edf in g_signal_emit () from 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#13 0x7fd307e5e7ba in gtk_widget_activate () from 
/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#14 0x7fd307d59eed in gtk_menu_shell_activate_item () from 
/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#15 0x7fd307d5a1b9 in ?? () from /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#16 0x7fd307d47a8b in ?? () from /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#17 0x7fd3074a6fd2 in g_closure_invoke () from 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#18 0x7fd3074b9f06 in ?? () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#19 

Bug#961345: cups: daemon crashes with invalid free()

[Bernhard Übelacker]

Am 02.09.20 um 10:20 schrieb Ronny Adsetts:
> Hi Bernhard,

> 
> Good news. I don't see any "invalid free" reports.
> 
> Can I thank you again for your time and energy in solving this. It really is 
> appreciated.
> 
> Let me know if there's anything I can do to help get this patch upstreamed.
> 
> Ronny


Hello Ronny,
that's great, I have opened an issue upstream,
let's see what they think.

Kind regards,
Bernhard

Bug#969456: kmix 20.08.0 crashes on exit

[Bernhard Übelacker]

Package: kmix
Version: 4:20.08.0-1
Severity: normal
Forwarded: https://bugs.kde.org/show_bug.cgi?id=425469
Tags: upstream fixed-upstream


Dear Maintainer,
I found several kmix cores lately and investigated a bit.

It crashes when attempting to do some cleanup on process exit.
There unfortunately the QtPaMainLoop structure got deleted,
but later still accessed.

Upstream has already a patch in git.

Kind regards,
Bernhard



==3727== Invalid read of size 8
==3727==at 0x7FBA456: pa_srbchannel_free (srbchannel.c:364)
==3727==by 0x7FB7032: check_srbpending.part.0 (pstream.c:724)
==3727==by 0x7FB9319: pa_pstream_unlink (pstream.c:1190)
==3727==by 0x7FB9319: pa_pstream_unlink (pstream.c:1181)
==3727==by 0x6E1FCB4: context_unlink (context.c:223)
==3727==by 0x6E1FCB4: context_unlink (context.c:201)
==3727==by 0x6E1FE01: context_free (context.c:244)
==3727==by 0x4A60F87: Mixer_PULSE::~Mixer_PULSE() (mixer_pulse.cpp:1073)
==3727==by 0x4A60FA8: Mixer_PULSE::~Mixer_PULSE() (mixer_pulse.cpp:1080)
==3727==by 0x4A3E0C4: Mixer::~Mixer() (mixer.cpp:115)
==3727==by 0x4A3E0D8: Mixer::~Mixer() (mixer.cpp:116)
==3727==by 0x4A37C36: MixerToolBox::deinitMixer() (mixertoolbox.cpp:356)
==3727==by 0x12D3F7: KMixWindow::~KMixWindow() (kmix.cpp:139)
==3727==by 0x12D4D8: KMixWindow::~KMixWindow() (kmix.cpp:151)
==3727==  Address 0x10704168 is 88 bytes inside a block of size 112 free'd
==3727==at 0x4839EAB: operator delete(void*) (vg_replace_malloc.c:584)
==3727==by 0x4A60F40: operator() (unique_ptr.h:85)
==3727==by 0x4A60F40: ~unique_ptr (unique_ptr.h:361)
==3727==by 0x4A60F40: Mixer_PULSE::~Mixer_PULSE() (mixer_pulse.cpp:1056)
==3727==by 0x4A60FA8: Mixer_PULSE::~Mixer_PULSE() (mixer_pulse.cpp:1080)
==3727==by 0x4A3E0C4: Mixer::~Mixer() (mixer.cpp:115)
==3727==by 0x4A3E0D8: Mixer::~Mixer() (mixer.cpp:116)
==3727==by 0x4A37C36: MixerToolBox::deinitMixer() (mixertoolbox.cpp:356)
==3727==by 0x12D3F7: KMixWindow::~KMixWindow() (kmix.cpp:139)
==3727==by 0x12D4D8: KMixWindow::~KMixWindow() (kmix.cpp:151)
==3727==by 0x136533: KMixApp::~KMixApp() (KMixApp.cpp:58)
==3727==by 0x12A527: main (main.cpp:73)
==3727==  Block was alloc'd at
==3727==at 0x4838DEF: operator new(unsigned long) (vg_replace_malloc.c:342)
==3727==by 0x4A5E538: Mixer_PULSE::connectToDaemon() (mixer_pulse.cpp:961)
==3727==by 0x4A61387: Mixer_PULSE::Mixer_PULSE(Mixer*, int) 
(mixer_pulse.cpp:1037)
==3727==by 0x4A61745: PULSE_getMixer(Mixer*, int) (mixer_pulse.cpp:947)
==3727==by 0x4A3E9F7: Mixer::Mixer(QString const&, int) (mixer.cpp:102)
==3727==by 0x4A381FE: 
MixerToolBox::initMixerInternal(MixerToolBox::MultiDriverMode, QStringList 
const&, bool) (mixertoolbox.cpp:142)
==3727==by 0x4A39602: initMixer (mixertoolbox.cpp:273)
==3727==by 0x4A39602: MixerToolBox::initMixer(bool, QStringList const&, 
bool) (mixertoolbox.cpp:284)
==3727==by 0x133724: KMixWindow::KMixWindow(bool, bool) (kmix.cpp:91)
==3727==by 0x1363AD: KMixApp::createWindowOnce(bool, bool) [clone .part.0] 
(KMixApp.cpp:69)
==3727==by 0x136B41: createWindowOnce (KMixApp.cpp:125)
==3727==by 0x136B41: KMixApp::restoreSessionIfApplicable(bool, bool) 
(KMixApp.cpp:125)
==3727==by 0x136CDE: KMixApp::newInstance(QStringList const&, QString 
const&) (KMixApp.cpp:166)
==3727==by 0x12A4F1: main (main.cpp:84)



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

Kernel: Linux 5.7.0-3-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kmix depends on:
ii  libasound2 1.2.3.2-1
ii  libc6  2.31-3
ii  libcanberra0   0.30-7
ii  libkf5configcore5  5.70.0-1
ii  libkf5configgui5   5.70.0-1
ii  libkf5configwidgets5   5.70.0-2
ii  libkf5coreaddons5  5.70.0-2
ii  libkf5dbusaddons5  5.70.0-1
ii  libkf5globalaccel-bin  5.70.0-1
ii  libkf5globalaccel5 5.70.0-1
ii  libkf5i18n55.70.0-1
ii  libkf5notifications5   5.70.0-1
ii  libkf5plasma5  5.70.1-1
ii  libkf5solid5   5.70.0-1
ii  libkf5widgetsaddons5   5.70.0-1
ii  libkf5windowsystem55.70.0-1
ii  libkf5xmlgui5  5.70.0-1+b1
ii  libpulse0  13.0-5
ii  libqt5core5a   5.14.2+dfsg-6
ii  libqt5dbus55.14.2+dfsg-6
ii  libqt5gui5 5.14.2+dfsg-6
ii  libqt5widgets5 5.14.2+dfsg-6
ii  libqt5xml5 5.14.2+dfsg-6
ii  libstdc++6 10.2.0-5

kmix recommends no packages.

kmix suggests no packages.

-- no debconf information

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