from:"Bernhard Übelacker"


Am 21.06.24 um 20:47 schrieb David Bremner:

Hi Bernhard;

Thanks for the patch. This does seem to be progress, but I don't think
it completely fixes Axel's bug. At least for me I still see

  -> .
nullmailer-smtpd: Error catching the return value from nullmailer-queue: No 
child processes
nullmailer-smtpd: Error catching the return value from nullmailer-queue: No 
child processes
<** 451 4.3.0 Error returned from nullmailer-queue

and I get a non-zero exit code. I think the problem you found was
probably a crash during the reporting of the error message.


Yes, it was crashing while it tried to write the error message.

I had hoped the expected behaviour might have been the error message ;-)

I did some archaeology and found the issue got visible
at 2017-12-30 in the Buster development cycle with the
migration of nullmailer 1:2.1-5 into testing.


Kind regards,
Bernhard



debian-9-stretch: 
Connection closed with child process.
testing https://snapshot.debian.org/archive/debian/20170801T042817Z/: 
Connection closed with child process.
testing https://snapshot.debian.org/archive/debian/20170901T034632Z/: 
Connection closed with child process.
testing https://snapshot.debian.org/archive/debian/20171001T043059Z/: 
Connection closed with child process.
testing https://snapshot.debian.org/archive/debian/20171101T034619Z/: 
Connection closed with child process.
testing https://snapshot.debian.org/archive/debian/20171201T034339Z/: 
Connection closed with child process.
testing https://snapshot.debian.org/archive/debian/20171215T032758Z/: 
Connection closed with child process.
testing https://snapshot.debian.org/archive/debian/20171223T034540Z/: 
Connection closed with child process.
testing https://snapshot.debian.org/archive/debian/20171227T051715Z/: 
Connection closed with child process.
testing https://snapshot.debian.org/archive/debian/20171229T045928Z/: 
Connection closed with child process.
testing https://snapshot.debian.org/archive/debian/20171230T035716Z/: Child 
process closed connection unexpectedly. nullmailer (1:2.1-5) over (1:1.13-1.2) 
...
testing https://snapshot.debian.org/archive/debian/20180101T053014Z/: Child 
process closed connection unexpectedly.
debian-10-buster: Child 
process closed connection unexpectedly.
debian-11-bullseye:   Child 
process closed connection unexpectedly.
debian-12-bookworm:   Child 
process closed connection unexpectedly.

Bug#1073987: RFS: serialportassistant/0.5.26-1 [ITP] -- Serial Port Assistant


control: reassign -1 sponsorship-requests



On Fri, 21 Jun 2024 08:35:11 +0200 (CEST) kl...@tuta.io wrote:

Package: sponsorship-requestsSeverity: wishlistDear mentors,I am looking for ...

Hello kl222,
please check your email setup and maybe send as text only.
Unfortunately it broke your requests.
Trying to reassign to sponsorship-requests.

Kind regards,
Bernhard

Bug#1073985: RFS: rabbitcommon/2.2.6-1 [ITP] -- Rabbit common library using Qt


On Fri, 21 Jun 2024 08:03:32 +0200 (CEST) kl...@tuta.io wrote:

Package: sponsor-requestsSeverity: wishlistDear mentors,I am looking for a 
sponsor ...


control: reassign -1 sponsor-requests


Hello kl222,
please check your email setup and maybe send as text only.
Unfortunately it broke your requests.
Trying to reassign to sponsor-requests.

Kind regards,
Bernhard

Bug#1072929: cyanrip: Segmentation fault upon running `cyanrip'


On Thu, 13 Jun 2024 20:24:33 +0800 =?UTF-8?B?RGFuYWkgU0FFLUhBTiAo6Z+T6YGU6ICQKQ==?= 
 wrote:



==659486== Process terminating with default action of signal 11 (SIGSEGV)
==659486==  Access not within mapped region at address 0x0
==659486==at 0x4847DC4: strcmp (in 
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==659486==by 0x11D8A5: ??? (in /usr/bin/cyanrip)
==659486==by 0x10F57C: ??? (in /usr/bin/cyanrip)
==659486==by 0x8100C89: (below main) (libc_start_call_main.h:58)




Thread 1 "cyanrip" received signal SIGSEGV, Segmentation fault.
(gdb) bt
#0  __strcmp_avx2 () at ../sysdeps/x86_64/multiarch/strcmp-avx2.S:283
#1  0x555698b6 in  ()
#2  0xb585 in  ()
#3  0x74442c8a in __libc_start_call_main 
(main=main@entry=0x9f20, argc=argc@entry=9, 
argv=argv@entry=0x7fffdbd8) at ../sysdeps/nptl/libc_start_call_main.h:58
#4  0x74442d45 in __libc_start_main_impl (main=0x9f20, argc=9, 
argv=0x7fffdbd8, init=, fini=, 
rtld_fini=, stack_end=0x7fffdbc8) at ../csu/libc-start.c:360
#5  0xd131 in  ()  




Hello Danai,
the lines at 0x55... are in the main executable and unfortunately your
gdb could not locate the debug symbols.
Therefore a first step would be to get these, then debuggers
should be able to show source line information.

This page lists a few ways: https://wiki.debian.org/HowToGetABacktrace

I find it nice to add the debug repository and install
the dbgsym packages as needed, in this case cyanrip-dbgsym.

The DEBUGINFOD_URLS method is easier, but may take longer because it downloads
everything for the debugged process and creates a cache directory in HOME.

Kind regards,
Bernhard

Bug#1072922: nullmailer: "sendmail -bs" crashes: "traps: nullmailer-smtp[15059] general protection fault ip:7f0368d73dd9 sp:7fff5e3d7088 error:0 in libc.so.6[7f0368c41000+157000]"


Am 21.06.24 um 01:57 schrieb Bernhard Übelacker:

Especially the third point is puzzling, I could not yet see why this 
pointer-content-mixup happens.



Hello David, hello Axel,
I did some further tests and found following location where cli_program
is delared here:

  ./lib/cli++/cli++.h:35:extern const char* cli_program;

But the defintion looks a bit different:

  ./src/smtpd.cc:55:extern const char cli_program[] = "nullmailer-smtpd";


A package built with following change does no longer show this crash.

Kind regards,
Bernhard


--- src/smtpd.cc.orig   2023-04-22 19:06:36.0 +0200
+++ src/smtpd.cc2024-06-21 10:45:25.982395298 +0200
@@ -53,5 +53,5 @@ static mystring sender;
 static mystring recipients;
 
-extern const char cli_program[] = "nullmailer-smtpd";

+const char* cli_program = "nullmailer-smtpd";
 
 static int readline()

Bug#1072922: nullmailer: "sendmail -bs" crashes: "traps: nullmailer-smtp[15059] general protection fault ip:7f0368d73dd9 sp:7fff5e3d7088 error:0 in libc.so.6[7f0368c41000+157000]"

2024-06-20 Thread Bernhard Übelacker



On Wed, 12 Jun 2024 07:19:02 -0300 David Bremner  wrote:

David Bremner  writes:

>
> Attempt #3
>
> swaks -t brem...@debian.org --pipe 'valgrind /usr/lib/sendmail -bs'
>
> This also runs without errors, so I'm out of ideas for the moment.

Attempt #4:

Rebuild with asan



Hello David, hello Axel,
I tried if I can reproduce it and if rr-debugger might be able to record it.

And I received following replay session of the crashing process (PID 3025:

- It forks another process nullmailer-queue (in this example PID 3026)

- It calls waitpid on the PID 3026, but this returns -1 and errno=10 (seems to 
be ECHILD)
  for some unknown reason.

- Therefore tries to write a error message, but the content and the pointer to 
cli_program
  seem to get mixed up, therefore the strlen crashes.

Especially the third point is puzzling, I could not yet see why this 
pointer-content-mixup happens.

Kind regards,
Bernhard




root@debian:~# rr replay --debugger-option=-q -p 3025 -g 2000 bash-1
root@debian:~# swaks -t a...@debian.org --pipe 'sendmail -bs'
=== Trying pipe to sendmail -bs...
=== Connected to sendmail -bs.
Reading symbols from 
/root/.local/share/rr/bash-1/mmap_pack_11_nullmailer-smtpd...
Reading symbols from 
/usr/lib/debug/.build-id/42/8c5f859ee211c1dfa8accdc66572493c471db1.debug...
Really redefine built-in command "restart"? (y or n) [answered Y; input not 
from terminal]
Really redefine built-in command "jump"? (y or n) [answered Y; input not from 
terminal]
Remote debugging using 127.0.0.1:7992

--
 ---> Reached target process 3025 at event 2000.
--
Reading symbols from /usr/bin/../lib/rr/librrpreload.so...
Reading symbols from /lib/x86_64-linux-gnu/libdl.so.2...
Reading symbols from 
/usr/lib/debug/.build-id/bc/40b1b7b2a76bc40d2372f4036be41bef33ef14.debug...
Reading symbols from /lib/x86_64-linux-gnu/libstdc++.so.6...
(No debugging symbols found in /lib/x86_64-linux-gnu/libstdc++.so.6)
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...
Reading symbols from 
/usr/lib/debug/.build-id/2e/01923fea4ad9f7fa50fe24e0f3385a45a6cd1c.debug...
Reading symbols from /lib/x86_64-linux-gnu/libm.so.6...
Reading symbols from 
/usr/lib/debug/.build-id/6c/771bfaca294a4e3d85ada43b358bf6b49dcd2a.debug...
Reading symbols from /lib64/ld-linux-x86-64.so.2...
Reading symbols from 
/usr/lib/debug/.build-id/a9/700083811ae36d1017fe16ebe5657d59cdda0a.debug...
Reading symbols from /lib/x86_64-linux-gnu/libgcc_s.so.1...
(No debugging symbols found in /lib/x86_64-linux-gnu/libgcc_s.so.1)
BFD: warning: system-supplied DSO at 0x6fffd000 has a section extending past 
end of file
0x7f0527d7f8b7 in __GI_mprotect () at ../sysdeps/unix/syscall-template.S:117
117 ../sysdeps/unix/syscall-template.S: Datei oder Verzeichnis nicht 
gefunden.
(rr) set width 0
(rr) set pagination off
(rr) directory 
/home/benutzer/source/nullmailer/orig/nullmailer-2.2+10~g7ed88a0/lib
Source directories searched: 
/home/benutzer/source/nullmailer/orig/nullmailer-2.2+10~g7ed88a0/lib:$cdir:$cwd
(rr) directory 
/home/benutzer/source/nullmailer/orig/nullmailer-2.2+10~g7ed88a0/src
Source directories searched: 
/home/benutzer/source/nullmailer/orig/nullmailer-2.2+10~g7ed88a0/src:/home/benutzer/source/nullmailer/orig/nullmailer-2.2+10~g7ed88a0/lib:$cdir:$cwd
(rr) display/i $pc
1: x/i $pc
=> 0x7f0527d7f8b7 <__GI_mprotect+7>:cmp$0xf001,%rax
(rr) b fork
Breakpoint 1 at 0x7f05278f5560: file ./posix/fork.c, line 41.
(rr) cont
Continuing.
<-  220 nullmailer-smtpd ready
 -> EHLO debian
<-  250 2.3.0 OK
 -> MAIL FROM:
<-  250 2.1.0 Sender accepted
 -> RCPT TO:
<-  250 2.1.5 Recipient accepted
 -> DATA

Breakpoint 1, __libc_fork () at ./posix/fork.c:41
41  ./posix/fork.c: Datei oder Verzeichnis nicht gefunden.
1: x/i $pc
=> 0x7f05278f5560 <__libc_fork>:push   %r14
(rr) finish
Run till exit from #0  __libc_fork () at ./posix/fork.c:41
0x5639bd9132d5 in fork_exec::start (this=this@entry=0x7ffc4099cd00, 
args=args@entry=0x7ffc4099cca0, redirn=redirn@entry=3, 
redirs=redirs@entry=0x7ffc4099cc90) at ./lib/forkexec.cc:67
67if ((pid = fork()) < 0)
1: x/i $pc
=> 0x5639bd9132d5 <_ZN9fork_exec5startEPPKciPi+501>:mov-0x58(%rbp),%rsi
Value returned is $1 = 3026
(rr) next
69if (pid == 0) {
1: x/i $pc
=> 0x5639bd9132e3 <_ZN9fork_exec5startEPPKciPi+515>:jne0x5639bd913306 
<_ZN9fork_exec5startEPPKciPi+550>
(rr) print pid
$2 = 3026
(rr) b fork_exec::wait
Breakpoint 2 at 0x5639bd912ea0: file ./lib/forkexec.cc, line 121.
(rr) cont
Continuing.
<-  354 End your message with a period on a line by itself
 -> Date: Fri, 21 Jun 2024 00:10:45 +0200
 -> To: a...@debian.org
 -> From: root@debian
 -> Subject: test Fri, 21 Jun 2024 00:10:45 +0200
 -> Message-Id: <20240621001045.003024@debian>
 -> X-Mailer: swaks v20240103.0 jetmore.org/john/code/swaks/
 ->
 -> This is a test mailing
 ->
 ->
 -> .

Breakpoint 2, fork_exec::wait

Bug#1072666: virsh drvesx coredumps on invalid connect URL esx://x?no_verify (without =0)

2024-06-18 Thread Bernhard Übelacker


On Thu, 06 Jun 2024 14:59:55 +1000 "Trent W. Buck"  wrote:


I accidentally did, which made virsh coredump (unexpected behaviour):

virsh -c esx://x?no_verify



Stack trace of thread 956182:
#0  0x7ff6c0ca5e3a __libc_free (libc.so.6 + 0x98e3a)
#1  0x7ff6c13c6549 n/a (libvirt.so.0 + 0x27a549)
#2  0x7ff6c13bb8dd n/a (libvirt.so.0 + 0x26f8dd)
#3  0x7ff6c13bc0e1 n/a (libvirt.so.0 + 0x2700e1)
#4  0x7ff6c1439704 n/a (libvirt.so.0 + 0x2ed704)
#5  0x7ff6c143a080 virConnectOpenAuth (libvirt.so.0 + 
0x2ee080)
#6  0x5595d686f0ef n/a (virsh + 0x400ef)




Hello,
I am no maintainer of libvirt, just tried to get some more information.

This crash seems to be a use-after-free, which valgrind starts to shows like 
this:

==1536== Invalid read of size 8
==1536==at 0x4B10B25: esxUtil_FreeParsedUri (esx_util.c:167)
==1536==by 0x4B0749C: esxFreePrivate (esx_driver.c:70)
==1536==by 0x4B08174: esxConnectOpen (esx_driver.c:908)
==1536==by 0x4B87075: virConnectOpenInternal (libvirt.c:1140)
==1536==by 0x4B87A6B: virConnectOpenAuth (libvirt.c:1283)
==1536==by 0x1449C6: virshConnect (virsh.c:127)
==1536==by 0x144C92: virshReconnect (virsh.c:208)
==1536==by 0x144314: virshInit (virsh.c:362)
==1536==by 0x144314: main (virsh.c:880)
==1536==  Address 0x8d0a450 is 0 bytes inside a block of size 48 free'd
==1536==at 0x48431EF: free (in 
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1536==by 0x4B10FE3: esxUtil_ParseUri (esx_util.c:153)
==1536==by 0x4B079A0: esxConnectOpen (esx_driver.c:810)
==1536==by 0x4B87075: virConnectOpenInternal (libvirt.c:1140)
==1536==by 0x4B87A6B: virConnectOpenAuth (libvirt.c:1283)
==1536==by 0x1449C6: virshConnect (virsh.c:127)
==1536==by 0x144C92: virshReconnect (virsh.c:208)
==1536==by 0x144314: virshInit (virsh.c:362)
==1536==by 0x144314: main (virsh.c:880)
==1536==  Block was alloc'd at
==1536==at 0x48459F3: calloc (in 
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1536==by 0x4F59E29: g_malloc0 (in 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.8000.2)
==1536==by 0x4B10BB4: esxUtil_ParseUri (esx_util.c:49)
==1536==by 0x4B079A0: esxConnectOpen (esx_driver.c:810)
==1536==by 0x4B87075: virConnectOpenInternal (libvirt.c:1140)
==1536==by 0x4B87A6B: virConnectOpenAuth (libvirt.c:1283)
==1536==by 0x1449C6: virshConnect (virsh.c:127)
==1536==by 0x144C92: virshReconnect (virsh.c:208)
==1536==by 0x144314: virshInit (virsh.c:362)
==1536==by 0x144314: main (virsh.c:880)


Setting the pointer after freeing might be already enough.
With this valgrind shows no longer any issue with the same virsh statement.
But have not tested any further.


--- libvirt-10.3.0.orig/src/esx/esx_util.c
+++ libvirt-10.3.0/src/esx/esx_util.c
@@ -170,6 +170,7 @@ esxUtil_FreeParsedUri(esxUtil_ParsedUri
 g_free((*parsedUri)->path);
 
 g_free(*parsedUri);

+*parsedUri = NULL;
 }



Kind regards,
Bernhard

# Trixie/testing amd64 qemu VM 2024-06-18


apt install systemd-coredump libunwind8 ccache gdb libvirt-clients 
libvirt-clients-dbgsym libvirt0-dbgsym
apt build-dep libvirt




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



benutzer@debian:~$ virsh $'--connect=esx://x?no_verify'
2024-06-18 19:55:30.936+: 1132: info : libvirt version: 10.3.0, package: 
10.3.0-3 (Debian)
2024-06-18 19:55:30.936+: 1132: info : hostname: debian
2024-06-18 19:55:30.936+: 1132: warning : esxConnectOpen:803 : Ignoring 
unexpected path '' for non-vpx scheme 'esx'
Speicherzugriffsfehler (Speicherabzug geschrieben)
benutzer@debian:~$



benutzer@debian:~$ coredumpctl gdb --debugger-argument=-q 1132
Hint: You are currently not seeing messages from other users and the system.
  Users in groups 'adm', 'systemd-journal' can see all messages.
  Pass -q to turn off this notice.
   PID: 1132 (virsh)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 11 (SEGV)
 Timestamp: Tue 2024-06-18 21:55:30 CEST (3min 42s ago)
  Command Line: virsh $'--connect=esx://x?no_verify'
Executable: /usr/bin/virsh
 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: 8dd2ade6f616424eab69a6ab475f351a
Machine ID: 16e4d7437c19482b8c85581d3feaba09
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.virsh.1000.8dd2ade6f616424eab69a6ab475f351a.1132.171874053000.zst
 (present)
  Size on Disk: 464.2K
   Message: Process 1132 (virsh) of user 1000 dumped core.

Reading symbols from /usr/bin/virsh...
Reading symbols from

Bug#1071996: libx11-6: Segfault in libX11.so.6.4.0 when using GNOME apps (Nautilus/Tweaks)

2024-06-18 Thread Bernhard Übelacker


On Mon, 27 May 2024 11:22:02 +0100 Jack Beckitt-Marshall  
wrote:


When I perform certain actions on my GNOME desktop, such as using the Location
bar (Ctrl+L) in Nautilus, clicking on System Information in GNOME Control
Center, or click Fonts in GNOME Tweaks, the programs close with a segmentation
fault. Here is the output from dmesg.

[ 1659.826530] nautilus[19533]: segfault at 41 ip 7f782c224d5d sp
7fffa9cbf770 error 4 in libX11.so.6.4.0[7f782c216000+8d000] likely on CPU 7
(core 7, socket 0)
[ 1659.826554] Code: ff 66 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 41 54
49 89 d4 55 48 89 f5 53 48 8b 87 68 09 00 00 48 89 fb 48 85 c0 74 02  10 48
89 ee 4c 89 e2 48 89 df e8 63 36 ff ff 89 c5 48 8b 83 68



Using Wayland and GNOME 44.9.



Debian Release: trixie/sid




Hello Jack,
I am not maintainer of libx11-6, just tried to collect some more information.

From the "Code" line the crash happens in function XGetWindowAttributes.
It looks strange this function gets called while using a Wayland session.

This gtk issue [1] shows similar calls into XGetWindowAttributes caused by
some library libim-scim.so from package scim-gtk-immodule.

Please check if you have this installed.
If it is needed it might be possbile to check if this still happens with
a Gnome X11 session, if not needed does it happens when this package is 
uninstalled?


For exact results a backtrace of the crash would still be good.
Maybe you can install the package systemd-coredump and retrieve from
e.g. `journalctl -b0 --no-pager` of a crash with a few lines before and 
afterwards. [2]


[1] https://gitlab.gnome.org/GNOME/gtk/-/issues/5472
[2] https://wiki.debian.org/HowToGetABacktrace


Kind regards,
Bernhard


[ 1659.826530] nautilus[19533]: segfault at 41 ip 7f782c224d5d sp 
7fffa9cbf770 error 4 in libX11.so.6.4.0[7f782c216000+8d000] likely on CPU 7 
(core 7, socket 0)
[ 1659.826554] Code: ff 66 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 41 54 
49 89 d4 55 48 89 f5 53 48 8b 87 68 09 00 00 48 89 fb 48 85 c0 74 02  10 48 
89 ee 4c 89 e2 48 89 df e8 63 36 ff ff 89 c5 48 8b 83 68
[ 1666.674595] nautilus[19622]: segfault at ff ip 7fd182c0fd5d sp 
7fff51cb2fa0 error 4 in libX11.so.6.4.0[7fd182c01000+8d000] likely on CPU 2 
(core 2, socket 0)
[ 1666.674608] Code: ff 66 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 41 54 
49 89 d4 55 48 89 f5 53 48 8b 87 68 09 00 00 48 89 fb 48 85 c0 74 02  10 48 
89 ee 4c 89 e2 48 89 df e8 63 36 ff ff 89 c5 48 8b 83 68


https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash


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



echo -n "find /b ..., ..., 0x" && \
echo "ff 66 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 41 54 49 89 d4 55 48 
89 f5 53 48 8b 87 68 09 00 00 48 89 fb 48 85 c0 74 02  10 48 89 ee 4c 89 e2 
48 89 df e8 63 36 ff ff 89 c5 48 8b 83 68" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'





# Trixie/testing amd64 qemu VM 2024-06-18

apt update
apt dist-upgrade

apt install --no-install-recommends gnome
apt install gdb




gdb -q --pid $(pgrep nautilus)

pipe info share | grep -i x11
find /b 0x7fd8fcd4e970,  0x7fd8fcdd881e, 0xff, 0x66, 0x66, 0x2e, 0x0f, 
0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x90, 0xf3, 0x0f, 0x1e, 0xfa, 0x41, 
0x54, 0x49, 0x89, 0xd4, 0x55, 0x48, 0x89, 0xf5, 0x53, 0x48, 0x8b, 0x87, 0x68, 
0x09, 0x00, 0x00, 0x48, 0x89, 0xfb, 0x48, 0x85, 0xc0, 0x74, 0x02, 0xff, 0x10, 
0x48, 0x89, 0xee, 0x4c, 0x89, 0xe2, 0x48, 0x89, 0xdf, 0xe8, 0x63, 0x36, 0xff, 
0xff, 0x89, 0xc5, 0x48, 0x8b, 0x83, 0x68




benutzer@debian:~$ gdb -q --pid $(pgrep nautilus)
Attaching to process 2298
[New LWP 2349]
[New LWP 2351]
[New LWP 2352]
[New LWP 2373]
[New LWP 2383]
[New LWP 2384]
[New LWP 2529]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7fd8fd40947f in __GI___poll (fds=0x5562fdf47790, nfds=2, timeout=24377) 
at ../sysdeps/unix/sysv/linux/poll.c:29
29  ../sysdeps/unix/sysv/linux/poll.c: Datei oder Verzeichnis nicht 
gefunden.
(gdb) pipe info share | grep -i x11
0x7fd8fcd4e970  0x7fd8fcdd881e  Yes (*) 
/lib/x86_64-linux-gnu/libX11.so.6
0x7fd8f8002040  0x7fd8f800211f  Yes (*) 
/lib/x86_64-linux-gnu/libX11-xcb.so.1
(gdb) find /b 0x7fd8fcd4e970,  0x7fd8fcdd881e, 0xff, 0x66, 0x66, 0x2e, 
0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x90, 0xf3, 0x0f, 0x1e, 0xfa, 
0x41, 0x54, 0x49, 0x89, 0xd4, 0x55, 0x48, 0x89, 0xf5, 0x53, 0x48, 0x8b, 0x87, 
0x68, 0x09, 0x00, 0x00, 0x48, 0x89, 0xfb, 0x48, 0x85, 0xc0, 0x74, 0x02, 0xff, 
0x10, 0x48, 0x89, 0xee, 0x4c, 0x89, 0xe2, 0x48, 0x89, 0xdf, 0xe8, 0x63, 0x36, 
0xff, 0xff, 0x89, 0xc5, 0x48, 0x8b, 0x83, 0x68
0x7fd8fcd5ad33 <_XGetWindowAttributes+483>
1 pattern found.
(gdb) b * (0x7fd8fcd5ad33 + 42)
Breakpoint 1 at 0x7fd8fcd5ad5d
(gdb) info b
Num Type   Disp Enb AddressWhat
1   breakpoint keep y

Bug#1072284: 1072284: gitg: Massive amount of valgrind error reports and memory leak int gitg on bookworm

2024-06-17 Thread Bernhard Übelacker


On Fri, 31 May 2024 13:03:58 +0200 Eric Degenetais 
 wrote:


> valgrind gitg &

[... zillions of error reports ...]

==103518== Conditional jump or move depends on uninitialised value(s)
==103518==at 0xD95C49B: ???
==103518==by 0x2108005F: ???
==103518==
==103518==



Architecture: amd64 (x86_64)




Hello,
I am not maintainer of gitk, just tried to reproduce this
and was able to within a minimal amd64 qemu VM.

There I received a similar valgrind output.
When digging deeper and having the related dbgsym packages installed
the backtrace ends in something like this:

  (gdb) bt
  #0  0x13dd23c8 in ?? ()
  ...
  #18 0x0dfb2890 in ?? ()
  #19 0x06742280 in jit_machine_stack_exec () at 
src/pcre2_jit_match.c:57
  #20 0x06776894 in pcre2_jit_match_8 () at src/pcre2_jit_match.c:168
  #21 0x055f1edc in g_match_info_next () at ../../../glib/gregex.c:1119
  ...


Searching the internet for pcre2 and valgrind leads to this discussion [2].

There is the existence of the pcre2 configure parameter "--enable-valgrind" 
mentioned.
A local built package libpcre2-8-0, with this switch enabled,
makes the valgrind reports to go away.

Therefore this reports might be just false positives
due to pcre2's JIT using SIMD instructions.


[2] https://www.mail-archive.com/pcre-dev@exim.org/msg06407.html


Kind regards,
Bernhard
# Trixie/testing amd64 qemu VM 2024-06-17

apt update
apt dist-upgrade

apt install xserver-xorg slim jwm weston xterm tmux mc fakeroot pkg-config 
valgrind gitg
apt install gitg-dbgsym libpixman-1-0-dbgsym libgtksourceview-4-0-dbgsym 
libglib2.0-0t64-dbgsym libgit2-glib-1.0-0-dbgsym libpcre2-8-0-dbgsym 
libgit2-1.7-dbgsym valgrind-dbgsym
apt install --no-install-recommends gdm3
apt build-dep pcre2



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





git clone https://salsa.debian.org/gnome-team/gitg.git
cd gitg



export DISPLAY=:0



valgrind gitg



script -c "valgrind gitg" -a "$HOME/valgrind-gitg_$(date 
+%Y-%m-%d_%H-%M-%S).log"
...
==5810== Conditional jump or move depends on uninitialised value(s)
==5810==at 0x13DD03C8: ???
==5810==by 0xD1DA52F: ???
==5810== 
...


script -c "valgrind --vgdb=yes --vgdb-error=0 gitg" -a 
"$HOME/valgrind-gitg-gdb_$(date +%Y-%m-%d_%H-%M-%S).log"
script -c "gdb -q gitg" -a "$HOME/valgrind-gitg-gdb-gitg_$(date 
+%Y-%m-%d_%H-%M-%S).log"

target remote | /usr/bin/vgdb --pid=5907
cont

==5907== Conditional jump or move depends on uninitialised value(s)
==5907==at 0x13DD13C8: ???
==5907==by 0xDC694FF: ???
==5907== 
==5907== (action on error) vgdb me ... 

Thread 1 received signal SIGTRAP, Trace/breakpoint trap.
0x13dd13c8 in ?? ()
(gdb) bt
#0  0x13dd13c8 in ?? ()
#1  0x001ffeff6f70 in ?? ()
#2  0x08a717e8 in ?? () from 
/lib/x86_64-linux-gnu/libpixman-1.so.0
#3  0x0dc694ff in ?? ()
#4  0x in ?? ()
.





benutzer@debian:~$ script -c "gdb -q gitg" -a 
"$HOME/valgrind-gitg-gdb-gitg_$(date +%Y-%m-%d_%H-%M-%S).log"
Script started, output log file is 
'/home/benutzer/valgrind-gitg-gdb-gitg_2024-06-18_00-22-58.log'.
Reading symbols from gitg...
Reading symbols from 
/usr/lib/debug/.build-id/32/1b946cae9d0f8c7485c341a43a3d15bf4d3032.debug...
(gdb) target remote | /usr/bin/vgdb --pid=6547
Remote debugging using | /usr/bin/vgdb --pid=6547
relaying data between gdb and process 6547
warning: remote target does not support file transfer, attempting to access 
files from local filesystem.
Reading symbols from /lib64/ld-linux-x86-64.so.2...
Reading symbols from 
/usr/lib/debug/.build-id/a9/700083811ae36d1017fe16ebe5657d59cdda0a.debug...
0x0401a810 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) cont
Continuing.
[New Thread 6571]
[New Thread 6572]
[New Thread 6573]
[New Thread 6574]
[New Thread 6575]
[New Thread 6576]

Thread 1 received signal SIGTRAP, Trace/breakpoint trap.
0x13dd23c8 in ?? ()
(gdb) set width 0
(gdb) set pagination off
(gdb) bt
#0  0x13dd23c8 in ?? ()
#1  0x001ffeff6f70 in ?? ()
#2  0x08a717e8 in pixman_gradient_walker_pixel_32 (walker=0xdfb2652, 
x=137422171408) at ../../pixman/pixman-gradient-walker.c:199
#3  0x0dfb264f in ?? ()
#4  0x0044 in ?? ()
#5  0x0dfb264f in ?? ()
#6  0x0dfb264f in ?? ()
#7  0x0dfb264f in ?? ()
#8  0x0dfb264f in ?? ()
#9  0x0dfb264f in ?? ()
#10 0x000f8000fff08000 in ?? ()
#11 0x001ffeff6f70 in ?? ()
#12 0x08a719b0 in ?? () at ../../pixman/pixman-gradient-walker.c:178 
from /lib/x86_64-linux-gnu/libpixman-1.so.0
#13 0xfeff6d20 in ?? ()
#14 0x0dfb2650 in ?? ()
#15 0x0dfb10b0 in ?? ()
#16 0x0e58c1b0 in ?? ()
#17 0x0003 in ?? ()
#18 0x0dfb2890 in ?? ()
#19

Bug#1071977: tmux: /lib/x86_64-linux-gnu/libtinfo.so.6: version `NCURSES6_TINFO_6.4.current' 404

2024-06-12 Thread Bernhard Übelacker


On Sun, 26 May 2024 22:36:53 +0200 Marcel Partap  wrote:


tmux:
  Installed: 3.4-5
  Candidate: 3.4-5
  Version table:
 *** 3.4-5 510
500 http://ftp.de.debian.org/debian testing/main amd64 Packages
510 http://ftp.de.debian.org/debian unstable/main amd64 Packages
500 http://http.kali.org/kali kali-rolling/main amd64 Packages
100 /var/lib/dpkg/status
 3.4-5~bpo12+1 100
100 http://ftp.de.debian.org/debian bookworm-backports/main amd64
Packages
 3.3a-3 500
500 http://ftp.de.debian.org/debian stable/main amd64 Packages
500 http://ftp.de.debian.org/debian bookworm/main amd64 Packages
 3.3a-3~bpo11+1 100
100 http://ftp.de.debian.org/debian bullseye-backports/main amd64
Packages
 3.1c-1+deb11u1 500
500 http://ftp.de.debian.org/debian bullseye/main amd64 Packages

libtinfo6:
  Installed: 6.5-2
  Candidate: 6.5-2
  Version table:
 *** 6.5-2 510
500 http://ftp.de.debian.org/debian testing/main amd64 Packages
510 http://ftp.de.debian.org/debian unstable/main amd64 Packages
500 http://http.kali.org/kali kali-rolling/main amd64 Packages
100 /var/lib/dpkg/status
 6.4-4 500
500 http://ftp.de.debian.org/debian stable/main amd64 Packages
500 http://ftp.de.debian.org/debian bookworm/main amd64 Packages
 6.2+20201114-2+deb11u2 500
500 http://ftp.de.debian.org/debian bullseye/main amd64 Packages


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (510, 'unstable'), (509, 'experimental'), (500, 
'stable-updates'), (500, 'stable-security'), (500, 'oldstable-updates'), (500, 
'oldstable-security'), (500, 'testing'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386





Hello Marcel, hello Romain,
is this probably caused by having e.g. tmux from a Debian repository,
and libtinfo from a Kali repository.

I guess this could qualify this installation as "FrankenDebian" [1].

It might be possible to disable the Kali repository, do a `apt update`
and then list packages, which are not available in the configured repositories:

apt list "?obsolete"

I assume this list will contain either tmux, libtinfo6 or an even more central 
system package.
(Or none at all if versions of Kali and Debian packages match exactly?)

Reinstalling the Debian version of such packages might get the system
back to a consistent state, but be prepared for breaking the system even more.
   
apt install --reinstall package-name


Kind regards,
Bernhard

[1] https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_FrankenDebian

Bug#1072344: kio-extras-data: package is architecture all but contains architecture dependent service file.

2024-06-01 Thread Bernhard Übelacker


Package: kio-extras-data
Version: 4:23.08.4-1
Severity: normal
X-Debbugs-Cc: buebelac...@mailbox.org


Dear Maintainer,
I upgraded lately an i386 installation to Bookworm and tried to
access files on a connected Android phone.


Unfortunately there was not visible response from the UI when
clicking in the connected devices menu.
This was shown in "journal --user":
  dbus-daemon[1030]: [session uid=1000 pid=1030] Activating service name='org.kde.kmtpd5' 
requested by ':1.82' (uid=1000 pid=2985 
comm="/lib/i386-linux-gnu/libexec/kf5/kioslave5 /usr/lib")
  dbus-daemon[1030]: [session uid=1000 pid=1030] Activated service 
'org.kde.kmtpd5' failed: Failed to execute program org.kde.kmtpd5: No such file 
or directory


And the service file contains this:
  $ cat /usr/share/dbus-1/services/org.kde.kmtpd5.service
  [D-BUS Service]
  Name=org.kde.kmtpd5
  Exec=/usr/lib/x86_64-linux-gnu/libexec/kf5/kiod5


But the executable is in a i386 directory instead of x86_64:
  $ dpkg -S kf5/kiod5
  kio: /usr/lib/i386-linux-gnu/libexec/kf5/kiod5


Unfortunately this seems to be the case for Bookworm/stable and Trixie/testing.


If I understand it right, because of kio-extras-data being "Architecture: all",
this package got build at amd64 but used at all archs?

Would moving the file "org.kde.kmtpd5.service" from
package kio-extras-data to kio-extras already be sufficient?


Kind regards,
Bernhard




-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 6.7.12-686-pae (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_SOFTLOCKUP
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 kio-extras-data depends on:
ii  perl  5.38.2-4

kio-extras-data recommends no packages.

kio-extras-data suggests no packages.

-- no debconf information

Bug#1070687: systemsettings: received signal SIGSEGV, Segmentation fault

2024-05-20 Thread Bernhard Übelacker


On Tue, 07 May 2024 11:30:41 +0200 antonio  wrote:


Dear Maintainer,
when I try to add a online account (Systemsettings->Pesonalization->Online
Accounts->Add new account... button) I get this error:

Thread 1 "systemsettings" received signal SIGSEGV, Segmentation fault.
0x7fffc40f8765 in Accounts::Provider::~Provider() () from
/usr/lib/x86_64-linux-gnu/libaccounts-qt5.so.1

where:
libaccounts-qt5-1=1.17-1



Dear Maintainer,
I still can reproduce this with current Trixie/testing [1] [2].

The crash seems to happen because for some reason the member m_tags
contains an invalid pointer 0x1 [3].

With rr-debugger I could record such a crash and reverse execute to
where m_tags got overwritten with this 0x1 [4].

Unfortunately I still cannot tell the exact reason,
because the crash no longer happens with a locally rebuilt
package libkaccounts2.

Therefore, might this be an ABI break?
And could be solved by a binNMU of libkaccounts2?

Kind regards,
Bernhard


[1]
#4  
#5  0x7f1fb43a2765 in Accounts::Provider::~Provider() () from 
/lib/x86_64-linux-gnu/libaccounts-qt5.so.1
#6  0x7f1fb43bf198 in ProvidersModel::data(QModelIndex const&, int) const 
() from /lib/x86_64-linux-gnu/libkaccounts.so.2
#7  0x7f1fce9d44f0 in ?? () from /lib/x86_64-linux-gnu/libQt5QmlModels.so.5


[2]
With debug symbols:
#4  
#5  std::__atomic_base::load (__m=std::memory_order_relaxed, this=) at 
/usr/include/c++/13/bits/atomic_base.h:503
#6  QAtomicOps::loadRelaxed (_q_value=) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qatomic_cxx11.h:239
#7  QBasicAtomicInteger::loadRelaxed (this=) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qbasicatomic.h:107
#8  QtPrivate::RefCount::deref (this=) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qrefcount.h:66
#9  QHash::~QHash (this=0x1, __in_chrg=) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qhash.h:250
#10 QSet::~QSet (this=0x1, __in_chrg=) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qset.h:53
#11 Accounts::Provider::~Provider (this=, __in_chrg=) at ./Accounts/provider.cpp:93
#12 0x7f1fb43bf198 in ProvidersModel::data (this=, index=..., 
role=) at ./src/lib/providersmodel.cpp:105
#13 0x7f1fce9d44f0 in QModelIndex::data (arole=261, this=0x7ffddfe29ce0) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qabstractitemmodel.h:460


[3]
93  delete m_tags;
(rr) print this
$1 = (Accounts::Provider * const) 0x7ffc316dca20
(rr) print *this
$2 = {m_provider = 0x55b1af209730, m_tags = 0x1}
(rr) print >m_tags
$4 = (QSet **) 0x7ffc316dca28


[4]
(rr) watch *0x7ffc316dca28
Hardware watchpoint 1: *0x7ffc316dca28
(rr) reverse-cont
Continuing.
Thread 1 hit Hardware watchpoint 1: *0x7ffc316dca28
Old value = 1
New value = 0
0x7f97bc1bc223 in ProvidersModel::data (this=0x55b1af23c460, index=..., 
role=261) at ./src/lib/providersmodel.cpp:86
86  data.setValue(!provider.isSingleAccount());
(rr) bt
#0  0x7f97bc1bc223 in ProvidersModel::data(QModelIndex const&, int) const 
(this=0x55b1af23c460, index=, role=261) at 
./src/lib/providersmodel.cpp:86
#1  0x7f97c8a6f4f0 in QModelIndex::data(int) const (arole=261, 
this=0x7ffc316dcac0) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qabstractitemmodel.h:460
#2  QQmlDMAbstractItemModelData::value(int) const (role=261, 
this=0x55b1af0f5610) at ./src/qmlmodels/qqmladaptormodel.cpp:414
#3  QQmlDMCachedModelData::metaCall(QMetaObject::Call, int, void**) (this=0x55b1af0f5610, 
call=, id=, arguments=0x7ffc316dcb70) at 
./src/qmlmodels/qqmladaptormodel.cpp:282
#4  0x7f97cada4fd6 in  () at /lib/x86_64-linux-gnu/libQt5Qml.so.5

Bug#1070220: jbig2: broken manual page: src/jbig2: error while loading shared libraries: libjbig2enc.so.0: cannot open shared object file: No such file or directory

2024-05-18 Thread Bernhard Übelacker


On Thu, 02 May 2024 12:28:29 +0800 Paul Wise  wrote:


The jbig2 manual page is broken. Looks like it was generated via
help2man using the binary in the build tree but without using
LD_LIBRARY_PATH so the binary could not find libraries it uses,
so jbig2 could not start, so it didn't print the usage statement
and help2man did not convert the usage statement to a manual page.
The help2man conversion in debian/rules may have some kind of problem.




Hello,
it looks like make is not exporting the variable by default
to the environment of subprocesses.

This could be achieved by adding the below export [1].

Another way would be to move the LD_LIBRARY_PATH assignment
to the same line of help2man [2].

Kind regards,
Bernhard



[1]
--- orig/jbig2enc-0.29/debian/rules 2024-02-28 14:02:09.0 +0100
+++ try5/jbig2enc-0.29/debian/rules 2024-05-18 11:13:29.796407931 +0200
@@ -53,2 +53,3 @@ override_dh_installchangelogs:
 jbig2.1: LD_LIBRARY_PATH = src/.libs
+export LD_LIBRARY_PATH
 jbig2.1: %.1: src/%


[2]
--- orig/jbig2enc-0.29/debian/rules 2024-02-28 14:02:09.0 +0100
+++ try2/jbig2enc-0.29/debian/rules 2024-05-18 10:07:46.877615011 +0200
@@ -52,5 +52,4 @@ override_dh_installchangelogs:
 # build manpages
-jbig2.1: LD_LIBRARY_PATH = src/.libs
 jbig2.1: %.1: src/%
-   help2man --section 1 --no-info --no-discard-stderr \
+   LD_LIBRARY_PATH=src/.libs help2man --section 1 --no-info 
--no-discard-stderr \
--name "encoder for JBIG2" \

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

2024-05-06 Thread Bernhard Übelacker

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

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

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

--
Happy hacking
Petter Reinholdtsen

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

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

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

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

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

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

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

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

I guess upstream discussed this issue here:

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

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

Attached file shows my actions inside a minimal bookworm VM.

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

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

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

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

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

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

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

Bug#1054080: stlcmd: stl_boolean segfaults on some inputs

2024-05-06 Thread Bernhard Übelacker


Hello,
I am not maintainer of stlcmd, just tried to collect some more information.

This crash seems to be a stack overflow because of a recursive function call.

There is a comment near that recursive call, which could be interesting here.
And this issue seems not to be a packaging issue in Debian, therefore it
might be better to report this issue upstream in [2].

Kind regards,
Bernhard

[1] 
https://github.com/AllwineDesigns/stl_cmd/blob/7c2582864df1c10d11f5acb4901fb04c55ea7492/src/csgjs/Trees.cpp#L44-L55
[2] https://github.com/AllwineDesigns/stl_cmd/issues


Core was generated by `stl_boolean -a one.stl -b intersection.stl -d 
one-additions.stl'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7fe2a95c855e in _int_malloc (av=av@entry=0x7fe2a9712b80 , 
bytes=bytes@entry=512) at malloc.c:3637
3637malloc.c: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0  0x7fe2a95c855e in _int_malloc (av=av@entry=0x7fe2a9712b80 , 
bytes=bytes@entry=512) at malloc.c:3637
#1  0x7fe2a95c9de4 in __GI___libc_malloc (bytes=512) at malloc.c:3058
#2  0x7fe2a991c0b5 in operator new(unsigned long) () from 
/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x56309140a744 in __gnu_cxx::new_allocator::allocate 
(this=, __n=) at 
/usr/include/c++/7/ext/new_allocator.h:111
#4  std::allocator_traits >::allocate 
(__a=..., __n=) at /usr/include/c++/7/bits/alloc_traits.h:436
#5  std::_Vector_base 
>::_M_allocate (this=0x210, this@entry=0x7fff7ccf8470, __n=) at 
/usr/include/c++/7/bits/stl_vector.h:172
#6  std::vector 
>::_M_realloc_insert (this=this@entry=0x7fff7ccf8470, 
__position=, __args#0=@0x7fff7ccf82a0: 
0x563093c75b00) at /usr/include/c++/7/bits/vector.tcc:406
#7  0x56309140a84b in std::vector >::emplace_back 
(this=this@entry=0x7fff7ccf8470, __args#0=@0x7fff7ccf82a0: 0x563093c75b00) at 
/usr/include/c++/7/bits/vector.tcc:105
#8  0x563091409a9a in std::vector >::push_back (__x=@0x7fff7ccf82a0: 
0x563093c75b00, this=0x7fff7ccf8470) at /usr/include/c++/7/bits/stl_vector.h:954
#9  csgjs::PolygonTreeNode::splitPolygonByPlane 
(this=this@entry=0x563093c75b00, plane=..., coplanarFrontNodes=std::vector of 
length 0, capacity 0, coplanarBackNodes=std::vector of length 32, capacity 32 = 
{...},  frontNodes=std::vector of length 0, capacity 0, backNodes=std::vector 
of length 32, capacity 32 = {...}) at src/csgjs/Trees.cpp:298
#10 0x563091409d7c in csgjs::PolygonTreeNode::splitLeafByPlane 
(this=0x563093c75b00, plane=..., coplanarFrontNodes=std::vector of length 0, 
capacity 0,  coplanarBackNodes=std::vector of length 32, capacity 32 = {...}, 
frontNodes=std::vector of length 0, capacity 0, backNodes=std::vector of length 
32, capacity 32 = {...}) at src/csgjs/Trees.cpp:239
#11 0x563091409f67 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563096390cc0, polyTreeNodes=std::vector of length 60, 
capacity 64 = {...}) at src/csgjs/Trees.cpp:40
#12 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563096390a50, polyTreeNodes=std::vector of length 60, 
capacity 64 = {...}) at src/csgjs/Trees.cpp:54
#13 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x5630963907e0, polyTreeNodes=std::vector of length 60, 
capacity 64 = {...}) at src/csgjs/Trees.cpp:54
#14 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563096390570, polyTreeNodes=std::vector of length 60, 
capacity 64 = {...}) at src/csgjs/Trees.cpp:54
#15 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563096390300, polyTreeNodes=std::vector of length 60, 
capacity 64 = {...}) at src/csgjs/Trees.cpp:54
...
#65433 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563093c99510, polyTreeNodes=std::vector of length 60, 
capacity 64 = {...}) at src/csgjs/Trees.cpp:54
#65434 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563093c994b0, polyTreeNodes=std::vector of length 60, 
capacity 64 = {...}) at src/csgjs/Trees.cpp:54
#65435 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563093c99880, polyTreeNodes=std::vector of length 60, 
capacity 64 = {...}) at src/csgjs/Trees.cpp:54
#65436 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563093c99820, polyTreeNodes=std::vector of length 60, 
capacity 64 = {...}) at src/csgjs/Trees.cpp:54
#65437 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563093c997c0, polyTreeNodes=std::vector of length 60, 
capacity 64 = {...}) at src/csgjs/Trees.cpp:54
#65438 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563093c99720, polyTreeNodes=std::vector of length 113, 
capacity 128 = {...}) at src/csgjs/Trees.cpp:54
#65439 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563093c68e20, polyTreeNodes=std::vector of length 497, 
capacity 512 = {...}) at src/csgjs/Trees.cpp:54
#65440 0x563091409ff8 in

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

2024-05-06 Thread Bernhard Übelacker


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

Control: tags -1 confirmed

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

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


Did not investigate further.



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


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


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

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


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

Kind regards,
Bernhard


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

Bug#1069598: cifs-utils: When mounting a samba-share by a client with kernel 6.1.0-20-amd64, some subdirectories and files within the mounted share are missing

2024-05-05 Thread Bernhard Übelacker


Hello,
this seems to be the same issue as here:

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

And the fix seems to be prepared here:
https://salsa.debian.org/kernel-team/linux/-/commit/37a0ac93027302ffbfae41ddc844312e88e72eef

Kind regards,
Bernhard

Bug#1057620: doomsday: Crashes on startup

2024-05-05 Thread Bernhard Übelacker


On Tue, 05 Dec 2023 23:39:39 + Witold Baryluk  
wrote:


Thread 1 "doomsday" received signal SIGSEGV, Segmentation fault.
0x75419e83 in _XFlush () from /lib/x86_64-linux-gnu/libX11.so.6
(gdb) bt
#0  0x75419e83 in _XFlush () at /lib/x86_64-linux-gnu/libX11.so.6
#1  0x7541cb3d in _XGetRequest () at /lib/x86_64-linux-gnu/libX11.so.6
#2  0x7540fa57 in XQueryExtension () at 
/lib/x86_64-linux-gnu/libX11.so.6
#3  0x75402b16 in XInitExtension () at /lib/x86_64-linux-gnu/libX11.so.6
#4  0x753cdc9b in XextAddDisplay () at 
/lib/x86_64-linux-gnu/libXext.so.6
#5  0x7538a860 in  () at /lib/x86_64-linux-gnu/libXrandr.so.2
#6  0x7538afc0 in XRRQueryExtension () at 
/lib/x86_64-linux-gnu/libXrandr.so.2
#7  0x7798bae4 in de::internal::RRInfo::RRInfo() () at 
/lib/x86_64-linux-gnu/libdeng_gui.so.2.3
#8  0x7798b02d in DisplayMode_Native_Init () at 
/lib/x86_64-linux-gnu/libdeng_gui.so.2.3
#9  0x7791fd11 in DisplayMode_Init () at 
/lib/x86_64-linux-gnu/libdeng_gui.so.2.3
#10 0x5573eb1d in ClientApp::initialize() ()
#11 0x5572175d in main ()
(gdb) 



Running under gnome shell.

xwayland 2:23.2.2-1



Hello,
I am not maintainer of the doomsday package, just tried to collect some
more information.

Bug 1062969 / Bug 1065714 mentions a workaround
to be able to run doomsday with wayland:

SDL_VIDEODRIVER=x11 QT_QPA_PLATFORM=xcb doomsday


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


It looks like upstream removed the relevant code and relies just
on SDL functions, but unfortunately did not release a new version yet.


https://github.com/skyjake/Doomsday-Engine/commit/5cc4995861


Kind regards,
Bernhard
# 2024-05-05 Trixie/testing amd64 qemu VM

apt update
apt dist-upgrade
apt install systemd-coredump task-gnome-desktop tmux git gdb rr doomsday 
doomsday-dbgsym doomsday-common-dbgsym libxrandr2-dbgsym libxext6-dbgsym 
libx11-6-dbgsym
apt build-dep libx11-6




mkdir /home/benutzer/source/libx11-6/orig -p
cd/home/benutzer/source/libx11-6/orig
apt source libx11-6




benutzer@debian:~$ doomsday
QSocketNotifier: Can only be used with threads started with QThread
Speicherzugriffsfehler (Speicherabzug geschrieben)


benutzer@debian:~$ coredumpctl list
TIME  PID  UID  GID SIG COREFILE EXE
   SIZE
Sun 2024-05-05 16:04:00 CEST 2967 1000 1000 SIGSEGV present  
/usr/games/doomsday-2.3.1 2.7M


benutzer@debian:~$ coredumpctl gdb --debugger-arguments=-q 2967
Hint: You are currently not seeing messages from other users and the system.
  Users in groups 'adm', 'systemd-journal' can see all messages.
  Pass -q to turn off this notice.
   PID: 2967 (doomsday)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 11 (SEGV)
 Timestamp: Sun 2024-05-05 16:04:00 CEST (1min 51s ago)
  Command Line: doomsday
Executable: /usr/games/doomsday-2.3.1
 Control Group: 
/user.slice/user-1000.slice/user@1000.service/app.slice/app-org.gnome.Terminal.slice/vte-spawn-1c8dc387-bf63-4b3f-9404-fea9f4d9f742.scope
  Unit: user@1000.service
 User Unit: vte-spawn-1c8dc387-bf63-4b3f-9404-fea9f4d9f742.scope
 Slice: user-1000.slice
 Owner UID: 1000 (benutzer)
   Boot ID: 13ee1fcd8e5043bf91db85c4d1c72a51
Machine ID: 16e4d7437c19482b8c85581d3feaba09
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.doomsday.1000.13ee1fcd8e5043bf91db85c4d1c72a51.2967.171491784000.zst
 (present)
  Size on Disk: 2.7M
   Message: Process 2967 (doomsday) of user 1000 dumped core.

Module libblkid.so.1 from deb util-linux-2.40-8.amd64
Module libmount.so.1 from deb util-linux-2.40-8.amd64
Module libsystemd.so.0 from deb systemd-255.5-1.amd64
Module libzstd.so.1 from deb libzstd-1.5.5+dfsg2-2.amd64
Stack trace of thread 2967:
#0  0x7effce83 _XFlush (libX11.so.6 + 0x44e83)
#1  0x7effc0003b3d _XGetRequest (libX11.so.6 + 0x47b3d)
#2  0x7effbfff6a57 XQueryExtension (libX11.so.6 + 0x3aa57)
#3  0x7effbffe9b16 XInitExtension (libX11.so.6 + 0x2db16)
#4  0x7effc1b9bc9b XextAddDisplay (libXext.so.6 + 0xdc9b)
#5  0x7effc0ce484f n/a (libXrandr.so.2 + 0x284f)
#6  0x7effc0ce4f88 XRRQueryExtension (libXrandr.so.2 + 
0x2f88)
#7  0x7effc25af3b1 _ZN2de8internal6RRInfoC1Ev 
(libdeng_gui.so.2.3 + 0xe03b1)
#8  0x7effc25ae7ef DisplayMode_Native_Init 
(libdeng_gui.so.2.3 + 0xdf7ef)
#9  0x7effc253e619 DisplayMode_Init (libdeng_gui.so.2.3 + 
0x6f619)
#10 0x560786a6520d _ZN9ClientApp10initializeEv 
(doomsday-2.3.1 + 0x1fc20d)
#11 0x560786a469d1 main

Bug#1053128: smbclient: "smbtree -N" causes a segfault when "server min protocol = NT1"


Hello,
I am not a samba maintainer, just trying to collect some more information.

As far as I see the crash happens
because "cli_credentials_get_password(creds)" in line 62
returns a null pointer, which gets forwarded to
the call to strlcpy without further check.

Kind regards,
Bernhard



(rr) reverse-finish
Run back to call of #0  strlcpy (dst=0x7fff875c0640 "", src=0x0, dsize=) at ./src/strlcpy.c:36
0x5574e9c43c8c in get_auth_data_with_context_fn (context=, server=, 
share=, domain=, domain_len=, user=, 
user_len=256, password=0x7fff875c0640 "", password_len=256) at source3/utils/smbtree.c:61
61  len = strlcpy(
(rr) bt
#0  0x5574e9c43c8c in get_auth_data_with_context_fn (context=, server=, 
share=, domain=, domain_len=, user=, 
user_len=256, password=0x7fff875c0640 "", password_len=256) at source3/utils/smbtree.c:61
#1  0x7f9851ec6510 in SMBC_call_auth_fn (ctx=ctx@entry=0x5574eb8ba610, 
context=context@entry=0x5574eb8b7900, server=server@entry=0x5574eb8c9fe0 "10.0.2.15", 
share=share@entry=0x7f9851ed46a4 "IPC$", pp_workgroup=pp_workgroup@entry=0x7fff875c09b8, 
pp_username=pp_username@entry=0x7fff875c09a0, pp_password=0x7fff875c09a8) at 
source3/libsmb/libsmb_server.c:171
...

(rr) list smbtree.c:42
37
38  static void get_auth_data_with_context_fn(
39  SMBCCTX *context,
40  const char *server,
41  const char *share,
42  char *domain,
43  int domain_len,
44  char *user,
45  int user_len,
46  char *password,
47  int password_len)
48  {
49  struct cli_credentials *creds = samba_cmdline_get_creds();
50  size_t len;
51
52  len = strlcpy(domain, cli_credentials_get_domain(creds), 
domain_len);
53  if ((int)len >= domain_len) {
54  return;
55  }
56  len = strlcpy(
57  user, cli_credentials_get_username(creds), user_len);
58  if ((int)len >= user_len) {
59  return;
60  }
61  len = strlcpy(
62  password, cli_credentials_get_password(creds), 
password_len);
63  if ((int)len >= password_len) {
64  /* pointless, but what can you do... */
65  return;
66  }

# 2024-05-04 Trixie/testing amd64 qemu VM

apt install systemd-coredump mc gdb rr samba smbclient smbclient-dbgsym 
libsmbclient0-dbgsym libbsd0-dbgsym
apt build-dep samba



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



mc -e /etc/samba/smb.conf
 [global]
+server min protocol = NT1
 

testparm -s
systemctl enable --now smb
systemctl enable --now nmb
systemctl restart smbd nmbd
# Maybe a minute waiting is needed or this message appears "main: This is 
utility doesn't work if netbios name resolution is not configured."
smbtree -N --option="client min protocol = NT1"






benutzer@debian:~$ rr record smbtree -N --option="client min protocol = NT1"
rr: Saving execution to trace directory 
`/home/benutzer/.local/share/rr/smbtree-0'.
===
INTERNAL ERROR: Signal 11: Speicherzugriffsfehler in smbtree () () pid 9884 
(4.19.6-Debian)
If you are running a recent Samba version, and if you think this problem is not 
yet fixed in the latest versions, please consider reporting this bug, see 
https://wiki.samba.org/index.php/Bug_Reporting
===
PANIC (pid 9884): Signal 11: Speicherzugriffsfehler in 4.19.6-Debian
BACKTRACE: 14 stack frames:
 #0 
/usr/lib/x86_64-linux-gnu/samba/libgenrand-samba4.so.0(log_stack_trace+0x32) 
[0x7f9851a105c2]
 #1 /usr/lib/x86_64-linux-gnu/samba/libgenrand-samba4.so.0(smb_panic+0xd) 
[0x7f9851a1085d]
 #2 /usr/lib/x86_64-linux-gnu/samba/libgenrand-samba4.so.0(+0x28f5) 
[0x7f9851a108f5]
 #3 /lib/x86_64-linux-gnu/libc.so.6(+0x3c510) [0x7f9851acd510]
 #4 /lib/x86_64-linux-gnu/libbsd.so.0(strlcpy+0x10) [0x7f9851c7f900]
 #5 /lib/x86_64-linux-gnu/libsmbclient.so.0(+0x14510) [0x7f9851ec6510]
 #6 /lib/x86_64-linux-gnu/libsmbclient.so.0(+0x14ab1) [0x7f9851ec6ab1]
 #7 /lib/x86_64-linux-gnu/libsmbclient.so.0(+0x14bdb) [0x7f9851ec6bdb]
 #8 /lib/x86_64-linux-gnu/libsmbclient.so.0(+0x156e4) [0x7f9851ec76e4]
 #9 /lib/x86_64-linux-gnu/libsmbclient.so.0(+0xd37f) [0x7f9851ebf37f]
 #10 smbtree(main+0x262) [0x5574e9c43692]
 #11 /lib/x86_64-linux-gnu/libc.so.6(+0x276ca) [0x7f9851ab86ca]
 #12 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) [0x7f9851ab8785]
 #13 smbtree(_start+0x21) [0x5574e9c43b21]
smb_panic(): calling panic action [/usr/share/samba/panic-action 9884]
smb_panic(): action returned status 0
Can not dump core: corepath not set up
benutzer@debian:~$


benutzer@debian:~$ rr replay --debugger-option=-q smbtree-0
Reading symbols from /usr/bin/smbtree...
(No debugging symbols found in

Bug#1057172: baloo-kf5: Baloo Service Crashes After Enabling 'Index File Contents' Option


On Fri, 1 Dec 2023 00:26:27 +0100 Lucy  wrote:


#3 0x7fbe9c25afd0 __restore_rt (libc.so.6 + 0x3bfd0)
#4 0x557d83358770 n/a (baloo_file + 0x13770)
#5 0x557d8335885d n/a (baloo_file + 0x1385d)
#6 0x557d83365bf1 n/a (baloo_file + 0x20bf1)
#7 0x7fbe9cadd6f0 _ZN7QObject5eventEP6QEvent (libQt5Core.so.5 + 0x2dd6f0)



Hello,
I am not maintainer of baloo-kf5,
just just tried to collect some more information.

The interesting lines above in the stacktrace translate to this:
...
#3 0x7fbe9c25afd0 __restore_rt (libc.so.6 + 0x3bfd0)  |
#4 0x557d83358770 n/a (baloo_file + 0x13770)  | in 
QString::QString(QString const&) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qstring.h:1093
#5 0x557d8335885d n/a (baloo_file + 0x1385d)  | in 
QList::append(QString const&) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qlist.h:623
#6 0x557d83365bf1 n/a (baloo_file + 0x20bf1)  | in 
Baloo::FileContentIndexer::slotFinishedIndexingFile(QString const&, bool) at 
./src/file/filecontentindexer.cpp:125
#7 0x7fbe9cadd6f0 _ZN7QObject5eventEP6QEvent (libQt5Core.so.5 + 0x2dd6f0) | 

...


Unfortunately this leads just to some upstream bugs,
which are not showing much more information.

https://bugs.kde.org/show_bug.cgi?id=441860
https://bugs.kde.org/show_bug.cgi?id=443483
https://bugs.kde.org/show_bug.cgi?id=476479


Kind regards,
Bernhard

Stack trace of thread 1876:
#0 0x7fbe9c2a9d3c __pthread_kill_implementation (libc.so.6 + 0x8ad3c)
#1 0x7fbe9c25af32 __GI_raise (libc.so.6 + 0x3bf32)
#2 0x7fbe9cfabb46 _ZN6KCrash19defaultCrashHandlerEi (libKF5Crash.so.5 + 
0x5b46)
#3 0x7fbe9c25afd0 __restore_rt (libc.so.6 + 0x3bfd0)
#4 0x557d83358770 n/a (baloo_file + 0x13770)
#5 0x557d8335885d n/a (baloo_file + 0x1385d)
#6 0x557d83365bf1 n/a (baloo_file + 0x20bf1)
#7 0x7fbe9cadd6f0 _ZN7QObject5eventEP6QEvent (libQt5Core.so.5 + 0x2dd6f0)
#8 0x7fbe9cab16cd _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent 
(libQt5Core.so.5 + 0x2b16cd)
#9 0x7fbe9cab4681 
_ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData 
(libQt5Core.so.5 + 0x2b4681)
#10 0x7fbe9cb0a153 n/a (libQt5Core.so.5 + 0x30a153)
#11 0x7fbe9b11e7a9 g_main_context_dispatch (libglib-2.0.so.0 + 0x547a9)
#12 0x7fbe9b11ea38 n/a (libglib-2.0.so.0 + 0x54a38)
#13 0x7fbe9b11eacc g_main_context_iteration (libglib-2.0.so.0 + 0x54acc)
#14 0x7fbe9cb09836 
_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE
 (libQt5Core.so.5 + 0x309836)
#15 0x7fbe9cab017b _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE 
(libQt5Core.so.5 + 0x2b017b)
#16 0x7fbe9cab82d6 _ZN16QCoreApplication4execEv (libQt5Core.so.5 + 0x2b82d6)
#17 0x557d83353982 n/a (baloo_file + 0xe982)
#18 0x7fbe9c2461ca __libc_start_call_main (libc.so.6 + 0x271ca)
#19 0x7fbe9c246285 __libc_start_main_impl (libc.so.6 + 0x27285)
#20 0x557d83353b61 n/a (baloo_file + 0xeb61)

Thread 1 (Thread 0x7fbe9ac86540 (LWP 1876)):
[KCrash Handler]
#5 0x557d83358770 in ?? ()
#6 0x557d8335885d in ?? ()
#7 0x557d83365bf1 in ?? ()
#8 0x7fbe9cadd6f0 in QObject::event(QEvent*) () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5
#9 0x7fbe9cab16cd in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
() from /lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x7fbe9cab4681 in QCoreApplicationPrivate::sendPostedEvents(QObject*, 
int, QThreadData*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x7fbe9cb0a153 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#12 0x7fbe9b11e7a9 in g_main_context_dispatch () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x7fbe9b11ea38 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x7fbe9b11eacc in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x7fbe9cb09836 in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x7fbe9cab017b in 
QEventLoop::exec(QFlags) () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5
#17 0x7fbe9cab82d6 in QCoreApplication::exec() () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5
#18 0x557d83353982 in ?? ()
#19 0x7fbe9c2461ca in __libc_start_call_main 
(main=main@entry=0x557d833536e0, argc=argc@entry=1, 
argv=argv@entry=0x7ffd6ffbbe18) at ../sysdeps/nptl/libc_start_call_main.h:58
#20 0x7fbe9c246285 in __libc_start_main_impl (main=0x557d833536e0, argc=1, 
argv=0x7ffd6ffbbe18, init=, fini=, 
rtld_fini=, stack_end=0x7ffd6ffbbe08) at ../csu/libc-start.c:360
#21 0x557d83353b61 in ?? ()




# 2024-05-04 Bookworm/stable amd64 qemu VM



apt install --no-install-recommends --no-install-suggests gdb baloo-kf5 
baloo-kf5-dbgsym
apt build-dep baloo-kf5



mkdir /home/benutzer/source/baloo-kf5/orig -p
cd/home/benutzer/source/baloo-kf5/orig
apt source baloo-kf5



gdb -q
set width 0
set pagination off
directory

Bug#1059041: Xorg segfault when unlocking from Xscreensaver while video playback


On Tue, 19 Dec 2023 20:22:43 +0100 Eduard Bloch  wrote:


#7  0x7fb14945a510 __restore_rt (libc.so.6 + 0x3c510)
#8  0x7fb149186702 n/a (amdgpu_drv.so + 0x16702)
#9  0x7fb149186c96 n/a (amdgpu_drv.so + 0x16c96)
#10 0x5577d8e75a6b xf86DPMSSet (Xorg + 0xd3a6b)



Hello,
I am not maintainer of xserver-xorg-video-amdgpu,
just tried to collect some more information.

The interesting lines above in the stacktrace translate to this:

Stack trace of thread 1011552:
...
#7  0x7fb14945a510 __restore_rt (libc.so.6 + 0x3c510) |
#8  0x7fb149186702 n/a (amdgpu_drv.so + 0x16702)  | in drmmode_set_mode at 
../../src/drmmode_display.c:1267
#9  0x7fb149186c96 n/a (amdgpu_drv.so + 0x16c96)  | in 
drmmode_set_mode_major at ../../src/drmmode_display.c:1371
#10 0x5577d8e75a6b xf86DPMSSet (Xorg + 0xd3a6b)   | in xf86DPMSSet
...

This leads to this [1] upstream issue and merge request [2].
Unfortunately this is not yet part of an upstream release.

A workaround could be a local build of xserver-xorg-video-amdgpu
containing the two commits. They are the first commits after the 23.0.0 release.

Kind regards,
Bernhard

[1] https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/-/issues/70
[2] 
https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/-/merge_requests/85
# 2024-05-04 Trixie/testing amd64 qemu VM



apt install gdb xserver-xorg xserver-xorg-video-amdgpu xserver-xorg-core-dbgsym 
xserver-xorg-video-amdgpu-dbgsym
apt build-dep xserver-xorg-video-amdgpu



mkdir /home/benutzer/source/xserver-xorg-video-amdgpu/orig -p
cd/home/benutzer/source/xserver-xorg-video-amdgpu/orig
apt source xserver-xorg-video-amdgpu



gdb -q
set width 0
set pagination off
directory 
/home/benutzer/source/xserver-xorg-video-amdgpu/orig/xserver-xorg-video-amdgpu-23.0.0/debian/patches
file /usr/lib/xorg/Xorg
tb main
run
call dlopen("/usr/lib/xorg/modules/drivers/amdgpu_drv.so",0x101)
print (int)getpid()
shell cat /proc/2535/maps | grep amdgpu_drv | head -n1
b *(0x774f9000 + 0x16c96)
b *(0x774f9000 + 0x16702)
info b
pipe disassemble drmmode_set_mode_major | grep -i c96 -C3
pipe disassemble drmmode_set_mode | grep -i 702 -C3
list drmmode_display.c:1371
list drmmode_display.c:1267



benutzer@debian:~$ gdb -q
(gdb) set width 0
(gdb) set pagination off
(gdb) directory 
/home/benutzer/source/xserver-xorg-video-amdgpu/orig/xserver-xorg-video-amdgpu-23.0.0/debian/patches
Source directories searched: 
/home/benutzer/source/xserver-xorg-video-amdgpu/orig/xserver-xorg-video-amdgpu-23.0.0/debian/patches:$cdir:$cwd
(gdb) file /usr/lib/xorg/Xorg
Reading symbols from /usr/lib/xorg/Xorg...
Reading symbols from 
/usr/lib/debug/.build-id/77/6f662cfdbd2d0952921614575518e7c1b90261.debug...
(gdb) tb main
Temporary breakpoint 1 at 0x4d260: file ../../../../dix/stubmain.c, line 33.
(gdb) run
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".

Temporary breakpoint 1, main (argc=1, argv=0x7fffe478, envp=0x7fffe488) 
at ../../../../dix/stubmain.c:33
33  ../../../../dix/stubmain.c: Datei oder Verzeichnis nicht gefunden.
(gdb) call dlopen("/usr/lib/xorg/modules/drivers/amdgpu_drv.so",0x101)
$1 = (void *) 0x55803a80
(gdb) info inferior
  Num  Description   Connection   Executable
* 1process 2535  1 (native)   /usr/lib/xorg/Xorg 
(gdb) print (int)getpid()
$2 = 2535
(gdb) shell cat /proc/2535/maps | grep amdgpu_drv | head -n1
774f9000-7750 r--p  08:12 681046 
/usr/lib/xorg/modules/drivers/amdgpu_drv.so
(gdb) b *(0x774f9000 + 0x16c96)
Breakpoint 2 at 0x7750fc96: file ../../src/drmmode_display.c, line 1371.
(gdb) b *(0x774f9000 + 0x16702)
Breakpoint 3 at 0x7750f702: file ../../src/drmmode_display.c, line 1267.
(gdb) info b
Num Type   Disp Enb AddressWhat
2   breakpoint keep y   0x7750fc96 in drmmode_set_mode_major at 
../../src/drmmode_display.c:1371
3   breakpoint keep y   0x7750f702 in drmmode_set_mode at 
../../src/drmmode_display.c:1267
(gdb) pipe disassemble drmmode_set_mode_major | grep -i c96 -C3
   0x7750fc8b <+955>:   mov%r14,%rsi
   0x7750fc8e <+958>:   mov%rbx,%rdi
   0x7750fc91 <+961>:   call   0x7750f650 
   0x7750fc96 <+966>:   test   %eax,%eax
   0x7750fc98 <+968>:   jne0x7750fef8 

   0x7750fc9e <+974>:   mov0x30(%rsp),%rdi
   0x7750fca3 <+979>:   lea0x60(%rsp),%rsi
(gdb) pipe disassemble drmmode_set_mode | grep -i 702 -C3
   0x7750f6f8 <+168>:   jne0x7750f710 
   0x7750f6fa <+170>:   mov0x78(%rsi),%rsi
   0x7750f6fe <+174>:   mov0x10(%rsi),%rsi
   0x7750f702 <+178>:   mov(%rsi),%r11d
   0x7750f705 <+181>:   movslq %ecx,%rsi

Bug#1059874: libuhd4.6.0: Segfault in gqrx related to libuhd 4.6.0


Am 04.05.24 um 13:46 schrieb Bernhard Übelacker:

These end in some boost::asio functions:
   boost::asio::detail::scheduler::concurrency_hint() const at 
/usr/include/boost/asio/detail/scheduler.hpp:142



Forgot to attach how I got there:
  debugging.txt


And for reference the upstream ticket:
  https://github.com/gqrx-sdr/gqrx/issues/1331



[17674.068551] gqrx[3226752]: segfault at f4 ip 7f5fee944cd6 sp 
7f5f967f8870 error 4
[17674.068551] gqrx[3226753]: segfault at f4 ip 7f5fee944cd6 sp 
7f5f95ff7870 error 4 in libuhd.so.4.6.0[7f5fee721000+a5e000]
[17674.068558]  in libuhd.so.4.6.0[7f5fee721000+a5e000]
[17674.068557] traps: gqrx[3226749] general protection fault ip:7f5fee944cd6 
sp:7f5f977fb7d0 error:0
[17674.068558] gqrx[3226751]: segfault at f4 ip 7f5fee944cd6 sp 
7f5f96ff9870 error 4
[17674.068560]  likely on CPU 9 (core 1, socket 0)
[17674.068560]  likely on CPU 10 (core 2, socket 0)
[17674.068563]  in libuhd.so.4.6.0[7f5fee721000+a5e000]
[17674.068562] Code: ec 78 64 48 8b 04 25 28 00 00 00 48 89 44 24 68 31 c0 80 
bf c0 00 00 00 00 0f 85 ed 00 00 00 48 8b 45 30 48 8b 9d d0 00 00 00 <44> 8b b8 
f4 00 00 00 48 85 db 0f 84 3a 01 00 00 48 8b 43 18 48 89
[17674.068563] Code: ec 78 64 48 8b 04 25 28 00 00 00 48 89 44 24 68 31 c0 80 
bf c0 00 00 00 00 0f 85 ed 00 00 00 48 8b 45 30 48 8b 9d d0 00 00 00 <44> 8b b8 
f4 00 00 00 48 85 db 0f 84 3a 01 00 00 48 8b 43 18 48 89
[17674.068564]  in libuhd.so.4.6.0[7f5fee721000+a5e000]
[17674.068569] traps: gqrx[3226745] general protection fault ip:7f5fee944cd6 
sp:7f5fbe7f99d0 error:0
[17674.068571] gqrx[3226754]: segfault at f4 ip 7f5fee944cd6 sp 
7f5f957f6870 error 4
[17674.068575]  in libuhd.so.4.6.0[7f5fee721000+a5e000]
[17674.068576]  in libuhd.so.4.6.0[7f5fee721000+a5e000]
[17674.068578]  likely on CPU 12 (core 4, socket 0)
[17674.068580]  likely on CPU 14 (core 6, socket 0)
[17674.068580] Code: ec 78 64 48 8b 04 25 28 00 00 00 48 89 44 24 68 31 c0 80 
bf c0 00 00 00 00 0f 85 ed 00 00 00 48 8b 45 30 48 8b 9d d0 00 00 00 <44> 8b b8 
f4 00 00 00 48 85 db 0f 84 3a 01 00 00 48 8b 43 18 48 89
[17674.068583] Code: ec 78 64 48 8b 04 25 28 00 00 00 48 89 44 24 68 31 c0 80 
bf c0 00 00 00 00 0f 85 ed 00 00 00 48 8b 45 30 48 8b 9d d0 00 00 00 <44> 8b b8 
f4 00 00 00 48 85 db 0f 84 3a 01 00 00 48 8b 43 18 48 89


https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash

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



echo -n "find /b ..., ..., 0x" && \
echo "ec 78 64 48 8b 04 25 28 00 00 00 48 89 44 24 68 31 c0 80 bf c0 00 00 00 
00 0f 85 ed 00 00 00 48 8b 45 30 48 8b 9d d0 00 00 00 <44> 8b b8 f4 00 00 00 48 
85 db 0f 84 3a 01 00 00 48 8b 43 18 48 89" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'



# 2024-05-03 trixie/testing amd64 qemu VM

apt dist-upgrade
apt install systemd-coredump xserver-xorg slim jwm xterm gdb pipewire gqrx-sdr 
gqrx-sdr-dbgsym libuhd4.6.0-dbgsym
systemctl start slim




gdb -q 
set width 0
set pagination off
file /usr/bin/gqrx
tb main
run
pipe info target | grep -E "\.text.*libuhd"
find /b 0x743274a0, 0x74d7ee0a, 0xec, 0x78, 0x64, 0x48, 0x8b, 
0x04, 0x25, 0x28, 0x00, 0x00, 0x00, 0x48, 0x89, 0x44, 0x24, 0x68, 0x31, 0xc0, 
0x80, 0xbf, 0xc0, 0x00, 0x00, 0x00, 0x00, 0x0f, 0x85, 0xed, 0x00, 0x00, 0x00, 
0x48, 0x8b, 0x45, 0x30, 0x48, 0x8b, 0x9d, 0xd0, 0x00, 0x00, 0x00, 0x44, 0x8b, 
0xb8, 0xf4, 0x00, 0x00, 0x00, 0x48, 0x85, 0xdb, 0x0f, 0x84, 0x3a, 0x01, 0x00, 
0x00, 0x48, 0x8b, 0x43, 0x18, 0x48, 0x89
b * (0x74544cac + 42)
info b
disassemble /r 0x74544cac, 0x74544cac + 62



benutzer@debian:~$ gdb -q 
(gdb) set width 0
(gdb) set pagination off
(gdb) file /usr/bin/gqrx
Reading symbols from /usr/bin/gqrx...
Reading symbols from 
/usr/lib/debug/.build-id/99/990c9578178123477597a27d771c5793452e95.debug...
(gdb) tb main
Temporary breakpoint 1 at 0x9b8a0: file ./src/applications/gqrx/main.cpp, line 
49.
(gdb) run
Starting program: /usr/bin/gqrx 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffeea006c0 (LWP 18355)]
[New Thread 0x7fffee0006c0 (LWP 18356)]
[New Thread 0x7fffed6006c0 (LWP 18357)]
[New Thread 0x7fffecc006c0 (LWP 18358)]
[New Thread 0x7fffec2006c0 (LWP 18359)]
[New Thread 0x7fffeb8006c0 (LWP 18360)]
[New Thread 0x7fffeae006c0 (LWP 18361)]
[New Thread 0x7fffea4006c0 (LWP 18362)]
[New Thread 0x7fffe9a006c0 (LWP 18363)]
[New Thread 0x7fffe90006c0 (LWP 18364)]

Thread 1 "gqrx" hit Temporary breakpoint 1, main (argc=1, argv=0x7fffe488) 
at ./src/applications/gqrx/main.cpp:49
49  ./src/applications/gqrx/main.cpp: Datei oder Verzeichnis nicht gefunden.
(gdb) pipe info target | grep -E "\.text.*libuhd"
0x743274a0 - 0x74d7ee0a is .text in 
/lib/x86_64-linux-gnu/libuhd.so.4.6.0
(gdb) fin

Bug#1059874: libuhd4.6.0: Segfault in gqrx related to libuhd 4.6.0


Hello,
I am not the maintainer of libuhd, just tried to get some more
information from the provided dmesg Code lines.

These end in some boost::asio functions:
  boost::asio::detail::scheduler::concurrency_hint() const at 
/usr/include/boost/asio/detail/scheduler.hpp:142

Unfortunately this allows no guess to where exactly this is called in libuhd.


When I start qgrx inside a minimal VM I could not see a crash,
but guess this needs some special hardware?


If this is still an issue please provide
- the exact steps until you receive a crash.
- maybe the output which gets written when starting qgrx from a terminal
- install systemd-coredump. This should produce in the journal some more 
information.

A lot more information about how to retrieve a backtrace could be found here:
  https://wiki.debian.org/HowToGetABacktrace

Kind regards,
Bernhard

Bug#1060293: gnome-nettool: Aborts with assert failure: * stack smashing detected *

2024-05-02 Thread Bernhard Übelacker


Hello,
I am not maintainer of gnome-nettool, just tried to debug this issue.

gnome-nettool collects the information from an execution
of a dig command [1] and parses the output.
Unfortunately the parsing is done into some fixed size arrays
and the dig output overflows those.
E.g. the destination buffer is 128 bytes,
but 419 bytes from the line get written to it.

This parsing is done here [2] with the format string from here [3].

The stack canary is overwritten with this backtrace [4].

Kind regards,
Bernhard


[1] dig +nocomments +search +nocmd +nostats +noadditional codethink.co.uk ANY

[2] https://sources.debian.org/src/gnome-nettool/42.0-1/src/lookup.c/#L260

[3] https://sources.debian.org/src/gnome-nettool/42.0-1/src/lookup.h/#L25

[4]
  (rr) bt
  #0  0x7f28a2aa5735 in __vfscanf_internal (s=s@entry=0x7fff90ce11c0, 
format=format@entry=0x5572c3ef6a71 "%s %d %s %s %[^\n]", 
argptr=argptr@entry=0x7fff90ce11a8, mode_flags=mode_flags@entry=2) at 
./stdio-common/vfscanf-internal.c:2896
  #1  0x7f28a2a9791d in __GI___isoc99_sscanf (s=0x5572c5b75e70 
"codethink.co.uk.\t20762\tIN\tRRSIG\tSOA 10 3 86400 20240531041601 20240501031601 19848 
codethink.co.uk. m9sD9b/i+u7lOqOp/I/DSSxR8XoF8nA4bjCkHKdx3w8RdvFUGjOwsH77 
5t2+sFagf7qZ2YLcABs+mDpOe3UFzrGcMbNGRkXGYcW"..., format=format@entry=0x5572c3ef6a71 "%s 
%d %s %s %[^\n]") at ./stdio-common/isoc99_sscanf.c:31
  #2  0x5572c3ef1f1d in strip_line (data=0x7fff90ce1400, line=) at ../src/lookup.c:260
  #3  lookup_foreach_with_tree (netinfo=, line=, 
len=, user_data=) at ../src/lookup.c:189
  #4  0x5572c3eeb7f2 in netinfo_io_text_buffer_dialog (channel=, 
condition=, data=0x5572c59204a0) at ../src/nettool.c:409
  #5  0x7f28a2c7e0d9 in g_main_dispatch 
(context=context@entry=0x5572c552dbd0) at ../../../glib/gmain.c:3476
  #6  0x7f28a2c81317 in g_main_context_dispatch_unlocked 
(context=0x5572c552dbd0) at ../../../glib/gmain.c:4284
  #7  g_main_context_iterate_unlocked (context=0x5572c552dbd0, block=block@entry=1, 
dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:4349
  #8  0x7f28a2c81c1f in g_main_loop_run (loop=loop@entry=0x5572c568a510) at 
../../../glib/gmain.c:4551
  #9  0x7f28a33fd65d in gtk_main () at ../../../gtk/gtkmain.c:1329
  #10 0x5572c3ee95ba in main (argc=, argv=) 
at ../src/main.c:231
# 2024-05-01 trixie/testing amd64 qemu VM

apt install systemd-coredump task-gnome-desktop mc tmux htop git gdb valgrind 
rr gnome-nettool gnome-nettool-dbgsym libglib2.0-0t64-dbgsym 
libgtk-3-0t64-dbgsym
apt build-dep gnome-nettool
apt build-dep rr


mkdir /home/benutzer/source/gnome-nettool/orig -p
cd/home/benutzer/source/gnome-nettool/orig
apt source gnome-nettool


mkdir /home/benutzer/source/net-tools/orig -p
cd/home/benutzer/source/net-tools/orig
apt source net-tools





root@debian:~# journalctl -e
Mai 01 17:56:52 debian gnome-nettool.desktop[4366]: *** stack smashing detected 
***: terminated
Mai 01 17:56:52 debian systemd[1]: Created slice 
system-systemd\x2dcoredump.slice - Slice /system/systemd-coredump.
Mai 01 17:56:52 debian systemd[1]: Started systemd-coredump@0-4400-0.service - 
Process Core Dump (PID 4400/UID 0).
Mai 01 17:56:52 debian systemd-coredump[4401]: [] Process 4366 (gnome-nettool) 
of user 1000 dumped core.



root@debian:~# coredumpctl list
TIME  PID  UID  GID SIG COREFILE EXE
SIZE
Wed 2024-05-01 17:56:52 CEST 4366 1000 1000 SIGABRT present  
/usr/bin/gnome-nettool 1.8M



root@debian:~# coredumpctl gdb --debugger-arguments=-q 4366
   PID: 4366 (gnome-nettool)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 6 (ABRT)
 Timestamp: Wed 2024-05-01 17:56:52 CEST (4min 14s ago)
  Command Line: /usr/bin/gnome-nettool
Executable: /usr/bin/gnome-nettool
 Control Group: 
/user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-gnome\x2dnettool-4366.scope
  Unit: user@1000.service
 User Unit: app-gnome-gnome\x2dnettool-4366.scope
 Slice: user-1000.slice
 Owner UID: 1000 (benutzer)
   Boot ID: 7408197c36284bc295b6d821669a3071
Machine ID: 16e4d7437c19482b8c85581d3feaba09
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.gnome-nettool.1000.7408197c36284bc295b6d821669a3071.4366.171457901200.zst
 (present)
  Size on Disk: 1.8M
   Message: Process 4366 (gnome-nettool) of user 1000 dumped core.

Module libzstd.so.1 from deb libzstd-1.5.5+dfsg2-2.amd64
Module libsystemd.so.0 from deb systemd-255.4-1.amd64
Stack trace of thread 4366:
#0  0x7fdb1d71a16c n/a (libc.so.6 + 0x8a16c)
#1  0x7fdb1d6cc472 raise (libc.so.6 + 0x3c472)
#2  0x7fdb1d6b64b2 abort (libc.so.6 + 0x264b2)
#3  0x7fdb1d6b71ed n/a (libc.so.6 + 0x271ed)
#4  0x7fdb1d7a8465 __fortify_fail (libc.so.6 + 0x118465)
#5

Bug#1060224: bluetoothd started segfaulting

2024-05-01 Thread Bernhard Übelacker


Hello,
I am just trying to get the source line from the dmesg code line.



[   97.073761] bluetoothd[838]: segfault at 561314652a23 ip 56167406a375 sp 
7fffb128a200 error 4 in bluetoothd[561674048000+ec000] likely on CPU 11 
(core 5, socket 0)
[   97.073799] Code: 00 31 c0 e9 54 ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 
f3 0f 1e fa 41 55 41 54 55 53 48 83 ec 08 48 8b 2a 48 8b 7a 08 <48> 8b 45 20 4c 
8b ad 88 00 00 00 4c 8b 20 48 85 ff 74 19 c7 47 08



And it points to function a2dp_suspend_complete, [transport.c:431].

This function leads to upstream report [701],
which should be fixed since release 5.72 [83cfad1].

Kind regards,
Bernhard

[transport.c:431] 
https://sources.debian.org/src/bluez/5.71-1/profiles/audio/transport.c/#L431
[701] https://github.com/bluez/bluez/issues/701
[83cfad1] 
https://github.com/bluez/bluez/commit/83cfad1badee6aae77eb15177ccc917249ab9bb3
[   97.073761] bluetoothd[838]: segfault at 561314652a23 ip 56167406a375 sp 
7fffb128a200 error 4 in bluetoothd[561674048000+ec000] likely on CPU 11 
(core 5, socket 0)
[   97.073799] Code: 00 31 c0 e9 54 ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 
66 90 f3 0f 1e fa 41 55 41 54 55 53 48 83 ec 08 48 8b 2a 48 8b 7a 08 <48> 8b 45 
20 4c 8b ad 88 00 00 00 4c 8b 20 48 85 ff 74 19 c7 47 08

https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash

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






# 2024-05-01 trixie/testing amd64 qemu VM

apt dist-upgrade
apt install gdb bluez bluez-dbgsym
apt build-dep bluez


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



echo -n "find /b ..., ..., 0x" && \
echo "00 31 c0 e9 54 ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e 
fa 41 55 41 54 55 53 48 83 ec 08 48 8b 2a 48 8b 7a 08 <48> 8b 45 20 4c 8b ad 88 
00 00 00 4c 8b 20 48 85 ff 74 19 c7 47 08" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'

gdb -q
set width 0
set pagination off
file /usr/sbin/bluetoothd
tb main
run
pipe info target | grep -E "\.text$"

find /b 0x555798f0, 0x55663b30, 0x00, 0x31, 0xc0, 0xe9, 0x54, 
0xff, 0xff, 0xff, 0x66, 0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x66, 0x90, 0xf3, 0x0f, 0x1e, 0xfa, 0x41, 0x55, 0x41, 0x54, 0x55, 0x53, 
0x48, 0x83, 0xec, 0x08, 0x48, 0x8b, 0x2a, 0x48, 0x8b, 0x7a, 0x08, 0x48, 0x8b, 
0x45, 0x20, 0x4c, 0x8b, 0xad, 0x88, 0x00, 0x00, 0x00, 0x4c, 0x8b, 0x20, 0x48, 
0x85, 0xff, 0x74, 0x19, 0xc7, 0x47, 0x08
b * (0x5559a34b + 42)
info b
disassemble /r 0x5559a34b, 0x5559a34b + 62
directory /home/benutzer/source/bluez/orig/bluez-5.71




benutzer@debian:~$ gdb -q
(gdb) set width 0
(gdb) set pagination off
(gdb) file /usr/sbin/bluetoothd
Reading symbols from /usr/sbin/bluetoothd...
Reading symbols from 
/usr/lib/debug/.build-id/b3/ec9634ecf4f0995fa44119b844150cc8d98db5.debug...
(gdb) tb main
Temporary breakpoint 1 at 0x25bd0: file src/main.c, line 1355.
(gdb) run
Starting program: /usr/sbin/bluetoothd 
[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=0x7fffe478) at src/main.c:1355
1355src/main.c: Datei oder Verzeichnis nicht gefunden.
(gdb) pipe info target | grep -E "\.text$"
0x555798f0 - 0x55663b30 is .text
(gdb) find /b 0x555798f0, 0x55663b30, 0x00, 0x31, 0xc0, 0xe9, 
0x54, 0xff, 0xff, 0xff, 0x66, 0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x66, 0x90, 0xf3, 0x0f, 0x1e, 0xfa, 0x41, 0x55, 0x41, 0x54, 0x55, 
0x53, 0x48, 0x83, 0xec, 0x08, 0x48, 0x8b, 0x2a, 0x48, 0x8b, 0x7a, 0x08, 0x48, 
0x8b, 0x45, 0x20, 0x4c, 0x8b, 0xad, 0x88, 0x00, 0x00, 0x00, 0x4c, 0x8b, 0x20, 
0x48, 0x85, 0xff, 0x74, 0x19, 0xc7, 0x47, 0x08
0x5559a34b 
1 pattern found.
(gdb) b * (0x5559a34b + 42)
Breakpoint 2 at 0x5559a375: file profiles/audio/transport.c, line 431.
(gdb) info b
Num Type   Disp Enb AddressWhat
2   breakpoint keep y   0x5559a375 in a2dp_suspend_complete at 
profiles/audio/transport.c:431
(gdb) disassemble /r 0x5559a34b, 0x5559a34b + 62
Dump of assembler code from 0x5559a34b to 0x5559a389:
...
   0x5559a360 :f3 0f 1e fa 
endbr64
   0x5559a364 :41 55   
push   %r13
   0x5559a366 :41 54   
push   %r12
   0x5559a368 :55  
push   %rbp
   0x5559a369 :53  
push   %rbx
   0x5559a36a :   48 83 ec 08 
sub$0x8,%rsp
   0x5559a36e :   48 8b 2a
mov(%rdx),%rbp
   0x5559a371 :   48 8b 7a 08 
mov0x8(%rdx),%rdi
   0x5559a375 :   48 8b 45 20 
mov0x20(%rbp),%rax  <
   0x5559a379 :   4c 8b ad

Bug#1062205: Crashes desktop when attempting to make a network display

2024-04-28 Thread Bernhard Übelacker


On Fri, 2 Feb 2024 00:58:31 -0800 Josh Triplett  wrote:


Feb 02 00:28:37 o kernel: gnome-shell[1083]: segfault at 20 ip 7fececdf8f04 
sp 7ffc5ad85ed8 error 4 in 
libmutter-clutter-12.so.0.0.0[7fececda5000+9] likely on CPU 3 (core 4, 
socket 0)
Feb 02 00:28:37 o kernel: Code: c3 0f 1f 44 00 00 48 8d 15 e1 1a 04 00 48 8d 35 d2 7e 
05 00 48 8d 3d 4e f4 03 00 e9 d6 f2 fa ff 66 0f 1f 44 00 00 f3 0f 1e fa <48> 8b 
47 20 c3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8b 47 28 c3 0f



Hello,
I am not involved in maintaining this package, just looking through some crash 
reports.

My attempt to resolve the dmesg lines from the crash to a source line 
information led me here:

  clutter_paint_context_get_redraw_clip at 
../clutter/clutter/clutter-paint-context.c:140

  
https://sources.debian.org/src/mutter/44.8-3.1/clutter/clutter/clutter-paint-context.c/#L140
  137 const cairo_region_t *
  138 clutter_paint_context_get_redraw_clip (ClutterPaintContext 
*paint_context)
  139 {
  140   return paint_context->redraw_clip;
  141 }

This function name leads to following bug report, which sounds interesting:
  https://gitlab.gnome.org/GNOME/mutter/-/issues/2876

And which got fixed by this merge request:
  https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3283

First upstream release containing this fix would be 45.1,
unfortunately not yet in unstable or testing.


But a proper backtrace might still help to confirm, if this crash is
really the same which is described in the mentioned mutter bug report.
  https://wiki.debian.org/HowToGetABacktrace
Simplest version could be to install systemd-coredump
and inspecting the journal after a crash.

Kind regards,
Bernhard
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062205
https://wiki.debian.org/HowToGetABacktrace
https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash


Feb 02 00:28:37 o kernel: gnome-shell[1083]: segfault at 20 ip 7fececdf8f04 
sp 7ffc5ad85ed8 error 4 in 
libmutter-clutter-12.so.0.0.0[7fececda5000+9] likely on CPU 3 (core 4, 
socket 0)
Feb 02 00:28:37 o kernel: Code: c3 0f 1f 44 00 00 48 8d 15 e1 1a 04 00 48 8d 35 
d2 7e 05 00 48 8d 3d 4e f4 03 00 e9 d6 f2 fa ff 66 0f 1f 44 00 00 f3 0f 1e fa 
<48> 8b 47 20 c3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8b 47 28 c3 0f


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





# 2024-04-28 Trixie/testing amd64 qemu VM

apt update
apt dist-upgrade
apt build-dep libmutter-12-0

apt install systemd-coredump gdb libmutter-12-0 libmutter-12-0-dbgsym 
coreutils-dbgsym



mkdir /home/benutzer/source/libmutter-12-0/orig -p
cd/home/benutzer/source/libmutter-12-0/orig
apt source libmutter-12-0



echo -n "find /b ..., ..., 0x" && \
echo "c3 0f 1f 44 00 00 48 8d 15 e1 1a 04 00 48 8d 35 d2 7e 05 00 48 8d 3d 4e 
f4 03 00 e9 d6 f2 fa ff 66 0f 1f 44 00 00 f3 0f 1e fa <48> 8b 47 20 c3 0f 1f 80 
00 00 00 00 f3 0f 1e fa 48 8b 47 28 c3 0f" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'



gdb -q 
set width 0
set pagination off
file /usr/bin/true
tb main
run
call 
dlopen("/usr/lib/x86_64-linux-gnu/mutter-12/libmutter-clutter-12.so.0.0.0",0x102)
pipe info target | grep "\.text.*libmutter-clutter"
find /b 0x77cf0f30, 0x77d7a6de, 0xc3, 0x0f, 0x1f, 0x44, 0x00, 
0x00, 0x48, 0x8d, 0x15, 0xe1, 0x1a, 0x04, 0x00, 0x48, 0x8d, 0x35, 0xd2, 0x7e, 
0x05, 0x00, 0x48, 0x8d, 0x3d, 0x4e, 0xf4, 0x03, 0x00, 0xe9, 0xd6, 0xf2, 0xfa, 
0xff, 0x66, 0x0f, 0x1f, 0x44, 0x00, 0x00, 0xf3, 0x0f, 0x1e, 0xfa, 0x48, 0x8b, 
0x47, 0x20, 0xc3, 0x0f, 0x1f, 0x80, 0x00, 0x00, 0x00, 0x00, 0xf3, 0x0f, 0x1e, 
0xfa, 0x48, 0x8b, 0x47, 0x28, 0xc3, 0x0f
b * (0x77d3eeda + 42)
info b
disassemble /r 0x77d3eeda, 0x77d3eeda + 62
directory /home/benutzer/source/libmutter-12-0/orig/mutter-44.8/clutter



benutzer@debian:~$ gdb -q 
(gdb) set width 0
(gdb) set pagination off
(gdb) file /usr/bin/true
Reading symbols from /usr/bin/true...
Reading symbols from 
/usr/lib/debug/.build-id/04/6669aefa60ba9f99cc1c829bf6aac6e0d05d4c.debug...
(gdb) tb main
Temporary breakpoint 1 at 0x2310: file src/true.c, line 56.
(gdb) run
Starting program: /usr/bin/true 
[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=0x7fffe488) at src/true.c:56
56  src/true.c: Datei oder Verzeichnis nicht gefunden.
(gdb) call 
dlopen("/usr/lib/x86_64-linux-gnu/mutter-12/libmutter-clutter-12.so.0.0.0",0x102)
$1 = (void *) 0xe340
(gdb) pipe info target | grep "\.text.*libmutter-clutter"
0x77cf0f30 - 0x77d7a6de is .text in 
/usr/lib/x86_64-linux-gnu/mutter-12/libmutter-clutter-12.so.0.0.0
(gdb) find /b 0x77cf0f30, 0x77d7a6de, 0xc3, 0x0f, 0x1f, 0x44, 
0x00, 0x00, 0x48, 0x8d, 0x15, 0xe1, 0x1a, 0x04, 0x00, 0x48, 0x8d, 0x35, 0xd2, 
0x7e, 0x05, 0x00, 0x48, 0x8d, 0x3d, 0x4e, 0xf4, 0x03, 0x00, 0xe9, 0xd6, 0xf2,

Bug#1064372: evolution: segfault during startup

2024-04-26 Thread Bernhard Übelacker


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

Kind regards,
Bernhard


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

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

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


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


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


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

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

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


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

Bug#1068680: din: Process 166294 (din) of user 1000 dumped core

2024-04-24 Thread Bernhard Übelacker

Hello Cláudio,
I am not maintainer of the din package, just reading through some crash reports.

Unfortunately I cannot follow your claim "The crash occurred in the module
libzstd.so.1".
None of the 5 threads show a frame inside libzstd.
It seems just listed in the Module list.

Thread 166294 shows all the last frames in the din executable,
all other visible threads may just be "waiting", therefore the epoll_wait frame.

I would suggest to install systemd-coredump and gdb if not happened yet.

If it was, following sequence of command should enable the debugger to load
debug information for involved executables and print out function names
with source file and line number information.

export DEBUGINFOD_URLS="https://debuginfod.debian.net;
coredumpctl gdb 166294
y
thread apply all bt full
quit

This downloads several megabytes into $HOME/.cache/debuginfod_client.

And would show way more details for the maintainer to look at.

I tried to reconstruct the line information to your first thread,
which I suspect is the crashing one.

More information about debugging crashes can be found in this page:
https://wiki.debian.org/HowToGetABacktrace

Kind regards,
Bernhard

Stack trace of thread 166294:
#0 0x5617dbae42ab n/a (din + 0xc02ab)in font::draw_char(char, int,
int, int) at ./src/font.cc:203
#1 0x5617dbae4a75 n/a (din + 0xc0a75)in draw_string(std::__cxx11::basic_string, std::allocator > const&, int, int, int) at
./src/font.cc:220
#2 0x5617dba8c2e4 n/a (din + 0x682e4)in options_list::draw() at
./src/options_list.h:93
#3 0x5617dbb73b55 n/a (din + 0x14fb55) in settings::draw() at
./src/settings.cc:281
#4 0x5617dbb8aab0 n/a (din + 0x166ab0) in ui_list::draw() at
./src/ui.cc:151
#5 0x5617dba5a15b main (din + 0x3615b) in main(int, char**) at
./src/main.cc:1606

https://sources.debian.org/src/din/56-1/src/font.cc/#L203

Bug#1064347: openssh-server: sshd crashes under heavy traffic

2024-04-23 Thread Bernhard Übelacker


Hello,
I am no maintainer, just tried to reproduce this issue which I could
inside a minimal Bullseye amd64 qemu VM with the instructions
from the linked Ubuntu bug.

I could not reproduce it within Bookworm or Trixie/testing.

Without "LogLevel DEBUG" it was also not observable.

Unfortunately did also not happen with a ssh package built with asan enabled.

And I upgraded step by step via snapshot.d.o, around 2021-11-15 it
stopped to be an issue. This step brought openssh 8.7p1-1.
Downgrading just openssh 8.4p1-6 in this exact VM showed it again.

Therefore I assume this issue got fixed between openssh 8.4p1-6 and 8.7p1-1.

Kind regards,
Bernhard


#13 
#14 malloc_consolidate (av=av@entry=0x7faa3b64cb80 ) at 
malloc.c:4518
#15 0x7faa3b5023d5 in _int_malloc (av=av@entry=0x7faa3b64cb80 , 
bytes=bytes@entry=8193) at malloc.c:3699
#16 0x7faa3b503063 in malloc_check (sz=8192, caller=) at 
hooks.c:239
#17 0x7faa3b504cea in __libc_calloc (n=n@entry=1, 
elem_size=elem_size@entry=8192) at malloc.c:3387
#18 0x7faa3b4f6ef4 in __GI___open_memstream 
(bufloc=bufloc@entry=0x7ffe636eb6e0, sizeloc=sizeloc@entry=0x7ffe636eb6e8) at 
memstream.c:83
#19 0x7faa3b5726e1 in __vsyslog_internal (pri=39, fmt=0x55b451dcb150 
"%.500s", ap=0x7ffe636eb7d0, mode_flags=2) at ../misc/syslog.c:181
#20 0x7faa3b572d5f in __syslog_chk (pri=pri@entry=7, flag=flag@entry=1, 
fmt=fmt@entry=0x55b451dcb150 "%.500s") at ../misc/syslog.c:136
#21 0x55b451d87e16 in syslog (__fmt=0x55b451dcb150 "%.500s", __pri=7) at 
/usr/include/x86_64-linux-gnu/bits/syslog.h:31
#22 do_log (level=level@entry=SYSLOG_LEVEL_DEBUG1, fmt=fmt@entry=0x55b451dba421 
"Forked child %ld.", args=args@entry=0x7ffe636ec110) at ../../log.c:484
#23 0x55b451d88254 in debug (fmt=fmt@entry=0x55b451dba421 "Forked child 
%ld.") at ../../log.c:229
#24 0x55b451d3c86e in server_accept_loop (config_s=0x7ffe636ec270, newsock=, sock_out=, sock_in=) at 
../../sshd.c:1377
#25 main (ac=, av=) at ../../sshd.c:2089
# 2024-04-23 Bullseye/stable amd64 qemu VM


apt update
apt dist-upgrade
apt install systemd-coredump moreutils parallel htop fakeroot mc ccache gdb 
openssh-server-dbgsym
apt build-dep glibc
apt build-dep openssh-server


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

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



sed -i.bak 's/#LogLevel INFO/LogLevel DEBUG/g' /etc/ssh/sshd_config
systemctl restart sshd



ssh-keygen -b 4096
ssh-copy-id -i .ssh/id_rsa.pub benutzer@localhost
parallel -j 32 -N0 "ssh benutzer@localhost 'true'" ::: {1..2}







benutzer@debian:~/.ssh$ ssh-keygen -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/benutzer/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/benutzer/.ssh/id_rsa
Your public key has been saved in /home/benutzer/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:Hgx6dUtFBhKiI0wBYKtXMkwZeRcP/eEZCUsU69bbO+o benutzer@debian
The key's randomart image is:
+---[RSA 4096]+
|+o==  ++B+.++|
|.=+ ...=.++o |
| .*.+.. =oo+ |
|.  = o = ++. |
|. . . . S o  |
| .   . o . o |
|. . .|
|..   |
| .E...   |
+[SHA256]-+


benutzer@debian:~$ ssh-copy-id -i .ssh/id_rsa.pub benutzer@localhost
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: ".ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter 
out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are 
prompted now it is to install the new keys
benutzer@localhost's password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'benutzer@localhost'"
and check to make sure that only the key(s) you wanted were added.





parallel -j 800 -N0 "ssh benutzer@localhost 'mount; sleep 1; cat /proc/cpuinfo; 
free -h; dd if=/dev/zero of=/dev/null bs=1 count=8192; mount -av; sleep 
$(($RANDOM % 5)); lscpu'" ::: {1..1}
# AMD Ryzen 1700, VM, 16 threads















root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Tue 2024-04-23 00:20:53 CEST 124297 0 0   6 present   /usr/sbin/sshd
Tue 2024-04-23 00:23:02 CEST 159284 0 0   6 present   /usr/sbin/sshd
Tue 2024-04-23 00:23:47 CEST 229261 0 0  11 present   /usr/sbin/sshd
Tue 2024-04-23 00:24:32 CEST 277265 0 0  11 present   /usr/sbin/sshd
Tue 2024-04-23 00:24:54 CEST 301567 0 0   6 present   /usr/sbin/sshd





root@debian:~# coredumpctl gdb 301567
   PID: 301567 (sshd)
   UID: 0 (root)
   GID: 0 (root)
Signal: 6 (ABRT)
 Timestamp: Tue 2024-04-23 00:24:53 CEST (47s ago)
  Command Line: sshd: /usr/sbin/sshd -D [listener] 4 of 10-100 startups
Executable: /usr/sbin/sshd

Bug#1064613: vtun: Segmentation fault with default config

2024-04-22 Thread Bernhard Übelacker


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

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

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

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



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

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

Kind regards,
Bernhard


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

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

apt update
apt install systemd-coredump mc htop gdb

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



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


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

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


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

systemctl start vtun.service

-> Could not reproduce the crash




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

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

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

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



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

Bug#1067691: FTBFS: double free or corruption

2024-04-21 Thread Bernhard Übelacker


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

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

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

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


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

Kind regards,
Bernhard




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


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


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

Bug#1067907: flam3-utils: flam3-genome randomly segfaults on ppc64el

2024-04-13 Thread Bernhard Übelacker


Hello,
tried to reproduce the issue and got on a first run this stack:

(gdb) bt
#0  iter_thread_int (fth=0x157681210) at rect.c:500
#1  0x7fffaa36bad0 in iter_thread_float () at rect.c:253
#2  0x7fffa9c9b010 in start_thread (arg=0x7fffa740f100) at 
pthread_create.c:444
#3  0x7fffa9d3e364 in .LY__clone () at 
../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:107
(gdb)

More details in attached file.

Kind regards,
Bernhardhttps://people.debian.org/~gio/dqib/
https://gitlab.com/giomasce/dqib/-/jobs/6565595570/artifacts/download?file_type=archive


echo "set enable-bracketed-paste off" >> /etc/inputrc
echo "deb-src http://deb.debian.org/debian/ unstable main" >> 
/etc/apt/sources.list
apt update
apt install systemd-coredump flam3-utils htop gdb libflam3-0-dbgsym 
flam3-utils-dbgsym
apt build-dep flam3


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


benutzer@debian:~$ env seed=$RANDOM issac_seed=$RANDOM flam3-genome > /dev/null
Segmentation fault (core dumped)
benutzer@debian:~$ 


benutzer@debian:~$ coredumpctl list -q
TIMEPID  UID  GID SIG COREFILE EXE  
 SIZE
Sat 2024-04-13 08:59:01 UTC 819 1001 1001 SIGSEGV present  
/usr/bin/flam3-genome 1.8M


export DEBUGINFOD_URLS="https://debuginfod.debian.net;
echo "set debuginfod enabled on" >> .gdbinit
cd /home/benutzer/source/flam3/orig/flam3-3.1.1+ds2

benutzer@debian:~$ coredumpctl gdb --debugger-arguments=-q 819 
Hint: You are currently not seeing messages from other users and the system.
  Users in groups 'adm', 'systemd-journal' can see all messages.
  Pass -q to turn off this notice.
   PID: 819 (flam3-genome)
   UID: 1001 (benutzer)
   GID: 1001 (benutzer)
Signal: 11 (SEGV)
 Timestamp: Sat 2024-04-13 08:58:58 UTC (8min ago)
  Command Line: flam3-genome
Executable: /usr/bin/flam3-genome
 Control Group: /system.slice/ssh.service
  Unit: ssh.service
 Slice: system.slice
   Boot ID: 264b6d6ac02b49fcbf29cf0bda4825ba
Machine ID: 9d83830458974e43a3f2f91f73a6969d
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.flam3-genome.1001.264b6d6ac02b49fcbf29cf0bda4825ba.819.171299873800.zst
 (present)
  Size on Disk: 1.8M
   Message: Process 819 (flam3-genome) of user 1001 dumped core.

Stack trace of thread 1051:
#0  0x7fffaa36b444 n/a (libflam3.so.0 + 0x2b444)
#1  0x7fffaa36bad0 n/a (libflam3.so.0 + 0x2bad0)
#2  0x7fffa9c9b010 n/a (libc.so.6 + 0x9b010)
#3  0x7fffa9d3e364 __clone (libc.so.6 + 0x13e364)
ELF object binary architecture: PowerPC64

Reading symbols from /usr/bin/flam3-genome...
(No debugging symbols found in /usr/bin/flam3-genome)   

 
[New LWP 1051]
[New LWP 819]
[Thread debugging using libthread_db enabled]   

 
Using host libthread_db library "/lib/powerpc64-linux-gnu/libthread_db.so.1".
Core was generated by `flam3-genome '.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7fffaa36b444 in ?? () from /lib/powerpc64-linux-gnu/libflam3.so.0
[Current thread is 1 (Thread 0x7fffa740f100 (LWP 1051))]
(gdb) bt
#0  0x7fffaa36b444 in ?? () from /lib/powerpc64-linux-gnu/libflam3.so.0
#1  0x7fffaa36bad0 in ?? () from /lib/powerpc64-linux-gnu/libflam3.so.0
#2  0x7fffa9c9b010 in start_thread (arg=0x7fffa740f100) at 
pthread_create.c:444
#3  0x7fffa9d3e364 in .LY__clone () at 
../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:107
(gdb) 

(gdb) noshare
(gdb) share
...
(gdb) bt
#0  iter_thread_int (fth=0x157681210) at rect.c:500
#1  0x7fffaa36bad0 in iter_thread_float () at rect.c:253
#2  0x7fffa9c9b010 in start_thread (arg=0x7fffa740f100) at 
pthread_create.c:444
#3  0x7fffa9d3e364 in .LY__clone () at 
../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:107
(gdb) 

(gdb) directory /home/benutzer/source/flam3/orig/flam3-3.1.1+ds2
Source directories searched: 
/home/benutzer/source/flam3/orig/flam3-3.1.1+ds2:$cdir:$cwd

(gdb) list iter_thread_int
248  pthread_exit((void *)0);
249#endif
250
251 }
252
253 static void iter_thread(void *fth) {
254double sub_batch;
255int j;
256flam3_thread_helper *fthp = (flam3_thread_helper *)fth;
257flam3_iter_constants *ficp = fthp->fic;
258struct timespec pauset;
259int SBS = ficp->spec->sub_batch_size;
260int fuse;
261int cmap_size = ficp->cmap_size;
262int cmap_size_m1 = ficp->cmap_size-1;
263
264double eta = 0.0;

Bug#1067639: sasl2-bin: terminates with smashed stack and kills qemu-user?!

2024-04-12 Thread Bernhard Übelacker


Hello,
I tried to find some more information, with the help of a prebuilt full-system 
VM image.


On Thu, 4 Apr 2024 21:00:59 + (UTC) Thorsten Glaser  wrote:

Sometimes, it does not crash with a smashed stack but instead:

Setting up sasl2-bin (2.1.28+dfsg1-6+b1) ...
BDB0002 __fop_file_setup:  Retry limit (100) exceeded
saslpasswd2: generic failure


This looks to be a result of the pre-existing /etc/__db.sasldb2.
If this file gets removed the stack smashing occurs again.

By some experimenting I could convince gdb to load the debug symbols.
And the stack seems to point into function __os_unique_id from libdb-5.3.so.

Unfortunately I am not sure where the canary gets overwritten.

Kind regards,
Bernhard





https://people.debian.org/~gio/dqib/
https://gitlab.com/giomasce/dqib/-/artifacts
https://gitlab.com/giomasce/dqib/-/jobs/6565595565/artifacts/download?file_type=archive


apt install gdb sasl2-bin sasl2-bin-dbgsym libsasl2-2-dbgsym 
libsasl2-modules-db-dbgsym
apt install libc6-dbg libc6-dbgsym db-util db5.3-util libldap-2.5-0 
libldap-common libsasl2-2 libsasl2-2-dbgsym libsasl2-modules libsasl2-modules-db


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

rm /etc/__db.sasldb2
echo -e "test\ntest" > exclam

gdb -q
file /usr/sbin/saslpasswd2
run -c 'no:such:user' https://debuginfod.debian.net>
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
Downloading separate debug info for /usr/sbin/saslpasswd2
(No debugging symbols found in /usr/sbin/saslpasswd2)
(gdb) run -c 'no:such:user' , fname=0xc0605cb9 
"/etc/sasldb2", dname=0x0, type=DB_HASH, flags=1, mode=432) at 
../src/db/db_iface.c:1193
#13 0xc0604248 in ?? ()
#14 0xd00087b0 in ?? ()
#15 0x in ?? ()
(gdb) shell objdump --all-headers 
/usr/lib/m68k-linux-gnu/sasl2/libsasldb.so.2.0.25 | grep .text
 11 .text 27f0  138c  138c  138c  2**2
(gdb) print/x 0x138c + 0xc0602000
$4 = 0xc060338c

(gdb) add-symbol-file /usr/lib/m68k-linux-gnu/sasl2/libsasldb.so.2.0.25 
0xc060338c
add symbol table from file "/usr/lib/m68k-linux-gnu/sasl2/libsasldb.so.2.0.25" 
at
.text_addr = 0xc060338c
(y or n) y
Reading symbols from /usr/lib/m68k-linux-gnu/sasl2/libsasldb.so.2.0.25...
Reading symbols from 
/usr/lib/debug/.build-id/29/c8e688eb61b57bcd21794b5403feefe1272dfd.debug...
(gdb) bt
...
#15 0xc0603572 in sasldb_auxprop_store (glob_context=0x0, sparams=0xd00077b8, 
ctx=0xd0007a58, user=0xeed9 "no:such:user", ulen=12) at 
../../plugins/sasldb.c:258
#16 0xc002d26c in ?? ()
#17 0x in ?? ()
(gdb) shell cat /proc/10276/maps | grep -i -E "^c00"
c000-c002 r-xp  08:01 535730 /usr/lib/m68k-linux-gnu/ld.so.1
c002-c0021000 rw-p  00:00 0
c0021000-c0022000 r--p 00021000 08:01 535730 /usr/lib/m68k-linux-gnu/ld.so.1
c0022000-c0024000 rw-p 00022000 08:01 535730 /usr/lib/m68k-linux-gnu/ld.so.1
c0028000-c003c000 r-xp  08:01 539155 
/usr/lib/m68k-linux-gnu/libsasl2.so.2.0.25
c003c000-c003d000 ---p 00014000 08:01 539155 
/usr/lib/m68k-linux-gnu/libsasl2.so.2.0.25
c003d000-c003e000 r--p 00015000 08:01 539155 
/usr/lib/m68k-linux-gnu/libsasl2.so.2.0.25
c003e000-c003f000 rw-p 00016000 08:01 539155 
/usr/lib/m68k-linux-gnu/libsasl2.so.2.0.25
c004-c01b1000 r-xp  08:01 535733 
/usr/lib/m68k-linux-gnu/libc.so.6
(gdb) shell objdump --all-headers /usr/lib/m68k-linux-gnu/libsasl2.so.2.0.25 | 
grep .text
 12 .text e284  3db0  3db0  3db0  2**2
(gdb) print/x 0x3db0 + 0xc0028000
$5 = 0xc002bdb0
(gdb) add-symbol-file /usr/lib/m68k-linux-gnu/libsasl2.so.2.0.25 0xc002bdb0
add symbol table from file "/usr/lib/m68k-linux-gnu/libsasl2.so.2.0.25" at
.text_addr = 0xc002bdb0
(y or n) y
Reading symbols from /usr/lib/m68k-linux-gnu/libsasl2.so.2.0.25...
Reading symbols from 
/usr/lib/debug/.build-id/0f/8954c0644d1a9efec7973fb3198b8fd7649d5f.debug...
(gdb) set width 0
(gdb) set pagination off
(gdb) bt
...
#17 0xc00366dc in sasl_setpass (conn=0xd0006670, user=0xeed9 "no:such:user", 
pass=0xd0006608 "test\ntest", passlen=9, oldpass=0x0, oldpasslen=0, flags=1) at 
../../lib/server.c:186
#18 0xd0001534 in ?? ()
...
(gdb) shell cat /proc/10276/maps | grep -i -E "^d00"
d000-d0002000 r-xp  08:01 539212 /usr/sbin/saslpasswd2
d0003000-d0004000 r--p 3000 08:01 539212 /usr/sbin/saslpasswd2
d0004000-d0005000 rw-p 4000 08:01 539212 /usr/sbin/saslpasswd2
d0005000-d0026000 rwxp  00:00 0  [heap]
(gdb) shell objdump --all-headers /usr/sbin/saslpasswd2 | grep .text
 13 .text 0950  10b8  10b8  10b8  2**2
(gdb) print/x 0x10b8 + 0xd000
$6 = 0xd00010b8

(gdb) add-symbol-file /usr/sbin/saslpasswd2 0xd00010b8
add symbol table from file "/usr/sbin/saslpasswd2" at
.text_addr = 0xd00010b8
(y or n) y
Reading symbols from /usr/sbin/saslpasswd2...
Reading symbols from

Bug#1056555: thunar: segfault when ejecting drive

2024-04-09 Thread Bernhard Übelacker


Hello ng,


On Wed, 22 Nov 2023 22:47:01 -0300 ng  wrote:


[18950.426861] Thunar[3027]: segfault at 0 ip 5615a96c98cc sp 
7ffd2dbd7320 error 4 in thunar[5615a964+92000] likely on CPU 7 (core 3, 
socket 0)
[18950.426895] Code: f3 48 83 ec 38 64 48 8b 04 25 28 00 00 00 48 89 44 24 28 31 c0 
48 c7 44 24 20 00 00 00 00 48 85 f6 0f 84 77 02 00 00 48 8b 06 <48> 39 10 0f 84 
f1 01 00 00 4c 8b bf 28 01 00 00 4c 39 fe 0f 84 cb


This lines point to following source location:

thunar/thunar-window.c, line 4000

https://sources.debian.org/src/thunar/4.18.4-1/thunar/thunar-window.c/#L4000
3999   /* if the view already has the correct type then just return */
4000   if (view != NULL && G_TYPE_FROM_INSTANCE (view) == view_type)
4001 return;


Unfortunately this might yet not be enough for the maintainer to fix the issue.

Following link contains a few pointers how to get a backtrace of a crash:
https://wiki.debian.org/HowToGetABacktrace


Kind regards,
Bernhard


https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash


[18950.426861] Thunar[3027]: segfault at 0 ip 5615a96c98cc sp 
7ffd2dbd7320 error 4 in thunar[5615a964+92000] likely on CPU 7 (core 3, 
socket 0)
[18950.426895] Code: f3 48 83 ec 38 64 48 8b 04 25 28 00 00 00 48 89 44 24 28 
31 c0 48 c7 44 24 20 00 00 00 00 48 85 f6 0f 84 77 02 00 00 48 8b 06 <48> 39 10 
0f 84 f1 01 00 00 4c 8b bf 28 01 00 00 4c 39 fe 0f 84 cb

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


echo -n "find /b ..., ..., 0x" && \
echo "f3 48 83 ec 38 64 48 8b 04 25 28 00 00 00 48 89 44 24 28 31 c0 48 c7 44 
24 20 00 00 00 00 48 85 f6 0f 84 77 02 00 00 48 8b 06 <48> 39 10 0f 84 f1 01 00 
00 4c 8b bf 28 01 00 00 4c 39 fe 0f 84 cb" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'





# Bookworm/stable amd64 qemu VM 2024-04-09

apt update
apt install gdb thunar thunar-dbgsym

gdb -q 
set width 0
set pagination off
file /usr/bin/thunar
tb main
run 
pipe info target | grep "\.text"
find /b 0x5557fdb0, 0x5560bad9, 0xf3, 0x48, 0x83, 0xec, 0x38, 
0x64, 0x48, 0x8b, 0x04, 0x25, 0x28, 0x00, 0x00, 0x00, 0x48, 0x89, 0x44, 0x24, 
0x28, 0x31, 0xc0, 0x48, 0xc7, 0x44, 0x24, 0x20, 0x00, 0x00, 0x00, 0x00, 0x48, 
0x85, 0xf6, 0x0f, 0x84, 0x77, 0x02, 0x00, 0x00, 0x48, 0x8b, 0x06, 0x48, 0x39, 
0x10, 0x0f, 0x84, 0xf1, 0x01, 0x00, 0x00, 0x4c, 0x8b, 0xbf, 0x28, 0x01, 0x00, 
0x00, 0x4c, 0x39, 0xfe, 0x0f, 0x84, 0xcb
b * (0x556038a2 + 42)
info b
disassemble /r 0x556038a2, 0x556038a2 + 62





benutzer@debian:~$ gdb -q 
(gdb) set width 0
(gdb) set pagination off
(gdb) file /usr/bin/thunar
Reading symbols from /usr/bin/thunar...
Reading symbols from 
/usr/lib/debug/.build-id/1c/0053bee14d3fb731923319e68ac183a810d9db.debug...
(gdb) tb main
Temporary breakpoint 1 at 0x2bdd0: file ./thunar/main.c, line 49.
(gdb) run 
Starting program: /usr/bin/thunar 
[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=0x7fffe4d8) at ./thunar/main.c:49
49  ./thunar/main.c: Datei oder Verzeichnis nicht gefunden.
(gdb) pipe info target | grep "\.text"
0x5557fdb0 - 0x5560bad9 is .text
...
(gdb) find /b 0x5557fdb0, 0x5560bad9, 0xf3, 0x48, 0x83, 0xec, 
0x38, 0x64, 0x48, 0x8b, 0x04, 0x25, 0x28, 0x00, 0x00, 0x00, 0x48, 0x89, 0x44, 
0x24, 0x28, 0x31, 0xc0, 0x48, 0xc7, 0x44, 0x24, 0x20, 0x00, 0x00, 0x00, 0x00, 
0x48, 0x85, 0xf6, 0x0f, 0x84, 0x77, 0x02, 0x00, 0x00, 0x48, 0x8b, 0x06, 0x48, 
0x39, 0x10, 0x0f, 0x84, 0xf1, 0x01, 0x00, 0x00, 0x4c, 0x8b, 0xbf, 0x28, 0x01, 
0x00, 0x00, 0x4c, 0x39, 0xfe, 0x0f, 0x84, 0xcb
0x556038a2 
1 pattern found.
(gdb) b * (0x556038a2 + 42)
Breakpoint 2 at 0x556038cc: file ./thunar/thunar-window.c, line 4000.
(gdb) info b
Num Type   Disp Enb AddressWhat
2   breakpoint keep y   0x556038cc in 
thunar_window_replace_view at ./thunar/thunar-window.c:4000
(gdb) disassemble /r 0x556038a2, 0x556038a2 + 62
Dump of assembler code from 0x556038a2 to 0x556038e0:
   0x556038a2 :  f3 48 83 ec 38  
repz sub $0x38,%rsp
   0x556038a7 :  64 48 8b 04 25 28 00 00 
00  mov%fs:0x28,%rax
   0x556038b0 :  48 89 44 24 28  
mov%rax,0x28(%rsp)
   0x556038b5 :  31 c0   
xor%eax,%eax
   0x556038b7 :  48 c7 44 24 20 00 00 00 
00  movq   $0x0,0x20(%rsp)
   0x556038c0 :  48 85 f6
test   %rsi,%rsi
   0x556038c3 :  0f 84 77 02 00 00   
je 0x55603b40 
   0x556038c9 :  48 8b 06
mov(%rsi),%rax
   0x556038cc :  48 39 10
cmp%rdx,(%rax)<<<
   0x556038cf :  0f 84 f1 01 00 00   
je 0x55603ac6 
   0x556038d5 :  4c 8b bf 28 01 00 00
mov

Bug#1053433: mate-panel: mate-clock segfaults on return from hibernation

2024-04-09 Thread Bernhard Übelacker


Hello Olly,



(gdb) bt
#0  __pthread_kill_implementation (threadid=, 
signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1  0x7fa84248315f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78
#2  0x7fa842435472 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/posix/raise.c:26
#3  0x7fa84241f4b2 in __GI_abort () at ./stdlib/abort.c:79
#4  0x7fa84276d5dd in  ()
#5  0x in  ()

I read that as it's already aborting when it segfaults, so maybe that's
not helpful in knowing the root cause.  I'm happy to debug further if
someone tells me what to try.




This means the instruction just before 0x7fa84276d5dd
is most probably a call to function abort.
Usually this is done if some assertion fails.
Therefore there might something like "assertion failed" in the
logs at this time.

Unfortunately 0x7fa84276d5dd might be inside of a shared object.
And for it is no -dbgsym package installed.

To find out which shared object you might have a look into the
output of `info share`.

If you receive such a crash you could create a core dump with
gdb command `generate-core-file`.

Or install some core dump collector, e.g. systemd-coredump.
With this after a crash happened one can inspect it via
  coredumpctl list
  coredumpctl gdb

This link contains some more ways to debug
and to install the dbgsym packages:

https://wiki.debian.org/HowToGetABacktrace

Kind regards,
Bernhard

Bug#993018: valgrind: vgcore files unusable in gdb / does not load debug symbols

2024-04-06 Thread Bernhard Übelacker


control: forwarded 993018 https://bugs.kde.org/show_bug.cgi?id=485134
control: found 993018 1:3.20.0-2.1


Hello,
I got recently remembered about this bug and patch.
So I try to find out what upstream thinks about this.

It can still be observed with current version in Trixie/testing.

Kind regards,
Bernhard

Bug#1040496: qt6-virtualkeyboard FTBFS with parallel=1: qmlcachegen segfaults

2024-04-02 Thread Bernhard Übelacker


Hello,
I tried to reproduce this inside a minimal stable/bookworm VM
and received a qmlcachegen crash.

See attached file for details.
The resulting backtrace is quite similar to that found in:
  https://bugreports.qt.io/browse/QTBUG-117361

Might avoid the crash, but cannot say if this would make the build succeed.

Kind regards,
Bernhard


# 2024-04-02 stable/bookworm amd64 qemu VM

apt install systemd-coredump gdb libqt6qmlcompiler6-dbgsym
apt build-dep qt6-virtualkeyboard

mkdir /home/benutzer/source/qt6-virtualkeyboard/orig -p
cd/home/benutzer/source/qt6-virtualkeyboard/orig
apt source qt6-virtualkeyboard


cd /home/benutzer/source/qt6-virtualkeyboard
cp orig try1 -a
cd try1/qt6-virtualkeyboard-6.4.2+dfsg
DEB_BUILD_OPTIONS=parallel=1 dpkg-buildpackage


...
[110/301] cd 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components
 && /usr/bin/cmake -E make_directory 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qmlcache
 && /usr/lib/qt6/libexec/qmlcachegen --bare --resource-path 
/qt-project.org/imports/QtQuick/VirtualKeyboard/Components/Keyboard.qml -I 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/lib/x86_64-linux-gnu/qt6/qml
 -I /usr/lib/x86_64-linux-gnu/qt6/qml -i 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/lib/x86_64-linux-gnu/qt6/qml/QtQuick/VirtualKeyboard/Components/qmldir
 --resource 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qmake_QtQuick_VirtualKeyboard_Components.qrc
 --resource 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qtvkbcomponentsplugin_raw_qml_0.qrc
 -o 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qmlcache/qtvkbcomponentsplugin_Keyboard_qml.cpp
 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/src/components/Keyboard.qml
FAILED: src/components/.rcc/qmlcache/qtvkbcomponentsplugin_Keyboard_qml.cpp 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qmlcache/qtvkbcomponentsplugin_Keyboard_qml.cpp
 
cd 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components
 && /usr/bin/cmake -E make_directory 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qmlcache
 && /usr/lib/qt6/libexec/qmlcachegen --bare --resource-path 
/qt-project.org/imports/QtQuick/VirtualKeyboard/Components/Keyboard.qml -I 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/lib/x86_64-linux-gnu/qt6/qml
 -I /usr/lib/x86_64-linux-gnu/qt6/qml -i 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/lib/x86_64-linux-gnu/qt6/qml/QtQuick/VirtualKeyboard/Components/qmldir
 --resource 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qmake_QtQuick_VirtualKeyboard_Components.qrc
 --resource 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qtvkbcomponentsplugin_raw_qml_0.qrc
 -o 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qmlcache/qtvkbcomponentsplugin_Keyboard_qml.cpp
 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/src/components/Keyboard.qml
Segmentation fault (core dumped)
ninja: build stopped: subcommand failed.
dh_auto_build: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j1 -v 
returned exit code 1
make: *** [debian/rules:8: binary] Fehler 1
dpkg-buildpackage: Fehler: Unterprozess debian/rules binary lieferte Exitstatus 
2
benutzer@debian:~/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg$



dmesg
[  431.390156] qmlcachegen[5680]: segfault at 0 ip 7fde080d0672 sp 
7ffe33185b60 error 4 in libQt6QmlCompiler.so.6.4.2[7fde0804d000+106000] 
likely on CPU 5 (core 5, socket 0)
[  431.390173] Code: 64 cd f7 ff 0f 1f 40 00 41 57 41 56 41 55 41 54 55 48 89 
fd 53 48 89 f3 48 83 ec 28 64 48 8b 04 25 28 00 00 00 48 89 44 24 18 <48> 8b 06 
48 c7 06 00 00 00 00 4c 8b 27 48 89 07 4d 85 e4 74 10 4c



journalctl -e
Apr 02 22:45:36 debian systemd-coredump[5682]: [] Process 5680 (qmlcachegen) 
of user 1000 dumped core.
   
   Stack trace of thread 5680:
   #0  0x7fde080d0672 n/a 
(libQt6QmlCompiler.so.6 + 0xa8672)

Bug#1040382: slapd: debian12 ships with slapd-2.5.13+dfsg-5 which crashes (segfault in dynlist.la).

2024-04-02 Thread Bernhard Übelacker


On Wed, 24 Jan 2024 15:07:46 +0100 wouldsmina  wrote:

2024-01-24T09:38:16.810558+01:00 ldap kernel: [ 1553.168747] slapd[13335]: 
segfault at 0 ip 7fc2370b49c1 sp 7fbd359fc0c0 error 4 in 
dynlist-2.5.so.0.1.8[7fc2370b1000+6000] likely on CPU 1 (core 0, socket 2)
2024-01-24T09:38:16.810568+01:00 ldap kernel: [ 1553.168761] Code: 48 29 d0 48 89 d7 
48 89 c1 31 c0 83 c1 6c c1 e9 03 f3 48 ab 48 8b 84 24 10 02 00 00 4c 89 ef c7 84 24 
a0 00 00 00 03 00 00 00 <48> 8b 00 ff 50 78 44 39 73 64 74 09 45 84 e4 0f 85 22 
03 00 00 48


Hello,
I tried to get back to the source line of this dmesg output, maybe it is of any 
help.

It points to:
dynlist_search at ../../../../../servers/slapd/overlays/dynlist.c:1817
1817(void)o.o_bd->be_search( ,  );

This is the same line shown in the attachment of the upstream bug report.

Attached file shows how I got to this line.

Kind regards,
Bernhardslapd[13335]: segfault at 0 ip 7fc2370b49c1 sp 7fbd359fc0c0 error 4 in 
dynlist-2.5.so.0.1.8[7fc2370b1000+6000] likely on CPU 1 (core 0, socket 2)
Code: 48 29 d0 48 89 d7 48 89 c1 31 c0 83 c1 6c c1 e9 03 f3 48 ab 48 8b 84 24 
10 02 00 00 4c 89 ef c7 84 24 a0 00 00 00 03 00 00 00 <48> 8b 00 ff 50 78 44 39 
73 64 74 09 45 84 e4 0f 85 22 03 00 00 48


https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash


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

echo -n "find /b ..., ..., 0x" && \
echo "48 29 d0 48 89 d7 48 89 c1 31 c0 83 c1 6c c1 e9 03 f3 48 ab 48 8b 84 24 
10 02 00 00 4c 89 ef c7 84 24 a0 00 00 00 03 00 00 00 <48> 8b 00 ff 50 78 44 39 
73 64 74 09 45 84 e4 0f 85 22 03 00 00 48" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'

find /b ..., ..., 0x48, 0x29, 0xd0, 0x48, 0x89, 0xd7, 0x48, 0x89, 0xc1, 0x31, 
0xc0, 0x83, 0xc1, 0x6c, 0xc1, 0xe9, 0x03, 0xf3, 0x48, 0xab, 0x48, 0x8b, 0x84, 
0x24, 0x10, 0x02, 0x00, 0x00, 0x4c, 0x89, 0xef, 0xc7, 0x84, 0x24, 0xa0, 0x00, 
0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x48, 0x8b, 0x00, 0xff, 0x50, 0x78, 0x44, 
0x39, 0x73, 0x64, 0x74, 0x09, 0x45, 0x84, 0xe4, 0x0f, 0x85, 0x22, 0x03, 0x00, 
0x00, 0x48



# 2024-04-02 stable/bookworm amd64 qemu VM

apt install gdb slapd slapd-dbgsym

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


gdb -q 
set width 0
set pagination off
file /usr/sbin/slapd
tb main
run 
call dlopen("/usr/lib/ldap/dynlist-2.5.so.0.1.8",0x102)
pipe info target | grep "\.text"
find /b 0x774874a0, 0x7748ccaa, 0x48, 0x29, 0xd0, 0x48, 0x89, 
0xd7, 0x48, 0x89, 0xc1, 0x31, 0xc0, 0x83, 0xc1, 0x6c, 0xc1, 0xe9, 0x03, 0xf3, 
0x48, 0xab, 0x48, 0x8b, 0x84, 0x24, 0x10, 0x02, 0x00, 0x00, 0x4c, 0x89, 0xef, 
0xc7, 0x84, 0x24, 0xa0, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x48, 0x8b, 
0x00, 0xff, 0x50, 0x78, 0x44, 0x39, 0x73, 0x64, 0x74, 0x09, 0x45, 0x84, 0xe4, 
0x0f, 0x85, 0x22, 0x03, 0x00, 0x00, 0x48
b * (0x7748a997 + 42)
info b
disassemble /r 0x7748a997, 0x7748a997 + 62
directory 
/home/benutzer/source/slapd/orig/openldap-2.5.13+dfsg/servers/slapd/overlays



benutzer@debian:~$ gdb -q 
(gdb) set width 0
(gdb) set pagination off
(gdb) file /usr/sbin/slapd
Reading symbols from /usr/sbin/slapd...
Reading symbols from 
/usr/lib/debug/.build-id/40/63a68f1de0ddfe5b5d68cb4f6869587bda460a.debug...
(gdb) tb main
Temporary breakpoint 1 at 0x20b50: file ../../../../servers/slapd/main.c, line 
408.
(gdb) run 
Starting program: /usr/sbin/slapd 
[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=0x7fffe4d8) at 
../../../../servers/slapd/main.c:408
408 ../../../../servers/slapd/main.c: Datei oder Verzeichnis nicht gefunden.
(gdb) call dlopen("/usr/lib/ldap/dynlist-2.5.so.0.1.8",0x102)
$1 = (void *) 0x557231f0
(gdb) pipe info target | grep "\.text"
0x55574aa0 - 0x556375c4 is .text
0x77fcc060 - 0x77ff0d51 is .text in 
/lib64/ld-linux-x86-64.so.2
0x77fc96b0 - 0x77fc9ced is .text in system-supplied DSO 
at 0x77fc9000
0x77f72260 - 0x77fa8f06 is .text in 
/lib/x86_64-linux-gnu/libldap-2.5.so.0
0x77f53670 - 0x77f5a22a is .text in 
/lib/x86_64-linux-gnu/liblber-2.5.so.0
0x77f365b0 - 0x77f47005 is .text in 
/lib/x86_64-linux-gnu/libsasl2.so.2
0x77ef9040 - 0x77f0e33c is .text in 
/lib/x86_64-linux-gnu/libcrypt.so.1
0x77edf010 - 0x77eeefdd is .text in 
/lib/x86_64-linux-gnu/libslapi-2.5.so.0
0x77ecb490 - 0x77ecf5e6 is .text in 
/lib/x86_64-linux-gnu/libltdl.so.7
0x77ec06e0 - 0x77ec415e is .text in 
/lib/x86_64-linux-gnu/libwrap.so.0
0x77d02380 - 0x77e55f2d is .text in 
/lib/x86_64-linux-gnu/libc.so.6
0x77a3aac0 - 0x77b69520 is .text

Bug#1035595: gl-117: Crash on exit

2024-03-30 Thread Bernhard Übelacker




> malloc(): unsorted double linked list corrupted
> abort


Hello,
I could not reproduce this in a minimal bullseye or trixie amd64 VM,
and also not in a bookworm i386 VM.

But valgrind shows a few "Mismatched free() / delete / delete []"
or "Conditional jump or move depends on uninitialised value(s)".
Maybe those are responsible for the malloc abort.

Attached file fixes most of the issues shown by valgrind entering the 
main menu.


Kind regards,
BernhardDescription: Fix a few delete and uninitilised values shown by valgrind

Author: Bernhard Übelacker 
Last-Update: 2024-03-30

Index: gl-117-1.3.2/src/3ds.cpp
===
--- gl-117-1.3.2.orig/src/3ds.cpp
+++ gl-117-1.3.2/src/3ds.cpp
@@ -69,7 +69,7 @@ BinaryFile::BinaryFile (char *filename)
 
 BinaryFile::~BinaryFile ()
 {
-  delete data;
+  delete[] data;
 }
 
 int BinaryFile::readFloat (float *f)
@@ -503,7 +503,7 @@ void CLoad3DS::ReadUVCoordinates (CObjec
   
   for (int i = 0; i < object->numTexVertex; i ++)
 object->vertex [i].tex.take ( [i]);
-  delete p;
+  delete[] p;
 }
 
 void CLoad3DS::ReadVertices (CObject *object, Chunk *previousChunk)
@@ -532,7 +532,7 @@ void CLoad3DS::ReadVertices (CObject *ob
 object->vertex [i].vector.y = object->vertex [i].vector.z;
 object->vertex [i].vector.z = -fTempY;
   }
-  delete p;
+  delete[] p;
 }
 
 void CLoad3DS::ReadObjectMaterial (CModel *model, CObject *object, Chunk 
*previousChunk)
Index: gl-117-1.3.2/src/model.cpp
===
--- gl-117-1.3.2.orig/src/model.cpp
+++ gl-117-1.3.2/src/model.cpp
@@ -616,7 +616,7 @@ CModel::~CModel ()
 delete object [i];
   if (refpoint)
   {
-delete refpoint;
+delete[] refpoint;
   }
 }
 
Index: gl-117-1.3.2/src/gl.cpp
===
--- gl-117-1.3.2.orig/src/gl.cpp
+++ gl-117-1.3.2/src/gl.cpp
@@ -239,10 +239,11 @@ void GL::shadeSmooth ()
 
 void GL::enableFog (float view)
 {
-  float fcol [3];
+  float fcol [4];
   fcol [0] = fogcolor [0] * foglum;
   fcol [1] = fogcolor [1] * foglum;
   fcol [2] = fogcolor [2] * foglum;
+  fcol [3] = 0.0;
   glEnable (GL_FOG);
   glFogfv (GL_FOG_COLOR, fcol);
   glFogf (GL_FOG_DENSITY, 0.1);
Index: gl-117-1.3.2/src/aiobject.cpp
===
--- gl-117-1.3.2.orig/src/aiobject.cpp
+++ gl-117-1.3.2/src/aiobject.cpp
@@ -87,6 +87,7 @@ void DynamicObj::dinit ()
   forcex = 0; forcez = 0; forcey = 0;
   maxthrust = 0.3; braking = 0/*0.99*/; manoeverability = 0.5;
   thrust = maxthrust; recthrust = thrust; recheight = 5.0;
+  realspeed = 1.0;
   ttl = -1;
   shield = 0.01F; maxshield = 0.01F;
   immunity = 0;

Bug#1034685: glob2: Clicking “Settings” and then clicking “Ok” crashes/hangs glob2

2024-03-29 Thread Bernhard Übelacker


Hello,
this issue is still present with current testing.

For some weird reason this loop in line 195 is never left.
Putting a printf into this loop confirms that n counts correctly,
but the loop is not left when it reaches 13 (NB_BUILDING).

Strangely a similar loop with the same condition in line 186 works.

Not being able to explain it, I wonder if this might be a GCC issue?

Upstream made a change to this line in [1], changing the condition from
"n, filename=) at /usr/include/c++/13/bits/basic_string.h:222
222   _M_data() const
(gdb) bt
#0  0x55723317 in Settings::save (this=, 
filename=) at /usr/include/c++/13/bits/basic_string.h:222
#1  0x5572d613 in SettingsScreen::onAction (this=0x7fff93c0, source=, 
action=, par1=, par2=) at 
src/SettingsScreen.cpp:373
#2  0x557d1445 in GAGGUI::Screen::dispatchEvents 
(this=this@entry=0x7fff93c0, event=event@entry=0x7fff9260) at 
libgag/src/GUIBase.cpp:596
#3  0x557d185b in GAGGUI::Screen::execute 
(this=this@entry=0x7fff93c0, gfx=0x55920560, 
stepLength=stepLength@entry=40) at libgag/src/GUIBase.cpp:506
#4  0x5566cfb0 in Glob2::run (this=this@entry=0x7fffe357, argc=, argv=) at src/Glob2.cpp:348
#5  0x555b58fa in main (argc=, argv=) at 
src/Glob2.cpp:409

(gdb) print n
$2 = 8331033
(gdb) print keyname
$3 = "defaultFlagRadius[8331033]"

src/Settings.cpp:
195 for(int n=0; n(n)+"]";
198 Utilities::streamprintf(stream, "%s=%i\n", 
keyname.c_str(), defaultFlagRadius[n]);
199 }



[1] 
https://github.com/Globulation2/glob2/commit/30d272363d14cb2f3494e8dc7ef86e147b6b

Bug#1033222: libgl1-mesa-dri: Segmentation fault with nouveau_dri.so

2024-03-27 Thread Bernhard Übelacker


On Mon, 20 Mar 2023 11:34:43 +0100 Christophe Lohr 
 wrote:

Package: libgl1-mesa-dri
Version: 22.3.3-1
Severity: normal
X-Debbugs-Cc: christophe.l...@cegetel.net

Dear Maintainer,
  Xorg is carshing with a segfault:

(EE) Backtrace:
(EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x55c365ce4cf9]
(EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) [0x7f00ef25af90]
(EE) 2: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so 
(nouveau_drm_screen_create+0x4406c) [0x7f00ed75999c]
(EE) 3: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so 
(nouveau_drm_screen_create+0x1e4c9) [0x7f00ed733df9]
(EE) 4: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so 
(nouveau_drm_screen_create+0x266) [0x7f00ed715b96]
(EE) unw_get_proc_name failed: no unwind info found [-10]
../..
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
(EE)



Hello,
tried to get some symbols for the given backtrace.


2:   0x76b5999c : mov0x20(%rax),%rdi
   in nouveau_pushbuf_destroy at 
../src/gallium/drivers/nouveau/nouveau_screen.c:244

3:0x76b33df4 :call   0x76b59950 

   in nvc0_screen_destroy at 
../src/gallium/drivers/nouveau/nvc0/nvc0_screen.c:740

4:0x76b15b93 :  call   *0x10(%rax)
   in nouveau_drm_screen_create at 
../src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c:133


An internet search leads to:
  https://docs.mesa3d.org/relnotes/22.3.7.html
Sam Edwards (1):
nouveau: Fix null dereference in nouveau_pushbuf_destroy


So this looks exactly like the place of above frame 2,
and the issue might be fixed by this commit:
  
https://gitlab.freedesktop.org/mesa/mesa/-/commit/4585f21de47af5e2b1a018a052ac0aaf5f1f3ac5
  
https://gitlab.freedesktop.org/italove/mesa/-/commit/9de997bde67df43a9e10a05f9b48419ee4cfec25
  https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21611


Unfortunately stable/bookworm seems to just have received mesa 22.3.6:
  
https://sources.debian.org/src/mesa/22.3.6-1%2Bdeb12u1/src/gallium/drivers/nouveau/nouveau_screen.c/#L244

A workaround might be to locally rebuild mesa with this patch applied.
And testing/trixie might no longer be affected with a mesa version above 22.3.7.

Kind regards,
Bernhard
# 2024-03-26 Debian stable/bookworm qemu x86_64 VM


apt install libgl1-mesa-dri gdb coreutils-dbgsym


wget 
https://snapshot.debian.org/archive/debian/20230113T215719Z/pool/main/m/mesa/libgl1-mesa-dri_22.3.3-1_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20230113T215719Z/pool/main/m/mesa/libglapi-mesa_22.3.3-1_amd64.deb
wget 
https://snapshot.debian.org/archive/debian-debug/20230113T151646Z/pool/main/m/mesa/libglapi-mesa-dbgsym_22.3.3-1_amd64.deb
dpkg -i *22.3.3*


gdb -q --args /bin/true
set pagination off
set width 0
set environment LD_DEBUG = libs
tb main
run
call dlopen("/usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so",0x101)
disassemble 
nouveau_drm_screen_create+0x266-20,nouveau_drm_screen_create+0x266+20
b *nouveau_drm_screen_create+611
disassemble 
nouveau_drm_screen_create+0x1e4c9-20,nouveau_drm_screen_create+0x1e4c9+20
b* 0x76b33df4
disassemble 
nouveau_drm_screen_create+0x4406c-20,nouveau_drm_screen_create+0x4406c+20
b *0x76b5999c
info b

Bug#1055607: gmemusage crashes immediately

2023-11-25 Thread Bernhard Übelacker


Hello,

On Wed, 08 Nov 2023 20:17:49 +0100 =?utf-8?q?Andr=C3=A9_Offringa?= 
 wrote:


$ gmemusage
realloc(): invalid next size
Aborted


Looks like caused by having not enough space
for process names longer than 13 characters.

A package built with the modification below
shows no longer this crash.

Kind regard,
Bernhard




(gdb) bt
#0  __pthread_kill_implementation (threadid=, 
signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1  0x7f43d244b15f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78
#2  0x7f43d23fd472 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/posix/raise.c:26
#3  0x7f43d23e74b2 in __GI_abort () at ./stdlib/abort.c:79
#4  0x7f43d23e81ed in __libc_message (fmt=fmt@entry=0x7f43d255a78c "%s\n") 
at ../sysdeps/posix/libc_fatal.c:150
#5  0x7f43d2454a75 in malloc_printerr (str=str@entry=0x7f43d2558326 "realloc(): 
invalid next size") at ./malloc/malloc.c:5658
#6  0x7f43d245876c in _int_realloc (av=av@entry=0x7f43d2594c80 
, oldp=oldp@entry=0x564149c00680, oldsize=oldsize@entry=912, 
nb=nb@entry=1808) at ./malloc/malloc.c:4836
#7  0x7f43d2459596 in __GI___libc_realloc 
(oldmem=oldmem@entry=0x564149c00690, bytes=bytes@entry=1792) at 
./malloc/malloc.c:3477
#8  0x564148a039a5 in addProc (procname=procname@entry=0x7fffa8056900 
"cpuhp/3", mem=0, rss=0) at hash.c:89
#9  0x564148a03f20 in makeProcs () at proc.c:215
#10 0x564148a02e32 in draw_window () at gmemusage.c:489
#11 0x564148a02b85 in main (argc=, argv=) at 
gmemusage.c:300



benutzer@debian:~$ valgrind gmemusage
==1246== Memcheck, a memory error detector
==1246== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==1246== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==1246== Command: gmemusage
==1246==
==1246== Invalid write of size 1
==1246==at 0x48468E4: strcpy (vg_replace_strmem.c:553)
==1246==by 0x10B958: addProc (hash.c:101)
==1246==by 0x10BF1F: makeProcs (proc.c:215)
==1246==by 0x10AE31: draw_window (gmemusage.c:489)
==1246==by 0x10AB84: main (gmemusage.c:300)
==1246==  Address 0x4e6b740 is 0 bytes after a block of size 3,584 alloc'd
==1246==at 0x484582F: realloc (vg_replace_malloc.c:1437)
==1246==by 0x10B9A4: addProc (hash.c:89)
==1246==by 0x10BF1F: makeProcs (proc.c:215)
==1246==by 0x10AE31: draw_window (gmemusage.c:489)
==1246==by 0x10AB84: main (gmemusage.c:300)
==1246==



--- hash.c.orig 1998-01-14 17:43:13.0 +0100
+++ hash.c  2023-11-25 11:26:06.292932169 +0100
@@ -10,2 +10,3 @@
 #include 
+#include 
 #include "common.h"
@@ -73,3 +74,4 @@ addProc ( char *procname , int mem , int
   thisproc = nextproc = procs ;
-  strcpy ( thisproc -> procname , procname ) ;
+  strncpy ( thisproc -> procname , procname , sizeof(thisproc -> procname) 
) ;
+  thisproc -> procname[sizeof(thisproc -> procname)-1] = '\0';
   thisproc -> totMem = mem ;
@@ -100,3 +102,4 @@ addProc ( char *procname , int mem , int
   thisproc = procs + nProcs ;
-  strcpy ( thisproc -> procname , procname ) ;
+  strncpy ( thisproc -> procname , procname , sizeof(thisproc -> procname) 
) ;
+  thisproc -> procname[sizeof(thisproc -> procname)-1] = '\0';
   thisproc -> totMem = mem ;

Bug#1039695: libtracker-sparql-3.0-0: keeps segfaulting and restarting endlessly

2023-07-13 Thread Bernhard Übelacker


Hell Mulas,
I tried to get to the source line of you dmesg output:



[254868.778098] tracker-miner-f[1916712]: segfault at 8 ip 7f9bf641bc18 sp 
7fff0ca38e10 error 4 in 
libtracker-sparql-3.0.so.0.402.0[7f9bf63f9000+6a000] likely on CPU 2 (core 2, 
socket 0)
[254868.778109] Code: 18 64 48 2b 04 25 28 00 00 00 75 35 48 83 c4 20 5b c3 48 8b 44 
24 10 48 8d 15 84 dd 04 00 be 08 00 00 00 48 8d 3d fd 77 04 00 <48> 8b 48 08 31 
c0 e8 5d de fd ff 48 8b 7c 24 10 e8 03 da fd ff eb



I think this relates to this source line:

https://sources.debian.org/src/tracker/3.4.2-3/src/libtracker-sparql/core/tracker-data-manager.c/#L4050

g_critical ("Could not set up interface : %s",
error->message);


But a full backtrace is probably still needed by the maintainer.
You could probably collect one by installing systemd-coredump.
Then journalctl should contain a more detailed information on
which functions are involved.

Kind regards,
Bernhard



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

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




[254868.778098] tracker-miner-f[1916712]: segfault at 8 ip 7f9bf641bc18 sp 
7fff0ca38e10 error 4 in 
libtracker-sparql-3.0.so.0.402.0[7f9bf63f9000+6a000] likely on CPU 2 (core 2, 
socket 0)
[254868.778109] Code: 18 64 48 2b 04 25 28 00 00 00 75 35 48 83 c4 20 5b c3 48 
8b 44 24 10 48 8d 15 84 dd 04 00 be 08 00 00 00 48 8d 3d fd 77 04 00 <48> 8b 48 
08 31 c0 e8 5d de fd ff 48 8b 7c 24 10 e8 03 da fd ff eb



echo -n "find /b ..., ..., 0x" && \
echo "18 64 48 2b 04 25 28 00 00 00 75 35 48 83 c4 20 5b c3 48 8b 44 24 10 48 
8d 15 84 dd 04 00 be 08 00 00 00 48 8d 3d fd 77 04 00 <48> 8b 48 08 31 c0 e8 5d 
de fd ff 48 8b 7c 24 10 e8 03 da fd ff eb" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'
#





apt install gdb tracker-miner-fs tracker-miner-fs-dbgsym 
libtracker-sparql-3.0-0-dbgsym



gdb -q --args /usr/libexec/tracker-miner-fs-3

set width 0
set pagination off
tb main
run

pipe info share | grep libtracker-sparql-3.0

find /b 0x77b4e120,  0x77bb49f2, 0x18, 0x64, 0x48, 0x2b, 0x04, 
0x25, 0x28, 0x00, 0x00, 0x00, 0x75, 0x35, 0x48, 0x83, 0xc4, 0x20, 0x5b, 0xc3, 
0x48, 0x8b, 0x44, 0x24, 0x10, 0x48, 0x8d, 0x15, 0x84, 0xdd, 0x04, 0x00, 0xbe, 
0x08, 0x00, 0x00, 0x00, 0x48, 0x8d, 0x3d, 0xfd, 0x77, 0x04, 0x00, 0x48, 0x8b, 
0x48, 0x08, 0x31, 0xc0, 0xe8, 0x5d, 0xde, 0xfd, 0xff, 0x48, 0x8b, 0x7c, 0x24, 
0x10, 0xe8, 0x03, 0xda, 0xfd, 0xff, 0xeb

b * (0x77b6dbee + 42)

(gdb) info b
Num Type   Disp Enb AddressWhat
2   breakpoint keep y   0x77b6dc18 in setup_interface_cb at 
../src/libtracker-sparql/core/tracker-data-manager.c:4050
(gdb) disassemble /r 0x77b6dbee, 0x77b6dbee + 62
Dump of assembler code from 0x77b6dbee to 0x77b6dc2c:
   0x77b6dbee :  18 64 48 2b sbb
%ah,0x2b(%rax,%rcx,2)
   0x77b6dbf2 :  04 25   add
$0x25,%al
   0x77b6dbf4 :  28 00   sub
%al,(%rax)
   0x77b6dbf6 :  00 00   add
%al,(%rax)
   0x77b6dbf8 :  75 35   jne
0x77b6dc2f 
   0x77b6dbfa :  48 83 c4 20 add
$0x20,%rsp
   0x77b6dbfe :  5b  pop
%rbx
   0x77b6dbff :  c3  ret
   0x77b6dc00 :  48 8b 44 24 10  mov
0x10(%rsp),%rax
   0x77b6dc05 : 48 8d 15 84 dd 04 00lea
0x4dd84(%rip),%rdx# 0x77bbb990
   0x77b6dc0c : be 08 00 00 00  mov
$0x8,%esi
   0x77b6dc11 : 48 8d 3d fd 77 04 00lea
0x477fd(%rip),%rdi# 0x77bb5415
>>>0x77b6dc18 : 48 8b 48 08 mov
>>>0x8(%rax),%rcx
   0x77b6dc1c : 31 c0   xor
%eax,%eax
   0x77b6dc1e : e8 5d de fd ff  call   
0x77b4ba80 
   0x77b6dc23 : 48 8b 7c 24 10  mov
0x10(%rsp),%rdi
   0x77b6dc28 : e8 03 da fd ff  call   
0x77b4b630 
End of assembler dump.


https://sources.debian.org/src/tracker/3.4.2-3/src/libtracker-sparql/core/tracker-data-manager.c/#L4050

g_critical ("Could not set up interface : %s",
error->message);

Bug#1037481: Bug #1037481: outguess: Stack smashing detected and SIGABRT during finding of best embedding

2023-07-11 Thread Bernhard Übelacker


Hello,
just tried to get some more information where this stack smashing happens.

The stack canary gets at least overwritten here:

165 memmove(detect + n + 1, detect + n,
166 (j - n) * sizeof(int));

The variable detect has a size of 12.
The parameter to memove is the second element,
therefore the size parameter to memove should be <= 8.

But actually the size parameter to memove is 12,
therefore memove writes beyond the variable detect.

Attached file shows some debugging attempts.

Kind regards,
Bernhard

# 2023-07-11 bookworm/stable amd64 qemu VM

apt update
apt dist-upgrade

apt install systemd-coredump gdb rr valgrind outguess outguess-dbgsym
apt build-dep outguess



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





benutzer@debian:~$ wget -q 
https://upload.wikimedia.org/wikipedia/commons/3/3f/JPEG_example_flower.jpg
benutzer@debian:~$ echo msg1 > msg1.txt
benutzer@debian:~$ echo msg2 > msg2.txt
benutzer@debian:~$ outguess -k "key1" -d msg1.txt -E -K "key2" -D msg2.txt -p 
100 JPEG_example_flower.jpg JPEG_example_flower.steg.jpg
Initialize encoding/decoding tables
Reading JPEG_example_flower.jpg
JPEG compression quality set to 100
Extracting usable bits:   70325 bits
Correctable message size: 17434 bits, 24.79%
Encoded 'msg1.txt': 40 bits, 5 bytes
Finding best embedding...
0:33(45.8%)[82.5%], bias28(0.85), saved:-1, total:  0.05%
1:28(38.9%)[70.0%], bias25(0.89), saved:-1, total:  0.04%
6:30(42.3%)[75.0%], bias19(0.63), saved:-1, total:  0.04%
   11:28(38.9%)[70.0%], bias13(0.46), saved:-1, total:  0.04%
11, 41: Embedding data: 40 in 70325
Bits embedded: 72, changed: 28(38.9%)[70.0%], bias: 13, tot: 68673, skip: 68601
Encoded 'msg2.txt' with ECC: 96 bits, 12 bytes
Finding best embedding...
*** stack smashing detected ***: terminated
Abgebrochen (Speicherabzug geschrieben)


cd /home/benutzer/source/outguess/orig/outguess-0.4

coredumpctl list
TIME  PID  UID  GID SIG COREFILE EXE
 SIZE
Tue 2023-07-11 10:00:02 CEST 1136 1000 1000 SIGABRT present  /usr/bin/outguess 
412.4K

coredumpctl gdb --debugger-argument=-q 1136

(gdb) bt
#0  __pthread_kill_implementation (threadid=, 
signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1  0x7f83ca05bd2f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78
#2  0x7f83ca00cef2 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/posix/raise.c:26
#3  0x7f83c9ff7472 in __GI_abort () at ./stdlib/abort.c:79
#4  0x7f83ca0502d0 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7f83ca16a210 "*** %s ***: terminated\n") at 
../sysdeps/posix/libc_fatal.c:155
#5  0x7f83ca0e8e82 in __GI___fortify_fail (msg=msg@entry=0x7f83ca16a1f8 
"stack smashing detected") at ./debug/fortify_fail.c:26
#6  0x7f83ca0e8e60 in __stack_chk_fail () at ./debug/stack_chk_fail.c:24
#7  0x5627c3781422 in steg_adjust_errors 
(bitmap=bitmap@entry=0x7ffda38f0c30, flags=flags@entry=8) at 
./src/outguess.c:187
#8  0x5627c37814ba in steg_embedchunk (bitmap=bitmap@entry=0x7ffda38f0c30, 
iter=iter@entry=0x7ffda38f0670, data=0, bits=1, bits@entry=8, 
embed=embed@entry=8) at ./src/outguess.c:206
#9  0x5627c3781aa8 in steg_embed (bitmap=bitmap@entry=0x7ffda38f0c30, 
iter=iter@entry=0x7ffda38f0670, as=as@entry=0x7ffda38f0560, 
data=data@entry=0x5627c4d96b30 "BU\026\330E\315>ۆL\260\246\203\177", 
datalen=datalen@entry=12, seed=seed@entry=0, embed=8) at ./src/outguess.c:285
#10 0x5627c3781e44 in steg_find (bitmap=bitmap@entry=0x7ffda38f0c30, 
iter=iter@entry=0x7ffda38f0a30, as=as@entry=0x7ffda38f0810, siter=, siterstart=, data=data@entry=0x5627c4d96b30 
"BU\026\330E\315>ۆL\260\246\203\177", datalen=12, flags=8) at 
./src/outguess.c:444
#11 0x5627c3782a04 in do_embed (bitmap=bitmap@entry=0x7ffda38f0c30, 
filename=filename@entry=0x7ffda38f16ec "msg2.txt", key=key@entry=0x7ffda38f0fe0 
"key2", klen=, cfg=cfg@entry=0x7ffda38f0c24, 
result=result@entry=0x7ffda38f0c08) at ./src/outguess.c:719
#12 0x5627c3780d12 in main (argc=, argv=0x7ffda38f1488) at 
./src/outguess.c:1025

(gdb) up
#7  0x5627c3781422 in steg_adjust_errors 
(bitmap=bitmap@entry=0x7ffda38f0c30, flags=flags@entry=8) at 
./src/outguess.c:187
187 }

(gdb) list 138, 188
138 void
139 steg_adjust_errors(bitmap *bitmap, int flags)
140 {
141 int i, j, n, many, flag;
142 int priority[ERRORBITS], detect[ERRORBITS];
143
144 many = ERRORBITS - steg_errors;
145 for (j = 0; j < many && j < steg_err_cnt; j++) {
146 priority[j] = steg_err_buf[j];
147 detect[j] = bitmap->detect[priority[j]];
148 }
149
150 /* Very simple sort */
151 do {
152 for (flag = 0, i = 0; i < j - 1; i++)

Bug#1036302: free(): double free detected in tcache 2 during history search

2023-06-02 Thread Bernhard Übelacker


Hello,
below is the top of a valgrind run
with dbgsym package installed.

Kind regards,
Bernhard



benutzer@debian:~$ valgrind bash
==1114== Memcheck, a memory error detector
==1114== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==1114== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==1114== Command: bash
==1114==
benutzer@debian:~$ bind '"\C-p": history-search-backward'
benutzer@debian:~$ bind '"\C-n": history-search-forward'
benutzer@debian:~$

Control-P   # history-search-backward
Control-U   # unix-line-discard
Control-P   # history-search-backward
Control-U   # unix-line-discard
Control-N   # history-search-forward
Control-J   # accept-line

==1114== Invalid read of size 4
==1114==at 0x1E9D04: rl_do_undo (undo.c:186)
==1114==by 0x1EA0B4: rl_revert_line (undo.c:337)
==1114==by 0x1CD86C: readline_internal_teardown (readline.c:498)
==1114==by 0x1CEC7B: readline_internal (readline.c:734)
==1114==by 0x1CEC7B: readline (readline.c:387)
==1114==by 0x13AFE1: yy_readline_get (parse.y:1528)
==1114==by 0x13DAE0: yy_getc (parse.y:1462)
==1114==by 0x13DAE0: shell_getc (parse.y:2393)
==1114==by 0x13FF5A: read_token.constprop.0 (parse.y:3402)
==1114==by 0x1440BA: yylex (parse.y:2890)
==1114==by 0x1440BA: yyparse (y.tab.c:1854)
==1114==by 0x13A5B5: parse_command (eval.c:348)
==1114==by 0x13A743: read_command (eval.c:392)
==1114==by 0x13A8F5: reader_loop (eval.c:139)
==1114==by 0x1393D8: main (shell.c:833)
==1114==  Address 0x53ba808 is 24 bytes inside a block of size 32 free'd
==1114==at 0x484317B: free (vg_replace_malloc.c:872)
==1114==by 0x1E9ABA: _rl_free_undo_list (undo.c:111)
==1114==by 0x1F03DF: _rl_free_saved_history_line (misc.c:396)
==1114==by 0x1D4286: rl_history_search_forward (search.c:647)
==1114==by 0x1CDD96: _rl_dispatch_subseq (readline.c:916)
==1114==by 0x1CE371: _rl_dispatch (readline.c:860)
==1114==by 0x1CE371: readline_internal_char (readline.c:675)
==1114==by 0x1CEC64: readline_internal_charloop (readline.c:721)
==1114==by 0x1CEC64: readline_internal (readline.c:733)
==1114==by 0x1CEC64: readline (readline.c:387)
==1114==by 0x13AFE1: yy_readline_get (parse.y:1528)
==1114==by 0x13DAE0: yy_getc (parse.y:1462)
==1114==by 0x13DAE0: shell_getc (parse.y:2393)
==1114==by 0x13FF5A: read_token.constprop.0 (parse.y:3402)
==1114==by 0x1440BA: yylex (parse.y:2890)
==1114==by 0x1440BA: yyparse (y.tab.c:1854)
==1114==by 0x13A5B5: parse_command (eval.c:348)
==1114==  Block was alloc'd at
==1114==at 0x48407B4: malloc (vg_replace_malloc.c:381)
==1114==by 0x1A2C8D: xmalloc (xmalloc.c:114)
==1114==by 0x1E9A4E: alloc_undo_entry (undo.c:75)
==1114==by 0x1E9A4E: rl_add_undo (undo.c:92)
==1114==by 0x1EDB41: rl_delete_text (text.c:152)
==1114==by 0x1E8E4C: rl_kill_text (kill.c:177)
==1114==by 0x1E9466: rl_unix_line_discard (kill.c:412)
==1114==by 0x1CDD96: _rl_dispatch_subseq (readline.c:916)
==1114==by 0x1CE371: _rl_dispatch (readline.c:860)
==1114==by 0x1CE371: readline_internal_char (readline.c:675)
==1114==by 0x1CEC64: readline_internal_charloop (readline.c:721)
==1114==by 0x1CEC64: readline_internal (readline.c:733)
==1114==by 0x1CEC64: readline (readline.c:387)
==1114==by 0x13AFE1: yy_readline_get (parse.y:1528)
==1114==by 0x13DAE0: yy_getc (parse.y:1462)
==1114==by 0x13DAE0: shell_getc (parse.y:2393)
==1114==by 0x13FF5A: read_token.constprop.0 (parse.y:3402)
==1114==
==1114== Invalid read of size 4
...
==1114==
benutzer@debian:~$ exit
...
==1114== ERROR SUMMARY: 85 errors from 13 contexts (suppressed: 0 from 0)
benutzer@debian:~$

Bug#973894: rr: Improve reproducibility

2023-04-14 Thread Bernhard Übelacker


Hello,
upstream uses now macro-prefix-map, therefore e.g.
source files using __FILE__ should no longer
contain absolute paths.

So there are still the *.S files embedding their absolute paths.
In the long run maybe dpkg-buildflags might help there [1], [2].

But there is also mentioned to "just" feed c-flags into asm-flags.
(See patch below.)
This produces from different build directories a deb file with
the same md5sum.

Kind regards,
Bernhard


[1] https://salsa.debian.org/debian/debhelper/-/merge_requests/50
[2] 
https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/scripts/Dpkg/BuildFlags.pm?id=ce5af1eeb795c6fa8ce122b801930ccd7adc8516


--- rr-5.6.0.orig/CMakeLists.txt
+++ rr-5.6.0/CMakeLists.txt
@@ -50,6 +50,9 @@ configure_file(
   ${CMAKE_BINARY_DIR}/git_revision.h
 )
 
+# For reproducibility, e.g. -ffile-prefix-map

+set(CMAKE_ASM_FLAGS "${CMAKE_ASM_FLAGS} ${CMAKE_C_FLAGS}")
+
 set(FLAGS_COMMON "-D__USE_LARGEFILE64 -pthread")
 set(supports32bit true)
 set(x86ish false)

Bug#1032834: freecad: Segmentation fault while redoing

2023-03-27 Thread Bernhard Übelacker


Why isn't there a symbol package, just for some ports?


Hello Patrick,
there are symbol packages for nearly all Debian packages nowadays.
You can add the debug component [1] to be able to install the dbgsym packages,
or if you like you can just use the DEBUGINFOD_URLS environment variable [2].

Kind regards,
Bernhard

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

Bug#1032423: lldb-15: Bug "No module named lldb.embedded_interpreter" reappeared again in lldb-15

2023-03-25 Thread Bernhard Übelacker


Dear Maintainer,
it looks like the searched file ends up here in the current package:
  /usr/lib/llvm-15/lib/python3.11/dist-packages/lldb/embedded_interpreter.py

But by inspecting the strace output it should probably be in this directory:
  /usr/lib/llvm-15/lib/python3/dist-packages/lldb

For a test I moved the files that way manually,
and it makes the error message go away.

Kind regards,
Bernhard



newfstatat(AT_FDCWD, "/usr/lib/python3/dist-packages/lldb", 
{st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0
newfstatat(AT_FDCWD, "/usr/lib/python3/dist-packages/lldb", 
{st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0
newfstatat(AT_FDCWD, "/usr/lib/python3/dist-packages/lldb", 
{st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0
openat(AT_FDCWD, "/usr/lib/python3/dist-packages/lldb", 
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
newfstatat(3, "", {st_mode=S_IFDIR|0755, st_size=4096, ...}, AT_EMPTY_PATH) = 0
getdents64(3, 0x55ab0a60fdf0 /* 5 entries */, 32768) = 160
getdents64(3, 0x55ab0a60fdf0 /* 0 entries */, 32768) = 0
close(3)= 0
write(2, "Traceback (most recent call last"..., 35Traceback (most recent call 
last):
) = 35
write(2, "  File \"\", line 1, in ", line 1, in 

) = 39
write(2, "ModuleNotFoundError: No module n"..., 65ModuleNotFoundError: No 
module named 'lldb.embedded_interpreter'
) = 65


$ ls -lisah /usr/lib/python3/dist-packages/lldb
1045401 0 lrwxrwxrwx 1 root root 44  3. Jan 20:55 
/usr/lib/python3/dist-packages/lldb -> 
../../llvm-15/lib/python3/dist-packages/lldb


$ ls -lisah /usr/lib/llvm-15/lib/python3/dist-packages/lldb
insgesamt 8,0K
674672 4,0K drwxr-xr-x 2 root root 4,0K 25. Mär 11:02 .
674671 4,0K drwxr-xr-x 3 root root 4,0K 25. Mär 11:02 ..
6747020 lrwxrwxrwx 1 root root   51  3. Jan 20:55 libLLVM-15.0.6.so.1 -> 
../../../../../x86_64-linux-gnu/libLLVM-15.0.6.so.1
6747030 lrwxrwxrwx 1 root root   51  3. Jan 20:55 libLLVM-15.so.1 -> 
../../../../../x86_64-linux-gnu/libLLVM-15.0.6.so.1
6747010 lrwxrwxrwx 1 root root   47  3. Jan 20:55 _lldb.so -> 
../../../../../x86_64-linux-gnu/liblldb-15.so.1


$ dpkg -S embedded
python3-lldb-15: 
/usr/lib/llvm-15/lib/python3.11/dist-packages/lldb/embedded_interpreter.py

Bug#1032642: iproute2: ip tunnel change ip6gre to gre crashes with stack smash

2023-03-24 Thread Bernhard Übelacker


Dear Maintainer,
I tried to find out where exactly the stack smashing takes place.
And found the ioctl SIOCCHGTUNNEL did write more than the 52 bytes
allocated in variable old_p, by that overwriting the stack canary.

Kind regards,
Bernhard


(gdb)
0x5557589f  62  {
1: x/i $pc
=> 0x5557589f :  mov%fs:0x28,%rax
(gdb)
0x555758a8  62  {
1: x/i $pc
=> 0x555758a8 :  mov%rax,0x68(%rsp)
(gdb) print/x $rax
$1 = 0xbf9b77d893accd00
(gdb) print/x $rsp + 0x68
$2 = 0x7fffea28


(gdb)
0x77e575f5  120 in ../sysdeps/unix/syscall-template.S
1: x/i $pc
=> 0x77e575f5 :syscall
2: /x *(uint64_t*)0x7fffea28 = 0xbf9b77d893accd00
(gdb) bt
#0  0x77e575f5 in ioctl () at ../sysdeps/unix/syscall-template.S:120
#1  0x55578230 in tnl_get_ioctl (basedev=0x7fffee8f "gre1", 
p=) at tunnel.c:77
#2  0x55576243 in parse_args (argc=9, argv=0x7fffec50, cmd=35315, 
p=0x7fffea70) at iptunnel.c:181
#3  0x555762fb in do_add (cmd=35315, argc=, argv=) at iptunnel.c:260
#4  0x5556258b in do_cmd (argv0=0x7fffee81 "tunnel", argc=11, 
argv=0x7fffec40) at ip.c:133
#5  0x55561fc2 in main (argc=12, argv=0x7fffec38) at ip.c:344
(gdb) stepi
0x77e575f7  120 in ../sysdeps/unix/syscall-template.S
1: x/i $pc
=> 0x77e575f7 :cmp$0xf001,%rax
2: /x *(uint64_t*)0x7fffea28 = 0x200

(gdb) print _p
$7 = (struct ip_tunnel_parm *) 0x7fffe9f0
(gdb) print sizeof(old_p)
$8 = 52
(gdb) print/x 0x7fffe9f0 + 52
$9 = 0x7fffea24

(gdb) list iptunnel.c:181
178 if (cmd == SIOCCHGTUNNEL && count == 0) {
179 struct ip_tunnel_parm old_p = {};
180
181 if (tnl_get_ioctl(*argv, _p))
182 return -1;

Bug#1018061: pads: segfault at 3a ip

2023-03-24 Thread Bernhard Übelacker


Am 23.03.23 um 17:38 schrieb Tim McConnell:

Bernhard,
Just cause I said it was fixed this happens to show up in journalctl:
systemd-coredump[3614]: Process 1704 (pads) of user 0 dumped core.
   
   Module

libsystemd.so.0 from deb systemd-252.5-2.amd64
   Stack trace of thread 1704:
   #0 0x5600f24f6954 
print_arp_asset_screen (pads + 0x9954)
   #1 0x5600f24f66f0 
print_arp_asset (pads + 0x96f0)
   #2 0x7fdc7fdb54f6 n/a 
(libpcap.so.0.8 + 0x84f6)
   #3 0x7fdc7fdb58ec n/a 
(libpcap.so.0.8 + 0x88ec)
   #4 0x7fdc7fdbcd1d 
pcap_loop (libpcap.so.0.8 + 0xfd1d)
   #5 0x5600f24efe5b 
main_pads (pads + 0x2e5b)
   #6 0x5600f24ef47b main 
(pads + 0x247b)
   #7 0x7fdc7fbec18a 
__libc_start_call_main (libc.so.6 + 0x2718a)
   #8 0x7fdc7fbec245 
__libc_start_main_impl (libc.so.6 + 0x27245)
   #9 0x5600f24ef4b1 _start 
(pads + 0x24b1)
   ELF object binary
architecture: AMD x86-64
Mar 04 14:31:02 DebianTim systemd[1]:
systemd-coredump@0-3613-0.service: Deactivated successfully.

Well I thought it was fixed :-(



Hello Time,
are you sure that your rebuilt package is still in place?
The offsets in your new backtrace are exactly the same as
in the email from 8 Feb 2023.

We have not changed the version of the rebuilt package.
Additionally built with "-b".
Then with a "apt dist-upgrade" always
the Debian version gets reinstalled.

Sorry for not mentioning that extra care has to be taken
to hold the rebuilt package version in place.

Kind regards,
Bernhard

Bug#1032426: xsane: Help>About XSane crashes without opening a window

2023-03-23 Thread Bernhard Übelacker




On Mon, 06 Mar 2023 14:40:12 + Reuben Thomas  wrote:


If I select Help→About XSane, the application pauses for a couple of seconds
then crashes. (The changes in Ubuntu’s version are just to depend on a
different JPEG library, so I think it’s reasonable to file a bug here.)



Dear Maintainer,
I could reproduce it also with a current Bookworm/testing system.

It looks like between 0.999-6 (buster/oldstable)
and 0.999-12 (bullseye/stable) the file xsane-logo.xpm got moved
from path /usr/share/sane/xsane to /usr/share/doc/xsane-common.

Unfortunately the about dialog still constructs the old path,
does not find there the pixmap and handles this case not carefully.

A workaround is to create a symlink and the dialog shows up without crash.

Kind regards,
Bernhard



Core was generated by `xsane'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7fd785b1b665 in IA__gtk_image_set_from_pixmap (image=0x557b947ccdb0, 
pixmap=0x0, mask=0x557b9456e230) at ../../../../gtk/gtkimage.c:858
858   g_return_if_fail (mask == NULL ||

(gdb) bt
#0  0x7fd785b1b665 in IA__gtk_image_set_from_pixmap (image=0x557b947ccdb0 
[GtkImage], pixmap=0x0, mask=0x557b9456e230) at ../../../../gtk/gtkimage.c:858
#1  0x7fd785b1b83d in IA__gtk_image_new_from_pixmap 
(pixmap=pixmap@entry=0x0, mask=0x557b9456e230) at ../../../../gtk/gtkimage.c:606
#2  0x557b92ea2d1b in xsane_about_dialog (data=, 
widget=) at ./src/xsane.c:3523
#6  0x7fd785f31dbf in  
(instance=instance@entry=0x557b946d60d0, signal_id=, 
detail=detail@entry=0) at ../../../gobject/gsignal.c:3606
#3  0x7fd785f183b0 in g_closure_invoke (closure=0x557b946d88e0, 
return_value=return_value@entry=0x0, n_param_values=1, 
param_values=param_values@entry=0x7ffc72ce6750, 
invocation_hint=invocation_hint@entry=0x7ffc72ce66d0) at 
../../../gobject/gclosure.c:832
#4  0x7fd785f2b076 in signal_emit_unlocked_R 
(node=node@entry=0x557b946c4540, detail=detail@entry=0, 
instance=instance@entry=0x557b946d60d0, 
emission_return=emission_return@entry=0x0, 
instance_and_params=instance_and_params@entry=0x7ffc72ce6750) at 
../../../gobject/gsignal.c:3796
#5  0x7fd785f31bf5 in g_signal_emit_valist (instance=, 
signal_id=, detail=, 
var_args=var_args@entry=0x7ffc72ce68d0) at ../../../gobject/gsignal.c:3549
#7  0x7fd785c57d94 in IA__gtk_widget_activate 
(widget=widget@entry=0x557b946d60d0 [GtkMenuItem]) at 
../../../../gtk/gtkwidget.c:5041
#8  0x7fd785b4baf5 in IA__gtk_menu_shell_activate_item (menu_shell=0x557b94544d80 
[GtkMenu], menu_item=0x557b946d60d0 [GtkMenuItem], force_deactivate=) at ../../../../gtk/gtkmenushell.c:1278
#9  0x7fd785b4be09 in gtk_menu_shell_button_release (widget=0x557b94544d80 
[GtkMenu], event=0x557b9489ca70) at ../../../../gtk/gtkmenushell.c:703
#14 0x7fd785f31dbf in  
(instance=instance@entry=0x557b94544d80, signal_id=, 
detail=detail@entry=0) at ../../../gobject/gsignal.c:3606
#10 0x7fd785b391ab in _gtk_marshal_BOOLEAN__BOXED (closure=0x557b944dfd30, 
return_value=0x7ffc72ce6be0, n_param_values=, param_values=0x7ffc72ce6c40, 
invocation_hint=, marshal_data=) at 
../../../../gtk/gtkmarshalers.c:84
#11 0x7fd785f183b0 in g_closure_invoke 
(closure=closure@entry=0x557b944dfd30, 
return_value=return_value@entry=0x7ffc72ce6be0, n_param_values=2, 
param_values=param_values@entry=0x7ffc72ce6c40, 
invocation_hint=invocation_hint@entry=0x7ffc72ce6bc0) at 
../../../gobject/gclosure.c:832
#12 0x7fd785f2b1a5 in signal_emit_unlocked_R (node=, 
detail=detail@entry=0, instance=instance@entry=0x557b94544d80, 
emission_return=emission_return@entry=0x7ffc72ce6d30, 
instance_and_params=instance_and_params@entry=0x7ffc72ce6c40) at 
../../../gobject/gsignal.c:3835
#13 0x7fd785f3142d in g_signal_emit_valist (instance=, 
signal_id=, detail=, 
var_args=var_args@entry=0x7ffc72ce6de0) at ../../../gobject/gsignal.c:3559
#15 0x7fd785c58fe4 in gtk_widget_event_internal 
(widget=widget@entry=0x557b94544d80 [GtkMenu], 
event=event@entry=0x557b9489ca70) at ../../../../gtk/gtkwidget.c:5010
#16 0x7fd785c592d5 in IA__gtk_widget_event 
(widget=widget@entry=0x557b94544d80 [GtkMenu], 
event=event@entry=0x557b9489ca70) at ../../../../gtk/gtkwidget.c:4807
#17 0x7fd785b377d4 in IA__gtk_propagate_event (widget=0x557b94544d80 
[GtkMenu], event=0x557b9489ca70) at ../../../../gtk/gtkmain.c:2503
#18 0x7fd785b37c4b in IA__gtk_main_do_event (event=0x557b9489ca70) at 
../../../../gtk/gtkmain.c:1698
#19 IA__gtk_main_do_event (event=) at 
../../../../gtk/gtkmain.c:1503
#20 0x7fd785fc0afc in gdk_event_dispatch (source=, 
callback=, user_data=) at 
../../../../../gdk/x11/gdkevents-x11.c:2425
#21 0x7fd7860f97a9 in g_main_dispatch (context=0x557b94477800) at 
../../../glib/gmain.c:3454
#22 g_main_context_dispatch (context=context@entry=0x557b94477800) at 
../../../glib/gmain.c:4172
#23 0x7fd7860f9a38 in g_main_context_iterate (context=0x557b94477800, 
block=block@entry=1,

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

2023-03-23 Thread Bernhard Übelacker


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

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

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



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

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

Kind regards,
Bernhard

Bug#1018061: pads: segfault at 3a ip

2023-03-22 Thread Bernhard Übelacker


control: tags -1 +patch


Hello Tim,
nice to hear it helps. Therefore adding the patch tag.

Kind regards,
Bernhard



Am 21.03.23 um 17:53 schrieb Tim McConnell:

Hi Bernhard,
I believe the patch has fixed the issue. I haven't seen any messages
about psad since installing the patch.
Thanks so much for the fix & patience with me.

Bug#1031868: kde-cli-tools: kstart5 : does not return after launching command since upgrade to KDE Fralework 5.103

2023-03-18 Thread Bernhard Übelacker


Dear Maintainer,
I tried to reproduce this issue and found a difference between
a minimal Bookworm VM with just running jwm window manager and my
regular Plasma desktop.

In the minimal VM a `kstart5 kcalc` returns immediately,
while at my regular Plasma desktop it blocks until the started
application is closed.

I found in the non-blocking case `KStart::windowAdded` gets executed
and therefore `QCoreApplication::exit` is called.

This seems to be caused by having useRule to be true
in the `KStart::KStart` constructor,
and therefore the connect call is not reached.

Kind regards,
Bernhard


(rr) bt
#0  0x7ffb802b1860 in QCoreApplication::exit 
(returnCode=returnCode@entry=0) at kernel/qcoreapplication.cpp:1430
#1  0x55a5e93fd065 in KStart::windowAdded (this=0x7fff2864b760, w=6291470) 
at ./kstart/kstart.cpp:201
#2  0x7ffb802e8f4f in QtPrivate::QSlotObjectBase::call (a=0x7fff2864adc0, 
r=0x7fff2864b760, this=0x55a5e9b58230) at 
../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398
#3  doActivate (sender=0x7ffb8174a440 <(anonymous 
namespace)::Q_QGS_g_kwmInstanceContainer::innerFunction()::holder>, signal_index=4, 
argv=0x7fff2864adc0) at kernel/qobject.cpp:3923
#4  0x7ffb802e21ef in QMetaObject::activate (sender=sender@entry=0x7ffb8174a440 
<(anonymous namespace)::Q_QGS_g_kwmInstanceContainer::innerFunction()::holder>, 
m=m@entry=0x7ffb81748700 , 
local_signal_index=local_signal_index@entry=1, argv=argv@entry=0x7fff2864adc0) at 
kernel/qobject.cpp:3983
#5  0x7ffb8170e522 in KWindowSystem::windowAdded (this=this@entry=0x7ffb8174a440 
<(anonymous namespace)::Q_QGS_g_kwmInstanceContainer::innerFunction()::holder>, 
_t1=, _t1@entry=6291470) at 
./obj-x86_64-linux-gnu/src/KF5WindowSystem_autogen/EWIEGA46WW/moc_kwindowsystem.cpp:409
#6  0x7ffb7b07363d in NETEventFilter::addClient (this=0x55a5e9b6baf0, 
w=6291470) at ./src/platforms/xcb/kwindowsystem.cpp:412
#7  0x7ffb8172ea51 in NETRootInfo::update (this=0x55a5e9b6baf0, 
properties=..., properties2=...) at ./src/platforms/xcb/netwm.cpp:2033
#8  0x7ffb7b071af7 in NETEventFilter::activate (this=) at 
./src/platforms/xcb/kwindowsystem.cpp:183
#9  KWindowSystemPrivateX11::init (this=this@entry=0x7ffb74006730, 
what=what@entry=KWindowSystemPrivateX11::INFO_BASIC) at 
./src/platforms/xcb/kwindowsystem.cpp:575
#10 0x7ffb7b071d4c in KWindowSystemPrivateX11::connectNotify 
(this=0x7ffb74006730, signal=...) at ./src/platforms/xcb/kwindowsystem.cpp:536
#11 0x7ffb8171fc35 in KWindowSystem::connectNotify (this=0x7ffb8174a440 
<(anonymous namespace)::Q_QGS_g_kwmInstanceContainer::innerFunction()::holder>, 
signal=...) at ./src/kwindowsystem.cpp:380
#12 0x7ffb802dea6a in QObjectPrivate::connectImpl (sender=sender@entry=0x7ffb8174a440 
<(anonymous namespace)::Q_QGS_g_kwmInstanceContainer::innerFunction()::holder>, signal_index=4, 
receiver=receiver@entry=0x7fff2864b760, slot=slot@entry=0x7fff2864b670, 
slotObj=slotObj@entry=0x55a5e9b58230, type=, types=, 
senderMetaObject=) at kernel/qobject.cpp:5108
#13 0x7ffb802ded45 in QObject::connectImpl (sender=0x7ffb8174a440 <(anonymous 
namespace)::Q_QGS_g_kwmInstanceContainer::innerFunction()::holder>, 
signal=signal@entry=0x7fff2864b660, receiver=receiver@entry=0x7fff2864b760, 
slot=slot@entry=0x7fff2864b670, slotObj=0x55a5e9b58230, type=Qt::AutoConnection, types=0x0, 
senderMetaObject=) at kernel/qobject.cpp:5038
#14 0x55a5e93fc7bb in QObject::connect (type=Qt::AutoConnection, slot=(void (KStart::*)(KStart * const, 
unsigned long long)) 0x55a5e93fcfc0 , 
receiver=0x7fff2864b760, signal=(void (KWindowSystem::*)(KWindowSystem * const, unsigned long long)) 
0x7ffb8170e4e0 , sender=) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:268
#15 KStart::KStart (this=0x7fff2864b760) at ./kstart/kstart.cpp:78
#16 0x55a5e93fac84 in main (argc=, argv=) at 
./kstart/kstart.cpp:424


kde-cli-tools-5.27.2/kstart/kstart.cpp
62  KStart::KStart()
63  : QObject()
64  {
65  bool useRule = false;
66
67  #ifdef HAVE_X11
68  if (QX11Info::isPlatformX11()) {
69  NETRootInfo i(QX11Info::connection(), NET::Supported);
70  useRule = i.isSupported(NET::WM2KDETemporaryRules);
71  }
72  #endif
73
74  if (useRule) {
75  sendRule();
76  } else {
77  // connect to window add to get the NEW windows
78  connect(KWindowSystem::self(), ::windowAdded, this, 
::windowAdded);
79  }

Bug#1032039: xorg: xserver fails to recover session after locking (xfce4 / lightdm)

2023-03-16 Thread Bernhard Übelacker


Dear Maintainer,
I tried to add source line information to the Xorg backtrace:

fdd in inl at /usr/include/x86_64-linux-gnu/sys/io.h:83  
(pci_device_linux_sysfs_read32+93)
f1a in x86emuOp_in_word_AX_DX at 
../../../../../../hw/xfree86/int10/../x86emu/ops.c:10364
024 in X86EMU_exec at ../../../../../../hw/xfree86/int10/../x86emu/decode.c:135
995 in xf86ExecX86int10 at ../../../../../../hw/xfree86/int10/xf86x86emu.c:39
486 in VBESetVBEMode at ../../../../../../hw/xfree86/int10/vbe.c:473
200 in VESASetMode at ../../src/vesa.c:1247
405 in VESAEnterVT at ../../src/vesa.c:1166
127 in CMapEnterVT at ../../../../../../hw/xfree86/common/xf86cmap.c:475
e31 in xf86VTEnter at ../../../../../../hw/xfree86/common/xf86Events.c:456
243 in WakeupHandler at ../../../../dix/dixutils.c:427
6b8 in WaitForSomething at ../../../../os/WaitFor.c:210
473 in Dispatch at ../../../../dix/dispatch.c:492
6cc in dix_main at ../../../../dix/main.c:272



[ 6.584] Current Operating System: Linux keats 4.19.0-5-amd64 #1 SMP Debian 
4.19.37-6 (2019-07-18) x86_64


The used kernel version is not from current testing.
Could that be the reason why the vesa driver
gets selected at all in the first place?


Kind regards,
Bernhard

Bug#1018061: pads: segfault at 3a ip

2023-03-15 Thread Bernhard Übelacker


Am 26.02.23 um 16:47 schrieb Tim McConnell:


Hi Bernhard,
The delay is fine, I'm sure it takes a minute to figure it out ;-) and
no I didn't have anything other than defaults for GDB set. I'm not a
programmer so I don't know all the tricks to GDB or when is best   to
use them. With that said, how would I go about installing /testing the
patch you provide? I'm happy to test it out for you, I just need the
knowledge of how to.
Thanks!




Hello Tim,
if you are fine with installing a bunch of build dependencies
you could use following steps to rebuild the package with the patch.

As root:
# apt build-dep pads

As user:
$ mkdir -p source/pads

Put attached patch to the new directory and continue as user:
$ cd   source/pads
$ apt source pads
$ cd pads-1.2/
$ patch -p1 < ../pads_print_arp_asset_initialize.patch
$ dpkg-buildpackage -b

As root (with the directory adjusted to your user):
# dpkg -i 
/home/benutzer/source/pads/{pads_1.2-14_amd64.deb,pads-dbgsym_1.2-14_amd64.deb}


And then see if it still works as expected and see
if the crash happens again.

Kind regards,
Bernhard
--- a/src/output/output.c2023-02-26 15:19:32.0 +0100
+++ b/src/output/output.c2023-02-26 15:54:54.007679051 +0100
@@ -182,7 +182,7 @@ int print_arp_asset (struct in_addr ip_a
 
 /* Find Asset */
 ArpAsset *list;
-ArpAsset *rec;
+ArpAsset *rec = NULL;
 
  list = (ArpAsset *)get_arp_pointer();
  while (list != NULL) {

Bug#1030842: fontforge: segfault during Open() of femkeklaver (inside pbuilder/lxc)

2023-03-09 Thread Bernhard Übelacker


Dear Maintainer,
with the help of the core saved in the artifacts I found that
the crash happens when fontforge tries to print some logging.

It just started to crash if I run the command with LANG=C.

It seems to be caused by the call to function iconv returns
with errno==EILSEQ (Illegal byte sequence).
This could possibly be this "©" in the string to be processed.

Kind regards,
Bernhard



$ LANG=C rr record fontforge -script 
/home/benutzer/source/fonts-femkeklaver/git/fonts-femkeklaver/debian/clear-fstype.pe
 /home/benutzer/source/fonts-femkeklaver/git/fonts-femkeklaver/femkeklaver.ttf
$ rr replay -o-q
...
Breakpoint 3, iconv (cd=cd@entry=0x55b4437f72d0, 
inbuf=inbuf@entry=0x7fff48abee88, inbytesleft=inbytesleft@entry=0x7fff48abee80, 
outbuf=outbuf@entry=0x7fff48abeea0, 
outbytesleft=outbytesleft@entry=0x7fff48abee98) at ./iconv/iconv.c:32
32  {
(rr) finish
Run till exit from #0  iconv (cd=cd@entry=0x55b4437f72d0, 
inbuf=inbuf@entry=0x7fff48abee88, inbytesleft=inbytesleft@entry=0x7fff48abee80, 
outbuf=outbuf@entry=0x7fff48abeea0, 
outbytesleft=outbytesleft@entry=0x7fff48abee98) at ./iconv/iconv.c:32
0x7fd0fc8a0b69 in do_iconv (cd=0x55b4437f72d0, inbuf=, 
inbuf@entry=0x7fff48abeef0, incount=, inunitsize=inunitsize@entry=1, 
outunitsize=outunitsize@entry=1) at ./Unicode/ucharmap.c:101
101 if (iconv(cd, (iconv_arg2_t), , , ) 
== (size_t)-1) {
Value returned is $19 = 18446744073709551615
(rr) next
102 if (errno == E2BIG) {
(rr) print errno
$20 = 84
(rr) print inbuf
$21 = 
(rr) up
#1  0x7fd0fc8a0fd5 in utf82def_copy (ufrom=ufrom@entry=0x7fff48abeef0 "Warning: 
Mac and Windows entries in the 'name' table differ for the\n Copyright string in the 
language English (US)\n Mac String: Typeface © (your company). 2008. All Rights 
Reserved\nWindows String: Typeface © (femkeklaver.nl). 2008. All Rights Reserved\n") 
at ./Unicode/ucharmap.c:159
159 return do_iconv(from_utf8, ufrom, strlen(ufrom), sizeof(ufrom[0]), 
sizeof(char));
(rr) print ufrom
$22 = 0x7fff48abeef0 "Warning: Mac and Windows entries in the 'name' table differ 
for the\n Copyright string in the language English (US)\n Mac String: Typeface © (your 
company). 2008. All Rights Reserved\nWindows String: Typeface © (femkeklaver.nl). 2008. 
All Rights Reserved\n"
(rr) bt
#0  do_iconv (cd=0x55b4437f72d0, inbuf=, inbuf@entry=0x7fff48abeef0, 
incount=, inunitsize=inunitsize@entry=1, 
outunitsize=outunitsize@entry=1) at ./Unicode/ucharmap.c:102
#1  0x7fd0fc8a0fd5 in utf82def_copy (ufrom=ufrom@entry=0x7fff48abeef0 "Warning: 
Mac and Windows entries in the 'name' table differ for the\n Copyright string in the 
language English (US)\n Mac String: Typeface © (your company). 2008. All Rights 
Reserved\nWindows String: Typeface © (femkeklaver.nl). 2008. All Rights Reserved\n") 
at ./Unicode/ucharmap.c:159
#2  0x7fd0fc958a84 in NOUI__LogError (format=, 
ap=ap@entry=0x7fff48abf0b0) at ./fontforge/nouiutil.c:55
#3  0x7fd0fc958c49 in NOUI_LogError (format=) at 
./fontforge/nouiutil.c:66
#4  0x7fd0fc98555a in TTFAddLangStr (language=, spec=, 
plat=, stroff=, strlength=, id=0, 
info=0x7fff48abf220, ttf=0x55b4437ff990) at ./fontforge/parsettf.c:1609
#5  readttfcopyrights (info=0x7fff48abf220, ttf=0x55b4437ff990) at 
./fontforge/parsettf.c:1748
#6  readttfpreglyph (info=0x7fff48abf220, ttf=0x55b4437ff990) at 
./fontforge/parsettf.c:1814
#7  readttf (filename=0x55b4437ff930 
"/home/benutzer/source/fonts-femkeklaver/git/fonts-femkeklaver/femkeklaver.ttf",
 info=0x7fff48abf220, ttf=0x55b4437ff990) at ./fontforge/parsettf.c:5554
#8  _SFReadTTF (ttf=ttf@entry=0x55b4437ff990, flags=flags@entry=0, 
openflags=openflags@entry=0, filename=filename@entry=0x55b4437ff930 
"/home/benutzer/source/fonts-femkeklaver/git/fonts-femkeklaver/femkeklaver.ttf",
 chosenname=chosenname@entry=0x0, fd=fd@entry=0x0) at ./fontforge/parsettf.c:6342
#9  0x7fd0fca66a7a in _ReadSplineFont (file=, file@entry=0x0, 
filename=filename@entry=0x55b4437ff870 
"/home/benutzer/source/fonts-femkeklaver/git/fonts-femkeklaver/femkeklaver.ttf", 
openflags=openflags@entry=0) at ./fontforge/splinefont.c:1130
#10 0x7fd0fca6794c in ReadSplineFont (filename=filename@entry=0x55b4437ff870 
"/home/benutzer/source/fonts-femkeklaver/git/fonts-femkeklaver/femkeklaver.ttf",
 openflags=openflags@entry=0) at ./fontforge/splinefont.c:1310
#11 0x7fd0fca67a51 in LoadSplineFont (filename=filename@entry=0x55b4437ff810 
"/home/benutzer/source/fonts-femkeklaver/git/fonts-femkeklaver/femkeklaver.ttf",
 openflags=openflags@entry=0) at ./fontforge/splinefont.c:1361
#12 0x7fd0fca0701e in bOpen (c=0x7fff48abfc10) at 
./fontforge/scripting.c:1802
#13 0x7fd0fca0a273 in docall (c=c@entry=0x7fff48ac03e0, 
name=name@entry=0x7fff48abfe60 "Open", val=val@entry=0x7fff48ac0280) at 
./fontforge/scripting.c:9241
#14 0x7fd0fca0a6ee in handlename (c=c@entry=0x7fff48ac03e0, 
val=val@entry=0x7fff48ac0280) at ./fontforge/scripting.c:9354
#15 0x7fd0fca0ba77 in term

Bug#1030854: kded5: It keeps on crashing everytime I boot into the system

2023-03-07 Thread Bernhard Übelacker


Stack trace of thread 67345:
#0  0x7f8daa6a9ccc n/a (libc.so.6 + 0x8accc)
#1  0x7f8daa65aef2 raise (libc.so.6 + 0x3bef2)
#2  0x7f8dabf4c83d _ZN6KCrash19defaultCrashHandlerEi 
(libKF5Crash.so.5 + 0x583d)
#3  0x7f8daa65af90 n/a (libc.so.6 + 0x3bf90)
#4  0x7f8d5553b740 _ZNK10PackageKit11Transaction3tidEv 
(libpackagekitqt5.so.1 + 0x1a740)
#5  0x7f8d555f16f3 n/a (kded_apperd.so + 0xf6f3)
#6  0x7f8d555f1df6 n/a (kded_apperd.so + 0xfdf6)
#7  0x7f8daaae8f4f n/a (libQt5Core.so.5 + 0x2e8f4f)
#8  0x7f8d5552f095 
_ZN10PackageKit6Daemon22transactionListChangedERK11QStringList 
(libpackagekitqt5.so.1 + 0xe095)
#9  0x7f8daaae8f7c n/a (libQt5Core.so.5 + 0x2e8f7c)
#10 0x7f8d55547b38 n/a (libpackagekitqt5.so.1 + 0x26b38)
#11 0x7f8d55548d73 n/a (libpackagekitqt5.so.1 + 0x27d73)
#12 0x7f8dab6c861b n/a (libQt5DBus.so.5 + 0x2361b)
#13 0x7f8daaadd6f0 _ZN7QObject5eventEP6QEvent 
(libQt5Core.so.5 + 0x2dd6f0)
#14 0x7f8dab962fae 
_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent (libQt5Widgets.so.5 + 
0x162fae)



Hello,
this seems similar to the backtrace in bug #1026062.

Kind regards,
Bernhard


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

Bug#1031655: Lutris: "The wine build you have selected does not support Esync/Fsync"

2023-03-06 Thread Bernhard Übelacker


On Sun, 19 Feb 2023 21:38:22 +0100 =?utf-8?q?Linus_L=C3=BCssing?= 
 wrote:

... They sound like build options to me ...



Hello Linus,
I tried to have a look how Lutris detects fsync support.

It looks like Lutris extracts the version
from the path the wine executable was found.
(see the is_version_fsync link below)

Unfortunately there is not any version information
from "/usr/bin/wine".

Therefore this does not yet sound like an wine issue.

Kind regards,
Bernhard

https://github.com/lutris/lutris/blob/v0.5.12/lutris/runners/wine.py#L310
https://github.com/lutris/lutris/blob/v0.5.12/lutris/runners/wine.py#L145  
#  fsync_support_callback
https://github.com/lutris/lutris/blob/v0.5.12/lutris/util/wine/wine.py#L308
#  is_version_fsync

Bug#1030919: xserver-xorg-video-intel: The server crashes when the mouse pointer hovers over a gtk button

2023-02-26 Thread Bernhard Übelacker


Dear Maintainer,
I tried to add line information using the dbgsym packages.
That led me to libc trying to print the
message "double free or corruption (out)".

Kind regards,
Bernhard


https://sources.debian.org/src/glibc/2.36-8/malloc/malloc.c/
4584malloc_printerr ("double free or corruption (out)");


0:  Xorg (OsLookupColor+0x139)  [0x55e578a89cc9] in 
OsSigHandler at ../../../../os/osinit.c:138
1:  libc.so.6(__sigaction+0x40) [0x7fee08244f90]
2:  libc.so.6(pthread_key_delete+0x14c) [0x7fee08293ccc] in 
__pthread_kill_implementation at ./nptl/pthread_kill.c:43
3:  libc.so.6(gsignal+0x12) [0x7fee08244ef2] in __GI_raise 
at ../sysdeps/posix/raise.c:26
4:  libc.so.6(abort+0xd3)   [0x7fee0822f472] in __GI_abort 
at ./stdlib/abort.c:79
5:  libc.so.6(__fsetlocking+0x290)  [0x7fee082882d0] in 
__libc_message at ../sysdeps/posix/libc_fatal.c:155
6:  libc.so.6(timer_settime+0x37a)  [0x7fee0829d64a] in 
malloc_printerr at ./malloc/malloc.c:5660
7:  libc.so.6(__default_morecore+0x8a0) [0x7fee0829f6b0] in _int_free 
at ./malloc/malloc.c:4584
8:  libc.so.6(__libc_free+0x6f) [0x7fee082a1d2f] in 
__GI___libc_free at ./malloc/malloc.c:3385
9:  intel_drv.so (?+0x0)[0x7fee075d8a0f] in 
I810SetPortAttribute / RegionUninit at /usr/include/xorg/regionstr.h:166
10: Xorg (DamageDestroy+0x23e)  [0x55e5789f627e] in 
damageDestroyPixmap at ../../../../../miext/damage/damage.c:1504
11: Xorg (ShmRegisterFbFuncs+0x80e) [0x55e5789b084e] in 
XvDestroyPixmap at ../../../../Xext/xvmain.c:369
12: Xorg (SyncVerifyFence+0x3354)   [0x55e5789af214] in 
ShmDestroyPixmap at ../../../../Xext/shm.c:260
13: Xorg (RegisterExtensionNames+0x1dd) [0x55e57893d22d] in 
doFreeResource at ../../../../dix/resource.c:885
14: Xorg (FreeResource+0xe9)[0x55e57893de19] in 
FreeResource at ../../../../dix/resource.c:915
15: Xorg (dixDestroyPixmap+0x27e)   [0x55e57891196e] in 
ProcFreePixmap at ../../../../dix/dispatch.c:1538
16: Xorg (SendErrorToClient+0x3d4)  [0x55e578916734] in Dispatch at 
../../../../dix/dispatch.c:550
17: Xorg (InitFonts+0x3bc)  [0x55e57891a6cc] in dix_main at 
../../../../dix/main.c:272

Bug#1018061: pads: segfault at 3a ip

2023-02-26 Thread Bernhard Übelacker


Am 08.02.23 um 19:31 schrieb Tim McConnell:

Opppss I thought I had, here it is.
bt full



Hello Tim,
sorry for the delay. For some reason the debug information
for libpcap.so.0.8 was missing in your backtrace (was the
DEBUGINFOD_URLS variable set in that console?).

But I guess I could fill in the gaps [2].

And I think in function print_arp_asset the variable rec
might get used uninitialized.
This is also warned about in the build log [3].

Therefore the crash could possibly avoided with the patch below [1].

Kind regards,
Bernhard



[1]
--- src/output/output.c.orig2023-02-26 15:19:32.0 +0100
+++ src/output/output.c 2023-02-26 15:54:54.007679051 +0100
@@ -182,7 +182,7 @@ int print_arp_asset (struct in_addr ip_a
 
 /* Find Asset */

 ArpAsset *list;
-ArpAsset *rec;
+ArpAsset *rec = NULL;
 
 list = (ArpAsset *)get_arp_pointer();

 while (list != NULL) {



[2]
(gdb)
#0  0x5641638af954 in print_arp_asset_screen (rec=0x2a) at 
./src/output/output-screen.c:115
#1  0x5641638af6f0 in print_arp_asset (ip_addr=..., mac_addr=0x7fa6db692384 
"") at ./src/output/output.c:210
head = 0x5641654a33f0
list = 
rec = 0x2a
#2  0x7fa6dbe004f6 in pcap_handle_packet_mmap () at ./pcap-linux.c:4072 
from /lib/x86_64-linux-gnu/libpcap.so.0.8
#3  0x7fa6dbe008ec in pcap_read_linux_mmap_v3 () at ./pcap-linux.c:4248 
from /lib/x86_64-linux-gnu/libpcap.so.0.8
#4  0x7fa6dbe07d1d in pcap_loop () at ./pcap.c:2923 from 
/lib/x86_64-linux-gnu/libpcap.so.0.8
#5  0x5641638a8e5b in main_pads () at ./src/pads.c:278
#6  0x5641638a847b in main (argc=, argv=) at 
./src/pads.c:491

(gdb) list output.c:210
179 int print_arp_asset (struct in_addr ip_addr, char mac_addr[MAC_LEN])
180 {
181 OutputPluginList *head;
182
183 /* Find Asset */
184 ArpAsset *list;
185 ArpAsset *rec;
186
187 list = (ArpAsset *)get_arp_pointer();
188 while (list != NULL) {
189 if (ip_addr.s_addr == list->ip_addr.s_addr
190 && (strcmp(mac_addr, list->mac_addr) == 0)) {
191
192 /* Found! */
193 rec = list;
194 break;
195 } else {
196 list = list->next;
197 }
198 }
199
200 /* Make sure that a record was found. */
201 if (rec == NULL)
202 return 1;
203
204 /* Cycle through output plugins and print to those that are active. 
*/
205 head = output_plugin_list;
206 while (head != NULL) {
207 /* Only print to active plugins. */
208 if (head->active == 1) {
209 if (head->plugin->print_arp)
210 (*head->plugin->print_arp)(rec);
211 }
212
213 head = head->next;
214 }


[3]
https://buildd.debian.org/status/fetch.php?pkg=pads=amd64=1.2-14=1665671920=0
output.c: In function ‘print_arp_asset’:
output.c:210:18: warning: ‘rec’ may be used uninitialized 
[-Wmaybe-uninitialized]
  210 | (*head->plugin->print_arp)(rec);
  | ~^~
output.c:185:15: note: ‘rec’ was declared here
  185 | ArpAsset *rec;
  |   ^~~

Bug#1029536: wine64-stable ENOENT

2023-02-18 Thread Bernhard Übelacker


On Sun, 12 Feb 2023 18:53:01 +0900 Junichi Uekawa  wrote:

/usr/bin/wine64-stable fails because of missing files.
Should /usr/bin/wine64-stable be there at all?


I guess having just package wine64 without package wine
installed should also work?
Then /usr/bin/wine64-stable would be needed.

Otherwise the user might really be expected to start it
via "/usr/lib/wine/wine64 wineboot", like proposed before.

At least the wrapper /usr/bin/wine from package wine
looks like it would not need "/usr/bin/wine64-stable".



Am 13.02.23 um 21:52 schrieb Jens Reyer:

On 12.02.23 10:53, Junichi Uekawa wrote:

/usr/bin/wine64-stable fails because of missing files.
Should /usr/bin/wine64-stable be there at all?


I don't know if we really need /usr/bin/wine64, or could just go with 
/usr/bin/wine and the rest in /usr/lib/wine.  But if we want 
/usr/bin/wine64 then we also need /usr/bin/wine64-stable (for the 
alternatives system).


Currently this is a link to /usr/lib/wine/wine64.  Current maintainers 
may replace it with a wrapper script or provide the link suggested 
previously. (Or figure out why the -stable suffix in the link is now 
expected by the binary, while it wasn't in the past.)


Before following commit [1] wine iterated through PATH environment
to find finally /usr/bin/wine64-stable, which is a link to ../lib/wine/wine64.

Afterwards it looks like it is "just" searching for /usr/lib/wine/wine64-stable.



Kind regards,
Bernhard

[1] 
https://gitlab.winehq.org/wine/wine/-/commit/ae8562ed2277a5c051e131dc317e94aa3d5413c8
ntdll: Always use the name of the current loader to exec a new process.

[7.21] 
https://gitlab.winehq.org/wine/wine/-/blob/053ee2d23d825f800baa16e455a218834aa2dec0/dlls/ntdll/unix/loader.c#L685

[7.22] 
https://gitlab.winehq.org/wine/wine/-/blob/20d86f34a066657048610803e7143232efa6c0d3/dlls/ntdll/unix/loader.c#L695

Bug#1031411: approx: starts to dislike spaces-only lines in configuration

2023-02-16 Thread Bernhard Übelacker


Package: approx
Version: 5.11-1
Severity: normal
X-Debbugs-Cc: bernha...@mailbox.org

Dear Maintainer,
approx got sensitive to lines in /etc/approx/approx.conf
which are empty except of spaces.
This did not harm previous approx versions.

Unfortunately there is no error message in journal:
  Started app...@347-xxx.xxx.xxx.xxx:-xxx.xxx.xxx.xxx:47158.service - 
caching proxy server for Debian archive files (xxx.xxx.xxx.xxx:47158).
  app...@347-xxx.xxx.xxx.xxx:-xxx.xxx.xxx.xxx:47158.service: Deactivated 
successfully.


The error message seems just to get delivered to the requester:
  $ wget --quiet --tries=1 -O- 
http://xxx.xxx.xxx.xxx:/debian-12-bookworm-deb.debian.org
  Fatal error: exception Failure("malformed line in /etc/approx/approx.conf: ")


Version 5.12-1 seems also affected.

Removing my spaces-only lines made approx 5.12-1 work again.

Kind regards,
Bernhard



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

Kernel: Linux 6.1.0-3-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages approx depends on:
ii  adduser  3.131
ii  bzip21.0.8-5+b1
ii  curl 7.87.0-2
ii  libc62.36-8
ii  rsyslog [system-log-daemon]  8.2212.0-1
ii  xz-utils 5.4.1-0.1

approx recommends no packages.

Versions of packages approx suggests:
pn  libconfig-model-approx-perl  

-- debconf information:
  approx/port: 
Thank you for using reportbug

Bug#1018061: pads: segfault at 3a ip

2023-02-08 Thread Bernhard Übelacker


Am 08.02.23 um 18:42 schrieb Tim McConnell:

Hi Bernhard,
Okay I did that. Let me know if that was of any use.


Hello Tim,
could you send the actual output below the `bt full`?

Kind regards,
Bernhard

Bug#1018061: pads: segfault at 3a ip

2023-02-08 Thread Bernhard Übelacker


Hello Tim,
thanks, that is good helpful information, but as long the core file
might be in the system, could you execute following commands:

  export DEBUGINFOD_URLS="https://debuginfod.debian.net;
  coredumpctl gdb 1546
  (gdb) bt full

This will enable gdb to download needed debug symbol files,
and the `bt` command to gdb can then show a backtrace with
source line information (hopefully).

The debug symbols get downloaded to "/root/.cache/debuginfod_client".

Kind regards,
Bernhard



Am 07.02.23 um 20:25 schrieb Tim McConnell:

New Backtrace:



 Stack trace of thread 1546:
 #0  0x5641638af954 print_arp_asset_screen (pads + 0x9954)
 #1  0x5641638af6f0 print_arp_asset (pads + 0x96f0)
 #2  0x7fa6dbe004f6 n/a (libpcap.so.0.8 + 0x84f6)
 #3  0x7fa6dbe008ec n/a (libpcap.so.0.8 + 0x88ec)
 #4  0x7fa6dbe07d1d pcap_loop (libpcap.so.0.8 + 0xfd1d)
 #5  0x5641638a8e5b main_pads (pads + 0x2e5b)
 #6  0x5641638a847b main (pads + 0x247b)

Bug#1029499: php-guzzlehttp-psr7: Build killed with signal TERM after 150 minutes of inactivity

2023-02-07 Thread Bernhard Übelacker


Out of curiosity I investigated a little more.
With the below steps I could reproduce it in a minimal
Bookworm/testing amd64 qemu VM.

There the build stopped at this line:
dpkg-buildpackage: info: binary-only upload ...

And killing from outside this php process made the build continue/finish.

Previously I copied an sbuild example using
unshare instead of schroot, but there
the hang was not observable.

Kind regards,
Bernhard



# as root:

apt install mc rr gdb htop sbuild sbuild-debian-developer-setup mmdebstrap
apt build-dep php-guzzlehttp-psr7

sbuild-adduser benutzer

cat << "EOF" > /etc/schroot/chroot.d/unstable-amd64-sbuild
[unstable-amd64-sbuild]
description=Debian unstable/amd64 autobuilder
groups=root,sbuild
root-groups=root,sbuild
profile=sbuild
type=directory
directory=/srv/chroot/sbuild-createchroot
union-type=overlay
EOF


mkdir  /srv/chroot
mmdebstrap --variant=buildd unstable /srv/chroot/sbuild-createchroot


# as user:

cat << "EOF" > ~/.sbuildrc
$chroot_mode = 'schroot';
$distribution = 'unstable';

#$run_autopkgtest = 1;
$autopkgtest_root_args = '';
$autopkgtest_opts = [ '--apt-upgrade', '--', 'schroot', '--release', '%r', 
'--arch', '%a' ];
EOF

mkdir /home/benutzer/source/php-guzzlehttp-psr7/orig
cd/home/benutzer/source/php-guzzlehttp-psr7/orig
apt source php-guzzlehttp-psr7

cd /home/benutzer/source/php-guzzlehttp-psr7
cp orig try1 -a
cd try1/php-guzzlehttp-psr7-2.4.3
sbuild --no-run-lintian

Bug#1029499: php-guzzlehttp-psr7: Build killed with signal TERM after 150 minutes of inactivity

2023-02-07 Thread Bernhard Übelacker


Dear Maintainer,
might this be caused by a process left running?

USER PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
benutzer 743  0.0  0.4 217032 30284 pts/0S14:55   0:00 php -S 
127.0.0.1:10002 tests/Integration/server.php


If that is really the case, would it be possible to
print all the processes this build currently runs before
the message "Build killed with signal TERM..."?

Kind regards,
Bernhard

Bug#1029536: wine64-stable ENOENT

2023-02-07 Thread Bernhard Übelacker


Dear Maintainer,
if one creates this wine64-stable just as a link to wine64,
then `wine64-stable wineboot` would start to work.

# ln -s wine64 /usr/lib/wine/wine64-stable

Kind regards,
Bernhard


(rr)
692 execv( argv[1], argv + 1 );
(rr) print argv[1]
$2 = 0x7e848400 "/usr/lib/wine/wine64-stable"
(rr) shell ls -lisah /usr/lib/wine/wine64-stable
ls: cannot access '/usr/lib/wine/wine64-stable': No such file or directory
(rr) bt
#0  preloader_exec (argv=argv@entry=0x7e8483d0) at dlls/ntdll/unix/loader.c:692
#1  0x7f5e1d159a6b in loader_exec (machine=34404, argv=0x7e8483d0) at 
dlls/ntdll/unix/loader.c:716
#2  __wine_main (argc=, argv=0x7ffd65438648, 
envp=0x7ffd65438660) at dlls/ntdll/unix/loader.c:2416
#3  0x7d001254 in main ()
(rr)


$ ls -lisah /usr/bin/wine64-stable /usr/bin/wine64 /usr/lib/wine/wine64-stable 
/usr/lib/wine/wine64
ls: cannot access '/usr/lib/wine/wine64-stable': No such file or directory
674145   0 lrwxrwxrwx 1 root root  24 Jan 27 02:36 /usr/bin/wine64 -> 
/etc/alternatives/wine64
673301   0 lrwxrwxrwx 1 root root  18 Jan 27 02:36 /usr/bin/wine64-stable -> 
../lib/wine/wine64
673289 16K -rwxr-xr-x 1 root root 15K Jan 27 02:36 /usr/lib/wine/wine64

Bug#1028493: geeqie: Does not print


Am 04.02.23 um 16:26 schrieb Andreas Rönnquist:


Thanks - it does indeed sound reasonable to recommend on evince - If
you have evince installed, does printing work as you expect it then?

-- Andreas Rönnquist
gus...@debian.org



Sorry, I am not using geeqie regularly, I was just looking through some
reports and tested inside a non-persistent VM, and I did not test if a
print to the cups-pdf printer would have really worked.
Just have forwarded my findings.

Bug#1028311: vflbanner: free(): invalid pointer





$ vflbanner -f /usr/share/fonts/truetype/liberation/LiberationSans-Regular.ttf
free(): invalid pointer
Aborted





Hello,
this seems to be call to hbf_release done twice [1].

If I see it right, if hbf_load_hbf_file is left via
the "Unexpected_Error" label, the hbf_release is still
called in function HBF_Open in the "Error" label.

So I tried to remove that hbf_release in hbf_load_hbf_file,
and the process can finish without crash [2].


In [3] there is another uninitialized access to
variable "uncomp_prog" pointed out by valgrind.

Kind regards,
Bernhard


[1]
==24083== Invalid free() / delete / delete[] / realloc()
==24083==at 0x484317B: free (vg_replace_malloc.c:872)
==24083==by 0x48767B3: hbf_release.part.0 (hbf.c:481)
==24083==by 0x4878236: hbf_release (hbf.c:480)
==24083==by 0x4878236: HBF_Open (hbf.c:119)
==24083==by 0x4878691: hbf_create (drv_hbf.c:295)
==24083==by 0x485DFFF: do_open_font.constprop.0 (VFlib.c:659)
==24083==by 0x485E818: open_font (VFlib.c:559)
==24083==by 0x485EF91: vf_openfont1 (VFlib.c:348)
==24083==by 0x10941C: vflbanner (vflbanner.c:109)
==24083==by 0x1091F9: main (vflbanner.c:70)
==24083==  Address 0x50141c0 is 0 bytes inside a block of size 64 free'd
==24083==at 0x484317B: free (vg_replace_malloc.c:872)
==24083==by 0x48767B3: hbf_release.part.0 (hbf.c:481)
==24083==by 0x48776A9: hbf_release (hbf.c:480)
==24083==by 0x48776A9: hbf_load_hbf_file (hbf.c:470)
==24083==by 0x48781E0: HBF_Open (hbf.c:100)
==24083==by 0x4878691: hbf_create (drv_hbf.c:295)
==24083==by 0x485DFFF: do_open_font.constprop.0 (VFlib.c:659)
==24083==by 0x485E818: open_font (VFlib.c:559)
==24083==by 0x485EF91: vf_openfont1 (VFlib.c:348)
==24083==by 0x10941C: vflbanner (vflbanner.c:109)
==24083==by 0x1091F9: main (vflbanner.c:70)
==24083==  Block was alloc'd at
==24083==at 0x48407B4: malloc (vg_replace_malloc.c:381)
==24083==by 0x486EB3E: vf_strdup (str.c:45)
==24083==by 0x48781A0: HBF_Open (hbf.c:86)
==24083==by 0x4878691: hbf_create (drv_hbf.c:295)
==24083==by 0x485DFFF: do_open_font.constprop.0 (VFlib.c:659)
==24083==by 0x485E818: open_font (VFlib.c:559)
==24083==by 0x485EF91: vf_openfont1 (VFlib.c:348)
==24083==by 0x10941C: vflbanner (vflbanner.c:109)
==24083==by 0x1091F9: main (vflbanner.c:70)



[2]
--- vflib3-3.7.2+dfsg.orig/src/hbf.c
+++ vflib3-3.7.2+dfsg/src/hbf.c
@@ -467,7 +467,6 @@ hbf_load_hbf_file(HBF hbf, SEXP fontdirs
 Unexpected_Error:
   if (uncomp_prog != NULL)
 vf_close_uncompress_stream(fp);
-  hbf_release(hbf);
   return -1;
 }
 



[3]
==31327== Conditional jump or move depends on uninitialised value(s)
==31327==at 0x4877698: hbf_load_hbf_file (hbf.c:468)
==31327==by 0x48781B0: HBF_Open (hbf.c:100)
==31327==by 0x4878661: hbf_create (drv_hbf.c:295)
==31327==by 0x485DFFF: do_open_font.constprop.0 (VFlib.c:659)
==31327==by 0x485E818: open_font (VFlib.c:559)
==31327==by 0x485EF91: vf_openfont1 (VFlib.c:348)
==31327==by 0x10941C: vflbanner (vflbanner.c:109)
==31327==by 0x1091F9: main (vflbanner.c:70)

--- vflib3-3.7.2+dfsg.orig/src/hbf.c
+++ vflib3-3.7.2+dfsg/src/hbf.c
@@ -126,7 +126,7 @@ hbf_load_hbf_file(HBF hbf, SEXP fontdirs
   FILE   *fp;
   char   linebuf[160], prop_string[160], *name, *file_path, *p;
   char   charset_name[80], charset_name2[80], charset_enc2[5], charset[90];
-  char   *uncomp_prog;
+  char   *uncomp_prog = NULL;
   intindex, r, i, n;
 
   hbf->byte2_range_start = NULL;

Bug#1030513: vflib3: dpkg-sym packages contain no useful information


Source: vflib3
Version: 3.7.2+dfsg-0.1
Severity: wishlist
X-Debbugs-Cc: t...@test.de

Dear Maintainer,
I was looking at the crash in #1028311 when I found
the dbgsym packages did just help to get function names.

But getting also source line numbers would be desirable.
As far as I see these are missing because the CFLAGS given
to configure in debian/rules are lost.
Following change would conserve them in make-sub and therefore
gcc would be called with the -g flag in the build.

Kind regards,
Bernhard



--- vflib3-3.7.2+dfsg.orig/make-sub.in
+++ vflib3-3.7.2+dfsg/make-sub.in
@@ -1,6 +1,7 @@
 # Common definitions
 
 CC=@CC@

+CFLAGS=@CFLAGS@
 VFCFLAGS=${CFLAGS} @XX_CFLAGS@ -DVFLIB_VERSION=\"@vflib_version@\"
 LDFLAGS=@LDFLAGS@
 EXT_LIBRARY= @freetype_libdir@  @freetype_lib@ \




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

Kernel: Linux 6.1.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
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
Thank you for using reportbug

Bug#1028493: geeqie: Does not print




On Wed, 11 Jan 2023 22:48:42 +0100 waxhead  wrote:


Tried to print a jpg picture



Restarted the machine, restarted printer, tried updating, looked at print queue 
(nothing), tried preview print (nothing)
Tried to print from GIMP (success)




Hello,
I tried to reach the print preview window and it looks like
geeqie does not print by itself, instead it seems to start evince:

/usr/lib/x86_64-linux-gnu/glib-2.0/gio-launch-desktop evince 
--unlink-tempfile --preview --print-settings /tmp/settingsDVNAZ1.ini 
/tmp/previewXTSFZ1.pdf
/usr/lib/x86_64-linux-gnu/glib-2.0/gio-launch-desktop evince-previewer 
--print-settings /tmp/settingsDVNAZ1.ini --unlink-tempfile 
/tmp/previewXTSFZ1.pdf

Therefore does installing the package evince get you to the print preview?


So either geeqie should report a missing evince,
or maybe adding a recommends would be desirable?

Kind regards,
Bernhard

Bug#1029129: gnome-control-center: gnome control center segfault on boot (dmesg)

2023-02-03 Thread Bernhard Übelacker


On Wed, 18 Jan 2023 11:26:42 +0100 xevilstar  wrote:

I am getting the following message in dmesg at boot

[Wed Jan 18 07:40:37 2023] gnome-control-c[14186]: segfault at 55a65c093a45 ip 
7f206782b8f3 sp 7ffe36eef7d0 error 4 in 
libgobject-2.0.so.0.7500.0[7f2067801000+32000] likely on CPU 9 (core 4, socket 
0)
[Wed Jan 18 07:40:37 2023] Code: 1f 84 00 00 00 00 00 41 56 41 55 41 54 55 48 89 fd 
53 48 85 ff 0f 84 cf 00 00 00 48 8b 07 48 89 f3 48 85 c0 0f 84 cd 00 00 00 <4c> 
8b 20 49 81 fc fc 03 00 00 0f 86 0d 01 00 00 4c 89 e7 48 83 e7

I'd love for it to disappear and I'd like the problem to be solved 
even tho the control center seems to work afterwards




Hello,
if you still experience this issue, would it be possible
to install the package systemd-coredump?
Then a automatic backtrace would be written to the journal,
or be retrieved by coredumpctl.
That could give the maintainer a better starting point.



Kind regards,
Bernhard

coredumpctl list
coredumpctl gdb

Bug#1028363: usbguard-notifier: crashes with "terminate called after throwing an instance of 'std::runtime_error'

2023-02-02 Thread Bernhard Übelacker


On Tue, 31 Jan 2023 12:17:14 -0500 =?UTF-8?Q?Louis-Philippe_V=c3=a9ronneau?= 
 wrote:

On 2023-01-31 05 h 02, Bernhard Übelacker wrote:



> could that be a dependency to "notification-daemon"?



No, this package is also installed on my system:


So I assume this daemon is not running in your environment?
Having a recommends to it might not harm, but would not start
it in your environment?

Maybe the 'std::runtime_error' is too aggressive,
and the message could be improved.

Kind regards,
Bernhard

Bug#1029150: toilet -E troff: Segmentation fault

2023-02-02 Thread Bernhard Übelacker


#5  export_troff (bytes=0xd438, cv=0x56564ae0) at codec/export.c:1056



Dear Maintainer,
this crash happens because the array ansi2troff has
just 16 values, but gets accessed at value 32.
This value 32 originates from the constant CACA_TRANSPARENT.

With the below patch the crash could be avoided.

Kind regards,
Bernhard


https://sources.debian.org/src/libcaca/0.99.beta20-3/caca/codec/export.c/#L1056
1056 cur += sprintf(cur, "\\M[%s]", ansi2troff[bg]);



--- libcaca-0.99.beta20.orig/caca/codec/export.c
+++ libcaca-0.99.beta20/caca/codec/export.c
@@ -1052,7 +1052,7 @@ static void *export_troff(caca_canvas_t
 
 if(fg != prevfg || !started)

 cur += sprintf(cur, "\\m[%s]", ansi2troff[fg]);
-if(bg != prevbg || !started)
+if((bg != prevbg || !started) && bg != CACA_TRANSPARENT)
 cur += sprintf(cur, "\\M[%s]", ansi2troff[bg]);
 if(lineattr[x] & CACA_BOLD)
 cur += sprintf(cur, "\\fB");




benutzer@debian:~$ toilet -E troff foo
.nf
\m[black]
   m""
 mm#mm   mmmmmm
   ##" "#  #" "#
   ##   #  #   #
   #"#m#"  "#m#"
 
 
benutzer@debian:~$

Bug#1028363: usbguard-notifier: crashes with "terminate called after throwing an instance of 'std::runtime_error'

2023-01-31 Thread Bernhard Übelacker

On Wed, 11 Jan 2023 15:20:22 -0500 =?UTF-8?Q?Louis-Philippe_V=c3=a9ronneau?= 
 wrote:

On 2023-01-11 01 h 26, Birger Schacht wrote:

> The crash message ("Failed to show notification") sounds to me as if 
> there is maybe no notification daemon running?

Here are the packages reportbug lists. I don't run GNOME or KDE, but a 
custom openbox DE, so maybe something is indeed missing and should be 
added in the packages' dependencies?

Hello,
could that be a dependency to "notification-daemon"?
Following link shows a list of other packages that
are providing "notification-daemon" too.

https://packages.debian.org/sid/notification-daemon

Kind regards,
Bernhard

Bug#1028649: Segmentation fault invoking bus.get_unique_name()

2023-01-30 Thread Bernhard Übelacker


Dear Maintainer,
this can be reproduced in current Bookworm/testing too.

The backtrace below shows PyBytes_FromString received for
parameter str a NULL, which documentation states must not be NULL [1].

Unfortunately could not find an issue or update in upstream page [2].

Kind regards,
Bernhard



[1] https://docs.python.org/3/c-api/bytes.html
[2] https://github.com/facebookincubator/pystemd


$ cat test.py
from pystemd.dbuslib import DBus
bus=DBus(user_mode=True)
bus.get_unique_name()
$


$ python3 test.py
pystemd.dbusexc.DBusBaseError: [err -22]: Failed to get unique name
This is DBusBaseError, a base error for DBus (i bet you did not see that 
coming) if you need a special error, enhance pystemd.sysdexc module!.
Exception ignored in: 'pystemd.dbuslib.DBus.get_unique_name'
Traceback (most recent call last):
  File "/home/benutzer/test.py", line 3, in 
bus.get_unique_name()
pystemd.dbusexc.DBusBaseError: [err -22]: Failed to get unique name
This is DBusBaseError, a base error for DBus (i bet you did not see that 
coming) if you need a special error, enhance pystemd.sysdexc module!.
Speicherzugriffsfehler (Speicherabzug geschrieben)
$


# coredumpctl gdb 1246
(gdb) bt
#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:76
#1  0x0059f40c in PyBytes_FromString (str=0x0) at 
../Objects/bytesobject.c:153
#2  0x7f360fb7b6a6 in __pyx_pf_7pystemd_7dbuslib_4DBus_20get_unique_name 
(__pyx_v_self=) at pystemd/dbuslib.c:10541
#3  __pyx_pw_7pystemd_7dbuslib_4DBus_21get_unique_name (__pyx_v_self=, 
unused=) at pystemd/dbuslib.c:10525
#4  0x0055a850 in method_vectorcall_NOARGS (func=, args=0x7f3610512070, nargsf=, kwnames=0x0) at 
../Objects/descrobject.c:453
#5  0x0053983c in _PyObject_VectorcallTstate (kwnames=, nargsf=, args=, callable=, 
tstate=0xa85258 <_PyRuntime+166328>) at ../Include/internal/pycore_call.h:92
#6  PyObject_Vectorcall (callable=, 
args=, nargsf=, kwnames=) at 
../Objects/call.c:299
...
(gdb) py-bt
Traceback (most recent call first):
  File "/home/benutzer/test.py", line 3, in 
bus.get_unique_name()
(gdb)


$ cat -n pystemd/dbuslib.c | grep 10541 -C10
 10531
 10532  static PyObject 
*__pyx_pf_7pystemd_7dbuslib_4DBus_20get_unique_name(struct 
__pyx_obj_7pystemd_7dbuslib_DBus *__pyx_v_self) {
 10533PyObject *__pyx_r = NULL;
 10534__Pyx_RefNannyDeclarations
 10535PyObject *__pyx_t_1 = NULL;
 10536int __pyx_lineno = 0;
 10537const char *__pyx_filename = NULL;
 10538int __pyx_clineno = 0;
 10539__Pyx_RefNannySetupContext("get_unique_name", 0);
 10540__Pyx_XDECREF(__pyx_r);
 10541__pyx_t_1 = 
__Pyx_PyBytes_FromString(__pyx_f_7pystemd_7dbuslib_4DBus_get_unique_name(__pyx_v_self,
 1)); if (unlikely(!__pyx_t_1)) __PYX_ERR(0, 526, __pyx_L1_error)
 10542__Pyx_GOTREF(__pyx_t_1);
 10543__pyx_r = __pyx_t_1;
 10544__pyx_t_1 = 0;
 10545goto __pyx_L0;
 10546
 10547/* function exit code */
...
$


$ cat -n pystemd/dbuslib.pyx | grep 536 -C10
   526  cpdef const char* get_unique_name(self):
   527  cdef:
   528  int r
   529  const char *unique_name
   530
   531  r = dbusc.sd_bus_get_unique_name(self.bus, _name)
   532
   533  if r < 0:
   534  raise DBusError(r, None, "Failed to get unique name")
   535
   536  return unique_name
   537
   538  cpdef int get_fd(self):
...
$

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

2023-01-29 Thread Bernhard Übelacker





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





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

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





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

Bug#1028220: cowbell: Cowbell crashes when opening a file

2023-01-29 Thread Bernhard Übelacker


Control: reassign 1028220 libglib2.0-cil 2.12.40-3.1
Control: affects 1028220 cowbell





=
Managed Stacktrace:
=
  at  <0x>
  at GLib.SList:g_free <0x000a2>
  at GLib.ListBase:Empty <0x001a4>
  at GLib.ListBase:Dispose <0x0002b>
  at GLib.ListBase:Dispose <0x00034>
  at GLib.Marshaller:ListPtrToArray <0x0016f>
  at Gtk.FileChooserDialog:get_Uris <0x00057>
  at Cowbell.Gui.MainWindow:OnFileOpenActivate <0x0008b>




Dear Maintainer,
I tried to have a look and found this seems to be caused
by an upstream commit in gtk-sharp2 [1], released in 2.12.39.

This got fixed in upstream commit [2], released in 2.12.41.

Unfortunately Debian packages just gtk-sharp version 2.12.40,
therefore does not contain this fix.


With a package built with patch [2] the crash is no longer
visible with an unmodified cowbell package.


This crash seems also to affect the package pinta in Debian [3].


Kind regards,
Bernhard


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

Bug#1028197: plasmashell: Program terminated with signal SIGSEGV


Am 24.01.23 um 00:30 schrieb piorunz:

On 23/01/2023 22:46, Bernhard Übelacker wrote:

https://bugs.debian.org/1028197

On Mon, 23 Jan 2023 21:48:23 + piorunz  wrote:

On 23/01/2023 13:35, Bernhard Übelacker wrote:
  journalctl --user --since="2023-01-08 12:10" --until="2023-01-08 
12:12"

-- No entries --


Then please try something like this:

   journalctl --user --since="2023-01-08 11:08" --until="2023-01-08 
11:12"


That worked! Attached.




Jan 08 11:11:06 ryzen systemd-coredump[1987371]: Process 1341349 (kded5) of 
user 1000 dumped core.
...
 #3  0x7faafb991f90 n/a 
(libc.so.6 + 0x3bf90)
 #4  0x7faa7b2e8ba4 
_ZNK10PackageKit11Transaction4roleEv (libpackagekitqt5.so.1 + 0x1aba4)
 #5  0x7faa7b3a4aae n/a 
(kded_apperd.so + 0xeaae)
 #6  0x7faa7b3a4b99 n/a 
(kded_apperd.so + 0xeb99)
 #7  0x7faafb6e8fcf n/a 
(libQt5Core.so.5 + 0x2e8fcf)
 #8  0x7faa7b2dc095 
_ZN10PackageKit6Daemon22transactionListChangedERK11QStringList 
(libpackagekitqt5.so.1 + 0xe095)
Jan 08 11:11:07 ryzen kscreen_backend_launcher[5795]: kscreen.xrandr: 
XRandR::setConfig
Jan 08 11:11:07 ryzen kscreen_backend_launcher[5795]: kscreen.xrandr: Requested 
screen size is QSize(7680, 2160)
Jan 08 11:11:07 ryzen kscreen_backend_launcher[5795]: kscreen.xrandr: Needed 
CRTCs:  2
Jan 08 11:11:07 ryzen kscreen_backend_launcher[5795]: kscreen.xrandr: Actions 
to perform:
Jan 08 11:11:07 ryzen kscreen_backend_launcher[5795]:  Primary Output: 
false
Jan 08 11:11:07 ryzen kscreen_backend_launcher[5795]: kscreen.xrandr: 
Change Screen Size: false
Jan 08 11:11:07 ryzen kscreen_backend_launcher[5795]: kscreen.xrandr: 
Disable outputs: false
Jan 08 11:11:07 ryzen kscreen_backend_launcher[5795]: kscreen.xrandr: 
Change outputs: false
Jan 08 11:11:07 ryzen kscreen_backend_launcher[5795]: kscreen.xrandr: 
Enable outputs: false
Jan 08 11:11:07 ryzen kscreen_backend_launcher[5795]: kscreen.xrandr: 
XRandR::setConfig done!
Jan 08 11:11:07 ryzen plasmashell[5575]: QFont::setPointSizeF: Point size <= 0 
(0.00), must be greater than 0
Jan 08 11:11:07 ryzen plasmashell[5575]: 25 -- exe=/usr/bin/plasmashell
Jan 08 11:11:07 ryzen plasmashell[5575]: KCrash: crashing... 
crashRecursionCounter = 2


Here was also just before such a kded5 crash right before.
Either this or the startup of the new kded5 might trigger this,
as it looks like setting up some screen parameters (xrandr).
And while doing this plasmashell wrote
this "QFont::setPointSizeF" message.

Those two upstream bugs appear, but both got closed,
because upstream could not reproduce them:
  https://bugs.kde.org/show_bug.cgi?id=453712
  https://bugs.kde.org/show_bug.cgi?id=462098

I don't know which package management you use,
but until there is a fix for Debian #1026062,
you could experiment with another package manager
like synaptic and uninstall apper for now, as a workaround.

Kind regards,
Bernhard

Bug#1028197: plasmashell: Program terminated with signal SIGSEGV


https://bugs.debian.org/1028197

On Mon, 23 Jan 2023 21:48:23 + piorunz  wrote:

On 23/01/2023 13:35, Bernhard Übelacker wrote:
  journalctl --user --since="2023-01-08 12:10" --until="2023-01-08 12:12"
-- No entries --


Then please try something like this:

  journalctl --user --since="2023-01-08 11:08" --until="2023-01-08 11:12"

Bug#1028208: plasma-discover: Program terminated with signal SIGSEGV


Am 23.01.23 um 23:07 schrieb piorunz:

On 23/01/2023 21:59, Bernhard Übelacker wrote:


Hello Piotr,
if it is not clear it would be possible to take
the bug number from the email addresses and open
the bug page e.g. https://bugs.debian.org/1028208.
This was just about the plasma-discover crash part.

However, you can also iterate through past logs by
showing the different boots like this:

$ journalctl --user --list-boots
IDX BOOT ID  FIRST ENTRY LAST 
ENTRY

...
-14  Thu 2022-12-29 16:49:33 CET Mon 
2023-01-09 12:05:55 CET

...


And then show the logging for your user at that boot and
scroll to the wanted time frame:

$ journalctl --user -b -14


Kind regards,
Bernhard



Thank you Bernhard,

I've extracted logs from that time, please see attached.




Hello Piotr,
ok, then I got distracted by this from coredumpctl, showing "GMT",
while it might be really localtime ... at least it is the same as in journalctl 
...
 Timestamp: Sun 2023-01-08 13:36:08 GMT (1h 29min ago)


Your log shows four times a crashing kded5 before, then the plasma-discover:
  Jan 08 13:35:03 ryzen systemd-coredump[2835427]: Process 1997855 (kded5) of 
user 1000 dumped core.
  Jan 08 13:35:04 ryzen systemd-coredump[2835810]: Process 2835418 (kded5) of 
user 1000 dumped core.
  Jan 08 13:35:06 ryzen systemd-coredump[2836051]: Process 2835806 (kded5) of 
user 1000 dumped core.
  Jan 08 13:35:08 ryzen systemd-coredump[2836163]: Process 2836048 (kded5) of 
user 1000 dumped core.
  Jan 08 13:36:09 ryzen systemd-coredump[2842084]: Process 2832872 
(plasma-discover) of user 1000 dumped core.


And before the plasma-discover PID 2832872 shows:
  Jan 08 13:35:00 ryzen plasmashell[2832872]: adding empty sources model 
QStandardItemModel(0x55cb965ccf70)
  Jan 08 13:35:00 ryzen plasmashell[2832872]: 
file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Controls.2/org.kde.desktop/private/TextFieldContextMenu.qml:159:5:
 QML MenuItem: Binding loop detected for property "implicitWidth"
  Jan 08 13:35:00 ryzen plasmashell[2832872]: 
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/private/PrivateActionToolButton.qml:76:5:
 QML Binding: Binding loop detected for property "value"
  Jan 08 13:35:00 ryzen plasmashell[2832872]: packagekitqt.transaction: Unknown Transaction 
property: "Sender" QVariant(QString, ":1.577")
  Jan 08 13:35:01 ryzen plasmashell[2832872]: packagekitqt.transaction: Unknown Transaction 
property: "Sender" QVariant(QString, ":1.577")
  Jan 08 13:35:01 ryzen plasmashell[2832872]: packagekitqt.transaction: Unknown Transaction 
property: "Sender" QVariant(QString, ":1.577")
  Jan 08 13:35:03 ryzen plasmashell[2832872]: took really long to fetch 
PackageKitBackend(0x55cb964b2e50)
  Jan 08 13:35:03 ryzen plasmashell[2832872]: 29 -- exe=/usr/bin/plasma-discover
  Jan 08 13:35:03 ryzen plasmashell[2832872]: KCrash: crashing... 
crashRecursionCounter = 2


So I assume this plasma-discover crash is a result
of the crash of kded5 with PID 1997855 in the same second before:
 #2  
_ZN6KCrash19defaultCrashHandlerEi (libKF5Crash.so.5 + 0x586d)
 #3  n/a (libc.so.6 + 0x3bf90)
 #4  
_ZNK10PackageKit11Transaction4roleEv (libpackagekitqt5.so.1 + 0x1aba4)
 #5  n/a (kded_apperd.so + 
0xeaae)
 #6  n/a (kded_apperd.so + 
0xeb99)
 #7  n/a (libQt5Core.so.5 + 
0x2e8fcf)
 #8  
_ZN10PackageKit6Daemon22transactionListChangedERK11QStringList 
(libpackagekitqt5.so.1 + 0xe095)

Which looks like that from Debian bug #1026062.


The 60 seconds between the crashes might be the timeout
of KCrash to give the user the chance to click the icon
in the systray, after that time it "forwards" the crash
to get collected by systemd-coredump.


So in the end it looks like plasma-discover is not prepared
for kded5 crashing, not ideal, but if kded5 gets fixed this
plasma-discover crash might disappear too.

Kind regards,
Bernhard

Bug#1028208: plasma-discover: Program terminated with signal SIGSEGV

Am 23.01.23 um 22:48 schrieb piorunz:

On 23/01/2023 13:35, Bernhard Übelacker wrote:

(gdb) bt
#0 0x7fbffc2a9ccc in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x7fbffc25aef2 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x7fbffe79dbe1 in KCrash::defaultCrashHandler(int) () from
/lib/x86_64-linux-gnu/libKF5Crash.so.5

#3
#4 0x7fbffc2a9ccc in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#5 0x7fbffc25aef2 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#6
#7 0x7fbffc2a9ccc in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#8 0x7fbffc25aef2 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#9 0x7fbffad3c3b0 in g_closure_invoke () from
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#10 0x7fbffad4f1a5 in ?? () from
/lib/x86_64-linux-gnu/libgobject-2.0.so.0

Hello Piotr,
this raise might indicate that libgobject wanted
to stop the process for some reason.
This reason it might have written to stdout/stderr.

Therefore probably you can still retrieve this logging.
From the "Sun 2023-01-08 13:36:08 GMT" I assume it happend at 14:36
your local time? Then following might possibly show related output.
If there is some could you provide the related parts?

journalctl --user --since="2023-01-08 14:34" --until="2023-01-08 14:38"

Unfortunately there might also be some programs writing to
~/.xsession-errors,

there the lines are not prefixed with the date and time ...
So it might be difficult to find them there.

Was this just a "one-time" crash, or do you get that regularly?

Kind regards,
Bernhard

Hello Bernhard,

Thanks for your reply. I am not sure what bug you want me to reply to so
I reply to both.

Plasma, or kwin, or entire desktop crashes all the time. There most
likely are multiple bugs. This is one of them. Sometimes desktop crashes
and there is no SIGSEV. Usually I launch Konsole from shortcut, restart
kwin and plasmashell with --replace option, but this not always helps.

I have modern Radeon GPU, it probably adds fuel to the fire.
Can't wait for more updates regarding kwin/plasmashell/multi monitor
handling/sleeping and waking up the monitor. There is a lot of bugs in
these areas, when Radeon GPU is involved at least. I will be happy to
debug as much as I can, you can tell me what else to do.

$ journalctl --user --since="2023-01-08 14:34" --until="2023-01-08 14:38"
-- No entries --

journalctl --user --since="2023-01-08 12:10" --until="2023-01-08 12:12"
-- No entries --

.xsession-errors:

Xsession: X session started for pioruns at Sat 7 Jan 08:04:38 GMT 2023
dbus-update-activation-environment: setting
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus

dbus-update-activation-environment: setting DISPLAY=:0
dbus-update-activation-environment: setting
XAUTHORITY=/home/pioruns/.Xauthority

localuser:pioruns being added to access control list
dbus-update-activation-environment: setting GTK_MODULES=gail:atk-bridge
dbus-update-activation-environment: setting QT_ACCESSIBILITY=1
file:///home/pioruns/.local/share/plasma/look-and-feel/com.github.vinceliuice.Qogir-light/contents/splash/Splash.qml:89:
ReferenceError: bottomRect is not defined
file:///home/pioruns/.local/share/plasma/look-and-feel/com.github.vinceliuice.Qogir-light/contents/splash/Splash.qml:88:
ReferenceError: bottomRect is not defined
file:///home/pioruns/.local/share/plasma/look-and-feel/com.github.vinceliuice.Qogir-light/contents/splash/Splash.qml:89:
ReferenceError: bottomRect is not defined
file:///home/pioruns/.local/share/plasma/look-and-feel/com.github.vinceliuice.Qogir-light/contents/splash/Splash.qml:89:
ReferenceError: bottomRect is not defined
file:///home/pioruns/.local/share/plasma/look-and-feel/com.github.vinceliuice.Qogir-light/contents/splash/Splash.qml:88:
ReferenceError: bottomRect is not defined
file:///home/pioruns/.local/share/plasma/look-and-feel/com.github.vinceliuice.Qogir-light/contents/splash/Splash.qml:89:
ReferenceError: bottomRect is not defined
Xsession: X session started for pioruns at Mon 9 Jan 10:52:01 GMT 2023

This seems to be a session between 7th and 9th January.

Hello Piotr,
if it is not clear it would be possible to take
the bug number from the email addresses and open
the bug page e.g. https://bugs.debian.org/1028208.
This was just about the plasma-discover crash part.

However, you can also iterate through past logs by
showing the different boots like this:

$ journalctl --user --list-boots
IDX BOOT ID FIRST ENTRY LAST ENTRY
...
-14 Thu 2022-12-29 16:49:33 CET Mon 2023-01-09
12:05:55 CET
...

And then show the logging for your user at that boot and
scroll to the wanted time frame:

$ journalctl --user -b -14

Kind regards,
Bernhard

Bug#1028309: linux-image-6.0.0-6-amd64: Regression in Kernel 6.0: System partially freezes with "nvme controller is down"




On Thu, 12 Jan 2023 18:31:37 + =?UTF-8?Q?Julian_Gro=c3=9f?= 
 wrote:
My computer just froze on Kernel version 5.19.11-1. Though nothing got 
logged.
Now I don't know if this is the same issue and newer kernels just behave 
better in terms of logging, or if this is a different issue..


I guess I will add a second screen to my computer, open journalctl on 
there, and point a camera at it to capture the issue.


Hello Julian,
Capturing with a camera might be possible.
But if you have a serial port at the target machine,
another capturing system available, and a cable connecting them,
it might be more convenient to capture the output from the serial port,
to have it in text form.


Below links show the kernel parameters at the target machine:
https://wiki.archlinux.org/title/working_with_the_serial_console#Kernel

And at the capturing machine you could start "script", that would
record all that happens to a file "typescript" in the current directory,
and inside start "screen" to the other machine like here:
https://wiki.archlinux.org/title/working_with_the_serial_console#Screen


If the machine is still kind of responsive then it might also be possible
to capture through a network connection via "netconsole", more details
in following link:
https://wiki.ubuntu.com/Kernel/Netconsole

Kind regards,
Bernhard

Bug#1029515: gdb: An attempt to debug a mono application gives: Assertion `jiter->jiter_data != nullptr' failed.




Package: gdb
Version: 12.1-4+b1
Severity: normal
X-Debbugs-Cc: bernha...@mailbox.org



Dear Maintainer,
I tried to debug a mono application in another Debian bug.

There I received the assertion below, with just trying to run
the application inside gdb.

I found this gdb upstream bug report:
https://sourceware.org/bugzilla/show_bug.cgi?id=29277

And a gdb package built with the proposed patch from comment 1
does no longer hit this assertion.

Might be just an issue with debug information
separated to external files (mono-runtime-dbg package).

Kind regards,
Bernhard



# with this packages installed: cowbell cowbell-dbgsym mono-dbg mono-runtime-dbg

benutzer@debian:~$ gdb -q --args /usr/bin/mono /usr/lib/cowbell/cowbell.exe
Reading symbols from /usr/bin/mono...
Reading symbols from /usr/lib/debug//usr/bin/mono-sgen...
Mono support loaded.
Mono support loaded.
(gdb) run
Starting program: /usr/bin/mono /usr/lib/cowbell/cowbell.exe
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
/build/gdb-JNEVqL/gdb-12.1/gdb/jit.c:1252: internal-error: jit_event_handler: 
Assertion `jiter->jiter_data != nullptr' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
- Backtrace -
0x55c034f2b21e gdb_internal_backtrace_1
/build/gdb-JNEVqL/gdb-12.1/gdb/bt-utils.c:122
0x55c034f2b21e _Z22gdb_internal_backtracev
/build/gdb-JNEVqL/gdb-12.1/gdb/bt-utils.c:168
0x55c035259d54 internal_vproblem
/build/gdb-JNEVqL/gdb-12.1/gdb/utils.c:394
0x55c035259f7a _Z15internal_verrorPKciS0_P13__va_list_tag
/build/gdb-JNEVqL/gdb-12.1/gdb/utils.c:471
0x55c035398e81 _Z14internal_errorPKciS0_z
/build/gdb-JNEVqL/gdb-12.1/gdbsupport/errors.cc:55
0x55c03509585c _Z17jit_event_handlerP7gdbarchP7objfile
/build/gdb-JNEVqL/gdb-12.1/gdb/jit.c:1252
0x55c034f0d0b8 handle_jit_event
/build/gdb-JNEVqL/gdb-12.1/gdb/breakpoint.c:5552
0x55c034f0d0b8 _Z20bpstat_run_callbacksP6bpstat
/build/gdb-JNEVqL/gdb-12.1/gdb/breakpoint.c:5753
0x55c035088266 process_event_stop_test
/build/gdb-JNEVqL/gdb-12.1/gdb/infrun.c:6452
0x55c03508c888 handle_stop_requested
/build/gdb-JNEVqL/gdb-12.1/gdb/infrun.c:4465
0x55c03508c888 handle_stop_requested
/build/gdb-JNEVqL/gdb-12.1/gdb/infrun.c:4460
0x55c03508c888 handle_inferior_event
/build/gdb-JNEVqL/gdb-12.1/gdb/infrun.c:5695
0x55c03508e479 _Z20fetch_inferior_eventv
/build/gdb-JNEVqL/gdb-12.1/gdb/infrun.c:4085
0x55c035399405 gdb_wait_for_event
/build/gdb-JNEVqL/gdb-12.1/gdbsupport/event-loop.cc:725
0x55c0353999f6 _Z16gdb_do_one_eventv
/build/gdb-JNEVqL/gdb-12.1/gdbsupport/event-loop.cc:212
0x55c0350cedec start_event_loop
/build/gdb-JNEVqL/gdb-12.1/gdb/main.c:421
0x55c0350cedec captured_command_loop
/build/gdb-JNEVqL/gdb-12.1/gdb/main.c:481
0x55c0350d0a64 captured_main
/build/gdb-JNEVqL/gdb-12.1/gdb/main.c:1351
0x55c0350d0a64 _Z8gdb_mainP18captured_main_args
/build/gdb-JNEVqL/gdb-12.1/gdb/main.c:1366
0x55c034e96219 main
/build/gdb-JNEVqL/gdb-12.1/gdb/gdb.c:32
-

1: *jit_bp_sym.objfile = {original_name = "/usr/lib/debug//usr/bin/mono-sgen" 
...
2: *jit_bp_sym.objfile->separate_debug_objfile_backlink = {original_name = 
"/usr/bin/mono" ...



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

Kernel: Linux 6.1.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
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 gdb depends on:
ii  libbabeltrace1  1.5.11-1+b1
ii  libc6   2.36-8
ii  libdebuginfod1  0.188-2.1
ii  libexpat1   2.5.0-1
ii  libgcc-s1   12.2.0-14
ii  libgmp102:6.2.1+dfsg1-1.1
ii  libipt2 2.0.5-1
ii  liblzma55.4.1-0.0
ii  libmpfr64.2.0-1
ii  libncursesw66.4-1
ii  libpython3.11   3.11.1-2
ii  libreadline88.2-1.3
ii  libsource-highlight4v5  3.1.9-4.2+b2
ii  libstdc++6  12.2.0-14
ii  libtinfo6   6.4-1
ii  libxxhash0  0.8.1-1
ii  zlib1g  1:1.2.13.dfsg-1

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

Versions of packages gdb suggests:
pn  gdb-doc
pn  gdbserver  

-- no debconf information
Thank you for using reportbug

Bug#1028197: plasmashell: Program terminated with signal SIGSEGV


(gdb) bt
...
#4  
#5  0x7f54b82563fb in QQuickItem::~QQuickItem() () from 
/lib/x86_64-linux-gnu/libQt5Quick.so.5
#6  0x7f54b83d0045 in ?? () from /lib/x86_64-linux-gnu/libQt5Quick.so.5
#7  0x7f54b66dd53f in QObject::event(QEvent*) () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x7f54b7362f5e in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#9  0x7f54b66b17c8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
() from /lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x7f54b66b4761 in QCoreApplicationPrivate::sendPostedEvents(QObject*, 
int, QThreadData*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x7f54b670a1d3 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#12 0x7f54b46657a9 in g_main_context_dispatch () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x7f54b4665a38 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x7f54b4665acc in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x7f54b67098b6 in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x7f54b66b024b in 
QEventLoop::exec(QFlags) () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5
#17 0x7f54b66b83b6 in QCoreApplication::exec() () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5
#18 0x55937ecd0c6c in ?? ()
#19 0x7f54b624618a in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#20 0x7f54b6246245 in __libc_start_main () from 
/lib/x86_64-linux-gnu/libc.so.6


Hello Piotr,
I fear that backtrace is not that distinctive.
Upstream I found [1] a few bugs, but they also do
not give helpful pointers.

So here it might also be helpful to see what might be contained
in journalctl or in .xsession-errors:

  journalctl --user --since="2023-01-08 12:10" --until="2023-01-08 12:12"

Can you please give a rough estimate how often it does crash?

Kind regards,
Bernhard

[1]
  https://bugs.kde.org/show_bug.cgi?id=461464
  https://bugs.kde.org/show_bug.cgi?id=460477

Bug#1028208: plasma-discover: Program terminated with signal SIGSEGV


(gdb) bt
#0  0x7fbffc2a9ccc in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7fbffc25aef2 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x7fbffe79dbe1 in KCrash::defaultCrashHandler(int) () from 
/lib/x86_64-linux-gnu/libKF5Crash.so.5
#3  
#4  0x7fbffc2a9ccc in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#5  0x7fbffc25aef2 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#6  
#7  0x7fbffc2a9ccc in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#8  0x7fbffc25aef2 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#9  0x7fbffad3c3b0 in g_closure_invoke () from 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#10 0x7fbffad4f1a5 in ?? () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0



Hello Piotr,
this raise might indicate that libgobject wanted
to stop the process for some reason.
This reason it might have written to stdout/stderr.

Therefore probably you can still retrieve this logging.
From the "Sun 2023-01-08 13:36:08 GMT" I assume it happend at 14:36
your local time? Then following might possibly show related output.
If there is some could you provide the related parts?

journalctl --user --since="2023-01-08 14:34" --until="2023-01-08 14:38"

Unfortunately there might also be some programs writing to ~/.xsession-errors,
there the lines are not prefixed with the date and time ...
So it might be difficult to find them there.

Was this just a "one-time" crash, or do you get that regularly?

Kind regards,
Bernhard

Bug#967941: Bug appeared again


On Sat, 14 Jan 2023 18:07:08 + Stephan =?ISO-8859-1?Q?Verb=FCcheln?= 
 wrote:

This bug appears back some time ago. For some months, video thumbnails
failed to generate on multiple of my machines. Since then, I was trying
to figure out the cause.

It only seemed to affect h264, but not all videos were affected. I even
had multiple videos saved from Youtube, some were generating
thumbnails, others were not. I could not find any difference in the
codec parameters.

Adding the -l option in /usr/share/thumbnailers/totem.thumbnailer
worked to prevent this bug. Does this option have any downsides?

Regards



Hello,
it looks like this option makes it not setting the process limits [1] [2].

Simon wrote it that way before:
  totem-video-thumbnailer sets a resource limit ... to avoid a runaway
  thumbnailing process consuming disproportionate system resources.

Kind regards,
Bernhard

[1] 
https://sources.debian.org/src/totem/43.0-2/src/totem-video-thumbnailer.c/#L587
587 { "no-limit", 'l', G_OPTION_FLAG_REVERSE, G_OPTION_ARG_NONE, _limit, 
"Don't limit the thumbnailing time to 30 seconds", NULL },

[2] 
https://sources.debian.org/src/totem/43.0-2/src/totem-resources.c/?hl=111#L111

Bug#1028083: plasma-discover: Discover tray app crashes kded5, causing other system tray icons to vanish