Bug#949003: Doesn't work on 64 bit architectures

[Bernhard Übelacker]

Dear Maintainer,
I tried to find some more information about this issue.
Attached is a file containing some hints how I did run
the UML process and some debugging output.

As far as I see it is yet another issue with some "caddr32_t"
sizes, this time they are used to map the input data.
Therefore 8 Bytes get written instead of 4, when assigning
the next and prev pointer inside function tcp_input, line 306. [2]

Therefore the checksum for each IP packet does not
match anymore and gets dropped. ("11 discarded for bad checksums")

As it seems this type is sometimes mapped to input data and
then used for holding real pointers, it looks their size
cannot be just increased as done in patch 012_ipq64.patch.

Related bugs seem to be: #948268 or #922323.


When realising this type being the issue I found this patch [1],
which might have been created in the Qemu area.

Unfortunately this patch did not apply cleanly, but attached
patch c11b4078042_fix_64_bit_issue_in_slirp.patch is created from
the package with all patches applied and additionally
949003_explicit_extern_declaration.patch to fix a build failure.


One thing to note is building the package with -DDEBUG allows to
use the '-d 7' switch to get some verbose output in file 'slirp_debug'.


A package built with both patches and "-DDEBUG" was able to
do some http downloads.

Kind regards,
Bernhard


[1] 
https://gitlab.freedesktop.org/slirp/libslirp/-/commit/c11b407804272b71e5bdd7a2a9181c64c7a594ed


[2]
(gdb) bt
#0  tcp_input (m=0x558551242be0, iphlen=, 
inso=inso@entry=0x0) at ./tcp_input.c:313
#1  0x55854f58399c in ip_input (m=) at ip_input.c:214
#2  0x55854f58c01f in sl_dispatch (ttyp=ttyp@entry=0x55855123e2c0) at 
./sl.c:127
#3  0x55854f58c1ee in sl_input (ttyp=0x55855123e2c0, 
if_bptr=0x7ffddbe4f67e "\300\264\004\002\b\n`\354\303a", if_n=63) at ./sl.c:35
#4  0x55854f581ed2 in if_input (ttyp=0x55855123e2c0) at ./if.c:191
#5  0x55854f58567f in main_loop () at ./main.c:1158
#6  0x55854f5757d7 in main (argc=3, argv=0x7ffddbe504f8) at ./main.c:95
Description: 949003

Author: Bernhard Übelacker 
Bug-Debian: https://bugs.debian.org/949003
Forwarded: no
Last-Update: 2020-09-02

Index: slirp-1.0.17/src/options.c
===
--- slirp-1.0.17.orig/src/options.c
+++ slirp-1.0.17/src/options.c
@@ -74,8 +74,8 @@ int nozeros;/* If se
  * Read the config file
  */
 
-int (*lprint_print) _P((void *, const char *format, va_list));
-char *lprint_ptr, *lprint_ptr2, **lprint_arg;
+extern int (*lprint_print) _P((void *, const char *format, va_list));
+extern char *lprint_ptr, *lprint_ptr2, **lprint_arg;
 struct sbuf *lprint_sb;
 
 int cfg_unit;
Description: Fix 64 bit issue in slirp

Origin: https://gitlab.freedesktop.org/slirp/libslirp/-/commit/c11b407804272b71e5bdd7a2a9181c64c7a594ed
Bug-Debian: https://bugs.debian.org/949003
Last-Update: 2020-09-02

Index: slirp-1.0.17/src/ip.h
===
--- slirp-1.0.17.orig/src/ip.h
+++ slirp-1.0.17/src/ip.h
@@ -187,35 +187,31 @@ struct	ip_timestamp {
 
 #define	IP_MSS		576		/* default maximum segment size */
 
-#ifdef HAVE_SYS_TYPES32_H  /* Overcome some Solaris 2.x junk */
-#include 
-#else
 #if SIZEOF_CHAR_P == 4
-typedef caddr_t caddr32_t;
-#else
-typedef void* caddr32_t;
-#endif
-#endif
-
-#if SIZEOF_CHAR_P == 4
-typedef struct ipq *ipqp_32;
-typedef struct ipasfrag *ipasfragp_32;
+struct mbuf_ptr {
+struct mbuf *mptr;
+uint32_t dummy;
+};
 #else
-typedef void* ipqp_32;
-typedef void* ipasfragp_32;
+struct mbuf_ptr {
+struct mbuf *mptr;
+};
 #endif
+struct qlink {
+void *next, *prev;
+};
 
 /*
  * Overlay for ip header used by other protocols (tcp, udp).
  */
 struct ipovly {
-	caddr32_t	ih_next, ih_prev;	/* for protocol sequence q's */
+	struct	mbuf_ptr ih_mbuf;	/* backpointer to mbuf */
 	u_int8_t	ih_x1;			/* (unused) */
 	u_int8_t	ih_pr;			/* protocol */
 	int16_t	ih_len;			/* protocol length */
 	struct	in_addr ih_src;		/* source internet address */
 	struct	in_addr ih_dst;		/* destination internet address */
-};
+} __attribute__((packed));
 
 /*
  * Ip reassembly queue structure.  Each fragment
@@ -225,44 +221,30 @@ struct ipovly {
  * size 28 bytes
  */
 struct ipq {
-	ipqp_32 next,prev;	/* to other reass headers */
+	struct	qlink frag_link;	/* to ip headers of fragments */
+	struct	qlink ip_link;		/* to other reass headers */
 	u_int8_t	ipq_ttl;		/* time for reass q to live */
 	u_int8_t	ipq_p;			/* protocol of this fragment */
 	u_int16_t	ipq_id;			/* sequence id for reassembly */
-	ipasfragp_32 ipq_next,ipq_prev;
-	/* to ip headers of fragments */
 	struct	in_addr ipq_src,ipq_dst;
 };
 
 /*
  * Ip header, when holding a fragment.
  *
- * Note: ipf_next must be at same offset as ipq_next above
+ * Note: ipf_link must be at same offset as frag_link above
  */
 struct	ipasfrag 

Bug#950646: sane-utils: saned does not work if starteed via systemd

[Bernhard Übelacker]

Hello,
searched the upstream issue tracker and found following,
that seems to match your situation.

https://gitlab.com/sane-project/backends/-/issues/275
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958074

Kind regards,
Bernhard

Bug#950646: sane-utils: saned does not work if starteed via systemd

[Bernhard Übelacker]

Hello Patrick,
I found another environment to increase verbosity
another little bit, please see below.


Your output points also into the direction of an permission
problem like what Stefan described in the first message.

The unit file starts the saned server with user and group saned.


On the other side it seems that the scanners usb vendor id and
product id should be inside /usr/lib/udev/hwdb.d/20-sane.hwdb,
and should get matched to libsane_matched=yes by udev ...

Could you please additionally provide an output of 'lsusb'?


A workaround might be to change the user running saned in the
systemd-unit file, or add the saned user to a group that could
access the usb devices.

Kind regards,
Bernhard


/lib/systemd/system/saned@.service:
User=saned
Group=saned
Environment=SANE_CONFIG_DIR=/etc/sane.d SANE_DEBUG_DLL=255 
SANE_DEBUG_PLUSTEK=12 SANE_DEBUG_SANEI_USB=255

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

[Bernhard Übelacker]

Hello Ronny,


> Incidentally, stopping the cups service (new packages) after a single print 
> job when under valgrind gave this in case it's related:
> 
> Aug 28 10:03:59 samba-prn-01.graysofwestminster.co.uk systemd[1]: Stopping 
> CUPS Scheduler...
> Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: 
> ==5238== Invalid free() / delete / delete[] / realloc()
> Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: 
> ==5238==at 0x48369AB: free (vg_replace_malloc.c:538)
> Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: 
> ==5238==by 0x4C73629: check_free (dlerror.c:202)
> Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: 
> ==5238==by 0x4C73629: check_free (dlerror.c:186)
> Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: 
> ==5238==by 0x4C73AB1: free_key_mem (dlerror.c:221)
> Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: 
> ==5238==by 0x4C73AB1: __dlerror_main_freeres (dlerror.c:239)

This might be what is described in here:
  https://sourceware.org/bugzilla/show_bug.cgi?id=24476
And I guess not related to the original issue.

At least could not reproduce this message
with libc6 2.31-3 in a up-to-date testing VM.


> So running with the patched cups packages seems to fix the "invalid free" on 
> a test print. I've restored the systemd service file to remove valgrind so 
> let's see how we go on a day's printing. :-).

Any news in this regard?


Kind regards,
Bernhard

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

[Bernhard Übelacker]

Hello Ronny,
unfortunately I don't have any pointers on that httpAddrGetList.

So you were able to build a package?


One additional note: I guess with "quilt refresh" any new changes
get added to the last patch. A 'dpkg-source --commit' would create
a new separate patch file.

Kind regards,
Bernhard

Bug#950646: sane-utils: saned does not work if starteed via systemd

[Bernhard Übelacker]

Hello Patrick,
you might add in the sane unit file a backend specific
logging environment too. That should give much more details
for the plustek module.

Kind regards,
Bernhard

/lib/systemd/system/saned@.service:
Environment=SANE_CONFIG_DIR=/etc/sane.d SANE_DEBUG_DLL=255 SANE_DEBUG_PLUSTEK=12

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

[Bernhard Übelacker]

Hello Ronny,
I tried to have a look and I get the feeling that there
is a disagreement if the attribute "printer-alert" is of type
IPP_TAG_TEXT or IPP_TAG_STRING.

Also it is the only line I found at a glance that calls
ippAddString with a IPP_TAG_STRING.

Other attributes of type IPP_TAG_STRING seem to get added
by a call to ippAddOctetString.

But still I am not sure which of STRING or TEXT is the right one.

Below patch is an attempt to add "printer-alert" in copy_printer_attrs
by using ippAddOctetString.
The important change is in scheduler/ipp.c, the changes to backend/ipp.c
should just mark another questionable place.
I could not test this change as I can not reproduce
the crash - so it is untested.

Kind regards,
Bernhard






Invalid free() / delete / delete[] / realloc()
   at 0x48369AB: free (vg_replace_malloc.c:538)
   by 0x4A2443D: ipp_free_values (ipp.c:6324)
https://sources.debian.org/src/cups/2.3.3-2/cups/ipp.c/#L6324
   by 0x4A243A7: ippDelete (ipp.c:1755)  
https://sources.debian.org/src/cups/2.3.3-2/cups/ipp.c/#L1755
   by 0x4A243A7: ippDelete (ipp.c:1729)  
https://sources.debian.org/src/cups/2.3.3-2/cups/ipp.c/#L1729
   by 0x11CCE3: cupsdWriteClient (client.c:2563) 
https://sources.debian.org/src/cups/2.3.3-2/scheduler/client.c/#L2563
   by 0x156D36: cupsdDoSelect (select.c:485) 
https://sources.debian.org/src/cups/2.3.3-2/scheduler/select.c/#L485
   by 0x1142F4: main (main.c:847)
https://sources.debian.org/src/cups/2.3.3-2/scheduler/main.c/#L847
 Address 0x68f1e04 is 4 bytes inside a block of size 23 alloc'd
   at 0x4837B65: calloc (vg_replace_malloc.c:760)
   by 0x4A34DD0: _cupsStrAlloc (string.c:107)
https://sources.debian.org/src/cups/2.3.3-2/cups/string.c/#L107
   by 0x4A234F5: ippAddString (ipp.c:957)
https://sources.debian.org/src/cups/2.3.3-2/cups/ipp.c/#L957
   by 0x13076D: copy_printer_attrs (ipp.c:4894)  
https://sources.debian.org/src/cups/2.3.3-2/scheduler/ipp.c/#L4894
   by 0x13DCCD: get_printer_attrs (ipp.c:7365)   
https://sources.debian.org/src/cups/2.3.3-2/scheduler/ipp.c/#L7365
   by 0x13DCCD: cupsdProcessIPPRequest (ipp.c:457)   
https://sources.debian.org/src/cups/2.3.3-2/scheduler/ipp.c/#L457
   by 0x11DD24: cupsdReadClient (client.c:1812)  
https://sources.debian.org/src/cups/2.3.3-2/scheduler/client.c/#L1812
   by 0x156C04: cupsdDoSelect (select.c:480) 
https://sources.debian.org/src/cups/2.3.3-2/scheduler/select.c/#L480
   by 0x1142F4: main (main.c:847)
https://sources.debian.org/src/cups/2.3.3-2/scheduler/main.c/#L847



./backend/ipp.c:3081:  if ((pa = ippFindAttribute(ipp, "printer-alert", 
IPP_TAG_TEXT)) != NULL)
./cups/encode.c:317:  { 1, "printer-alert", IPP_TAG_STRING, 
IPP_TAG_PRINTER },
./scheduler/ipp.c:4893:  if (printer->alert && (!ra || cupsArrayFind(ra, 
"printer-alert")))ippAddString(con->response, IPP_TAG_PRINTER, 
IPP_TAG_STRING, "printer-alert", NULL, printer->alert);
./scheduler/job.c:5276: CUPSD_EVENT_PRINTER_STATE ???



diff --git a/backend/ipp.c b/backend/ipp.c
index a99079e..94fb701 100644
--- a/backend/ipp.c
+++ b/backend/ipp.c
@@ -3026,6 +3026,7 @@ report_attr(ipp_attribute_t *attr)/* I - 
Attribute */
   valptr += strlen(valptr);
   break;
 
+  case IPP_TAG_STRING :
   default :
  /*
  * Unsupported value type...
@@ -3078,7 +3079,7 @@ report_printer_state(ipp_t *ipp)  /* I - IPP response */
   * Report alerts and messages...
   */
 
-  if ((pa = ippFindAttribute(ipp, "printer-alert", IPP_TAG_TEXT)) != NULL)
+  if ((pa = ippFindAttribute(ipp, "printer-alert", IPP_TAG_STRING)) != NULL)
 report_attr(pa);
 
   if ((pam = ippFindAttribute(ipp, "printer-alert-message",
diff --git a/scheduler/ipp.c b/scheduler/ipp.c
index 2fe3bf2..1494ecf 100644
--- a/scheduler/ipp.c
+++ b/scheduler/ipp.c
@@ -4891,7 +4891,7 @@ copy_printer_attrs(
   }
 
   if (printer->alert && (!ra || cupsArrayFind(ra, "printer-alert")))
-ippAddString(con->response, IPP_TAG_PRINTER, IPP_TAG_STRING, 
"printer-alert", NULL, printer->alert);
+ippAddOctetString(con->response, IPP_TAG_PRINTER, "printer-alert", 
printer->alert, (int)strlen(printer->alert));
 
   if (printer->alert_description && (!ra || cupsArrayFind(ra, 
"printer-alert-description")))
 ippAddString(con->response, IPP_TAG_PRINTER, IPP_TAG_TEXT, 
"printer-alert-description", NULL, printer->alert_description);

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

[Bernhard Übelacker]

Am 25.08.20 um 14:40 schrieb Ronny Adsetts:
> In which case a backport of valgrind would be dead handy. :-).


You might be able to build one yourself:
(maybe inside a VM too, because several build dependencies get installed ...)


# Buster/stable amd64 qemu VM 2020-08-25
apt update
apt build-dep valgrind
apt install devscripts
mkdir /home/benutzer/source/valgrind/orig -p
cd/home/benutzer/source/valgrind/orig
dget http://deb.debian.org/debian/pool/main/v/valgrind/valgrind_3.16.1-1.dsc
cd ..
cp -a orig try1
cd try1/valgrind-3.16.1
sed -i 's/debhelper-compat (= 13)/debhelper-compat (= 12)/' debian/control
dpkg-buildpackage

cd /home/benutzer/source/valgrind/try1
apt install libc6-dbg
dpkg -i valgrind_3.16.1-1_amd64.deb


Just tested with a few installed executables ...

Kind regards,
Bernhard

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

[Bernhard Übelacker]

Am 25.08.20 um 11:02 schrieb Ronny Adsetts:
> Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==by 0x13076D: ??? 
> (in /usr/sbin/cupsd)
> Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==by 0x5AC5261: ???
> Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==by 0x5F44D23F: ???
> Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==
> 
> Does that give any further insight?

Is the cups-daemon-dbgsym installed and from the same
source as the cups-daemon package?

Does following command show the same BuildID ?

Kind regards,
Bernhard

# file /usr/sbin/cupsd 
/usr/lib/debug/.build-id/8a/de7144c28e948515ffa5b45d70e4e02e008e17.debug
/usr/sbin/cupsd:  ELF 
64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, 
interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, 
BuildID[sha1]=8ade7144c28e948515ffa5b45d70e4e02e008e17, stripped
/usr/lib/debug/.build-id/8a/de7144c28e948515ffa5b45d70e4e02e008e17.debug: ELF 
64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, 
interpreter *empty*, for GNU/Linux 3.2.0, 
BuildID[sha1]=8ade7144c28e948515ffa5b45d70e4e02e008e17, with debug_info, not 
stripped
# dpkg -S de7144c28e948515ffa5b45d70e4e02e008e17
cups-daemon-dbgsym: 
/usr/lib/debug/.build-id/8a/de7144c28e948515ffa5b45d70e4e02e008e17.debug

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

[Bernhard Übelacker]

Hello Ronny

Am 25.08.20 um 10:14 schrieb Ronny Adsetts:

>> I tried to run it in a VM and tested with some virtual PDF and PS
>> printer. Following were the configuration changes to have it run
>> under valgrind.
>>
>> nano /lib/systemd/system/cups.service
>>
>> -ExecStart=/usr/sbin/cupsd -l +# ExecStart=/usr/sbin/cupsd -l 
>> +ExecStart=/usr/bin/valgrind --trace-children=no /usr/sbin/cupsd -l
>>
>> systemctl daemon-reload systemctl stop cups.service systemctl start
>> cups.service
>>
>> But I don't know if that might create a problem perfomance wise.
>>
>> I have tried to build with AddressSanitizer, but the build itself
>> makes trouble and the resulting binary is not able to print...
> 
> I've never used valgrind before. How long should I run it this way for? How 
> do I get the result of running it to send to you?
> 

Adding the line above would just appear in 'journalctl -e -u cups.service'.
Otherwise one could add the option '--log-file=/tmp/valgrind' to redirect
and separate the additional output of valgrind.

I have also not yet run valgrind that way, but I would expect either the crash
happen the same way, therefore process would end and maybe automatically 
restarted.

It might also just print something and continue or the issue does not happen
at all when running under valgrind, I cannot be sure.

Kind regards,
Bernhard

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

[Bernhard Übelacker]

Hello Ronny,


Am 24.08.20 um 13:12 schrieb Ronny Adsetts:

> The "bt full" on a recent crash:

Unfortunately I cannot find something striking.



>> Otherwise running cupsd within valgrind could also give some hints.
> 
> I'll see if I can do this. I'll have to schedule some down time so it won't 
> be immediate (or possibly even quick).

I tried to run it in a VM and tested with some virtual PDF and PS printer.
Following were the configuration changes to have it run under valgrind.

nano /lib/systemd/system/cups.service

-ExecStart=/usr/sbin/cupsd -l
+# ExecStart=/usr/sbin/cupsd -l
+ExecStart=/usr/bin/valgrind --trace-children=no /usr/sbin/cupsd -l

systemctl daemon-reload
systemctl stop cups.service
systemctl start cups.service


But I don't know if that might create a problem perfomance wise.


I have tried to build with AddressSanitizer, but the build itself makes
trouble and the resulting binary is not able to print...


Kind regards,
Bernhard

Bug#968756: Further Info

[Bernhard Übelacker]

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



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

This line points to function below.

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

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

Kind regards,
Bernhard



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

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

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

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



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

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







# Buster amd64 qemu VM 2020-08-24


apt update
apt dist-upgrade


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

apt update


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

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



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

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

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

[Bernhard Übelacker]

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

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

Kind regards,
Bernhard



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

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

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

Bug#941236: posterazor: error while loading shared libraries: libIlmImf.so.6

[Bernhard Übelacker]

Hello David Grajal,
find the ldd output of ldd inside a up-to-date buster amd64 VM below.

So either your /usr/bin/PosteRazor does not match the
current debian packaged binary, or it loads some
shared object which has this dependency.

At least the version in Debian posterazor 1.5.1-2+b1 got built against
libopenexr22 2.2.0-11+b1 which just built a libIlmImf-2_2.so.22.0.0.

Kind regards,
Bernhard



root@debian:~# ldd /usr/bin/PosteRazor
linux-vdso.so.1 (0x7ffec0e92000)
libfltk.so.1.1 => /lib/x86_64-linux-gnu/libfltk.so.1.1 
(0x7f70fb296000)
libfltk_images.so.1.1 => /lib/x86_64-linux-gnu/libfltk_images.so.1.1 
(0x7f70fb285000)
libfreeimage.so.3 => /lib/x86_64-linux-gnu/libfreeimage.so.3 
(0x7f70fb1cd000)
libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x7f70fb08c000)
libXpm.so.4 => /lib/x86_64-linux-gnu/libXpm.so.4 (0x7f70fae7a000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f70facf6000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f70fab71000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f70fab57000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f70fa996000)
libXft.so.2 => /lib/x86_64-linux-gnu/libXft.so.2 (0x7f70fa78)
libfontconfig.so.1 => /lib/x86_64-linux-gnu/libfontconfig.so.1 
(0x7f70fa73a000)
libXinerama.so.1 => /lib/x86_64-linux-gnu/libXinerama.so.1 
(0x7f70fa735000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f70fa72e000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f70fa70d000)
libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 
(0x7f70fa6d4000)
libjpeg.so.62 => /lib/x86_64-linux-gnu/libjpeg.so.62 
(0x7f70fa46b000)
libjxrglue.so.0 => /lib/x86_64-linux-gnu/libjxrglue.so.0 
(0x7f70fa249000)
libopenjp2.so.7 => /lib/x86_64-linux-gnu/libopenjp2.so.7 
(0x7f70fa1f2000)
libraw.so.19 => /lib/x86_64-linux-gnu/libraw.so.19 (0x7f70fa10e000)
libtiff.so.5 => /lib/x86_64-linux-gnu/libtiff.so.5 (0x7f70fa08d000)
libwebpmux.so.3 => /lib/x86_64-linux-gnu/libwebpmux.so.3 
(0x7f70f9e83000)
libwebp.so.6 => /lib/x86_64-linux-gnu/libwebp.so.6 (0x7f70f9c1a000)
libIlmImf-2_2.so.23 => /lib/x86_64-linux-gnu/libIlmImf-2_2.so.23 
(0x7f70f9941000)
libHalf.so.23 => /lib/x86_64-linux-gnu/libHalf.so.23 
(0x7f70f96fe000)
libIex-2_2.so.23 => /lib/x86_64-linux-gnu/libIex-2_2.so.23 
(0x7f70f94dc000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f70f92be000)
libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x7f70f9294000)
/lib64/ld-linux-x86-64.so.2 (0x7f70fb5c2000)
libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6 
(0x7f70f91d8000)
libXrender.so.1 => /lib/x86_64-linux-gnu/libXrender.so.1 
(0x7f70f8fce000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 
(0x7f70f8f8f000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f70f8f86000)
libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 (0x7f70f8d74000)
libjpegxr.so.0 => /lib/x86_64-linux-gnu/libjpegxr.so.0 
(0x7f70f8b3e000)
liblcms2.so.2 => /lib/x86_64-linux-gnu/liblcms2.so.2 
(0x7f70f8ae1000)
libgomp.so.1 => /lib/x86_64-linux-gnu/libgomp.so.1 (0x7f70f8aae000)
libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x7f70f8a0e000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f70f89e6000)
libjbig.so.0 => /lib/x86_64-linux-gnu/libjbig.so.0 (0x7f70f87d8000)
libImath-2_2.so.23 => /lib/x86_64-linux-gnu/libImath-2_2.so.23 
(0x7f70f85c6000)
libIlmThread-2_2.so.23 => /lib/x86_64-linux-gnu/libIlmThread-2_2.so.23 
(0x7f70f83bd000)
libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x7f70f81b9000)
libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 
(0x7f70f7fb3000)
libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x7f70f7f99000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f70f7f8f000)

root@debian:~# dpkg -S libIlmImf-2_2.so.23
libopenexr23:amd64: /usr/lib/x86_64-linux-gnu/libIlmImf-2_2.so.23
libopenexr23:amd64: /usr/lib/x86_64-linux-gnu/libIlmImf-2_2.so.23.0.0

root@debian:~# dpkg -l | grep libopenexr
ii  libopenexr23:amd64 2.2.1-4.1amd64runtime files for the OpenEXR 
image library

root@debian:~# md5sum /usr/bin/PosteRazor
7b1e2b6d466776add9a94fd230ac9df1  /usr/bin/PosteRazor

https://buildd.debian.org/status/fetch.php?pkg=posterazor=amd64=1.5.1-2%2Bb1=1488894655=0

Bug#941125: xfce4-terminal: Multiple open windows; closing one by button; bash zombie

[Bernhard Übelacker]

Dear Maintainer,
I tried to have a look at this issue and could reproduce
it in a buster amd64 qemu VM.
But this is also observable with current Bullseye/testing.

This seems to be based on the fact that all xfce4-terminal
windows are owned by the same parent process.

I could observe if a second terminal window is closed by the
"X" in the window decoration then the xfce4-terminal process
does not receive a SIGCHLD for the bash process running inside
that window.
Therefore dispatch_unix_signals/waitpid is not executed which
causes the defunct process.

Further I think the issue lies inside libutempter0 which
is forking off a helper program and therefore temporarily
changes signal handling for SIGCHLD to SIG_DFL, and
therefore the signal seems to be lost. [1]

Attached patch tries to receive all SIGCHLD signals and
resend the unexpected ones after the original
signal handler is active again.
But it operates on a single static variable,
is therefore not thread safe, if it needs to be?

Kind regards,
Bernhard

[1] 
http://git.altlinux.org/people/ldv/packages/?p=libutempter.git;a=blob;f=libutempter/iface.c;hb=HEAD#l84

# Buster amd64 qemu VM 2020-08-22


apt update
apt dist-upgrade


apt install systemd-coredump xfce4 xterm xfce4-terminal psmisc mc colordiff 
fakeroot quilt git python3-pexpect gdb xfce4-terminal-dbgsym 
libvte-2.91-0-dbgsym libglib2.0-0-dbgsym libutempter0-dbgsym
apt build-dep xfce4-terminal
apt build-dep rr


reboot
echo 1 > /proc/sys/kernel/perf_event_paranoid



mkdir /home/benutzer/source/xfce4-terminal/orig -p
cd/home/benutzer/source/xfce4-terminal/orig
apt source xfce4-terminal
cd

mkdir /home/benutzer/source/libvte-2.91-0/orig -p
cd/home/benutzer/source/libvte-2.91-0/orig
apt source libvte-2.91-0
cd

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

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

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

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


#


export DISPLAY=:0
export SESSION_MANAGER=$(cat /proc/647/environ | tr '\0' '\12' | grep 
SESSION_MANAGER | sed 's/SESSION_MANAGER=//g')


/home/benutzer/source/rr/git/obj/bin/rr /usr/bin/xfce4-terminal


# Started one terminal

benutzer@debian:~$ pstree -p | grep xfce4-terminal -A3
|   
|-sshd(29466)---sshd(29472)---bash(29473)---rr(29618)-+-xfce4-terminal(29626)-+-bash(29630)
|   |   
  |   |-{xfce4-terminal}(29627)
|   |   
  |   `-{xfce4-terminal}(29628)


# Started second terminal window with one tab

benutzer@debian:~$ pstree -p | grep xfce4-terminal -A3
|   
|-sshd(29466)---sshd(29472)---bash(29473)---rr(29618)-+-xfce4-terminal(29626)-+-bash(29630)
|   |   
  |   |-bash(29653)
|   |   
  |   |-{xfce4-terminal}(29627)
|   |   
  |   |-{xfce4-terminal}(29628)
|   |   
  |   `-{xfce4-terminal}(29652)


# enter 'exit' in the second window

benutzer@debian:~$ ps aux | grep defunct | grep -v "grep defunct"
benutzer@debian:~$ 

-> does not show the problem


# Started third terminal window with one tab

benutzer@debian:~$ pstree -p | grep xfce4-terminal -A3
|   
|-sshd(29466)---sshd(29472)---bash(29473)---rr(29618)-+-xfce4-terminal(29626)-+-bash(29630)
|   |   
  |   |-bash(29671)
|   |   
  |   |-{xfce4-terminal}(29627)
|   |   
  |   |-{xfce4-terminal}(29628)
|   |   
  |   `-{xfce4-terminal}(29670)


# exit by pressing X in the window decoration

benutzer@debian:~$ ps aux | grep defunct | grep -v "grep defunct"
benutzer 29671  0.0  0.0  0 0 ?Zs   16:49   0:00 [bash] 


benutzer@debian:~$ pstree -p | grep xfce4-terminal -A3
|   
|-sshd(29466)---sshd(29472)---bash(29473)---rr(29618)-+-xfce4-terminal(29626)-+-bash(29630)
|   | 

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

[Bernhard Übelacker]

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

Kind regards,
Bernhard

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

[Bernhard Übelacker]

Hello Ronny,
sorry for the delay.
You wrote you recompiled - then I guess your build directory should
also contain the libcups2-dbgsym and cups-daemon-dbgsym packages.

If you still get this crash, could you install these dbgsym packages
from your build and recreate that backtrace in coredumpctl?
A 'bt full' could contain some details too.

Otherwise running cupsd within valgrind could also give some hints.


This bug might describe the same issue, unfortunately also without solution:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1846334
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1826648
https://marc.info/?l=openbsd-ports=157331902608071=2

Kind regards,
Bernhard


https://sources.debian.org/src/cups/2.3.3-2/cups/ipp.c/#L1729
https://sources.debian.org/src/cups/2.3.3-2/scheduler/client.c/#L2244

Bug#968787: No printer can be installed in cups

[Bernhard Übelacker]

Hello Karsten,

Am 21.08.20 um 18:21 schrieb Karsten:

>> Unfortunately I did not get the message
>> "Gesamte Anfrage zu gross" / "Request Entity Too Large".
> 
> Hmmm - there are many details not working in Debian 10.
> Maybe because this version has been upgraded.

>From which debian version did you upgrade to Debian 10?
Did the upgrade went through successfully?


>> - the relevant parts of /var/log/cups/error_log and
>> /var/log/cups/access_log
> 
> It seems that there is no logging.

Is journalctl -f giving some output, when started before
trying to access localhost:631 ?

Kind regards,
Bernhard

Bug#939256: gkrellm: transparent themes make gkrellm crash

[Bernhard Übelacker]

Dear Maintainer,
I tried to collect some more information about this issue
and could reproduce it (details in attached file).

It looks like this issue appears just when running
gkrellm within XFCE.
The issue also shows in current testing.

When switching gkrellm to the external downloadable
theme it shows this message:

The program 'gkrellm' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadPixmap (invalid Pixmap parameter)'.
  (Details: serial 6930 error_code 4 request_code 56 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Following that advice one comes to this backtrace:
(gdb) bt
#0  gdk_x_error (display=0x544a60, error=0xbfffe60c) at 
../../../../../gdk/x11/gdkmain-x11.c:458
#1  0xb71d7cbf in _XError (dpy=0x544a60, rep=0x65c920) at 
../../src/XlibInt.c:1491
#2  0xb71d496c in handle_error (dpy=dpy@entry=0x544a60, err=0x65c920, 
in_XReply=) at ../../src/xcb_io.c:199
#3  0xb71d4a17 in handle_response (dpy=dpy@entry=0x544a60, 
response=0x65c920, in_XReply=in_XReply@entry=1) at ../../src/xcb_io.c:324
#4  0xb71d5b0c in _XReply (dpy=0x544a60, rep=0xbfffe77c, extra=0, 
discard=1) at ../../src/xcb_io.c:634
#5  0xb71d115d in XSync (dpy=0x544a60, discard=0) at ../../src/Sync.c:44
#6  0xb71d11fa in _XSyncFunction (dpy=0x544a60) at ../../src/Synchro.c:35
#7  0xb71d03a7 in XSetTile (dpy=0x544a60, gc=0x681ea0, tile=989) at 
../../src/SetTile.c:44
#8  0x0049202c in gkrellm_winop_apply_rootpixmap_transparency () at 
winops-x11.c:735
#9  0x004330eb in gkrellm_build () at main.c:1941
...


The issue seems to be that XFCE "stores" a XID of a window
into "_XROOTPMAP_ID" instead of a XID of a Pixmap.

There is this Xfce upstream bug report:

   https://gitlab.xfce.org/xfce/xfdesktop/-/issues/62

Building a package xfdesktop with both patches shown in the
merge request applied, makes gkrellm be able to use such themes.

Kind regards,
Bernhard

# Bullseye/testing i386 qemu VM 2020-08-21


apt update
apt dist-upgrade


apt install systemd-coredump mc xfce4 git fakeroot gdb gkrellm gkrellm-dbgsym 
libgtk2.0-0-dbgsym libglib2.0-0-dbgsym libx11-6-dbgsym xserver-xorg-core-dbgsym
apt build-dep gkrellm
apt build-dep rr
apt build-dep xfdesktop4


reboot



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

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

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

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



mkdir /home/benutzer/source/rr/git -p
cd/home/benutzer/source/rr/git
git clone https://github.com/mozilla/rr.git
cd
cd /home/benutzer/source/rr/git/
mkdir obj && cd obj
cmake ../rr
make -j4




# login to xfce


export DISPLAY=:0
gkrellm
# quit




# http://www.muhri.net/gkrellm/nav.php3?node=gkrellmall=name
wget http://www.muhri.net/gkrellm/Glass.gkrellm.tar.gz

$ md5sum $HOME/Glass.gkrellm.tar.gz 
36dd204d9bf3b6dbb6e93795ace5e17d  /home/benutzer/Glass.gkrellm.tar.gz

cd $HOME/.gkrellm2/themes/
tar -zxf $HOME/Glass.gkrellm.tar.gz
cd




gkrellm
# switch themes by Shift+PgDown





benutzer@debian:~$ gkrellm
The program 'gkrellm' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadPixmap (invalid Pixmap parameter)'.
  (Details: serial 6930 error_code 4 request_code 56 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)





benutzer@debian:~$ gkrellm
The program 'gkrellm' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadPixmap (invalid Pixmap parameter)'.
  (Details: serial 6930 error_code 4 request_code 56 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
benutzer@debian:~$ gdb -q --args gkrellm --sync
Reading symbols from gkrellm...
(No debugging symbols found in gkrellm)
(gdb) set 

Bug#968787: No printer can be installed in cups

[Bernhard Übelacker]

Hello Karsten,
I am no involved in the packaging cups but I tried to
reproduce your cups issue inside a minimal VM.

Unfortunately I did not get the message
"Gesamte Anfrage zu gross" / "Request Entity Too Large".

Therefore it seems you need to supply some more informations like
- with which user you are authenticating against cups?
- have you done some cups configuration changes?
- the relevant parts of /var/log/cups/error_log and
/var/log/cups/access_log

Kind regards,
Bernhard

# Buster amd64 qemu VM 2020-08-21


apt update
apt dist-upgrade


apt install systemd-coredump sddm xserver-xorg mc task-kde-desktop 
task-german-kde-desktop firefox-esr-l10n-de task-print-server
apt build-dep cups


reboot


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





# login

# firefox

http://localhost:631

Administration
Add Printer

# Add Printer page is shown, no error message "Gesamte Anfrage zu gross"





benutzer@debian:~/source/cups/orig/cups-2.2.10$ grep "Gesamte Anfrage zu gross" 
. -Rn -B1
./locale/cups_de.po-4701-msgid "Request Entity Too Large"
./locale/cups_de.po:4702:msgstr "Gesamte Anfrage zu gross"

benutzer@debian:~/source/cups/orig/cups-2.2.10$ grep "Request Entity Too Large" 
. -Rn
./cups/http-support.c:1529:s = _("Request Entity Too Large");

benutzer@debian:~/source/cups/orig/cups-2.2.10$ cat -n ./cups/http-support.c | 
grep 1529 -C1
  1528  case HTTP_STATUS_REQUEST_TOO_LARGE :
  1529  s = _("Request Entity Too Large");
  1530  break;

benutzer@debian:~/source/cups/orig/cups-2.2.10$ grep 
HTTP_STATUS_REQUEST_TOO_LARGE . -Rn
./cups/request.c:1154:case HTTP_STATUS_REQUEST_TOO_LARGE :
./cups/http.h:271:  HTTP_STATUS_REQUEST_TOO_LARGE,  /* Request entity too 
large */
./cups/http.h:327:#define HTTP_REQUEST_TOO_LARGE
HTTP_STATUS_REQUEST_TOO_LARGE
./cups/http-support.c:1528:case HTTP_STATUS_REQUEST_TOO_LARGE :
...
./scheduler/client.c:1364:  if (!cupsdSendError(con, 
HTTP_STATUS_REQUEST_TOO_LARGE, CUPSD_AUTH_NONE))
./scheduler/client.c:1541:  if (!cupsdSendError(con, 
HTTP_STATUS_REQUEST_TOO_LARGE, CUPSD_AUTH_NONE))
./scheduler/client.c:1578:if (!cupsdSendError(con, 
HTTP_STATUS_REQUEST_TOO_LARGE, CUPSD_AUTH_NONE))
./scheduler/client.c:1789:  if (!cupsdSendError(con, 
HTTP_STATUS_REQUEST_TOO_LARGE, CUPSD_AUTH_NONE))
./scheduler/client.c:1807:  if (!cupsdSendError(con, 
HTTP_STATUS_REQUEST_TOO_LARGE, CUPSD_AUTH_NONE))
./scheduler/client.c:1843:if (!cupsdSendError(con, 
HTTP_STATUS_REQUEST_TOO_LARGE, CUPSD_AUTH_NONE))
./scheduler/client.c:1929:if (!cupsdSendError(con, 
HTTP_STATUS_REQUEST_TOO_LARGE, CUPSD_AUTH_NONE))
./scheduler/client.c:1969:if (!cupsdSendError(con, 
HTTP_STATUS_REQUEST_TOO_LARGE, CUPSD_AUTH_NONE))
./scheduler/client.c:1987:  if (!cupsdSendError(con, 
HTTP_STATUS_REQUEST_TOO_LARGE,
./scheduler/client.c:2038:  if (!cupsdSendError(con, 
HTTP_STATUS_REQUEST_TOO_LARGE, CUPSD_AUTH_NONE))
./doc/help/cupspm.html:6150:HTTP_STATUS_REQUEST_TOO_LARGE  
   Request entity too large

Bug#940804: libglib-2.0-0: Pidgin sigabrts when trying a new connection (IRC)

[Bernhard Übelacker]

Dear Maintainer,
the attached file in message #5 contains
a backtrace with this part [1].

I am quite sure that the call to __fdelt_chk in g_spawn_sync is
at this source location [2] in gspawn.c line 442.

Because __fdelt_chk checks if the fd outpipe is either
negative or below FD_SETSIZE, and outpipe is just checked
before to be greater or equal to zero, I would assume that
this process did run out of file descriptors.

If that is really the case might be visible if one checks
the output of 'lsof | grep $(pidof pidgin)'.

Upstream glib has fixed this FD_SETSIZE limitation in [4].
The last link shows a backtrace with the same
g_spawn_sync/__fdelt_chk combination.
Therefore I would assume current testing should not show this fault.

Kind regards,
Bernhard


[1]
...
#5  0x7fe1c2aca940 in __GI___chk_fail () at chk_fail.c:28
#6  0x7fe1c2acc737 in __fdelt_chk (d=) at fdelt_chk.c:25
#7  0x7fe1c2f021c5 in g_spawn_sync () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#8  0x7fe1c2f02997 in g_spawn_command_line_sync () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#9  0x7fe1c2db1794 in purple_gnome_proxy_get_parameter 
(parameter=parameter@entry=0 '\000', gnome_version=gnome_version@entry=1 
'\001') at ././libpurple/proxy.c:270
#10 0x7fe1c2db1e2b in purple_gnome_proxy_get_parameter 
(gnome_version=, parameter=0 '\000') at ././libpurple/proxy.c:307
...

[2]
(gdb) list gspawn.c:360,450
...
440   FD_ZERO ();
441   if (outpipe >= 0)
442 FD_SET (outpipe, ); 
443   if (errpipe >= 0)
444 FD_SET (errpipe, );
...
https://sources.debian.org/src/glib2.0/2.58.3-2+deb10u2/glib/gspawn.c/#L442

[3]
long int
__fdelt_chk (long int d)
{
  if (d < 0 || d >= FD_SETSIZE)
__chk_fail ();

  return d / __NFDBITS;
}

[4]
https://gitlab.gnome.org/GNOME/glib/-/issues/954

https://gitlab.gnome.org/GNOME/glib/-/commit/a7242d4a5e5e5875699bcff2749beac19864943b
https://gitlab.gnome.org/GNOME/glib/-/issues/2079

# Buster/stable amd64 qemu VM 2020-08-20


apt update
apt dist-upgrade


apt install systemd-coredump sddm xserver-xorg openbox xterm mc dpkg-dev 
devscripts gdb pidgin


reboot


cat /proc/sys/kernel/randomize_va_space
echo 0 > /proc/sys/kernel/randomize_va_space


wget 
https://snapshot.debian.org/archive/debian/20190822T033017Z/pool/main/g/glib2.0/libglib2.0-data_2.58.3-2%2Bdeb10u1_all.deb
wget 
https://snapshot.debian.org/archive/debian/20190822T033017Z/pool/main/g/glib2.0/libglib2.0-0_2.58.3-2%2Bdeb10u1_amd64.deb
wget 
https://snapshot.debian.org/archive/debian-debug/20190928T162431Z/pool/main/g/glib2.0/libglib2.0-0-dbgsym_2.58.3-2%2Bdeb10u1_amd64.deb
dpkg -i *.deb


mkdir /home/benutzer/source/libglib2.0-0/orig -p
cd/home/benutzer/source/libglib2.0-0/orig
dget 
https://snapshot.debian.org/archive/debian/20190821T220217Z/pool/main/g/glib2.0/glib2.0_2.58.3-2%2Bdeb10u1.dsc
cd

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

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


export DISPLAY=:0
pidgin


gdb -q --pid $(pidof pidgin)

set width 0
set pagination off
directory /home/benutzer/source/libglib2.0-0/orig/glib2.0-2.58.3/glib
disassemble g_spawn_sync
b *0x771221c0


(gdb) b *0x771221c0
Breakpoint 1 at 0x771221c0: file ../../../glib/gspawn.c, line 442.

(gdb) list gspawn.c:360,450
360 gboolean
361 g_spawn_sync (const gchar  *working_directory,
362   gchar   **argv,
363   gchar   **envp,
364   GSpawnFlags   flags,
365   GSpawnChildSetupFunc  child_setup,
366   gpointer  user_data,
367   gchar   **standard_output,
368   gchar   **standard_error,
369   gint *exit_status,
370   GError  **error) 
371 {
372   gint outpipe = -1;
373   gint errpipe = -1;
374   GPid pid;
375   fd_set fds;
376   gint ret;
377   GString *outstr = NULL;
378   GString *errstr = NULL;
379   gboolean failed;
380   gint status;
381   
382   g_return_val_if_fail (argv != NULL, FALSE);
383   g_return_val_if_fail (!(flags & G_SPAWN_DO_NOT_REAP_CHILD), FALSE);
384   g_return_val_if_fail (standard_output == NULL ||
385 !(flags & G_SPAWN_STDOUT_TO_DEV_NULL), FALSE);
386   g_return_val_if_fail (standard_error == NULL ||
387 !(flags & G_SPAWN_STDERR_TO_DEV_NULL), FALSE);
388   
389   /* Just to ensure segfaults if callers try to use
390* these when an error is reported.
391*/
392   if (standard_output)
393 *standard_output 

Bug#968686: rr: doesn't work on newer libcs because of crash in clock_getres

[Bernhard Übelacker]

Package: rr
Version: 5.3.0-2
Severity: normal
Tags: upstream fixed-upstream


Dear Maintainer,
while investigating a different bug I found rr failed for
me inside a current testing VM inside a call to clock_getres,
while inside a similar stable VM it succeeds.

I think this got reported and fixed upstream already in [1].
There it was explained by newer libc versions now
using VDSO for clock_getres.

A build from rr git head yesterday was working in testing.
Unfortunately there was not yet a new release containing that fix.

Kind regards,
Bernhard

[1] https://github.com/mozilla/rr/issues/2428

# Bullseye/testing amd64 qemu VM 2020-08-19


apt update
apt dist-upgrade


apt install systemd-coredump gdb rr coreutils-dbgsym


echo 1 > /proc/sys/kernel/perf_event_paranoid


cat < /tmp/test.py
import time
clk_id1 = time.CLOCK_REALTIME
precision1 = time.clock_getres(clk_id1)
print("Precision of system-wide real-time clock:", precision1)
EOF

/usr/bin/rr /usr/bin/python3.8 /tmp/test.py

/usr/bin/rr replay /root/.local/share/rr/python3.8-1



root@debian:~# /usr/bin/rr /usr/bin/python3.8 /tmp/test.py
rr: Saving execution to trace directory `/root/.local/share/rr/python3.8-1'.
Speicherzugriffsfehler
root@debian:~# /usr/bin/rr replay /root/.local/share/rr/python3.8-1
GNU gdb (Debian 9.2-1) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from 
/root/.local/share/rr/python3.8-1/mmap_hardlink_3_python3.8...
(No debugging symbols found in 
/root/.local/share/rr/python3.8-1/mmap_hardlink_3_python3.8)
Really redefine built-in command "restart"? (y or n) [answered Y; input not 
from terminal]
Remote debugging using 127.0.0.1:991
Reading symbols from /lib64/ld-linux-x86-64.so.2...
Reading symbols from 
/usr/lib/debug/.build-id/63/7706dbbbd112d03fbad61ca30125b48e60aa92.debug...
0x7fbd57400090 in _start () from /lib64/ld-linux-x86-64.so.2
(rr) cont
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x7ffeb81f9d25 in clock_getres ()
(rr) bt
#0  0x7ffeb81f9d25 in clock_getres ()
#1  0x7fbd5710bb91 in __clock_getres (clock_id=0, res=0x7ffeb81f3760) at 
../sysdeps/unix/sysv/linux/clock_getres.c:37
#2  0x004c1c72 in ?? ()
#3  0x00520ed6 in PyCFunction_Call ()
#4  0x00510243 in _PyObject_MakeTpCall ()
#5  0x0050a847 in _PyEval_EvalFrameDefault ()
#6  0x00503b25 in _PyEval_EvalCodeWithName ()
#7  0x005ce503 in PyEval_EvalCode ()
#8  0x005ec461 in ?? ()
#9  0x005e7a5f in ?? ()
#10 0x005f0377 in PyRun_FileExFlags ()
#11 0x005efdb0 in PyRun_SimpleFileExFlags ()
#12 0x005e4f45 in Py_RunMain ()
#13 0x005c3899 in Py_BytesMain ()
#14 0x7fbd5706ccca in __libc_start_main (main=0x5c3860 , argc=2, 
argv=0x7ffeb81f3d28, init=, fini=, 
rtld_fini=, stack_end=0x7ffeb81f3d18)
at ../csu/libc-start.c:308
#15 0x005c379a in _start ()
(rr) disassemble
Dump of assembler code for function clock_getres:
   0x7ffeb81f9d10 <+0>: cmp$0xf,%edi
   0x7ffeb81f9d13 <+3>: ja 0x7ffeb81f9d65 
   0x7ffeb81f9d15 <+5>: lea-0x4c9c(%rip),%rax# 
0x7ffeb81f5080
   0x7ffeb81f9d1c <+12>:lea-0x1ca3(%rip),%rdx# 
0x7ffeb81f8080
   0x7ffeb81f9d23 <+19>:mov%edi,%ecx
=> 0x7ffeb81f9d25 <+21>:cmpl   $0x7fff,-0x4cab(%rip)# 
0x7ffeb81f5084
   0x7ffeb81f9d2f <+31>:cmovne %rax,%rdx
   0x7ffeb81f9d33 <+35>:mov$0x1,%eax
   0x7ffeb81f9d38 <+40>:shl%cl,%eax
   0x7ffeb81f9d3a <+42>:test   $0x893,%eax
   0x7ffeb81f9d3f <+47>:jne0x7ffeb81f9d5d 
   0x7ffeb81f9d41 <+49>:test   $0x60,%al
   0x7ffeb81f9d43 <+51>:je 0x7ffeb81f9d65 
   0x7ffeb81f9d45 <+53>:mov$0x3d0900,%eax
   0x7ffeb81f9d4a <+58>:test   %rsi,%rsi
   0x7ffeb81f9d4d <+61>:je 0x7ffeb81f9d6d 
   0x7ffeb81f9d4f <+63>:mov%rax,0x8(%rsi)
   0x7ffeb81f9d53 <+67>:xor%eax,%eax
   0x7ffeb81f9d55 <+69>:movq   $0x0,(%rsi)
   0x7ffeb81f9d5c <+76>:retq   
   0x7ffeb81f9d5d <+77>:mov0xe8(%rdx),%eax
   0x7ffeb81f9d63 <+83>:jmp0x7ffeb81f9d4a 
   0x7ffeb81f9d65 <+85>:mov$0xe5,%eax
   0x7ffeb81f9d6a <+90>:syscall 
   0x7ffeb81f9d6c <+92>:retq   
   0x7ffeb81f9d6d <+93>: 

Bug#968606: CVE assignment request for NULL-dereference segfault

[Bernhard Übelacker]

Hello Max, hello Simon,
after some sleep I thought why this next variable gets assigned
that soon ... so I tested following patch, which just moves the
assignment to below the process call, and I could not reproduce
the crash in some guake restarts.

If this is enough, or if the garbage collector might attempt to
destroy the that too at some point I cannot say.

Kind regards,
Bernhard




--- vte2.91-0.60.3.orig/src/vte.cc
+++ vte2.91-0.60.3/src/vte.cc
@@ -10509,14 +10509,14 @@ update_repeat_timeout (gpointer data)
for (l = g_active_terminals; l != NULL; l = next) {
auto that = reinterpret_cast(l->data);
 
-next = l->next;
-
if (l != g_active_terminals) {
_vte_debug_print (VTE_DEBUG_WORK, "T");
}
 
 that->process(true);
 
+next = l->next;
+
again = that->invalidate_dirty_rects_and_process_updates();
if (!again) {
 remove_from_active_list(that);

Bug#968606: CVE assignment request for NULL-dereference segfault

[Bernhard Übelacker]

Hello Max, hello Simon,
I thought this issue might be a case for mozilla/rr, a time-travel-debugger.
It allows record a process and then replay that process forward and backward
inside a debugger.

And the segfault was reproducible within rr.

Attached file contains some notes about my test environment and
the second half a replay of a crashed process.


In that session I forward to the crash:

Thread 1 received signal SIGSEGV, Segmentation fault.
vte::terminal::Terminal::process (this=this@entry=0x22e5020, ...) at 
../src/vtetypes.hh:221
221 inline constexpr operator int () const noexcept { 
return m_fd; }
(rr) bt
#0  vte::terminal::Terminal::process(bool) (this=this@entry=0x22e5020, ...) 
at ../src/vtetypes.hh:221
#1  0x7f1397281c61 in vte::terminal::update_repeat_timeout(gpointer) 
(...) at ../src/vte.cc:10518
...


Then I rewind back to the begin of "vte::terminal::update_repeat_timeout".

When iterating through the for loop and watching the g_active_terminals
in 10518 the second and some more elements disappeared.
Unfortunately our next variable still points to it ...


Before:
1: g_active_terminals = 0x22c9c40 = {0x331, 0x3291000, 0x3226a50, 
0x31b, 0x3143630, 0x30c8000, 0x305dad0, 0x2bd9800, 0x2bd2000, 0x2ad9980, 
0x2742c00, 0x281, ...}
^ 
^ ^ ^ ^ 
^

10518   that->process(true);

After:
1: g_active_terminals = 0x22c9c40 = {0x331, 0x3226a50, 0x3143630, 
0x305dad0, 0x2bd2000, 0x2742c00, 0x28ef800, 0x2a14000, 0x26212f0, 0x2f0f400, 
0x2ea6f60, 0x2e29000, ...}


Then a reverse-next and a watchpoint to the next->data pointer
and I receive the backtrace in [1].

That would point to a garbage collector run, while we are in
the loop and holding elements in the next variable that get deleted?
Could that be the case?

Kind regards,
Bernhard


(rr) list vte.cc:10495,10525
10495
10496   static gboolean
10497   update_repeat_timeout (gpointer data)
10498   {
10499   GList *l, *next;
10500   bool again;
10501
10502   in_update_timeout = TRUE;
10503
10504   _vte_debug_print (VTE_DEBUG_WORK, "[");
10505   _vte_debug_print (VTE_DEBUG_TIMEOUT,
10506 "Repeat timeout:  %d active\n",
10507 g_list_length(g_active_terminals));
10508
10509   for (l = g_active_terminals; l != NULL; l = next) {
10510   auto that = 
reinterpret_cast(l->data);
10511
10512   next = l->next;
10513
10514   if (l != g_active_terminals) {
10515   _vte_debug_print (VTE_DEBUG_WORK, "T");
10516   }
10517
10518   that->process(true);
10519
10520   again = 
that->invalidate_dirty_rects_and_process_updates();
10521   if (!again) {
10522   remove_from_active_list(that);
10523   }
10524   }
10525



[1]
(rr) bt
#0  thread_memory_magazine2_free (tmem=0x1d06770, mem=0x22c6a80, ix=) at ../../../glib/gslice.c:856
#1  g_slice_free1 (mem_size=, mem_block=0x22c6a80) at 
../../../glib/gslice.c:1121
#2  0x7f139a5bee3a in g_list_delete_link (list=0x22c9c40 = {...}, 
link_=0x22c6a80 = {...}) at ../../../glib/glist.c:687
#3  0x7f139726f63c in 
vte::terminal::remove_from_active_list(vte::terminal::Terminal*, 
vte::terminal::Terminal*) (that=, that=) at 
../src/vte.cc:10193
#4  0x7f139726f717 in 
vte::terminal::stop_processing(vte::terminal::Terminal*) (that=) 
at ../src/vte.cc:10201
#5  0x7f139727fcca in vte::terminal::Terminal::unset_pty(bool) 
(this=this@entry=0x3291000, notify_widget=notify_widget@entry=false) at 
../src/vte.cc:10057
#6  0x7f1397286187 in vte::terminal::Terminal::~Terminal() (this=0x3291000, 
__in_chrg=) at ../src/vte.cc:8047
#7  0x7f13972a4838 in vte::platform::Widget::~Widget() (this=0x30c7780, 
__in_chrg=) at ../src/widget.cc:126
#8  0x7f139728d823 in vte_terminal_finalize(GObject*) (object=0x30c7930 
[guake+terminal+GuakeTerminal]) at ../src/vtegtk.cc:429
#9  0x7f139a52d09e in g_object_unref (_object=) at 
../../../gobject/gobject.c:3499
#10 g_object_unref (_object=0x30c7930) at ../../../gobject/gobject.c:3391
#11 0x7f139a6cb8b2 in pygobject_clear (self=self@entry=0x7f138e74c580) at 
gi/pygobject-object.c:1240
#12 0x004f4e62 in subtype_clear (self=) at 
../Objects/typeobject.c:1147
#13 delete_garbage (state=, old=, 
collectable=0x7ffe53e6b6b0) at ../Modules/gcmodule.c:948
#14 collect.constprop.0 (generation=0, n_collected=0x7ffe53e6b780, 
n_uncollectable=0x7ffe53e6b788, nofail=0, state=) at 
../Modules/gcmodule.c:1123
#15 0x005ca15a in collect_with_callback.constprop.0 
(generation=generation@entry=0, state=) at 
../Modules/gcmodule.c:1240
#16 0x005219d9 

Bug#950646: sane-utils: saned does not work if starteed via systemd

[Bernhard Übelacker]

Hello Stefan, hello Patrick,
I am not specifically involved in packaging sane but tried
to reproduce your issue.

These were the steps I tested:
- systemctl enable saned.socket
- systemctl start saned.socket
- activated the backend "test" in /etc/sane.d/dll.conf 
- added the "remote" server localhost to /etc/sane.d/net.conf
- listed scanners with "scanimage -L"
- made a test scan with "scanimage --device-name=net:localhost:test:0 > 
testscan"

As far as I see this worked as exepected, so your issue might be
related to the backend you are using.
Unfortunately the information which backend you need is
not included in your reports.

Also you might make the output more verbose by
- adding "SANE_DEBUG_DLL=255" to the Environment
  line in /lib/systemd/system/saned@.service
- reload that change by "systemctl daemon-reload"
- test again.

Kind regards,
Bernhard

# Buster/stable amd64 qemu VM 2020-08-18


apt update
apt dist-upgrade


apt install systemd-coredump net-tools mc sane-utils



root@debian:~# systemctl status saned
● saned.service
Loaded: masked (Reason: Unit saned.service is masked.)
Active: inactive (dead)


root@debian:~# systemctl start saned
Failed to start saned.service: Unit saned.service is masked.


root@debian:~# systemctl status saned.socket 
● saned.socket - saned incoming socket
Loaded: loaded (/lib/systemd/system/saned.socket; disabled; vendor 
preset: enabled)
Active: inactive (dead)
Listen: [::]:6566 (Stream)
Accepted: 0; Connected: 0;


root@debian:~# systemctl enable saned.socket
Created symlink /etc/systemd/system/sockets.target.wants/saned.socket → 
/lib/systemd/system/saned.socket.


root@debian:~# systemctl status saned.socket 
● saned.socket - saned incoming socket
Loaded: loaded (/lib/systemd/system/saned.socket; enabled; vendor 
preset: enabled)
Active: inactive (dead)
Listen: [::]:6566 (Stream)
Accepted: 0; Connected: 0;


root@debian:~# systemctl start saned.socket 


root@debian:~# netstat -anp | grep 6566
tcp6   0  0 :::6566 :::*
LISTEN  1/init  


root@debian:~# systemctl status saned.socket 
● saned.socket - saned incoming socket
Loaded: loaded (/lib/systemd/system/saned.socket; enabled; vendor 
preset: enabled)
Active: active (listening) since Tue 2020-08-18 10:54:43 CEST; 3min 38s 
ago
Listen: [::]:6566 (Stream)
Accepted: 0; Connected: 0;
Tasks: 0 (limit: 3565)
Memory: 52.0K
CGroup: /system.slice/saned.socket

Aug 18 10:54:43 debian systemd[1]: Listening on saned incoming socket.


root@debian:~# systemctl status saned.service 
● saned.service
Loaded: masked (Reason: Unit saned.service is masked.)
Active: inactive (dead)




root@debian:~# echo localhost >> /etc/sane.d/net.conf


benutzer@debian:~$ scanimage -L

root@debian:~# journalctl -f

Aug 18 10:59:49 debian systemd[1]: Created slice system-saned.slice.
Aug 18 10:59:49 debian systemd[1]: Started Scanner Service 
([::1]:49780).
Aug 18 10:59:49 debian saned[2553]: saned (AF-indep+IPv6+systemd) from 
sane-backends 1.0.27 starting up
Aug 18 10:59:49 debian saned[2553]: check_host: access by remote host: 
::1
Aug 18 10:59:49 debian saned[2553]: init: access granted to benutzer@::1
Aug 18 10:59:53 debian saned[2553]: saned exiting
Aug 18 10:59:53 debian systemd[1]: saned@0-::1:6566-::1:49780.service: 
Succeeded.



root@debian:/etc/sane.d# sed -i 's/#test/test/g' /etc/sane.d/dll.conf 



benutzer@debian:~$ scanimage -L
device `test:0' is a Noname frontend-tester virtual device
device `test:1' is a Noname frontend-tester virtual device
device `net:localhost:test:0' is a Noname frontend-tester virtual device
device `net:localhost:test:1' is a Noname frontend-tester virtual device

Aug 18 11:06:20 debian systemd[1]: Started Scanner Service 
([::1]:49784).
Aug 18 11:06:20 debian saned[2935]: saned (AF-indep+IPv6+systemd) from 
sane-backends 1.0.27 starting up
Aug 18 11:06:20 debian saned[2935]: check_host: access by remote host: 
::1
Aug 18 11:06:20 debian saned[2935]: init: access granted to benutzer@::1
Aug 18 11:06:25 debian saned[2935]: saned exiting
Aug 18 11:06:25 debian systemd[1]: saned@1-::1:6566-::1:49784.service: 
Succeeded.



root@debian:/etc/sane.d# mc -e /lib/systemd/system/saned@.service
-Environment=SANE_CONFIG_DIR=/etc/sane.d
-# Environment=SANE_CONFIG_DIR=/etc/sane.d SANE_DEBUG_DLL=255
+# Environment=SANE_CONFIG_DIR=/etc/sane.d
+Environment=SANE_CONFIG_DIR=/etc/sane.d SANE_DEBUG_DLL=255

root@debian:/etc/sane.d# systemctl daemon-reload




benutzer@debian:~$ scanimage --device-name=net:localhost:test:0 > testscan

Aug 18 11:23:10 debian systemd[1]: Started 

Bug#964162: trousers: tcsd segfault crash when dns server is not available

[Bernhard Übelacker]

Hello Novak Frantisek,
I am just trying to reproduce crashes on random packages,
so I tried on this bug report, too. But I was not able
to come anywhere near the crash you are describing.

You might want to add some more information to that report,
about which TPM version you have 'dmesg | grep -i tpm',
and maybe some details how you did integrate trousers+tpmtools
into your initramfs.

You might also be able to retrieve the crash line
and the following code line from dmesg?

Kind regards,
Bernhard

Bug#967082: grub-customizer: dmesg has error info:segfault at 50 ip 0000558a7f3024e1

[Bernhard Übelacker]

Dear Maintainer,
I tried to have a look, but can just tell the location,
the dmesg output points to, is the following location.
And at this point the register rdi contains the value of "this",
at the submitters system 0x50, therefore causing the segfault.

Maybe install debug symbols and running at submitters system
inside valgrind could give some more pointers ... [1].

Kind regards,
Bernhard


Thread 1 "grub-customizer" hit Breakpoint 1, 
Trait_ActionLoggerAware::logActionBegin (action="update-timeout-setting", 
this=0x55f619eb7680) at 
./src/main/../Controller/Common/../../lib/Trait/ActionLoggerAware.hpp:42
42  
this->logger->logActionBegin(this->_controllerName, action);
1: x/i $pc
=> 0x55f6199c94e1 :
mov(%rdi),%rax
(gdb) bt
#0  0x55f6199c94e1 in 
Trait_ActionLoggerAware::logActionBegin(std::__cxx11::basic_string, std::allocator > const&) const 
(action="update-timeout-setting", this=0x55f619eb7680) at 
./src/main/../Controller/Common/../../lib/Trait/ActionLoggerAware.hpp:42
#1  0x55f6199c94e1 in SettingsController::updateTimeoutSettingAction() 
(this=0x55f619eb7680) at ./src/main/../Controller/SettingsController.hpp:285
...

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


# Buster/stable amd64 qemu VM 2020-08-16


apt update
apt dist-upgrade


apt install systemd-coredump sddm xserver-xorg openbox xterm mc gdb 
grub-customizer grub-customizer-dbgsym
apt build-dep grub-customizer



mkdir /home/benutzer/source/grub-customizer/orig -p
cd/home/benutzer/source/grub-customizer/orig
apt source grub-customizer
cd



export DISPLAY=:0
export XAUTHORITY=/home/benutzer/.Xauthority
export LANG=zh_CN.utf8

grub-customizer




echo -n "find /b ..., ..., 0x" && \
echo "00 48 89 84 24 98 00 00 00 31 c0 48 8d 6c 24 40 48 8d 45 10 48 89 ef 48 
89 44 24 40 e8 e8 bb fa ff 48 8b 7b 08 48 85 ff 74 0d <48> 8b 07 48 8d 73 18 48 
89 ea ff 50 18 48 8b 7c 24 40 48 8d 45 10" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'

find /b ..., ..., 0x00, 0x48, 0x89, 0x84, 0x24, 0x98, 0x00, 0x00, 0x00, 0x31, 
0xc0, 0x48, 0x8d, 0x6c, 0x24, 0x40, 0x48, 0x8d, 0x45, 0x10, 0x48, 0x89, 0xef, 
0x48, 0x89, 0x44, 0x24, 0x40, 0xe8, 0xe8, 0xbb, 0xfa, 0xff, 0x48, 0x8b, 0x7b, 
0x08, 0x48, 0x85, 0xff, 0x74, 0x0d, 0x48, 0x8b, 0x07, 0x48, 0x8d, 0x73, 0x18, 
0x48, 0x89, 0xea, 0xff, 0x50, 0x18, 0x48, 0x8b, 0x7c, 0x24, 0x40, 0x48, 0x8d, 
0x45, 0x10



gdb -q --pid $(pidof grub-customizer)

(gdb) directory /home/benutzer/source/grub-customizer/orig/grub-customizer-5.1.0

(gdb) info target
Entry point: 0x560dab1723e0
0x55f6198a82a8 - 0x55f6198a82c4 is .interp
...
0x55f619a9d0e0 - 0x55f619a9d230 is .bss
0x7ffb4989d238 - 0x7ffb4989d25c is .note.gnu.build-id in 
/lib/x86_64-linux-gnu/libgtkmm-3.0.so.1
...

(gdb) find /b 0x55f6198a82a8, 0x55f619a9d230, 0x00, 0x48, 0x89, 0x84, 
0x24, 0x98, 0x00, 0x00, 0x00, 0x31, 0xc0, 0x48, 0x8d, 0x6c, 0x24, 0x40, 0x48, 
0x8d, 0x45, 0x10, 0x48, 0x89, 0xef, 0x48, 0x89, 0x44, 0x24, 0x40, 0xe8, 0xe8, 
0xbb, 0xfa, 0xff, 0x48, 0x8b, 0x7b, 0x08, 0x48, 0x85, 0xff, 0x74, 0x0d, 0x48, 
0x8b, 0x07, 0x48, 0x8d, 0x73, 0x18, 0x48, 0x89, 0xea, 0xff, 0x50, 0x18, 0x48, 
0x8b, 0x7c, 0x24, 0x40, 0x48, 0x8d, 0x45, 0x10
0x55f6199c94b7 
1 pattern found.

(gdb) b * (0x55f6199c94b7 + 42)
Breakpoint 2 at 0x560dab1ee4e1: file 
./src/main/../Controller/Common/../../lib/Trait/ActionLoggerAware.hpp, line 42.
(gdb) cont

(gdb) cont
Continuing.
[Thread 0x7ffb43244700 (LWP 19172) exited]
[New Thread 0x7ffb43244700 (LWP 19174)]

Thread 1 "grub-customizer" hit Breakpoint 1, 
Trait_ActionLoggerAware::logActionBegin (action="update-timeout-setting", 
this=0x55f619eb7680)
at ./src/main/../Controller/Common/../../lib/Trait/ActionLoggerAware.hpp:42
42  
this->logger->logActionBegin(this->_controllerName, action);
1: x/i $pc
=> 0x55f6199c94e1 :
mov(%rdi),%rax
(gdb) set width 0
(gdb) set pagination off
(gdb) bt
#0  0x55f6199c94e1 in 
Trait_ActionLoggerAware::logActionBegin(std::__cxx11::basic_string, std::allocator > const&) const 
(action="update-timeout-setting", this=0x55f619eb7680) at 
./src/main/../Controller/Common/../../lib/Trait/ActionLoggerAware.hpp:42
#1  0x55f6199c94e1 in SettingsController::updateTimeoutSettingAction() 
(this=0x55f619eb7680) at ./src/main/../Controller/SettingsController.hpp:285
#2  0x7ffb49793dc8 in 
Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*) () at 
/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
#3  0x7ffb495bdc8d in g_closure_invoke () at 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#4  0x7ffb495d0e64 in  () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#5  0x7ffb495da2be in g_signal_emit_valist () at 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#6  0x7ffb495da97f in g_signal_emit () at 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#7  0x7ffb487a5fc0 in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#8  

Bug#968106: [Debian-on-mobile-maintainers] Bug#968106: phosh: Shell doesn't start

[Bernhard Übelacker]

Hello Michel Le Bihan,
found this issue interesting and tried to get more information.

First the "trap int3" originates from here [1], and seems just
a consequence of missing packages.

When installing following packages the user interface
could successfully start, without changing the VM vga "hardware".

  systemctl stop phosh
  apt update
  apt install --no-install-recommends --no-install-suggests gnome-session-bin 
libglib2.0-bin gnome-settings-daemon policykit-1 phosh-osk-stub
  systemctl start phosh

Kind regards,
Bernhard


[1]
(gdb) bt
#0  _g_log_abort (breakpoint=1) at ../../../glib/gmessages.c:554
#1  0x7f161ac595f5 in g_log_default_handler 
(log_domain=log_domain@entry=0x55b43a8e7164 "phoc-server", 
log_level=log_level@entry=6, message=message@entry=0x55b43b7dc1d0 "Could not 
create backend", unused_data=unused_data@entry=0x0) at ../../..
/glib/gmessages.c:3123
#2  0x7f161ac5983c in g_logv (log_domain=0x55b43a8e7164 "phoc-server", 
log_level=G_LOG_LEVEL_ERROR, format=, 
args=args@entry=0x7ffdc3657270) at ../../../glib/gmessages.c:1350
#3  0x7f161ac59a1f in g_log (log_domain=log_domain@entry=0x55b43a8e7164 
"phoc-server", log_level=log_level@entry=G_LOG_LEVEL_ERROR, 
format=format@entry=0x55b43a8e7170 "Could not create backend") at 
../../../glib/gmessages.c:1415
#4  0x55b43a8d1502 in phoc_server_constructed (object=0x55b43b7d8010) 
at ../src/server.c:139
#5  0x7f161ad41704 in g_object_new_internal 
(class=class@entry=0x55b43b7d7b70, params=params@entry=0x0, 
n_params=n_params@entry=0) at ../../../gobject/gobject.c:1977
#6  0x7f161ad42f0d in g_object_new_with_properties 
(object_type=94232580553008, n_properties=0, names=names@entry=0x0, 
values=values@entry=0x0) at ../../../gobject/gobject.c:2105
#7  0x7f161ad43961 in g_object_new (object_type=, 
first_property_name=first_property_name@entry=0x0) at 
../../../gobject/gobject.c:1777
#8  0x55b43a8d17ed in phoc_server_get_default () at ../src/server.c:212
#9  0x55b43a8d0f89 in main (argc=, argv=) 
at ../src/main.c:131

# Bullseye/testing amd64 qemu VM 2020-08-16


apt update
apt dist-upgrade


apt install systemd-coredump mmdebstrap squashfs-tools sddm xserver-xorg 
openbox xterm mc qemu-system-x86


su -
mkdir /home/benutzer/test
cd/home/benutzer/test

mmdebstrap --include=linux-image-amd64,live-boot,xserver-xorg-video-all,phosh 
--arch amd64 sid debian-live-root 
http://192.168.178.25:/debian-11-bullseye-deb.debian.org/


root@debian:/home/benutzer/test# mmdebstrap 
--include=linux-image-amd64,live-boot,xserver-xorg-video-all,phosh --arch amd64 
sid debian-live-root 
http://192.168.178.25:/debian-11-bullseye-deb.debian.org/
I: automatically chosen mode: root
I: chroot architecture amd64 is equal to the host's architecture
I: running apt-get update...
done
I: downloading packages with apt...
done
I: extracting archives...
done
I: installing packages...
done
I: downloading apt...
done
I: installing apt...
done
I: installing remaining packages inside the chroot...
done
I: cleaning package lists and apt cache...
done
done


chroot debian-live-root passwd
chroot debian-live-root useradd -m -s /bin/bash -p $(openssl passwd -1 123456) 
user
chroot debian-live-root systemctl enable phosh
cp debian-live-root/vmlinuz .
cp debian-live-root/initrd.img .
mksquashfs debian-live-root root.squashfs -comp lz4
exit

cd /home/benutzer/test
python3 -m http.server -b localhost 8080

cd /home/benutzer/test
export DISPLAY=:0
qemu-system-x86_64 \
-machine accel=kvm \
-m 2G \
-device virtio-net-pci,netdev=net0 \
-serial stdio -monitor vc \
-netdev 
user,id=net0,hostfwd=tcp::-:22,guestfwd=tcp:10.0.2.252:8080-tcp:localhost:8080,hostname=debian-live
 \
-kernel ./vmlinuz \
-initrd ./initrd.img \
-append "console=ttyS0 ip=frommedia boot=live nopersistence 
fetch=http://10.0.2.252:8080/root.squashfs;




[   28.531593] traps: phoc[354] trap int3 ip:7f45cbc70585 sp:7fff27e0a260 
error:0 in libglib-2.0.so.0.6400.4[7f45cbc36000+81000]
[   33.884796] traps: phoc[373] trap int3 ip:7f136d421585 sp:7ffce5012e30 
error:0 in libglib-2.0.so.0.6400.4[7f136d3e7000+81000]
[   39.221241] traps: phoc[381] trap int3 ip:7f99bb354585 sp:7ffd8b465610 
error:0 in libglib-2.0.so.0.6400.4[7f99bb31a000+81000]
[   44.560172] traps: phoc[389] trap int3 ip:7f0c127e8585 sp:7fff4ec1e510 
error:0 in libglib-2.0.so.0.6400.4[7f0c127ae000+81000]
[   49.897137] traps: phoc[397] trap int3 ip:7fea829a4585 sp:7ffd2f846bc0 
error:0 in libglib-2.0.so.0.6400.4[7fea8296a000+81000]
...
[  257.428198] traps: phoc[1618] trap int3 ip:7f61de676585 sp:7fff9ffe6490 
error:0 in libglib-2.0.so.0.6400.4[7f61de63c000+81000]

echo "deb http://192.168.178.25:/debian-11-bullseye-debug.deb.debian.org/ 
sid-debug main contrib non-free" >> /etc/apt/sources.list

apt update
apt install systemd-coredump openssh-server 

Bug#968457: iptables: segfault with specific command when run as non-root

[Bernhard Übelacker]

Dear Maintainer,
following is a backtrace where the crash happens.
This seems to affect just stable.
Testing shows a permission denied warning.

By default it seems iptables is not contained in the path,
nevertheless it crashes when executed by full path.

Kind regards,
Bernhard


Program received signal SIGSEGV, Segmentation fault.
nftnl_rule_list_add (r=r@entry=0x555f5900, list=0x0) at rule.c:782
782 list_add(>head, >list);
(gdb) bt
#0  nftnl_rule_list_add (r=r@entry=0x555f5900, list=0x0) at rule.c:782
#1  0x55567eac in nft_rule_insert (h=h@entry=0x7fffe480, 
chain=chain@entry=0x7fffe848 "OUTPUT", table=table@entry=0x5557b126 
"filter", data=data@entry=0x7fffe300, rulenum=rulenum@entry=0, 
verbose=verbose@entry=false) at nft.c:2146
#2  0x55562629 in add_entry (chain=0x7fffe848 "OUTPUT", 
table=0x5557b126 "filter", cs=cs@entry=0x7fffe300, rulenum=0, family=2, 
s=..., d=..., verbose=false, h=0x7fffe480, append=false) at xtables.c:412
#3  0x55564270 in do_commandx (h=h@entry=0x7fffe480, 
argc=argc@entry=3, argv=argv@entry=0x7fffe608, 
table=table@entry=0x7fffe478, restore=restore@entry=false) at xtables.c:1122
#4  0x55562350 in xtables_main (family=family@entry=2, 
progname=progname@entry=0x5557a011 "iptables", argc=3, argv=0x7fffe608) 
at xtables-standalone.c:72
#5  0x5556248a in xtables_ip4_main (argc=, 
argv=) at xtables-standalone.c:96
#6  0x7763809b in __libc_start_main (main=0xcfb0 , 
argc=3, argv=0x7fffe608, init=, fini=, 
rtld_fini=, stack_end=0x7fffe5f8) at ../csu/libc-start.c:308
#7  0xcfea in _start ()

# Buster/stable amd64 qemu VM 2020-08-16

apt update
apt dist-upgrade


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


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

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



gdb -q --args /usr/sbin/iptables -I OUTPUT

directory /home/benutzer/source/libnftnl11/orig/libnftnl-1.1.2/src
directory /home/benutzer/source/iptables/orig/iptables-1.8.2/iptables
set width 0
set pagination off
run


##




benutzer@debian:~$ /usr/sbin/iptables -I OUTPUT
Speicherzugriffsfehler (Speicherabzug geschrieben)


dmesg:
[So Aug 16 13:58:00 2020] iptables[1170]: segfault at 0 ip 7f27c75541f0 sp 
7ffc0c5bd208 error 4 in libnftnl.so.11.0.0[7f27c754d000+17000]
[So Aug 16 13:58:00 2020] Code: 83 c4 08 48 89 ef 5b 5d e9 6d 8e ff ff 66 66 2e 
0f 1f 84 00 00 00 00 00 66 90 31 c0 48 39 3f 0f 94 c0 c3 0f 1f 80 00 00 00 00 
<48> 8b 06 48 89 78 08 48 89 07 48 89 77 08 48 89 3e c3 66 66 2e 0f


root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Sun 2020-08-16 13:58:01 CEST   1170  1000  1000  11 present   
/usr/sbin/xtables-nft-multi


root@debian:~# coredumpctl gdb 1170
   PID: 1170 (iptables)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 11 (SEGV)
 Timestamp: Sun 2020-08-16 13:58:01 CEST (54s ago)
  Command Line: /usr/sbin/iptables -I OUTPUT
Executable: /usr/sbin/xtables-nft-multi
 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: 90c355c183dc4e728cac96d0d7b28324
Machine ID: 33f18f39d2a9438eb75b0ed52848afcd
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.iptables.1000.90c355c183dc4e728cac96d0d7b28324.1170.159757908100.lz4
   Message: Process 1170 (iptables) of user 1000 dumped core.

Stack trace of thread 1170:
#0  0x7f27c75541f0 nftnl_rule_list_add (libnftnl.so.11)
#1  0x556112a23eac n/a (xtables-nft-multi)
#2  0x556112a1e629 n/a (xtables-nft-multi)
#3  0x556112a20270 n/a (xtables-nft-multi)
#4  0x556112a1e350 n/a (xtables-nft-multi)
#5  0x556112a1e48a n/a (xtables-nft-multi)
#6  0x7f27c6de909b __libc_start_main (libc.so.6)
#7  0x556112a18fea n/a (xtables-nft-multi)

GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:

Bug#940317: Re : Bug#940317: hplip: No more printing

[Bernhard Übelacker]

Dear Maintainer,
after additionally re-reading the merged bugs I think I
realized that function IsChromeOs searches the line "NAME=...",
but finds the line "PRETTY_NAME=...",
which overflows the variable os_name.

Kind regards,
Bernhard

Bug#940317: Re : Bug#940317: hplip: No more printing

[Bernhard Übelacker]

Dear Maintainer,
I was able to reproduce this issue, kind of.

I guess the debian release name stored in /etc/os-release is too long.

Therefore in /usr/lib/cups/filter/hpcups in function IsChromeOs
the local array os_name with length 30 is overwritten by 1 byte.

At least that issue I received when executing the cupsfilter command from
the previous mails, with the ppd created when setting up a printer selecting
the "HP Photosmart c4700 Series, hpcups" driver. (Details in attached file.)

The easiest fix might be to make this array in IsChromeOs e.g. 100 bytes long?

Kind regards,
Bernhard


(rr) reverse-cont
Continuing.

Hardware watchpoint 1: *0xbfb54eac

Old value = -1349680094
New value = -1349680128
IsChromeOs () at common/utils.c:39
39os_name[i]=*ptr;
1: x/i $pc
=> 0x433720 :   mov%dl,0x0(%ebp,%ecx,1)

(rr) bt
#0  IsChromeOs () at common/utils.c:39
#1  0x0041ba91 in HPCupsFilter::startPage (this=, 
cups_header=) at prnt/hpcups/HPCupsFilter.cpp:461
#2  0x0041c98d in HPCupsFilter::processRasterData (this=0x481ce0 , 
cups_raster=) at prnt/hpcups/HPCupsFilter.cpp:655
#3  0x0041cfc1 in HPCupsFilter::StartPrintJob (this=, 
argc=, argv=) at prnt/hpcups/HPCupsFilter.cpp:584
#4  0x0041a0ce in main (argc=6, argv=0xbfb55e34) at 
prnt/hpcups/HPCupsFilter.cpp:56

(rr) print os_name
$2 = "\"Debian GNU/Linux bullseye/sid"
(rr) print i
$3 = 30
(rr) print *ptr
$4 = 34 '"'

# Unstable i386 qemu VM 2020-08-14

apt update
apt dist-uprade


apt install systemd-coredump gdb git fakeroot mc cups printer-driver-hpcups 
hpijs-ppds printer-driver-hpijs hplip cups-filters foomatic-db cups-dbgsym 
cups-filters-dbgsym printer-driver-hpcups-dbgsym

apt build-dep rr


echo 1 > /proc/sys/kernel/perf_event_paranoid





root@debian:~# dpkg -l | grep -i -E 
"ghostscript|cups|foomatic|hpijs|hplip|printer"
ii  cups 2.3.3-2i386
 Common UNIX Printing System(tm) - PPD/driver support, web interface
ii  cups-browsed 1.27.5-2   i386
 OpenPrinting CUPS Filters - cups-browsed
ii  cups-client  2.3.3-2i386
 Common UNIX Printing System(tm) - client programs (SysV)
ii  cups-common  2.3.3-2all 
 Common UNIX Printing System(tm) - common files
ii  cups-core-drivers2.3.3-2i386
 Common UNIX Printing System(tm) - driverless printing
ii  cups-daemon  2.3.3-2i386
 Common UNIX Printing System(tm) - daemon
ii  cups-dbgsym  2.3.3-2i386
 debug symbols for cups
ii  cups-filters 1.27.5-2   i386
 OpenPrinting CUPS Filters - Main Package
ii  cups-filters-core-drivers1.27.5-2   i386
 OpenPrinting CUPS Filters - Driverless printing
ii  cups-ipp-utils   2.3.3-2i386
 Common UNIX Printing System(tm) - IPP developer/admin utilities
ii  cups-ppdc2.3.3-2i386
 Common UNIX Printing System(tm) - PPD manipulation utilities
ii  cups-server-common   2.3.3-2all 
 Common UNIX Printing System(tm) - server common files
ii  foomatic-db  20200527-1 all 
 OpenPrinting printer support - database
ii  foomatic-db-engine   4.0.13-5   i386
 OpenPrinting printer support - programs
rc  foomatic-filters 4.0.17-11  i386
 OpenPrinting printer support - filters
ii  ghostscript  9.52~dfsg-1i386
 interpreter for the PostScript language and for PDF
ii  hplip-data   3.20.5+dfsg0-3 all 
 HP Linux Printing and Imaging - data files
ii  ipp-usb  0.9.10-2   i386
 Daemon for IPP over USB printer support
ii  libcups2:i3862.3.3-2i386
 Common UNIX Printing System(tm) - Core library
ii  libcupsfilters1:i386 1.27.5-2   i386
 OpenPrinting CUPS Filters - Shared library
ii  libcupsimage2:i386   2.3.3-2i386
 Common UNIX Printing System(tm) - Raster image library
ii  libfontembed1:i386   1.27.5-2   i386
 OpenPrinting CUPS Filters - Font Embed Shared library
ii  libgutenprint-common 5.3.3-4all 
 support files for the Gutenprint printer driver library
ii  libgutenprint9   5.3.3-4i386
 runtime for 

Bug#964458: checkinstall: causes segfault of cmake

[Bernhard Übelacker]

Dear Maintainer,
tried to have a look and it seems that installwatch.so's
initialize function was not yet called.

Attached are some details and a patch trying to call initialize
just before the call to true_xstat64.

Another patch would add a build-id to the shared object, so
the build process can create a debug symbol package.

Kind regards,
Bernhard


Location just before we end up with eip=0:
  (rr) reverse-stepi
  0xb7edd1d8 in __xstat64 (version=, pathname=, 
info=) at installwatch.c:3731
  3731result=true_xstat64(version,pathname,info);
  1: x/i $pc
  => 0xb7edd1d8 <__xstat64+88>:   jmp*%eax

  (rr) print true_xstat64
  $1 = (int (*)(int, const char *, struct stat64 *)) 0x0
Description: Force initialize for xstat64

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

Index: checkinstall-1.6.2+git20170426.d24a630/installwatch/installwatch.c
===
--- checkinstall-1.6.2+git20170426.d24a630.orig/installwatch/installwatch.c
+++ checkinstall-1.6.2+git20170426.d24a630/installwatch/installwatch.c
@@ -3728,6 +3728,8 @@ int __xstat64(int version,const char *pa
 	  /* We were asked to work in "real" mode */
 	if( !(__instw.gstatus & INSTW_INITIALIZED) ||
 	!(__instw.gstatus & INSTW_OKWRAP) ) {
+		if (!true_xstat64)
+			initialize();
 		result=true_xstat64(version,pathname,info);
 		return result;
 	}
Description: Add build-id to enable automatic generation of dbgsym package.

Author: Bernhard Übelacker 
Forwarded: no
Last-Update: 2020-08-15

Index: checkinstall-1.6.2+git20170426.d24a630/installwatch/Makefile
===
--- checkinstall-1.6.2+git20170426.d24a630.orig/installwatch/Makefile
+++ checkinstall-1.6.2+git20170426.d24a630/installwatch/Makefile
@@ -16,7 +16,7 @@ LIBDIR=$(PREFIX)/lib
 all: installwatch.so
 
 installwatch.so: installwatch.o
-	ld -znow -shared -o installwatch.so installwatch.o -ldl -lc
+	ld -znow -shared --build-id -o installwatch.so installwatch.o -ldl -lc
 
 installwatch.o: installwatch.c localdecls.h
 	gcc $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) -Wall -c -g -D_GNU_SOURCE -DPIC -fPIC -D_REENTRANT -DVERSION=\"$(VERSION)\" installwatch.c

# Unstable i386 qemu VM 2020-08-14

apt update
apt dist-uprade


apt install systemd-coredump gdb git fakeroot mc checkinstall libgnutls30-dbgsym
apt build-dep libgnutls30
apt build-dep rr
apt build-dep checkinstall


echo 1 > /proc/sys/kernel/perf_event_paranoid



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



# unfortunately no checkinstall-dbgsym package available ...

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

cd /home/benutzer/source/checkinstall
cp orig try1 -a
cd try1/checkinstall-1.6.2+git20170426.d24a630/
DEB_BUILD_OPTIONS=nostrip dpkg-buildpackage

dpkg -i 
/home/benutzer/source/checkinstall/try1/checkinstall_1.6.2+git20170426.d24a630-2_i386.deb







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

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








touch CMakeLists.txt
cmake .
installwatch cmake .


$ installwatch cmake .

INFO : Using a default root directory : /tmp/tmp.2yZ1I6G54F

/usr/bin/installwatch: Zeile 338:  3465 Speicherzugriffsfehler  (Speicherabzug 
geschrieben) "$@"


dmesg:
[Sa Aug 15 01:32:54 2020] cmake[3465]: segfault at 0 ip  sp bfd2951c 
error 14 in cmake[4bf000+1]
[Sa Aug 15 01:32:54 2020] Code: Bad RIP value.


root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Sat 2020-08-15 01:32:55 CEST   3465  1000  1000  11 present   /usr/bin/cmake



root@debian:~# coredumpctl gdb 3465
...
Core was generated by `cmake .'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0xb6a59c13 in ?? () from /usr/lib/i386-linux-gnu/libgnutls.so.30
#2  0xb6a6d535 in ?? () from /usr/lib/i386-linux-gnu/libgnutls.so.30
#3  0xb6a3f990 in ?? () from /usr/lib/i386-linux-gnu/libgnutls.so.30
#4  0xb7f3be9c in call_init (l=, argc=argc@entry=2, 
argv=argv@entry=0xbfd29694, env=0xbfd296a0) at dl-init.c:72
#5  0xb7f3bfa2 in call_init (env=0xbfd296a0, argv=0xbfd29694, argc=2, 
l=) at dl-init.c:30
#6  _dl_init (main_map=, argc=2, argv=0xbfd29694, 
env=0xbfd296a0) at dl-init.c:119
#7  0xb7f2c0fa in _dl_start_user () from /lib/ld-linux.so.2


(gdb) bt
#0  0x in ?? ()
#1  0xb6a59c13 in stat64 (__statbuf=, __path=0xb6b572bb 
"/etc/gnutls/config") at /usr/include/i386-linux-gnu/sys/stat.h:455
#2  _gnutls_update_system_priorities () at ../../lib/priority.c:1309
#3  0xb6a6d535 in _gnutls_

Bug#968372: sylpheed: crash on startup

[Bernhard Übelacker]

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

This state is retrieved from the renderer of type _PangoRendererPrivate.


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

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


Kind regards,
Bernhard



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

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


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


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

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

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

# Unstable i386 qemu VM 2020-08-14

apt update
apt dist-uprade


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


echo 1 > /proc/sys/kernel/perf_event_paranoid




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

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





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


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


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

# coredumpctl gdb 992
   PID: 992 (sylpheed)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 11 (SEGV)
 Timestamp: Fri 2020-08-14 18:33:29 CEST (2min 10s ago)
  Command Line: sylpheed
Executable: /usr/bin/sylpheed
 Control Group: /user.slice/user-1000.slice/session-6.scope
  Unit: session-6.scope
 Slice: user-1000.slice
   Session: 6
 Owner UID: 1000 (benutzer)
   Boot ID: 4c238d8aaaba40d19b8c886c81502ce0
Machine ID: 45f49504b47f4e5690bc479adf67aa5b
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.sylpheed.1000.4c238d8aaaba40d19b8c886c81502ce0.992.1597422809.zst
   Message: Process 992 (sylpheed) of user 1000 dumped core.

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

Bug#948287: bash: *** stack smashing detected *** ( SIGABRT crash )

[Bernhard Übelacker]

Dear Maintainer,

encountered again such a crash of a bash that was started
while the old libc6 was installed, then installed a libc6 update,
and then the "old" bash crashed after a tab completion.

libc6:amd64 (2.30-8, 2.31-3)
bash:amd64 (5.0-6, 5.0-7)

Kind regards,
Bernhard


$ cp log*** stack smashing detected ***:  terminated
Connection to ... closed.

# coredumpctl gdb
   PID: 4738 (bash)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 6 (ABRT)
 Timestamp: Fri 2020-08-14 17:50:14 CEST (37s ago)
  Command Line: -bash
Executable: /usr/bin/bash

Stack trace of thread 4738:
#0  0x7f4c0d38e781 n/a 
(/usr/lib/x86_64-linux-gnu/libc-2.30.so (deleted) + 0x3b781)
#1  0x7f4c0d45fd7d n/a 
(/usr/lib/x86_64-linux-gnu/libc-2.30.so (deleted) + 0x10cd7d)

Bug#968375: scottfree: Crashes when restoring save file

[Bernhard Übelacker]

 Backward compatibility */
700 if(DarkFlag)



##



https://buildd.debian.org/status/fetch.php?pkg=scottfree=amd64=1.14-10%2Bb1=1525522418=0

ScottCurses.c: In function 'LoadGame':
ScottCurses.c:696:17: warning: format '%d' expects argument of type 'int *', 
but argument 4 has type 'short int *' [-Wformat=]
  fscanf(f,"%ld %d %hd %d %d %hd\n",
~^
%hd
   ,
 ~



##



cd /home/benutzer/source/scottfree
cp orig try1 -a
cd try1/scottfree-1.14
dpkg-buildpackage -b


Description: Include time.h, fix two warnings in fscanf calls.

Author: Bernhard Übelacker 
Bug-Debian: https://bugs.debian.org/968375
Forwarded: no
Last-Update: 2020-08-14

Index: scottfree-1.14/ScottCurses.c
===
--- scottfree-1.14.orig/ScottCurses.c
+++ scottfree-1.14/ScottCurses.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "Scott.h"
 
@@ -239,7 +240,7 @@ void LoadDatabase(FILE *f, int loud)
 /* Load the header */
 	
 	if(fscanf(f,"%*d %d %d %d %d %d %d %d %d %d %d %d",
-		,,,)<10)
+		,,)<10)
 		Fatal("Invalid database(bad header)");
 	GameHeader.NumItems=ni;
 	Items=(Item *)MemAlloc(sizeof(Item)*(ni+1));
@@ -693,7 +694,7 @@ void LoadGame(char *name)
 	{
 		fscanf(f,"%d %d\n",[ct],[ct]);
 	}
-	fscanf(f,"%ld %d %hd %d %d %hd\n",
+	fscanf(f,"%ld %hd %hd %d %d %hd\n",
 		,
 		);
 	/* Backward compatibility */

Bug#964181: linux-image-4.19.0-9-amd64: Unable to get battery status

[Bernhard Übelacker]

Dear Maintainer,
this bug sounds similar to this one:
https://bugs.debian.org/927163

Kind regards,
Bernhard

Bug#947788: openshot-qt: SIGSEGV crash

[Bernhard Übelacker]

Dear Maintainer,
this bug might be related to bug #940839.
At least the frames Json::Reader::parse appear there too.

Kind regards,
Bernhard

Bug#962372: linux-image-5.7.0-rc5-amd64: Silead module not installed

[Bernhard Übelacker]

Dear Maintainer,
bug #925424 seems to be about the same issue.

Kind regards,
Bernhard

Bug#961993: Undelivered Mail Returned to Sender

[Bernhard Übelacker]

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

My email could not be delivered to the submitter.

Bug#961993: gimp crashes on start up

[Bernhard Übelacker]

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

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

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

Kind regards,
Bernhard

Bug#961926: rr: record fails on i386

[Bernhard Übelacker]

Hello Stephen,

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


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

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

Kind regards,
Bernhard

Bug#961926: rr: record fails on i386

[Bernhard Übelacker]

Package: rr
Version: 5.3.0-3
Severity: normal

Dear Maintainer,
thank you for building i386 again.

Unfortunately I found recording not working in a small test [1].

A git bisect led to a helper function introduced by upstream in [2].
This helper uses a function parameter of type off_t.
But the pwrite64 from glibc uses off64_t.
Therefore offset values with the highest bit set get incorrectly
converted to the 64 bit type, e.g.: 0xb622 -> 0xb622
Therefore the write fails and rr stops.

Attached patch makes rr work on i386 and passing most tests
in my test VM, except [3]. Have not tested for side effects at amd64.

I am going to try to forward this to upstream too,
will update this bug then.

Kind regards,
Bernhard




[1]
$ /usr/bin/rr record /bin/ls
rr: Saving execution to trace directory `/home/benutzer/.local/share/rr/ls-0'.
[FATAL /build/rr-wu2MDM/rr-5.3.0/src/AddressSpace.cc:320:map_rr_page()] 
 (task 6291 (rec:6291) at time 14)
 -> Assertion `child_fd == -EACCES' failed to hold. Unexpected error mapping 
rr_page
Tail of trace dump:
[FATAL /build/rr-wu2MDM/rr-5.3.0/src/DumpCommand.cc:180:dump_events_matching()] 
TraceTaskEvent times non-increasing
=== Start rr backtrace:
/usr/bin/rr(_ZN2rr13dump_rr_stackEv+0x43)[0x6489e3]
/usr/bin/rr(_ZN2rr15notifying_abortEv+0x5a)[0x648a8a]
/usr/bin/rr(_ZN2rr12FatalOstreamD1Ev+0x53)[0x569723]
/usr/bin/rr(+0x6f175)[0x521175]
/usr/bin/rr(_ZN2rr4dumpERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKNS_9DumpFlagsERKSt6vectorIS5_SaIS5_EEP8_IO_FILE+0x8d)[0x521c5d]
/usr/bin/rr(+0xb7985)[0x569985]
/usr/bin/rr(_ZN2rr21EmergencyDebugOstreamD2Ev+0x81)[0x569c11]
/usr/bin/rr(_ZN2rr12AddressSpace11map_rr_pageERNS_18AutoRemoteSyscallsE+0x8b8)[0x50d188]
/usr/bin/rr(_ZN2rr12AddressSpace17post_exec_syscallEPNS_4TaskE+0x88)[0x50f7b8]
/usr/bin/rr(_ZN2rr4Task17post_exec_syscallEv+0x46)[0x625b26]
/usr/bin/rr(+0xf989f)[0x5ab89f]
/usr/bin/rr(+0x114183)[0x5c6183]
/usr/bin/rr(_ZN2rr19rec_process_syscallEPNS_10RecordTaskE+0xa3)[0x5cd1c3]
/usr/bin/rr(_ZN2rr13RecordSession21syscall_state_changedEPNS_10RecordTaskEPNS0_9StepStateE+0xe5d)[0x59143d]
/usr/bin/rr(_ZN2rr13RecordSession11record_stepEv+0x45b)[0x5978bb]
/usr/bin/rr(_ZN2rr13RecordCommand3runERSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EE+0xf68)[0x58c6d8]
/usr/bin/rr(main+0x298)[0x5054a8]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0xb791bef1]
/usr/bin/rr(_start+0x31)[0x505611]
=== End rr backtrace
Abgebrochen



[2] 
https://github.com/mozilla/rr/commit/531062cca8670f13ae99de3322df650e43269784



[3]
98% tests passed, 20 tests failed out of 1157
Total Test time (real) = 3370.80 sec
The following tests FAILED:
440 - quotactl (Failed)
441 - quotactl-no-syscallbuf (Failed)
512 - sem (Failed)
513 - sem-no-syscallbuf (Failed)
534 - shm (Failed)
535 - shm-no-syscallbuf (Failed)
536 - shm_unmap (Failed)
537 - shm_unmap-no-syscallbuf (Failed)
708 - std_random (Failed)
709 - std_random-no-syscallbuf (Failed)
962 - vsyscall_reverse_next (Failed)
963 - vsyscall_reverse_next-no-syscallbuf (Failed)
1110 - shm_checkpoint (Failed)
 - shm_checkpoint-no-syscallbuf (Failed)
1116 - signal_stop (Failed)
1117 - signal_stop-no-syscallbuf (Failed)
1118 - signal_checkpoint (Failed)
1119 - signal_checkpoint-no-syscallbuf (Failed)
1132 - step_signal (Failed)
1133 - step_signal-no-syscallbuf (Failed)
Errors while running CTest




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

Kernel: Linux 5.6.0-2-686-pae (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rr depends on:
ii  libc6   2.30-8
ii  libcapnp-0.7.0  0.7.0-6
ii  libgcc-s1   10.1.0-3
ii  libstdc++6  10.1.0-3
ii  python3 3.8.2-3
ii  sse2-support5

rr recommends no packages.

rr suggests no packages.

-- no debconf information
>From bd04f8a1a3ac113a25f38f8e4da66945a98fac32 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
Date: Sun, 31 May 2020 13:25:50 +0200
Subject: [PATCH 1/1] i386: Use off64_t instead of off_t.

A offset value of 0xb622 in pwrite_all_fallible gets converted
to a value of 0xb622 in __libc_pwrite64.
This gets visible just at 32bit.

Got introduced by commit 531062cca8670f13ae99de3322df650e43269784.

[FATAL /build/rr-wu2MDM/rr-5.3.0/src/AddressSpace.cc:320:map_rr_page()]
 (task 6291 (rec:6291) at time 14)
 -> Assertion `child_fd == -EACCES' failed to hold. Unexpected error mapping rr_page
---
 src/util.cc | 2 +-
 src/util.h  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Index: rr-5.3.0/src/util.cc

Bug#961710: rr: Is it possible to reintroduce rr on i386 if depending on sse2-support

[Bernhard Übelacker]

Package: rr
Version: 5.2.0-4
Severity: wishlist

Dear Maintainer,
in bug #915337 the i386 support got dropped because of
the i386 baseline violation.

Would it be enough to depend just on i386 on
the package sse2-support.

That way the user gets an error when attempting to install
on an non-sse-enabled system.

There was a discussion in [1] that I think matches
the situation here too. There the result, as far as I see,
was that it would be sufficient to have the user informed of
the problem instead of letting the process crash.

Kind regards,
Bernhard

[1] https://lists.debian.org/debian-devel/2014/09/msg00666.html




-- System Information:
Debian Release: 10.4
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'stable')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-9-686-pae (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rr depends on:
ii  libc6   2.28-10
ii  libcapnp-0.6.1  0.6.1-1
ii  libgcc1 1:8.3.0-6
ii  libstdc++6  8.3.0-6

rr recommends no packages.

rr suggests no packages.

-- no debconf information

Bug#960732: Segmentation fault with true-color escape sequences in :term

[Bernhard Übelacker]

Dear Maintainer,
tried to reproduce the steps and found neovim crashing too.
Used a minimal testing VM, created a test video with ffmpeg.
This led to the backtrace below.

In the meantime someone created this upstream bug describing a
similar situation and showing the same backtrace:

https://github.com/neovim/neovim/issues/12366

Kind regards,
Bernhard


(gdb) bt
#0  0x55f2bdc1f7c4 in update_attrs (ui=ui@entry=0x55f2be8fbdd0, 
attr_id=-19221) at ../src/nvim/tui/tui.c:516
#1  0x55f2bdc1ffcb in print_cell (ui=ui@entry=0x55f2be8fbdd0, 
ptr=ptr@entry=0x7f9914082990) at ../src/nvim/tui/tui.c:658
#2  0x55f2bdc20161 in tui_raw_line (ui=0x55f2be8fbdd0, g=, 
linerow=44, startcol=, endcol=213, clearcol=213, clearattr=0, 
flags=0, chunk=0x55f2beb4f540, attrs=0x55f2beb61320) at 
../src/nvim/tui/tui.c:1302
#3  0x55f2bdc1c8e9 in ui_bridge_raw_line_event (argv=0x7f991c5a9758) at 
../src/nvim/ui_bridge.c:157
#4  0x55f2bdd7ba99 in multiqueue_process_events (this=0x7f9914000d30) at 
../src/nvim/event/multiqueue.c:157
#5  0x55f2bdd7bcb8 in loop_poll_events (loop=0x7f991c5a98d0, ms=) at ../src/nvim/event/loop.c:70
#6  0x55f2bdc35b75 in tui_main (bridge=0x55f2be8fbef0, ui=0x55f2be8fbdd0) 
at ../src/nvim/tui/tui.c:440
#7  0x7f991cce5f27 in start_thread (arg=) at 
pthread_create.c:479
#8  0x7f991ce5331f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

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

apt update
apt dist-upgrade

apt install systemd-coredump gdb neovim mpv ffmpeg neovim-dbgsym


# ssh into the VM, terminal is konsole in a kde/plasma desktop

ffmpeg -f lavfi -i testsrc=duration=30:size=1280x720:rate=30 testsrc.mpg

nvim
:term

mpv --quiet --vo=tct testsrc.mpg

Speicherzugriffsfehler (Speicherabzug geschrieben)


# journalctl -e
Mai 25 18:56:15 debian kernel: nvim[5458]: segfault at 7f991b59c9d0 ip 
55f2bdc1f7c4 sp 7f991c5a9640 error 4
Mai 25 18:56:15 debian kernel: Code: 00 00 84 c0 0f 84 04 02 00 00 49 8b 97 30 
0f 01 00 41 89 c4 48 8d 04 dd 00 00 00 00 41 89 9f 38 0f 01 00 48 29 d8 48 8d 
04 82 <8b> 48 0c 89 4c 24 10 45 84 ed 0f 84 94 01 00 00 44>
Mai 25 18:56:15 debian systemd[1]: Created slice 
system-systemd\x2dcoredump.slice.
Mai 25 18:56:15 debian systemd[1]: Started Process Core Dump (PID 5517/UID 0).
Mai 25 18:56:16 debian systemd-coredump[5518]: Process 5457 (nvim) of user 1000 
dumped core.
   
   Stack trace of thread 5458:
   #0  0x55f2bdc1f7c4 n/a (nvim 
+ 0x9b7c4)
   #1  0x55f2bdc1ffcb n/a (nvim 
+ 0x9bfcb)
   #2  0x55f2bdc20161 n/a (nvim 
+ 0x9c161)
   #3  0x55f2bdc1c8e9 n/a (nvim 
+ 0x988e9)
   #4  0x55f2bdd7ba99 
multiqueue_process_events (nvim + 0x1f7a99)
   #5  0x55f2bdd7bcb8 
loop_poll_events (nvim + 0x1f7cb8)
   #6  0x55f2bdc35b75 n/a (nvim 
+ 0xb1b75)
   #7  0x7f991cce5f27 
start_thread (libpthread.so.0 + 0x8f27)
   #8  0x7f991ce5331f __clone 
(libc.so.6 + 0xfd31f)
   
   Stack trace of thread 5457:
   #0  0x55f2bdd0eb43 
kh_resize_HlEntry_int_map (nvim + 0x18ab43)
   #1  0x55f2bdd0ee5c 
kh_put_HlEntry_int_map (nvim + 0x18ae5c)
   #2  0x55f2bdd0efa0 
map_HlEntry_int_put (nvim + 0x18afa0)
   #3  0x55f2bdd24d51 n/a (nvim 
+ 0x1a0d51)
   #4  0x55f2bdd251b7 
hl_get_term_attr (nvim + 0x1a11b7)
   #5  0x55f2bdc2d6ba 
terminal_get_line_attributes (nvim + 0xa96ba)
   #6  0x55f2bdc86ae2 n/a (nvim 
+ 0x102ae2)
   #7  0x55f2bdc8bd0a n/a (nvim 
+ 0x107d0a)
   #8  0x55f2bdc83575 n/a (nvim 
+ 0xff575)
   #9  0x55f2bdc2df77 n/a (nvim 
+ 0xa9f77)
   #10 0x55f2bdc47406 
state_enter (nvim + 0xc3406)
   #11 0x55f2bdc2e3de 
terminal_enter (nvim + 0xaa3de)
   #12 0x55f2bddc1df5 edit 
(nvim + 0x23ddf5)
   #13 0x55f2bdcdb36d n/a (nvim 
+ 0x15736d)
   #14 

Bug#961128: apt-transport-https: https fails with segmentation fault

[Bernhard Übelacker]

Am 25.05.20 um 12:38 schrieb meht...@protonmail.com:
> While trying to get the core file I renamed "https" to "https.bin" and
> created a shell script "https" which had "ulimit -c unlimited; 
> /path/https.bin $@"
> or something like that..

Another way to receive core files might have been to install
a package providing the virtual package core-dump-handler
like systemd-coredump or corekeeper.

Kind regards,
Bernhard

Bug#961141: antimony: error while loading shared libraries: libboost_python36.so.1.67.0

[Bernhard Übelacker]

Dear Maintainer,
I tried to collect some more information and found that
version 0.9.3-1+b1 got built against
libboost-python1.67.0 in version 1.67.0-10.

Up to 1.67.0-11 this package provided both, a lib *python36* and *python37*.
Since 1.67.0-12 it looks like there is just a *python37* lib.

A local rebuild got linked to *python37*, therefore
a binNMU might be enough for buster?


Other packages, depending on libboost-python1.67.0,
might be affected too.

Kind regards,
Bernhard

# Buster/stable amd64 qemu VM 2020-05-25

apt update
apt dist-upgrade


apt install systemd-coredump antimony fakeroot



root@debian:~# dpkg -l | grep libboost
ii  libboost-python1.67.0 1.67.0-13+deb10u1amd64
Boost.Python Library


root@debian:~# ldd /usr/bin/antimony
...
libboost_python36.so.1.67.0 => not found
...



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




https://buildd.debian.org/status/logs.php?pkg=boost1.67=amd64

https://buildd.debian.org/status/fetch.php?pkg=boost1.67=amd64=1.67.0-11=1543612644=0
-rw-r--r-- root/root288264 2018-11-30 17:12 
./usr/lib/x86_64-linux-gnu/libboost_python27.so.1.67.0
-rw-r--r-- root/root280072 2018-11-30 17:12 
./usr/lib/x86_64-linux-gnu/libboost_python36.so.1.67.0
-rw-r--r-- root/root280072 2018-11-30 17:12 
./usr/lib/x86_64-linux-gnu/libboost_python37.so.1.67.0

https://buildd.debian.org/status/fetch.php?pkg=boost1.67=amd64=1.67.0-12=1548248464=0
-rw-r--r-- root/root288264 2019-01-23 11:14 
./usr/lib/x86_64-linux-gnu/libboost_python27.so.1.67.0
-rw-r--r-- root/root280072 2019-01-23 11:14 
./usr/lib/x86_64-linux-gnu/libboost_python37.so.1.67.0





https://buildd.debian.org/status/fetch.php?pkg=antimony=amd64=0.9.3-1%2Bb1=1542484831=0
Setting up libboost-python1.67.0 (1.67.0-10) ...




apt build-dep antimony

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

cd /home/benutzer/source/antimony
cp -a orig try1
cd try1/antimony-0.9.3
dpkg-buildpackage

dpkg -i /home/benutzer/source/antimony/try1/antimony_0.9.3-1_amd64.deb

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

[Bernhard Übelacker]

Hello Peter,
I am not involved in packaging cups, just trying to help
to collect some information.

If possible you could install the package systemd-coredump.
Then in the journal might then appear additional information
where the problem occoured, that could help identifying the issue.

Kind regards,
Bernhard

Bug#961128: apt-transport-https: https fails with segmentation fault

[Bernhard Übelacker]

Dear Maintainer, hello Mehturt,
I guess the missing debug information is contained in libcurl3-dbg [1].

I tried to find out to which line this address in Mehturt's backtrace
points to and came to this location:

  (gdb) bt
  #0  0x777cd4d7 in Curl_close (data=0x5579f6c0) at url.c:399
  #1  0x874b in HttpsMethod::~HttpsMethod (this=0x7fffe470, 
__in_chrg=) at ./methods/https.cc:538
  #2  main (argv=) at ./methods/https.cc:546

  https://sources.debian.org/src/curl/7.52.1-5+deb9u10/lib/url.c/#L399
  https://sources.debian.org/src/apt/1.4.10/methods/https.cc/#L538

In my opinion the instruction "mov0x60(%rbx),%rdi" is executed, for Mehturt,
while $rbx contains no valid pointer.

The crash did not show up in my test VM. Attached an example debug session
to debug to this location.

@Mehturt: maybe you can still install libcurl3-dbg and inspect the core again.
(Maybe adding a "display/i $pc" and "print/x $rbx", before any "bt full")


Maybe related, upstream has added a null pointer check to Curl_close.
  https://sources.debian.org/src/curl/7.68.0-1/lib/url.c/#L325

Kind regards,
Bernhard

[1] 
https://snapshot.debian.org/package/curl/7.52.1-5%2Bdeb9u10/#libcurl3-gnutls_7.52.1-5:2b:deb9u10
# Stretch/oldstable amd64 qemu VM 2020-05-23



#sources.list
deb http://192.168.178.25:/debian-9-stretch-debug.mirrors.debian.org/ 
stretch-debug main
deb http://192.168.178.25:/debian-9-stretch-debug.mirrors.debian.org/ 
stretch-proposed-updates-debug main contrib non-free

#approx.conf
debian-9-stretch-deb.debian.org 
http://deb.debian.org/debian/
debian-9-stretch-security.debian.orghttp://security.debian.org/
debian-9-stretch-debug.mirrors.debian.org   
http://debug.mirrors.debian.org/debian-debug/


# or https://wiki.debian.org/AutomaticDebugPackages




apt update
apt dist-upgrade

apt install systemd-coredump


# https://github.com/matrix-org/synapse/blob/master/INSTALL.md

apt install -y lsb-release wget apt-transport-https
wget -O /usr/share/keyrings/matrix-org-archive-keyring.gpg 
https://packages.matrix.org/debian/matrix-org-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/matrix-org-archive-keyring.gpg] 
https://packages.matrix.org/debian/ $(lsb_release -cs) main" | tee 
/etc/apt/sources.list.d/matrix-org.list
apt update
apt install matrix-synapse-py3

# no crash




root@debian:~# dpkg -S /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
libcurl3-gnutls:amd64: /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
root@debian:~# dpkg -l | grep libcurl3-gnutls
ii  libcurl3-gnutls:amd64 7.52.1-5+deb9u10  amd64   
 easy-to-use client-side URL transfer library (GnuTLS flavour)




apt install gdb apt-transport-https-dbgsym libcurl3-dbg




rm matrix-synapse-py3_1.13.0+stretch1_amd64.deb

gdb -q
set width 0
set pagination off
file /usr/bin/apt
set detach-on-fork off
set follow-fork-mode child
set follow-exec-mode new
b HttpsMethod::~HttpsMethod
y
run download matrix-synapse-py3
info inferiors
inferior 1
cont
info inferiors
inferior 1
set detach-on-fork on
cont
info inferiors
bt
cont
stepi
stepi









benutzer@debian:~$ rm matrix-synapse-py3_1.13.0+stretch1_amd64.deb ^C
benutzer@debian:~$ gdb -q
(gdb) set width 0
(gdb) set pagination off
(gdb) file /usr/bin/apt
Reading symbols from /usr/bin/apt...(no debugging symbols found)...done.
(gdb) set detach-on-fork off
(gdb) set follow-fork-mode child
(gdb) set follow-exec-mode new
(gdb) b HttpsMethod::~HttpsMethod
Function "HttpsMethod::~HttpsMethod" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (HttpsMethod::~HttpsMethod) pending.
(gdb) run download matrix-synapse-py3
Starting program: /usr/bin/apt download matrix-synapse-py3
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New process 3044]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Reading symbols from 
/usr/lib/debug/.build-id/77/5143e680ff0cd4cd51cce1ce8ca216e635a1d6.debug...done.
Reading symbols from 
/usr/lib/debug/.build-id/db/2caeeec37482a98ab1416d0a9afe2944930de9.debug...done.
Reading symbols from 
/usr/lib/debug/.build-id/ea/d5fd817712e63c1212d1ee7d7ee1b9c29f93a7.debug...done.
Reading symbols from 
/usr/lib/debug/.build-id/16/d609487bcc4acbac29a4eaa2dda0d2f56211ec.debug...done.
Reading symbols from 
/usr/lib/debug/.build-id/4e/49714c557ce0472c798f39365ca10f9c0e1933.debug...done.
Reading symbols from 
/usr/lib/debug/.build-id/60/6df9c355103e82140d513bc7a25a635591c153.debug...done.
process 3044 is executing new program: /usr/bin/dpkg
[New process 3044]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Inferior 3 (process 3044) exited normally]
(gdb) info inferiors
  Num  Description   Executable
  1process 3040 

Bug#961205: winetricks: cannot isntall font the download of PowerPointViwer.exe hans with server down

[Bernhard Übelacker]

Dear Maintainer,
if a targetted fix for buster would be desired, following
upstream commits seem to be the last changes to the
download URL in question.
  https://github.com/Winetricks/winetricks/commit/ac51cdb pptfonts: use a 
helper function
  https://github.com/Winetricks/winetricks/commit/76f5fdf calibri, cambria, 
candara, consolas, constantia, corbel, meiryo: update URL

Upstream issue:
  https://github.com/Winetricks/winetricks/issues/1540

The version 0.0+20200412-1 in unstable seems to be affected too.

Kind regards,
Bernhard

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

[Bernhard Übelacker]

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

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

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

Kind regards,
Bernhard

Bug#948288: gnome-shell reproducibly crashes on boot, and the boot process gets stuck

[Bernhard Übelacker]

Hello Md,
not involved in packaging or development I was just trying
to collect more information about the crash for the maintainer.
I guess reassigning might not be a bad idea and might
give some feedback.
Another option would be to open an issue in the upstream
bug tracker (please put links here and there if you do so).
Also it might be helpful, if you could check if current testing
is still affected. One way to check this could be the live CDs in [1].

Kind regards,
Bernhard

[1] 
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/weekly-live-builds/amd64/iso-hybrid/

Bug#959425: loopback command hangs in 2.04 under UEFI

[Bernhard Übelacker]

Dear Maintainer,
I further tried to get some more logging output by "set debug=all".

There I found that the loopback command actually returns after
around 2 minutes for my 335 MB ISO file.
>From the logging is looks like the whole ISO is read
to memory, if the tpm module is loaded.
If it is not loaded the ISO seems to get not touched at all.

Is it "just" checking if the file is signed?
(Even when running without secureboot?)

Kind regards,
Bernhard
13:42:00
13:44:03
~123 seconds



#serial --speed=115200 efi0
terminal_input console serial_efi0
terminal_output gfxterm serial_efi0

set debug=all
#set pager=1
date; loopback loop /debian-10.3.0-amd64-netinst.iso; date




###

# With module tpm loaded:

grub> set debug=all
script/script.c:65: free 0xbbc4fdc0
script/script.c:65: free 0xbbc4fe00
script/script.c:65: free 0xbbc4fe40
script/script.c:65: free 0xbbc4f960
script/script.c:65: free 0xbbc4f9c0
script/script.c:65: free 0xbbc4fa00
script/script.c:65: free 0xbbc4fa60
script/script.c:65: free 0xbbc4fac0
script/script.c:65: free 0xbbc4fba0
script/script.c:65: free 0xbbc4fc80
script/script.c:65: free 0xbbc4fce0
script/script.c:65: free 0xbbc4fd20
grub> date; loopback loop /debian-10.3.0-amd64-netinst.iso; date
script/lexer.c:321: token 288 text [date]
script/script.c:50: malloc 0xbbc4fb40
script/script.c:50: malloc 0xbbc4fb00
script/script.c:163: arglist
script/script.c:50: malloc 0xbbc4faa0
script/lexer.c:321: token 265 text [;]
script/script.c:50: malloc 0xbbc4fa40
script/script.c:50: malloc 0xbbc4fa00
script/script.c:198: cmdline
script/script.c:50: malloc 0xbbc4f9a0
script/lexer.c:321: token 288 text [loopback]
script/script.c:50: malloc 0xbbc4f940
script/script.c:50: malloc 0xbbc4f900
script/script.c:294: append command
script/script.c:50: malloc 0xbbc4f8c0
script/script.c:163: arglist
script/script.c:50: malloc 0xbbc4f860
script/lexer.c:321: token 288 text [loop]
script/script.c:50: malloc 0xbbc4f800
script/script.c:50: malloc 0xbbc4f7c0
script/script.c:163: arglist
script/script.c:50: malloc 0xbbc4f760
script/lexer.c:321: token 289 text [/debian-10.3.0-amd64-netinst.iso]
script/script.c:50: malloc 0xbbc4f4c0
script/script.c:50: malloc 0xbbc4f460
script/script.c:163: arglist
script/script.c:50: malloc 0xbbc4f400
script/lexer.c:321: token 265 text [;]
script/script.c:50: malloc 0xbbc4f3a0
script/script.c:50: malloc 0xbbc4f360
script/script.c:198: cmdline
script/script.c:50: malloc 0xbbc4f300
script/lexer.c:321: token 288 text [date]
script/script.c:50: malloc 0xbbc4f2a0
script/script.c:50: malloc 0xbbc4f260
script/script.c:294: append command
script/script.c:163: arglist
script/script.c:50: malloc 0xbbc4f200
script/lexer.c:321: token 259 text [
]
script/script.c:50: malloc 0xbbc4f1a0
script/script.c:50: malloc 0xbbc4f160
script/script.c:198: cmdline
script/script.c:50: malloc 0xbbc4f100
script/lexer.c:321: token 0 text []
script/script.c:50: malloc 0xbbc4fca0
script/script.c:50: malloc 0xbbc4fc60
script/script.c:294: append command
kern/disk.c:196: Opening `hd0,gpt2'...
disk/efi/efidisk.c:482: opening hd0
disk/efi/efidisk.c:511: m = 0xbef1d300, last block = 27f, block size = 200,
io align = 8
disk/efi/efidisk.c:531: opening hd0 succeeded
partmap/gpt.c:90: Read a valid GPT header
partmap/gpt.c:112: GPT entry 0: start=2048, length=1048576
partmap/gpt.c:112: GPT entry 1: start=1050624, length=36704256
kern/fs.c:56: Detecting procfs...
kern/fs.c:78: procfs detection failed.
kern/fs.c:56: Detecting zfs...
disk/efi/efidisk.c:593: reading 0x100 sectors at the sector 0x100900 from hd0
fs/zfs/zfs.c:1192: label ok 0
disk/efi/efidisk.c:593: reading 0x40 sectors at the sector 0x100800 from hd0
disk/efi/efidisk.c:593: reading 0xc0 sectors at the sector 0x100840 from hd0
disk/efi/efidisk.c:593: reading 0x100 sectors at the sector 0x100b00 from hd0
fs/zfs/zfs.c:1192: label ok 1
disk/efi/efidisk.c:593: reading 0x40 sectors at the sector 0x100a00 from hd0
disk/efi/efidisk.c:593: reading 0xc0 sectors at the sector 0x100a40 from hd0
disk/efi/efidisk.c:593: reading 0x100 sectors at the sector 0x2400500 from hd0
fs/zfs/zfs.c:1192: label ok 2
disk/efi/efidisk.c:593: reading 0x40 sectors at the sector 0x2400400 from hd0
disk/efi/efidisk.c:593: reading 0xc0 sectors at the sector 0x2400440 from hd0
disk/efi/efidisk.c:593: reading 0x100 sectors at the sector 0x2400700 from hd0
fs/zfs/zfs.c:1192: label ok 3
disk/efi/efidisk.c:593: reading 0x40 sectors at the sector 0x2400600 from hd0
disk/efi/efidisk.c:593: reading 0xc0 sectors at the sector 0x2400640 from hd0
kern/fs.c:78: zfs detection failed.
kern/fs.c:56: Detecting xfs...
fs/xfs.c:907: Reading sb
fs/xfs.c:257: Validating superblock
kern/fs.c:78: xfs detection failed.
kern/fs.c:56: Detecting squash4...
kern/fs.c:78: squash4 detection failed.
kern/fs.c:56: Detecting ntfs...
kern/fs.c:78: ntfs detection failed.
kern/fs.c:56: Detecting jfs...
kern/fs.c:78: jfs detection failed.
kern/fs.c:56: Detecting iso9660...
kern/fs.c:78: iso9660 detection failed.
kern/fs.c:56: 

Bug#959425: loopback command hangs in 2.04 under UEFI

[Bernhard Übelacker]

Dear Maintainer,
I could reproduce this issue with these grub images
inside a QEmu EFI enabled VM (no secureboot enabled).

grub-efi-amd64-signed: /usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed
grub-efi-amd64-bin:/usr/lib/grub/x86_64-efi/monolithic/grubx64.efi

Further tried to track it down by manually creating the
image like it is done in grub2-2.04/debian/build-efi-images.

At the end I had a not hanging image, where just the "tpm"
module was left out.

Kind regards,
Bernhard

5956434be4b81e6376151b64ef9b1596  debian-10.3.0-amd64-netinst.iso

loopback loop /debian-10.3.0-amd64-netinst.iso


#
#



# Bullseye/testing amd64 qemu VM 2020-05-03

apt update
apt dist-upgrade


apt install efitools fakeroot mc
apt build-dep grub2



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



#
#



apt install grub-efi-amd64-signed
Die folgenden NEUEN Pakete werden installiert:
  grub-efi-amd64-signed mokutil shim-helpers-amd64-signed shim-signed 
shim-signed-common shim-unsigned



root@debian:~# dpkg -l | grep -i grub
ii  grub-common   2.04-7 amd64
GRand Unified Bootloader (common files)
ii  grub-efi-amd642.04-7 amd64
GRand Unified Bootloader, version 2 (EFI-AMD64 version)
ii  grub-efi-amd64-bin2.04-7 amd64
GRand Unified Bootloader, version 2 (EFI-AMD64 modules)
ii  grub-efi-amd64-signed 1+2.04+7   amd64
GRand Unified Bootloader, version 2 (amd64 UEFI signed by Debian)
ii  grub2-common  2.04-7 amd64
GRand Unified Bootloader (common files for version 2)

root@debian:~# dpkg -L grub-efi-amd64-signed
...
/usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed
...

root@debian:~# md5sum /boot/efi/EFI/debian/
BOOTX64.CSV  fbx64.efigrub.cfg grubx64.efi  mmx64.efishimx64.efi  
root@debian:~# md5sum /boot/efi/EFI/debian/grubx64.efi 
b9a9e8799558393ac6e50f111ff11719  /boot/efi/EFI/debian/grubx64.efi
root@debian:~# file /boot/efi/EFI/debian/grubx64.efi
/boot/efi/EFI/debian/grubx64.efi: PE32+ executable (EFI application) x86-64 
(stripped to external PDB), for MS Windows
root@debian:~# ls -lisah /boot/efi/EFI/debian/grubx64.efi
22 1,6M -rwx-- 1 root root 1,6M Mai  3 09:17 
/boot/efi/EFI/debian/grubx64.efi

root@debian:~# md5sum /usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed
b9a9e8799558393ac6e50f111ff11719  
/usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed
root@debian:~# file /usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed
/usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed: PE32+ executable (EFI 
application) x86-64 (stripped to external PDB), for MS Windows
root@debian:~# ls -lisah /usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed
919451 1,6M -rw-r--r-- 1 root root 1,6M Apr 22 15:52 
/usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed

-> Hangs



#



dpkg --purge grub-efi-amd64-signed
grub-install

root@debian:~# md5sum /boot/efi/EFI/debian/grubx64.efi 
5e1c77f5da51d2ed6500315f2d662bda  /boot/efi/EFI/debian/grubx64.efi

root@debian:~# dpkg -S grubx64
grub-efi-amd64-bin: /usr/lib/grub/x86_64-efi/monolithic/grubx64.efi

root@debian:~# md5sum /usr/lib/grub/x86_64-efi/monolithic/grubx64.efi
c440c1cb17c6f6442fa72bb256d191d1  
/usr/lib/grub/x86_64-efi/monolithic/grubx64.efi

root@debian:~# ls -lisah /boot/efi/EFI/debian/grubx64.efi 
/usr/lib/grub/x86_64-efi/monolithic/grubx64.efi
22 128K -rwx-- 1 root root 128K Mai  3 11:05 
/boot/efi/EFI/debian/grubx64.efi
927732 1,6M -rw-r--r-- 1 root root 1,6M Apr 22 15:52 
/usr/lib/grub/x86_64-efi/monolithic/grubx64.efi

cp /usr/lib/grub/x86_64-efi/monolithic/grubx64.efi 
/boot/efi/EFI/debian/grubx64.efi

-> Hangs



#



root@debian:~# grub-install 
x86_64-efi wird für Ihre Plattform installiert.
installation beendet. Keine Fehler aufgetreten.
root@debian:~# md5sum /boot/efi/EFI/debian/grubx64.efi 
5e1c77f5da51d2ed6500315f2d662bda  /boot/efi/EFI/debian/grubx64.efi


-> Works



#



cp /usr/lib/grub/x86_64-efi/monolithic/grubx64.efi 
/boot/efi/EFI/debian/grubx64-backup.efi



workdir=/tmp
platform=x86_64-efi
GRUB_MODULES="all_video boot btrfs cat chain configfile echo efifwsetup efinet 
ext2 fat font f2fs gettext gfxmenu gfxterm gfxterm_background gzio halt help 
hfsplus iso9660 jfs jpeg keystatus loadenv loopback linux ls lsefi lsefimmap 
lsefisystab lssal memdisk minicmd normal ntfs part_apple part_msdos part_gpt 
password_pbkdf2 png probe reboot regexp search search_fs_uuid search_fs_file 
search_label sleep squash4 test true video xfs zfs zfscrypt zfsinfo cpuid 
linuxefi play tpm cryptodisk gcry_arcfour gcry_blowfish gcry_camellia 
gcry_cast5 gcry_crc gcry_des gcry_dsa gcry_idea gcry_md4 gcry_md5 gcry_rfc2268 
gcry_rijndael gcry_rmd160 gcry_rsa gcry_seed gcry_serpent gcry_sha1 gcry_sha256 
gcry_sha512 gcry_tiger gcry_twofish 

Bug#959400: mesa: SIGSEGV in iris_dri.so using mpv or glxgears, Intel HD Graphics 620

[Bernhard Übelacker]

Dear Maintainer,
the given backtraces are similar to the ones attached in this message:

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

Kind regards,
Bernhard

Bug#959432: gdm3: server crashes after 90 seconds frozen on Wayland

[Bernhard Übelacker]

Hello Francisco Gómez,
not deeper involved in packaging of gdm3, I might have a hint
to get a better backtrace from the core file.

You seem to opened the core just with gdb, therefore the
backtrace is lacking module information.
Could you please add the executable to the gdb command line e.g.

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

This should show at least some function names and module informations.

Additionally maybe you could install xwayland-dbgsym [1] and repeat
the gdb operation, then it should print some source line information too.

Kind regards,
Bernhard

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

Bug#959223: fcitx won't start anymore

[Bernhard Übelacker]

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



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

Below are the source locations where the backtraces points to.

Kind regards,
Bernhard




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


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

Bug#954651: gimp: Shrinking layer with cubic interpolation causes a segmentation fault

[Bernhard Übelacker]

Dear Maintainer,
if it may be of any help, below is the backtrace from
the submitter, with line information manually added.

Could not find a complete match in upstream bugs, just one
mentioning OpenCL is not yet stable - is this still the case?

Kind regards,
Bernhard


0x779c0398 in gimp_stack_trace_print at gimputils.c:1381
0x5562b980 in gimp_eek at errors.c:377
0x5562bda8 in gimp_fatal_error at errors.c:234
0x5562c419 in gimp_sigfatal_handler at signals.c:179
0x76eb7110 <__restore_rt>
0x7758c591 in _gegl_buffer_cl_cache_flush2 at 
../gegl/opencl/gegl-buffer-cl-cache.c:143
0x7757e2b7 in gegl_tile_handler_cache_get_tile_command at 
../gegl/buffer/gegl-tile-handler-cache.c:192
0x55a541a5 in gegl_tile_source_command at 
/usr/include/gegl-0.4/gegl-tile-source.h:72
0x7757f64a in gegl_tile_source_command at 
../gegl/buffer/gegl-tile-source.h:98
0x7757ef5c in gegl_tile_source_command at 
../gegl/buffer/gegl-tile-source.h:98
0x775680d4 in gegl_tile_source_command at 
../gegl/buffer/gegl-tile-source.h:98
0x7755ce70 in gegl_tile_source_command at 
../gegl/buffer/gegl-tile-source.h:98
0x7755e3d2 in gegl_buffer_iterate_read_dispatch at 
../gegl/buffer/gegl-buffer-access.c:1864
0x7755f8dc in _gegl_buffer_get_unlocked at 
../gegl/buffer/gegl-buffer-access.c:2293
0x557245ea in gimp_display_shell_render at gimpdisplayshell-render.c:274
0x5571f9e2 in gimp_display_shell_draw_image at gimpdisplayshell-draw.c:234
0x5571c4e1 in gimp_display_shell_canvas_draw_image at 
gimpdisplayshell-callbacks.c:568
0x77c14a8b in _gtk_marshal_BOOLEAN__BOXED at 
../../../../gtk/gtkmarshalers.c:84
0x77148fd2 in g_closure_invoke at ../../../gobject/gclosure.c:810
0x7715c784 in signal_emit_unlocked_R at ../../../gobject/gsignal.c:3742
0x77167078 in g_signal_emit_valist at ../../../gobject/gsignal.c:3508
0x77167edf in g_signal_emit at ../../../gobject/gsignal.c:3554
0x77d2c9e4 in gtk_widget_event_internal at ../../../../gtk/gtkwidget.c:5010
0x77c13380 in IA__gtk_main_do_event at ../../../../gtk/gtkmain.c:1623
0x77a6b98f in _gdk_window_process_updates_recurse at 
../../../../gdk/gdkwindow.c:5479
0x77a6b93b in _gdk_window_process_updates_recurse at 
../../../../gdk/gdkwindow.c:5452
0x77a6b93b in _gdk_window_process_updates_recurse at 
../../../../gdk/gdkwindow.c:5452
0x77a6845d in gdk_window_process_updates_internal at 
../../../../gdk/gdkwindow.c:5646
0x77a68d90 in IA__gdk_window_process_all_updates at 
../../../../gdk/gdkwindow.c:5752
0x77b985b1 in gtk_container_idle_sizer at 
../../../../gtk/gtkcontainer.c:1360
0x77a47865 in gdk_threads_dispatch at ../../../../gdk/gdk.c:534
0x7705e4de in g_main_dispatch at ../../../glib/gmain.c:3309
0x7705e890 in g_main_context_iterate at ../../../glib/gmain.c:4047
0x7705eb63 in g_main_loop_run at ../../../glib/gmain.c:4241
0x5562b176 in app_run at app.c:433
0x5562aa4e in main at main.c:531
0x76d04e0b in __libc_start_main at ../csu/libc-start.c:308
0x5562abda <_start+36>


https://sources.debian.org/src/gegl/0.4.22-3/gegl/opencl/gegl-buffer-cl-cache.c/#L143
https://gitlab.gnome.org/GNOME/gegl/-/blob/master/gegl/opencl/gegl-buffer-cl-cache.c#L143
https://gitlab.gnome.org/GNOME/gimp/-/issues/3622

Bug#958104: system-config-printer-udev: ABRT: free(): invalid pointer

[Bernhard Übelacker]

Dear Maintainer,
looking at the backtrace from message 13 and at the changes
done by upstream, following commit sounds related:

https://github.com/OpenPrinting/system-config-printer/commit/b9289dfe105bdb502f183f0afe7a115ecae5f2af#diff-d3f2f90b6e176486d4b8dfe3222577f7

Kind regards,
Bernhard

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

[Bernhard Übelacker]

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

It crashes with the backtrace below.

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

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

Kind regards,
Bernhard




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





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







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

Buster i386 qemu VM 2020-04-27

apt update
apt dist-upgrade


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




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


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



dmesg:
[  344.474571] etherape[918]: segfault at 0 ip b6da9726 sp bfb69ed8 error 4 in 

Bug#949699: 0ad dies with 'Assertion failed: "cache.Validate()"'

[Bernhard Übelacker]

Dear Maintainer,
I tried to have a look at the first call stack, and
could reconstruct it using the dbgsym package to the
backtrace below.

@Bob Ham:
could you supply some information about the CPU you are using.
If it is an AMD Ryzen 3xxx the first two links below might describe
your issue and the third link points to a workaround patch for this CPU.

Kind regards,
Bernhard


0x55b661de in debug_DumpStack(wchar_t*, unsigned long, void*, wchar_t 
const*) at ../../../source/lib/sysdep/os/linux/ldbg.cpp:82
0x55b11c51 in debug_BuildErrorMessage(wchar_t const*, wchar_t const*, int, 
char const*, void*, wchar_t const*, ErrorMessageMem*) at 
../../../source/lib/debug.cpp:304
0x55b13148 in debug_DisplayError(wchar_t const*, unsigned long, void*, 
wchar_t const*, wchar_t const*, int, char const*, long volatile*) at 
../../../source/lib/debug.cpp:471
0x55b13648 in debug_OnAssertionFailure(wchar_t const*, long volatile*, 
wchar_t const*, int, char const*) at /usr/include/c++/8/bits/basic_string.h:2290
0x55b5e59e in x86_x64::AddCache(x86_x64::Cache const&) at 
../../../source/lib/sysdep/arch/x86_x64/cache.cpp:43
0x55b5ebf4 in x86_x64::AMD::DetectCacheAndTLB() at 
../../../source/lib/sysdep/arch/x86_x64/cache.cpp:130
0x55b5f0b5 in x86_x64::DetectCacheAndTLB() at 
../../../source/lib/sysdep/arch/x86_x64/cache.cpp:623
0x55b94343 in ModuleInit(long volatile*, long (*)()) at 
../../../source/lib/module_init.cpp:46
0x55b5f8fe in x86_x64::Caches(unsigned long) at 
../../../source/lib/sysdep/arch/x86_x64/cache.cpp:652
0x55b6078a in topology::MaxLogicalPerCache at 
../../../source/lib/sysdep/arch/x86_x64/topology.cpp:392
0x55b94343 in ModuleInit(long volatile*, long (*)()) at 
../../../source/lib/module_init.cpp:46
0x55b6036a in topology::NumCaches() at 
../../../source/lib/sysdep/arch/x86_x64/topology.cpp:456
0x5580161f in RunHardwareDetection() at 
../../../source/ps/GameSetup/HWDetect.cpp:310
0x557f8329 in InitGraphics(CmdLineArgs const&, int, std::vector > const&) at 
../../../source/ps/GameSetup/GameSetup.cpp:1001
0x55608691 in RunGameOrAtlas(int, char const**) at 
../../../source/main.cpp:631
0x555f40b7 in main(int, char**) at ../../../source/main.cpp:680


https://wildfiregames.com/forum/index.php?/topic/27550-problems-with-0ad/
https://wildfiregames.com/forum/index.php?/topic/26890-problem-with-ryzen-3000er-series/page/2/
https://github.com/0ad/0ad/commit/c6c8774a0712a80408bd07f9d9250b242753f713#diff-746bc8707bf20685fe8c98acfacb304f

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

[Bernhard Übelacker]

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

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

Bug#934680: gjs-console crashed with signal 5

[Bernhard Übelacker]

merge 934680 934770

Bug#956119: asterisk: segfault in libspandsp.so.2.0.0 when using Set(FAXOPT(gateway)=yes,30) between SIP and iax

[Bernhard Übelacker]

Dear Maintainer,
I tried to extract from the submitter's dmesg line the
source location of the crash.

I assume it happened here [1], with
variable s containing an invalid pointer:

0x77f5bb90 in update_rx_timing at t38_gateway.c:2244

2242 static void update_rx_timing(t38_gateway_state_t *s, int len)
2243 {
2244 if (s->core.samples_to_timeout > 0)
2245 {

https://sources.debian.org/src/spandsp/0.0.6+dfsg-2/src/t38_gateway.c/#L2244


Maybe it is of some help.
But a proper backtrace like described in following link would probably
be way better: https://wiki.debian.org/HowToGetABacktrace

Kind regards,
Bernhard


From submitter:
[14509242.948899] asterisk[27070]: segfault at 2c7b4 ip 7f9a52389b90 sp 
7f9a23d8a4f8 error 4 in libspandsp.so.2.0.0[7f9a5234d000+56000]
[14509242.948908] Code: 00 00 00 00 00 5b c3 0f 1f 00 e9 1b fd ff ff 0f 1f 00 
e8 33 ef ff ff eb e2 90 e9 2b ef ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 <8b> 87 
8c 2c 00 00 85 c0 7e 0c 29 f0 89 87 8c 2c 00 00 85 c0 7e 0a


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

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












# Buster/stable amd64 qemu VM 2020-04-07

apt update
apt dist-upgrade

apt install systemd-coredump gdb asterisk asterisk-dbgsym libspandsp2-dbgsym



echo -n "find /b ..., ..., 0x" && \
echo "00 00 00 00 00 5b c3 0f 1f 00 e9 1b fd ff ff 0f 1f 00 e8 33 ef ff ff eb 
e2 90 e9 2b ef ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 <8b> 87 8c 2c 00 00 85 c0 
7e 0c 29 f0 89 87 8c 2c 00 00 85 c0 7e 0a" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'



gdb -q
set width 0
set pagination off
file /usr/sbin/asterisk
set environment LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libspandsp.so.2.0.0
b main
run
dele 1
info share

find /b 0x77f20520, 0x77f7473f, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x5b, 0xc3, 0x0f, 0x1f, 0x00, 0xe9, 0x1b, 0xfd, 0xff, 0xff, 0x0f, 0x1f, 0x00, 
0xe8, 0x33, 0xef, 0xff, 0xff, 0xeb, 0xe2, 0x90, 0xe9, 0x2b, 0xef, 0xff, 0xff, 
0x66, 0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x8b, 0x87, 
0x8c, 0x2c, 0x00, 0x00, 0x85, 0xc0, 0x7e, 0x0c, 0x29, 0xf0, 0x89, 0x87, 0x8c, 
0x2c, 0x00, 0x00, 0x85, 0xc0, 0x7e, 0x0a

b * (0x77f5bb66 + 42)
info b
disassemble /r 0x77f5bb66, 0x77f5bb66 + 62

set max-value-size 10



#




benutzer@debian:~$ echo -n "find /b ..., ..., 0x" && \
> echo "00 00 00 00 00 5b c3 0f 1f 00 e9 1b fd ff ff 0f 1f 00 e8 33 ef ff ff eb 
> e2 90 e9 2b ef ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 <8b> 87 8c 2c 00 00 85 
> c0 7e 0c 29 f0 89 87 8c 2c 00 00 85 c0 7e 0a" \
>  | sed 's/[<>]//g' | sed 's/ /, 0x/g'
find /b ..., ..., 0x00, 0x00, 0x00, 0x00, 0x00, 0x5b, 0xc3, 0x0f, 0x1f, 0x00, 
0xe9, 0x1b, 0xfd, 0xff, 0xff, 0x0f, 0x1f, 0x00, 0xe8, 0x33, 0xef, 0xff, 0xff, 
0xeb, 0xe2, 0x90, 0xe9, 0x2b, 0xef, 0xff, 0xff, 0x66, 0x66, 0x2e, 0x0f, 0x1f, 
0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x8b, 0x87, 0x8c, 0x2c, 0x00, 0x00, 0x85, 
0xc0, 0x7e, 0x0c, 0x29, 0xf0, 0x89, 0x87, 0x8c, 0x2c, 0x00, 0x00, 0x85, 0xc0, 
0x7e, 0x0a

benutzer@debian:~$ gdb -q
(gdb) set width 0
(gdb) set pagination off
(gdb) file /usr/sbin/asterisk
Reading symbols from /usr/sbin/asterisk...Reading symbols from 
/usr/lib/debug/.build-id/23/f49a19a60d0fecbf537ba0f24d2f05792ccf44.debug...done.
done.
(gdb) set environment LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libspandsp.so.2.0.0
(gdb) b main
Breakpoint 1 at 0x42e40: file asterisk.c, line 3488.
(gdb) run
Starting program: /usr/sbin/asterisk 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, main (argc=1, argv=0x7fffe5d8) at asterisk.c:3488
3488asterisk.c: Datei oder Verzeichnis nicht gefunden.
(gdb) dele 1
(gdb) info share
FromTo  Syms Read   Shared Object Library
...
0x77f20520  0x77f7473f  Yes 
/usr/lib/x86_64-linux-gnu/libspandsp.so.2.0.0
...
(*): Shared library is missing debugging information.
(gdb) find /b 0x77f20520, 0x77f7473f, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x5b, 0xc3, 0x0f, 0x1f, 0x00, 0xe9, 0x1b, 0xfd, 0xff, 0xff, 0x0f, 0x1f, 
0x00, 0xe8, 0x33, 0xef, 0xff, 0xff, 0xeb, 0xe2, 0x90, 0xe9, 0x2b, 0xef, 0xff, 
0xff, 0x66, 0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x8b, 
0x87, 0x8c, 0x2c, 0x00, 0x00, 0x85, 0xc0, 0x7e, 0x0c, 0x29, 0xf0, 0x89, 0x87, 
0x8c, 0x2c, 0x00, 0x00, 0x85, 0xc0, 0x7e, 0x0a
0x77f5bb66 
1 pattern found.
(gdb) b * (0x77f5bb66 + 42)
Breakpoint 2 at 0x77f5bb90: file t38_gateway.c, line 2244.
(gdb) info b
Num Type   Disp Enb AddressWhat
2   breakpoint keep y   0x77f5bb90 in update_rx_timing at 
t38_gateway.c:2244
(gdb) disassemble /r 0x77f5bb66, 0x77f5bb66 + 62
Dump of assembler code from 0x77f5bb66 to 0x77f5bba4:
   0x77f5bb66 :00 00   
add%al,(%rax)
   0x77f5bb68 :00 00   
add

Bug#955279: sysdig: undefined symbol: _ZN4grpc13ClientContextC1Ev

[Bernhard Übelacker]

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

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

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

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

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

Kind regards,
Bernhard


_ZN4grpc13ClientContextC1Ev

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







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

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






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

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


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

apt update
apt dist-upgrade


apt install systemd-coredump binutils sysdig


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


##


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

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

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


##



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

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



##



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

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



##



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

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



##



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

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



##


grpc 1.22.0-1, not available for amd64


##



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

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

Bug#955747: libgl1-mesa-dri: all GL programms crash on startup

[Bernhard Übelacker]

Hello Felix Rublack,
I do not know if the maintainer are able to reproduce this issue,
but instead or additional to the strace a backtrace of the crash
might help them. The easiest way might be to install systemd-coredump
and look at "journalctl -e" after a crash. More info in [1].
(Even better with debug symbols installed.)

Nevertheless the segfault lines in dmesg lead to
following locations in iris_dri.so:

mpv/vo:
  function iris_resource_bo called from function stream_state:

https://sources.debian.org/src/mesa/20.0.2-1/src/gallium/drivers/iris/iris_resource.h/#L290

https://sources.debian.org/src/mesa/20.0.2-1/src/gallium/drivers/iris/iris_blorp.c/#L60
   until L63

vlc:
glxgears:
  function GEN9_3DSTATE_VERTEX_ELEMENTS_pack called from iris_blorp_exec:
file src/intel/genxml/gen9_pack.h, line 6901. (unfortunately a generated 
file?)
maybe related to 
https://sources.debian.org/src/mesa/20.0.2-1/src/intel/blorp/blorp_genX_exec.h/#L550

Kind regards,
Bernhard

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

From submitter:

[   37.001269] mpv/vo[1739]: segfault at a0 ip 7fe5d34a62a8 sp 
7fe5e6092de0 error 4 in iris_dri.so[7fe5d2a8d000+d2e000]
[   37.001276] Code: 44 24 18 48 c7 44 24 10 00 00 00 00 48 c7 44 24 18 00 00 
00 00 50 4c 8d 4c 24 18 e8 e2 a4 b6 ff 48 8b 44 24 18 31 d2 48 89 ef <4c> 8b b0 
a0 00 00 00 4c 89 f6 e8 09 94 fd ff 48 8b bd 28 01 00 00

[   46.41] vlc[1778]: segfault at 24 ip 7fcc272a4c06 sp 
7fcbf9e01c50 error 6 in iris_dri.so[7fcc2688b000+d2e000]
[   46.420006] Code: 7e 30 44 01 ff 81 ff ff ff 00 00 0f 87 ab 17 00 00 49 01 
c7 4c 89 7e 38 48 85 c0 0f 84 2c 02 00 00 83 ea 01 81 ca 00 00 09 78 <89> 10 48 
8d 50 04 45 85 ed 74 74 41 8d 75 ff 48 8d 74 f0 0c 66 0f

[   57.343120] glxgears[1785]: segfault at 24 ip 7f4a1467ec06 sp 
7ffd2389b2f0 error 6 in iris_dri.so[7f4a13c65000+d2e000]
[   57.343126] Code: 7e 30 44 01 ff 81 ff ff ff 00 00 0f 87 ab 17 00 00 49 01 
c7 4c 89 7e 38 48 85 c0 0f 84 2c 02 00 00 83 ea 01 81 ca 00 00 09 78 <89> 10 48 
8d 50 04 45 85 ed 74 74 41 8d 75 ff 48 8d 74 f0 0c 66 0f


https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash


"error 4"   ==   0: no page found, 0: read access,  1: user-mode access
"error 6"   ==   0: no page found, 1: write access, 1: user-mode access



echo -n "find /b ..., ..., 0x" && \
> echo "44 24 18 48 c7 44 24 10 00 00 00 00 48 c7 44 24 18 00 00 00 00 50 4c 8d 
> 4c 24 18 e8 e2 a4 b6 ff 48 8b 44 24 18 31 d2 48 89 ef <4c> 8b b0 a0 00 00 00 
> 4c 89 f6 e8 09 94 fd ff 48 8b bd 28 01 00 00" \
>  | sed 's/[<>]//g' | sed 's/ /, 0x/g'
find /b ..., ..., 0x44, 0x24, 0x18, 0x48, 0xc7, 0x44, 0x24, 0x10, 0x00, 0x00, 
0x00, 0x00, 0x48, 0xc7, 0x44, 0x24, 0x18, 0x00, 0x00, 0x00, 0x00, 0x50, 0x4c, 
0x8d, 0x4c, 0x24, 0x18, 0xe8, 0xe2, 0xa4, 0xb6, 0xff, 0x48, 0x8b, 0x44, 0x24, 
0x18, 0x31, 0xd2, 0x48, 0x89, 0xef, 0x4c, 0x8b, 0xb0, 0xa0, 0x00, 0x00, 0x00, 
0x4c, 0x89, 0xf6, 0xe8, 0x09, 0x94, 0xfd, 0xff, 0x48, 0x8b, 0xbd, 0x28, 0x01, 
0x00, 0x00


$ echo -n "find /b ..., ..., 0x" && \
> echo "7e 30 44 01 ff 81 ff ff ff 00 00 0f 87 ab 17 00 00 49 01 c7 4c 89 7e 38 
> 48 85 c0 0f 84 2c 02 00 00 83 ea 01 81 ca 00 00 09 78 <89> 10 48 8d 50 04 45 
> 85 ed 74 74 41 8d 75 ff 48 8d 74 f0 0c 66 0f" \
>  | sed 's/[<>]//g' | sed 's/ /, 0x/g'
find /b ..., ..., 0x7e, 0x30, 0x44, 0x01, 0xff, 0x81, 0xff, 0xff, 0xff, 0x00, 
0x00, 0x0f, 0x87, 0xab, 0x17, 0x00, 0x00, 0x49, 0x01, 0xc7, 0x4c, 0x89, 0x7e, 
0x38, 0x48, 0x85, 0xc0, 0x0f, 0x84, 0x2c, 0x02, 0x00, 0x00, 0x83, 0xea, 0x01, 
0x81, 0xca, 0x00, 0x00, 0x09, 0x78, 0x89, 0x10, 0x48, 0x8d, 0x50, 0x04, 0x45, 
0x85, 0xed, 0x74, 0x74, 0x41, 0x8d, 0x75, 0xff, 0x48, 0x8d, 0x74, 0xf0, 0x0c, 
0x66, 0x0f






# Unstable amd64 qemu VM 2020-04-04

apt update
apt dist-upgrade


apt install systemd-coredump sddm xserver-xorg openbox xterm gdb mesa-utils 
mesa-utils-dbgsym libgl1-mesa-dri-dbgsym


gdb -q
set width 0
set pagination off
file /usr/bin/glxgears
b main
set environment LD_PRELOAD=/usr/lib/x86_64-linux-gnu/dri/iris_dri.so
run
dele 1
info share
find ...
b * (... + 42)
info b






$ gdb -q
(gdb) set width 0
(gdb) set pagination off
(gdb) file /usr/bin/glxgears
Reading symbols from /usr/bin/glxgears...
Reading symbols from 
/usr/lib/debug/.build-id/40/dc623a2c150d26c9229676fba7f45a49aed7d7.debug...
(gdb) b main
Breakpoint 1 at 0x2410: file glxgears.c, line 723.
(gdb) set environment LD_PRELOAD=/usr/lib/x86_64-linux-gnu/dri/iris_dri.so
(gdb) run
Starting program: /usr/bin/glxgears 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, main (argc=1, argv=0x7fffe608) at glxgears.c:723
723 glxgears.c: Datei oder Verzeichnis nicht gefunden.
(gdb) dele 1
(gdb) info share
FromTo  Syms Read   Shared Object Library
...
0x76a5e010  0x77788b1e  Yes 
/usr/lib/x86_64-linux-gnu/dri/iris_dri.so
...
(*): Shared library is missing 

Bug#955407: linux-image-4.19.0-8-amd64: "Uhhuh. NMI received for unknown reason" on AMD Ryzen

[Bernhard Übelacker]

Dear Maintainer,
I observed such logging, too. My system is similar to the submitters one.
Found two occourences in still available kern.log* files. (See attached file.)

One was most probably related to a "GPU fault" 25 seconds before,
running 4.19.0-8-amd64/4.19.98-1.

The other was while not being at the idling system,
running 5.4.0-0.bpo.3-amd64/5.4.13-1~bpo10+1.
No negative consequence found at that time.

Kind regards,
Bernhard
# LANG=C lscpu
...
CPU family:  23
Model:   1
Model name:  AMD Ryzen 7 1700 Eight-Core Processor
Stepping:1
...


# (zcat kern.log.4.gz kern.log.3.gz kern.log.2.gz; cat kern.log.1 kern.log) | grep -E "NMI received|Linux version" -A3

Mar  7 00:10:29 rechner kernel: [0.00] Linux version 4.19.0-8-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.98-1 (2020-01-26)
...
Mar  7 00:10:29 rechner kernel: [0.00] DMI: System manufacturer System Product Name/PRIME B350M-A, BIOS 4801 04/25/2019
...
Mar  7 00:13:49 rechner kernel: [  205.788363] amdgpu :08:00.0: GPU fault detected: 147 0x0c304401 for process SOTTR.exe pid 3426 thread SOTTR.exe:cs0 pid 3448
Mar  7 00:13:49 rechner kernel: [  205.788370] amdgpu :08:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x0FF22786
Mar  7 00:13:49 rechner kernel: [  205.788373] amdgpu :08:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0E044001
Mar  7 00:13:49 rechner kernel: [  205.788378] amdgpu :08:00.0: VM fault (0x01, vmid 7, pasid 32782) at page 267528070, read from 'TC1' (0x54433100) (68)
...
Mar  7 00:13:49 rechner kernel: [  205.788463] amdgpu :08:00.0: VM fault (0x01, vmid 7, pasid 32782) at page 142747517, read from 'TC1' (0x54433100) (68)
Mar  7 00:13:59 rechner kernel: [  215.998608] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=25858, emitted seq=25860
Mar  7 00:13:59 rechner kernel: [  215.998615] [drm] GPU recovery disabled.
Mar  7 00:14:14 rechner kernel: [  230.580910] Uhhuh. NMI received for unknown reason 2d on CPU 7.
Mar  7 00:14:14 rechner kernel: [  230.580911] Do you have a strange power saving mode enabled?
Mar  7 00:14:14 rechner kernel: [  230.580914] Dazed and confused, but trying to continue
Mar  7 00:15:17 rechner kernel: [  294.139939] sysrq: SysRq : Keyboard mode set to system default
Mar  7 00:15:20 rechner kernel: [  296.891922] sysrq: SysRq : Terminate All Tasks

(attempt to test Shadow of the Tomb Raider Trial via Steam, kernel crash dump available, at least the "GPU fault" was reproducible.)

--

Mar 26 10:00:52 rechner kernel: [0.00] Linux version 5.4.0-0.bpo.3-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 5.4.13-1~bpo10+1 (2020-02-07)
...
Mar 26 10:00:52 rechner kernel: [0.00] DMI: System manufacturer System Product Name/PRIME B350M-A, BIOS 4801 04/25/2019
...
Mar 29 07:27:08 rechner kernel: [246383.312487] Uhhuh. NMI received for unknown reason 3c on CPU 6.
Mar 29 07:27:08 rechner kernel: [246383.312488] Do you have a strange power saving mode enabled?
Mar 29 07:27:08 rechner kernel: [246383.312489] Dazed and confused, but trying to continue
Mar 29 07:35:37 rechner kernel: [246892.656398] Process accounting resumed

(system was at this time idle, no negative consequences recognized, system could be shutdown later without problems.)

Bug#562625: rovclock: Floating point exception on ATI Mobility Radeon HD 4570

[Bernhard Übelacker]

Hello,
tries to find a way to underclock the gpu of an HP elitebook 8460p
with a radeon HD 6470M, because it does not handle well the 3d
requirements of a current plasma desktop and leads to the laptop
turning just off. (Turning off the compositor as a workaround.)

So "rovclock -i" leads on that system to the same exception.

This is just for the record as there might not be any
update for this package.

Kind regards,
Bernhard


(gdb) bt
#0  0x55acfe349488 in round_div (den=, num=) 
at rovclock.c:178
#1  pll_info (rovclock=0x7ffc745acac0) at rovclock.c:256
#2  0x55acfe348e0c in main (argc=2, argv=0x7ffc745acc38) at rovclock.c:463


https://sources.debian.org/src/rovclock/0.6e-7/rovclock.c/#L178
https://sources.debian.org/src/rovclock/0.6e-7/rovclock.c/#L256

# rovclock -i
Radeon overclock 0.6e by Hasw (h...@hasw.net)

Found ATI card on 01:00, device id: 0x6760
I/O base address: 0x4000
Video BIOS shadow found @ 0xc
Invalid reference clock from BIOS: 0.0 MHz
Memory size: 0 kB
Memory channels: 1, CD,CH only: 0
tRcdRD:   3
tRcdWR:   1
tRP:  3
tRAS: 6
tRRD: 1
tR2W-CL:  1
tWR:  1
tW2R: 0
tW2Rsb:   0
tR2R: 1
tRFC: 13
tWL(0.5): 0
tCAS: 0
tCMD: 0
tSTR: 0
Gleitkomma-Ausnahme (Speicherabzug geschrieben)


dmesg:
[  357.622976] traps: rovclock[1975] trap divide error ip:55acfe349488 
sp:7ffc745acaa0 error:0 in rovclock[55acfe348000+3000]



journalctl -e



# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Mon 2020-03-30 15:29:40 CEST   1975 0 0   8 present   /usr/sbin/rovclock



# coredumpctl gdb
   PID: 1975 (rovclock)
   UID: 0 (root)
   GID: 0 (root)
Signal: 8 (FPE)
 Timestamp: Mon 2020-03-30 15:29:40 CEST (1min 39s ago)
  Command Line: rovclock -i
Executable: /usr/sbin/rovclock
 Control Group: /user.slice/user-1000.slice/session-5.scope
  Unit: session-5.scope
 Slice: user-1000.slice
   Session: 5
 Owner UID: 1000 (benutzer)
   Boot ID: bff2520b59914f03b61e4827890a413a
Machine ID: c6f75e824dc44bdaaa07b94b9f66a5b3
  Hostname: hpelitebook
   Storage: 
/var/lib/systemd/coredump/core.rovclock.0.bff2520b59914f03b61e4827890a413a.1975.158557498000.lz4
   Message: Process 1975 (rovclock) of user 0 dumped core.

Stack trace of thread 1975:
#0  0x55acfe349488 n/a (rovclock)
#1  0x55acfe348e0c n/a (rovclock)
#2  0x7fd888b2c09b __libc_start_main (libc.so.6)
#3  0x55acfe348f7a n/a (rovclock)

GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/rovclock...(no debugging symbols found)...done.
[New LWP 1975]
Core was generated by `rovclock -i'.
Program terminated with signal SIGFPE, Arithmetic exception.
#0  0x55acfe349488 in ?? ()
(gdb) bt
#0  0x55acfe349488 in ?? ()
#1  0x55acfe348e0c in ?? ()
#2  0x7fd888b2c09b in __libc_start_main (main=0x55acfe348c90, argc=2, 
argv=0x7ffc745acc38, init=, fini=, 
rtld_fini=, stack_end=0x7ffc745acc28) at ../csu/libc-start.c:308
#3  0x55acfe348f7a in ?? ()



# With rovclock-dbgsym installed

Core was generated by `rovclock -i'.
Program terminated with signal SIGFPE, Arithmetic exception.
#0  0x55acfe349488 in round_div (den=, num=) 
at rovclock.c:178
178 rovclock.c: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0  0x55acfe349488 in round_div (den=, num=) 
at rovclock.c:178
#1  pll_info (rovclock=0x7ffc745acac0) at rovclock.c:256
#2  0x55acfe348e0c in main (argc=2, argv=0x7ffc745acc38) at rovclock.c:463



https://sources.debian.org/src/rovclock/0.6e-7/rovclock.c/#L178
https://sources.debian.org/src/rovclock/0.6e-7/rovclock.c/#L256








# strace -f rovclock -i
execve("/usr/sbin/rovclock", ["rovclock", "-i"], 0x7ffe27b59230 /* 11 vars */) 
= 0
brk(NULL)   = 0x56284fd6d000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (Datei oder Verzeichnis 
nicht gefunden)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=119455, ...}) = 0
mmap(NULL, 119455, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9d5dc4f000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", 

Bug#955134: kodi-bin-dbgsym: Does not contain debug information for kodi-x11

[Bernhard Übelacker]

Package: kodi-bin-dbgsym
Version: 2:18.6+dfsg1-1
Severity: normal

Dear Maintainer,

I attempted to add line information to bug 954782.
Unfortunately I found that kodi-bin-dbgsym does not contain
the debug information for the kodi-x11 binary.

It does just contain debug information for
kodi-xrandr and libdvdnav-x86_64-linux.so.

Kind regards,
Bernhard


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

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

Versions of packages kodi-bin-dbgsym depends on:
ii  kodi-bin  2:18.6+dfsg1-1

kodi-bin-dbgsym recommends no packages.

kodi-bin-dbgsym suggests no packages.

-- no debconf information

Bug#954950: dislocker reports memory access error / segfault after call

[Bernhard Übelacker]

Hello Michael,
that is great news, just two points I want to mention:

If you want to forward information to certain people,
please send email to both, the bugs address and the person,
e.g. use "reply all" in your mail client.

And if you get e.g. "/lib/libdislocker.so.0.7" in your backtrace
instead of a real source code line, then you may try to add
additional dbgsym packages like in this case libdislocker0.7-dbgsym.
And repeat the coredumpctl step, then it should provide better
information. But not necessary now as you found the issue already.

Kind regards,
Bernhard

Bug#954739: gimp: GIMP crashed with a fatal error: fatal error: Segmentation fault

[Bernhard Übelacker]

> #6  0x5614726b3f04 in gimp_param_spec_layer_id ()
> #7  0x5614725cea67 in gimp_pdb_compat_param_spec ()
> #8  0x5614725db487 in gimp_plug_in_handle_message ()

Hello Andre,
I think this is the same thing as #953880, #953854, #953794. Please
upgrade the gimp package to version 2.10.14-3 which should fix it.

Kind regards,
Bernhard

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

[Bernhard Übelacker]

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

The allocator aborts at the backtrace below.

A valgrind run points to the same function txt_add_fragment.

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

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

The same pattern in lines 2134 to 2139.

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

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

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

Kind regards,
Bernhard



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

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





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

Bug#954935: dbgsym packages for 2:4.9.5+dfsg-5+deb10u1? (winbind crashes when queried for user)

[Bernhard Übelacker]

Dear Maintainer,
I tried to start looking at the given backtrace, but could
not find the winbind-dbgsym packages for 2:4.9.5+dfsg-5+deb10u1
like they are availabe for 2:4.9.5+dfsg-5.
At least apt did not find it in buster-proposed-updates-debug
and at snapshot.debian.org they are also not listed.
Is there a source known for the dbgsym packages?

Kind regards,
Bernhard

Bug#954950: dislocker reports memory access error / segfault after call

[Bernhard Übelacker]

Hello Michael,
I am not involved in packaging dislocker but might have some points.

This "error 14" should mean it cannot read from memory the next
instruction to execute. This makes sense as the "ip" or "RIP" has
a value of 0xbb6 which is unlikely to contain program code.

If it is possible to install e.g. systemd-coredump more details
of any crashes are tried to be collected.
I guess for this kind of crash the output of "journalctl --no-pager"
migth not reveal much more useful information,
but "coredump gdb", with the command "bt" at the "(gdb)" prompt,
might be able to show a reasonable backtrace.

This would improve if the debug symbols in package
dislocker-dbgsym could be installed, too.
More hints on the debug symbol repositories and this topic
in general are collected in [2].

Kind regards,
Bernhard

[1] https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash
"error 14" == 0x14 == 0n20 == 0b10100
-> user-mode access, fault was an instruction fetch

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

Bug#954203: Client splash and exit after login in

[Bernhard Übelacker]

Hello Gulfstream,


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

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

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


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

This has to be answered by the xrdp maintainers.


Kind regards,
Bernhard

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

Bug#954203: Client splash and exit after login in

[Bernhard Übelacker]

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

Upstream bugs are here [1].

A workaround could be to use xfreerdp like this:

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

Kind regards,
Bernhard


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

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

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

# Unstable amd64 qemu VM 2020-03-21

apt update
apt dist-upgrade

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


reboot


adduser test


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








export DISPLAY=:0








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

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

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

-> trying to connect over and over again








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

Bug#953204: postgresql-11 segmentation fault

[Bernhard Übelacker]

Hello,
I just tried to get some more information from the
second dmesg line the submitter added.

I think it crashed inside function getmissingattr because
tupleDesc->constr contains an invalid pointer e.g. -1

Maybe this is of any help, but still a proper
backtrace or core would be better.

Kind regards,
Bernhard


0x5...a06 in getmissingattr at 
./build/../src/backend/access/common/heaptuple.c:101

heaptuple.c:
...
84  getmissingattr(TupleDesc tupleDesc,
...
99  Assert(tupleDesc->constr->missing);
100 
101 attrmiss = tupleDesc->constr->missing + (attnum - 1);
102 
103 if (attrmiss->am_present)
...

https://sources.debian.org/src/postgresql-11/11.7-0+deb10u1/src/backend/access/common/heaptuple.c/#L101


dmesg from submitter:

[   77.674822] postgres[879]: segfault at 55ae73423960 ip 7fd09d6741a7 sp 
7ffc7e247c28 error 4 in libc-2.28.so[7fd09d53a000+148000]
[   77.680661] Code: f9 20 77 1f c5 fd 74 0f c5 fd d7 c1 85 c0 0f 85 df 00 00 
00 48 83 c7 20 83 e1 1f 48 83 e7 e0 eb 36 66 90 83 e1 1f 48 83 e7 e0  fd 74 
0f c5 fd d7 c1 d3 f8 85 c0 74 1b f3 0f bc c0 48 01 f8 48

[   77.690252] postgres[884]: segfault at f ip 55ae597d1a06 sp 
7ffc7e2474c0 error 4 in postgres[55ae597c5000+465000]
[   77.695474] Code: 83 c7 70 48 8d 48 01 49 39 c1 0f 84 04 01 00 00 48 89 c8 
80 bf 81 00 00 00 00 74 d8 4c 8b 5e 18 48 89 c1 48 c1 e1 04 4c 01 c1 <49> 03 4b 
10 80 39 00 74 c1 41 c6 04 02 00 48 8b 49 08 eb bd 66 0f


--> "error 4": no page found, read access, user-mode access




# Buster/stable amd64 qemu VM 2020-03-20

apt update
apt dist-upgrade

apt install systemd-coredump gdb postgresql postgresql-11-dbgsym

# dpkg -l | grep postgres
ii  postgresql11+200+deb10u3  all  
object-relational SQL database (supported version)
ii  postgresql-11 11.7-0+deb10u1  amd64
object-relational SQL database, version 11 server
ii  postgresql-11-dbgsym  11.7-0+deb10u1  amd64
debug symbols for postgresql-11
ii  postgresql-client-11  11.7-0+deb10u1  amd64
front-end programs for PostgreSQL 11
ii  postgresql-client-common  200+deb10u3 all  
manager for multiple PostgreSQL client versions
ii  postgresql-common 200+deb10u3 all  
PostgreSQL database-cluster manager




gdb -q

set width 0
set pagination off
file /usr/lib/postgresql/11/bin/postgres
b main
run
dele 1
generate-core-file /tmp/core
kill
y
q





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


gdb -q

set width 0
set pagination off
file /usr/lib/postgresql/11/bin/postgres
core /tmp/core
info target

...
Local exec file:
`/usr/lib/postgresql/11/bin/postgres', file type elf64-x86-64.
Entry point: 0x5560ae40
...
0x55609d30 - 0x55a6c25e is .text
...



echo -n "find /b ..., ..., 0x" && \
echo "83 c7 70 48 8d 48 01 49 39 c1 0f 84 04 01 00 00 48 89 c8 80 bf 81 00 00 
00 00 74 d8 4c 8b 5e 18 48 89 c1 48 c1 e1 04 4c 01 c1 <49> 03 4b 10 80 39 00 74 
c1 41 c6 04 02 00 48 8b 49 08 eb bd 66 0f" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'




(gdb) find /b 0x55609d30, 0x55a6c25e, 0x83, 0xc7, 0x70, 0x48, 
0x8d, 0x48, 0x01, 0x49, 0x39, 0xc1, 0x0f, 0x84, 0x04, 0x01, 0x00, 0x00, 0x48, 
0x89, 0xc8, 0x80, 0xbf, 0x81, 0x00, 0x00, 0x00, 0x00, 0x74, 0xd8, 0x4c, 0x8b, 
0x5e, 0x18, 0x48, 0x89, 0xc1, 0x48, 0xc1, 0xe1, 0x04, 0x4c, 0x01, 0xc1, 0x49, 
0x03, 0x4b, 0x10, 0x80, 0x39, 0x00, 0x74, 0xc1, 0x41, 0xc6, 0x04, 0x02, 0x00, 
0x48, 0x8b, 0x49, 0x08, 0xeb, 0xbd, 0x66, 0x0f
0x556149dc 
1 pattern found.


(gdb) b * (0x556149dc + 42)
Breakpoint 1 at 0x55614a06: file 
./build/../src/backend/access/common/heaptuple.c, line 101.

(gdb) info b
Num Type   Disp Enb AddressWhat
1   breakpoint keep y   0x55614a06 in getmissingattr at 
./build/../src/backend/access/common/heaptuple.c:101

(gdb) disassemble /r heap_deform_tuple
Dump of assembler code for function heap_deform_tuple:
   0x556147c0 <+0>: 55  push   %rbp
...
   0x556149db <+539>:   48 83 c7 70 add$0x70,%rdi
   0x556149df <+543>:   48 8d 48 01 lea0x1(%rax),%rcx
   0x556149e3 <+547>:   49 39 c1cmp%rax,%r9
   0x556149e6 <+550>:   0f 84 04 01 00 00   je 0x55614af0 

   0x556149ec <+556>:   48 89 c8mov%rcx,%rax
   0x556149ef <+559>:   80 bf 81 00 00 00 00cmpb   $0x0,0x81(%rdi)
   0x556149f6 <+566>:   74 d8   je 0x556149d0 

   0x556149f8 <+568>:   4c 8b 5e 18 mov0x18(%rsi),%r11
   0x556149fc <+572>:   48 89 c1mov%rax,%rcx
   0x556149ff <+575>:   48 c1 e1 04 shl$0x4,%rcx
   0x55614a03 <+579>:   4c 01 c1   

Bug#954266: qemu-system-x86: graphical-mode monitor doesn't work

[Bernhard Übelacker]

Hello,
tried to collect some more details.
Found that the failure started with the migration
of these packages into testing:

  libvte-2.91-0 libvte-2.91-common (0.60.0-2)

The monitor worked before with 0.58.3-1.

Kind regards,
Bernhard


# Bullseye/testing amd64 qemu VM 2020-03-20

apt update
apt dist-upgrade


apt install systemd-coredump sddm xserver-xorg openbox xterm qemu-system


export DISPLAY=:0
qemu-system-x86_64

(qemu,outside) sendkey ctrl-alt-2



# dpkg -l | grep 1:4.2-3
ii  qemu-system-common   1:4.2-3 amd64  
  QEMU full system emulation binaries (common files)
ii  qemu-system-data 1:4.2-3 all
  QEMU full system emulation (data files)
ii  qemu-system-gui  1:4.2-3 amd64  
  QEMU full system emulation binaries (user interface and audio support)
ii  qemu-system-misc 1:4.2-3 amd64  
  QEMU full system emulation binaries (miscellaneous)
ii  qemu-system-x86  1:4.2-3 amd64  
  QEMU full system emulation binaries (x86)
ii  qemu-utils   1:4.2-3 amd64  
  QEMU utilities




wget 
https://snapshot.debian.org/archive/debian/20191026T211939Z/pool/main/q/qemu/qemu-system-common_4.1-1%2Bb4_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20190827T150849Z/pool/main/q/qemu/qemu-system-data_4.1-1_all.deb
wget 
https://snapshot.debian.org/archive/debian/20191026T211939Z/pool/main/q/qemu/qemu-system-gui_4.1-1%2Bb4_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20191026T211939Z/pool/main/q/qemu/qemu-system-misc_4.1-1%2Bb4_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20191026T211939Z/pool/main/q/qemu/qemu-system-x86_4.1-1%2Bb4_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20191026T211939Z/pool/main/q/qemu/qemu-utils_4.1-1%2Bb4_amd64.deb
apt install libbluetooth3
dpkg -i *.deb

-> already here




wget 
https://snapshot.debian.org/archive/debian/20190528T165330Z/pool/main/q/qemu/qemu-system-common_3.1%2Bdfsg-8_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20190528T101728Z/pool/main/q/qemu/qemu-system-data_3.1%2Bdfsg-8_all.deb
wget 
https://snapshot.debian.org/archive/debian/20190528T165330Z/pool/main/q/qemu/qemu-system-gui_3.1%2Bdfsg-8_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20190528T165330Z/pool/main/q/qemu/qemu-system-misc_3.1%2Bdfsg-8_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20190528T165330Z/pool/main/q/qemu/qemu-system-x86_3.1%2Bdfsg-8_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20190528T165330Z/pool/main/q/qemu/qemu-utils_3.1%2Bdfsg-8_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20190831T031850Z/pool/main/n/nettle/libnettle6_3.5.1%2Breally3.4.1-1_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20190924T204643Z/pool/main/b/brltty/libbrlapi0.6_5.6-11%2Bb1_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20190109T223525Z/pool/main/v/virglrenderer/libvirglrenderer0_0.7.0-2_amd64.deb
dpkg -i *.deb

-> already here --> maybe caused by dependency ?




#



Buster/stable amd64 qemu VM 2020-03-20



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


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


apt update
apt dist-upgrade
apt install systemd-coredump sddm xserver-xorg openbox xterm qemu-system
reboot



20190801T00Z -> testing still works (qemu 1:3.1+dfsg-8)
20190901T00Z -> testing still works (qemu 1:3.1+dfsg-8)
20191001T00Z -> testing still works (qemu 1:4.1-1)
20191101T00Z -> testing still works (qemu 1:4.1-1+b2)
20191201T00Z -> testing still works (qemu 1:4.1-1+b4)
20200101T00Z -> testing still works (qemu 1:4.1-3)
20200201T00Z -> testing still works (qemu 1:4.2-1)
20200215T00Z -> testing still works (qemu 1:4.2-1)
20200301T00Z -> testing still works (qemu 1:4.2-3)
20200303T00Z -> testing still works (qemu 1:4.2-3)
20200305T00Z -> testing still works (qemu 1:4.2-3)
20200307T00Z -> testing still works (qemu 1:4.2-3)
20200309T00Z -> testing still works (qemu 1:4.2-3)
20200311T00Z -> testing still works (qemu 1:4.2-3)
20200313T00Z -> testing still works (qemu 1:4.2-3)
20200315T00Z -> testing still works (qemu 1:4.2-3)
20200316T00Z -> testing still works (qemu 1:4.2-3)

apt install dconf-gsettings-backend dconf-service gpgv libdconf1 libicu63 
libnspr4 logrotate ovmf python3-idna python3-pycurl 

Bug#954315: rastertopwg segfault

[Bernhard Übelacker]

Hello Till,
I am not the initial reporter of the issue and I cannot reproduce it,
therefore cannot test the suggested change.
Just tried to share my results.

Kind regards,
Bernhard

Bug#954315: rastertopwg segfault

[Bernhard Übelacker]

Hello,
the stack trace should look like this with line numbers, if it helps:

0x7...671 in __strlen_avx2 at 
../sysdeps/x86_64/multiarch/strlen-avx2.S:65
0x7...2f4 in _cups_strlcpy at string.c:739
0x5...a31 in main at rastertopwg.c:274
0x7...e09 in __libc_start_main at ../csu/libc-start.c:308
0x5...1a4 <_start+36>

https://sources.debian.org/src/cups/2.3.1-11/cups/string.c/#L739
https://sources.debian.org/src/cups/2.3.1-11/filter/rastertopwg.c/#L274

Kind regards,
Bernhard


# From submitter:
Stack trace of thread 31898:
#0  0x7f7a61751671 
__strlen_avx2 (libc.so.6 + 0x15e671)
#1  0x7f7a618032f9 
_cups_strlcpy (libcups.so.2 + 0x4d2f9)
#2  0x55a058ca1a36 main 
(rastertopwg + 0x1a36)
#3  0x7f7a61619e0b 
__libc_start_main (libc.so.6 + 0x26e0b)
#4  0x55a058ca21aa _start 
(rastertopwg + 0x21aa)


###


# Unstable amd64 qemu VM 2020-03-20


apt update
apt dist-upgrade


apt install systemd-coredump gdb cups cups-dbgsym libcups2-dbgsym

reboot



# dpkg -l | grep cups
ii  cups  2.3.1-11   amd64
Common UNIX Printing System(tm) - PPD/driver support, web interface
ii  cups-browsed  1.27.2-1   amd64
OpenPrinting CUPS Filters - cups-browsed
ii  cups-client   2.3.1-11   amd64
Common UNIX Printing System(tm) - client programs (SysV)
ii  cups-common   2.3.1-11   all  
Common UNIX Printing System(tm) - common files
ii  cups-core-drivers 2.3.1-11   amd64
Common UNIX Printing System(tm) - driverless printing
ii  cups-daemon   2.3.1-11   amd64
Common UNIX Printing System(tm) - daemon
ii  cups-dbgsym   2.3.1-11   amd64
debug symbols for cups
ii  cups-filters  1.27.2-1   amd64
OpenPrinting CUPS Filters - Main Package
ii  cups-filters-core-drivers 1.27.2-1   amd64
OpenPrinting CUPS Filters - Driverless printing
ii  cups-ipp-utils2.3.1-11   amd64
Common UNIX Printing System(tm) - IPP developer/admin utilities
ii  cups-ppdc 2.3.1-11   amd64
Common UNIX Printing System(tm) - PPD manipulation utilities
ii  cups-server-common2.3.1-11   all  
Common UNIX Printing System(tm) - server common files
ii  libcups2:amd642.3.1-11   amd64
Common UNIX Printing System(tm) - Core library
ii  libcups2-dbgsym:amd64 2.3.1-11   amd64
debug symbols for libcups2
ii  libcupsfilters1:amd64 1.27.2-1   amd64
OpenPrinting CUPS Filters - Shared library




gdb -q

set width 0
set pagination off
file /usr/lib/cups/filter/rastertopwg
b main
run
dele 1
generate-core-file /tmp/core
kill
y
q


gdb -q

set width 0
set pagination off
file /usr/lib/cups/filter/rastertopwg
core /tmp/core

disassemble _start
b *0x61a4

disassemble __libc_start_main
b *0x77d8ee09

disassemble main
b *0x5a31

disassemble _cups_strlcpy
b *0x77f782f4

disassemble __strlen_avx2
b *0x77ec6671

info b





0x77ec6671 in __strlen_avx2 at 
../sysdeps/x86_64/multiarch/strlen-avx2.S:65
0x77f782f4 in _cups_strlcpy at string.c:739
0x5a31 in main at rastertopwg.c:274
0x77d8ee09 in __libc_start_main at ../csu/libc-start.c:308
0x61a4 <_start+36>


0x7...671 in __strlen_avx2 at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
0x7...2f4 in _cups_strlcpy at string.c:739
0x5...a31 in main at rastertopwg.c:274
0x7...e09 in __libc_start_main at ../csu/libc-start.c:308
0x5...1a4 <_start+36>




https://sources.debian.org/src/cups/2.3.1-11/cups/string.c/#L739
https://sources.debian.org/src/cups/2.3.1-11/filter/rastertopwg.c/#L274

Bug#954330: GIMP 2 .10 crash

[Bernhard Übelacker]

Hello Valentin,
this looks similar to bug #953794, #953854 or #953880.

Kind regards,
Bernhard

Bug#953412: apt: segfault at 0 ip 00007f024bc54e6f sp 00007ffcc6b28d40 error 4 in libapt-pkg.so.5.0.2

[Bernhard Übelacker]

Hello,
I tried to locate the source line of the address shown
in the /var/log/messages output.
But that failed but I found in the strace output that
it loads for some reason two libapt-pkg.so files ...

...
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libapt-pkg.so.6.0", 
O_RDONLY|O_CLOEXEC) = 3
...
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libapt-pkg.so.5.0", 
O_RDONLY|O_CLOEXEC) = 3
...

Just in case if that helps.

Kind regards,
Bernhard

Bug#952684: cups: segfault in printers.cgi when browsing finished jobs in the cups webpage

[Bernhard Übelacker]

Package: cups
Version: 2.2.10-6+deb10u2
Severity: normal



Dear Maintainer,

I found today some suspicious segfault line in dmesg output and
could reproduce it every time I loaded the finished jobs of a printer
with this URL:

http://localhost:631/printers/Samsung_CLX-3180_Series?which_jobs=completed

This is the dmesg output:

kernel: printers.cgi[3587]: segfault at 0 ip 7f05a859e181 sp 
7fffcf0fb678 error 4 in libc-2.28.so[7f05a8464000+148000]
kernel: Code: 84 00 00 00 00 00 0f 1f 00 31 c0 c5 f8 77 c3 66 2e 0f 1f 84 
00 00 00 00 00 89 f9 48 89 fa c5 f9 ef c0 83 e1 3f 83 f9 20 77 1f  fd 74 0f 
c5 fd d7 c1 85 c0 0f 85 df 00 00 00 48 83 c7 20 83 e1

Unfortunately no core was collected by systemd-coredump, but
I could generate one manually by running it in gdb described in
attached file.

(gdb) bt
#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
#1  0x7f02ba505dae in __GI___strdup (s=0x0) at strdup.c:41
#2  0x556d4f025055 in cgiGetArray (name=name@entry=0x7fffd550ce11 
"job_name", element=element@entry=0) at var.c:171
#3  0x556d4f023cdc in cgi_copy (out=out@entry=0x7f02ba63a760 
<_IO_2_1_stdout_>, in=in@entry=0x556d4f068590, element=element@entry=0, 
term=term@entry=125 '}', indent=indent@entry=4) at template.c:299
#4  0x556d4f0245fe in cgi_copy (out=out@entry=0x7f02ba63a760 
<_IO_2_1_stdout_>, in=in@entry=0x556d4f068590, element=element@entry=0, 
term=term@entry=125 '}', indent=indent@entry=2) at template.c:348
#5  0x556d4f023ee6 in cgi_copy (out=0x7f02ba63a760 <_IO_2_1_stdout_>, 
in=in@entry=0x556d4f068590, element=element@entry=0, term=term@entry=0 '\000', 
indent=indent@entry=0) at template.c:602
#6  0x556d4f024977 in cgiCopyTemplateLang 
(tmpl=tmpl@entry=0x556d4f027091 "jobs.tmpl") at template.c:148
#7  0x556d4f02206e in cgiShowJobs (http=, 
dest=0x7fffd5510ee0 "Samsung_CLX-3180_Series") at ipp-var.c:1506
#8  0x556d4f01f9e6 in show_printer (printer=0x7fffd5510ee0 
"Samsung_CLX-3180_Series", http=0x556d4f06c370) at printers.c:540
#9  main () at printers.c:137

...
(gdb) up
#2  0x556d4f025055 in cgiGetArray (name=name@entry=0x7fffd550ce11 
"job_name", element=element@entry=0) at var.c:171
171   return (strdup(var->values[element]));

I found an upstream change that leaves cgiGetArray
if "var->values[element]" would be a NULL value [1].

This change reached bullseye/testing already, therefore
just buster/stable would be affected [2].

But I am not sure if this is the real problem as the
file /var/spool/cups/c00208 really contains a "job-name",
but no "job_name".

My guess is the "job_name" originates from 
/usr/share/cups/templates/de/jobs.tmpl.
Therefore might this be a internationalisation issue?

A package cups built with the patch in [1] makes the
finished jobs page load completely.

All print jobs show as name unknown ("Unbekannt"),
except some recent test pages.
Most regular prints are done from a kde environment e.g. okular.


So maybe this upstream patch is worth to be considered in stable?

And second, can someone confirm if this unknown name is an issue,
while the file in /var/spool/cups does contain a job-name?
When opening the kde print queue I get the job names - maybe it
is changed to unknown on purpose for security reasons?
In bullseye/testing the web page shows also unknown, even
when credentials were given before and test page is printed
from there. (Should this go into a separate bug?)



Kind regards,
Bernhard


[1] 
https://github.com/apple/cups/commit/eda46e3aac94d42e4199d95befe99ff83afb098f
https://github.com/apple/cups/pull/5621

[2] https://sources.debian.org/src/cups/2.2.10-6+deb10u2/cgi-bin/var.c/#L171
https://sources.debian.org/src/cups/2.3.1-11/cgi-bin/var.c/#L173








-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-7-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cups depends on:
ii  cups-client2.2.10-6+deb10u2
ii  cups-common2.2.10-6+deb10u2
ii  cups-core-drivers  2.2.10-6+deb10u2
ii  cups-daemon2.2.10-6+deb10u2
ii  cups-filters   1.21.6-5
ii  cups-ppdc  2.2.10-6+deb10u2
ii  cups-server-common 2.2.10-6+deb10u2
ii  debconf [debconf-2.0]  1.5.71
ii  ghostscript9.27~dfsg-2+deb10u3
ii  libavahi-client3   0.7-4+b1
ii  libavahi-common3   0.7-4+b1
ii  libc6  2.28-10
ii  libcups2   2.2.10-6+deb10u2
ii  libcupsimage2  2.2.10-6+deb10u2
ii  libgcc1   

Bug#951468: symlinks: segfault when symlink is /..

[Bernhard Übelacker]

Dear Maintainer,
I tried to debug this issue.

(gdb) bt
#0  tidy_path (path=0x55f0c81ea140  "/../") at symlinks.c:96
#1  0x55f0c7fe6908 in fix_symlink (my_dev=2049, path=0x55f0c81ec1e0 
 "/tmp/tmp.tlVVwIgOZQ/mylink") at symlinks.c:185
#2  0x55f0c7fe6e81 in dirwalk (pathlen=, dev=2049, 
path=0x55f0c81ec1e0  "/tmp/tmp.tlVVwIgOZQ/mylink") at symlinks.c:290
#3  0x55f0c7fe5f1d in main (argc=, argv=0x7ffd5d3596f0) 
at symlinks.c:376


I guess I found a buffer underrun in following lines:

76  static int tidy_path (char *path)
...
91  while ((p = strstr(path,"/../")) != NULL) {
92  s = p+3;
93  for (p--; p != path; p--) if (*p == '/') break;

In line 93 p equals path already but is decremented before the
condition 'p != path' is checked the first time.
Therefore this loop is just ended when the first '/' is found
before the begin of the path variable, which is "luckily" in our
case in the .rodata section of the executable, to that we want
to write in line 96.

This modification makes symlinks not crash and shows plausible output:

-   for (p--; p != path; p--) if (*p == '/') break;
+   for (p--; p > path; p--) if (*p == '/') break;

Kind regards,
Bernhard

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


apt update
apt dist-upgrade

apt install systemd-coredump mc fakeroot symlinks gdb symlinks-dbgsym
apt build-dep symlinks




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




cat < reproduce.sh
#! /usr/bin/env sh
MYTMP=\$(mktemp -d)
ln -s /.. \$MYTMP/mylink
symlinks \$MYTMP
EOF

chmod +x reproduce.sh
./reproduce.sh

journalctl --no-pager

coredumpctl list

coredumpctl gdb 1443

set width 0
set pagination off
directory /home/benutzer/source/symlinks/orig/symlinks-1.4
bt







###
###
###





benutzer@debian:~$ ./reproduce.sh 
Segmentation fault (core dumped)



root@debian:~# journalctl --no-pager
...
Feb 17 23:49:17 debian kernel: symlinks[1443]: segfault at 55f0c81e70ed ip 
55f0c7fe675a sp 7ffd5d359360 error 7 in symlinks[55f0c7fe5000+3000]
Feb 17 23:49:17 debian kernel: Code: 1d 0f 1f 80 00 00 00 00 80 3a 2f 74 11 48 
83 ea 01 48 39 d5 75 f2 48 89 ea 80 3a 2f 75 29 31 c9 0f b6 74 08 03 bb 01 00 
00 00 <40> 88 34 0a 48 83 c1 01 40 84 f6 75 e9 4c 89 e6 48 89 ef e8 0e f6
Feb 17 23:49:17 debian systemd[1]: Created slice 
system-systemd\x2dcoredump.slice.
Feb 17 23:49:17 debian systemd[1]: Started Process Core Dump (PID 1444/UID 0).
Feb 17 23:49:17 debian systemd-coredump[1445]: Process 1443 (symlinks) of user 
1000 dumped core.
   
   Stack trace of thread 1443:
   #0  0x55f0c7fe675a n/a 
(symlinks)
   #1  0x55f0c7fe6908 n/a 
(symlinks)
   #2  0x55f0c7fe6e81 n/a 
(symlinks)
   #3  0x55f0c7fe5f1d n/a 
(symlinks)
   #4  0x7fea02a9f09b 
__libc_start_main (libc.so.6)
   #5  0x55f0c7fe61da n/a 
(symlinks)
Feb 17 23:49:17 debian systemd[1]: systemd-coredump@0-1444-0.service: Succeeded.


https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash
error 7 == 0b111
 *   bit 0 ==1: protection fault
 *   bit 1 ==1: write access
 *   bit 2 ==1: user-mode access





root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Mon 2020-02-17 23:49:17 CET1443  1000  1000  11 present   /usr/bin/symlinks





root@debian:~# coredumpctl gdb 1443
   PID: 1443 (symlinks)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 11 (SEGV)
 Timestamp: Mon 2020-02-17 23:49:17 CET (1min 25s ago)
  Command Line: symlinks /tmp/tmp.tlVVwIgOZQ
Executable: /usr/bin/symlinks
 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: 2d5d5576a57947a7aad042da5f907289
Machine ID: 33f18f39d2a9438eb75b0ed52848afcd
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.symlinks.1000.2d5d5576a57947a7aad042da5f907289.1443.158197975700.lz4
   Message: Process 1443 (symlinks) of user 1000 dumped core.

Stack trace of thread 1443:
#0  0x55f0c7fe675a n/a (symlinks)
#1  0x55f0c7fe6908 n/a (symlinks)
#2  0x55f0c7fe6e81 n/a (symlinks)
#3  0x55f0c7fe5f1d n/a (symlinks)
#4  0x7fea02a9f09b __libc_start_main (libc.so.6)
#5  0x55f0c7fe61da n/a (symlinks)

GNU gdb 

Bug#951412: proftpd-basic: segfault when logging in through sftp

[Bernhard Übelacker]

Hello Tomas,

Am 16.02.20 um 17:30 schrieb Tomas Janousek:
> So unless that palloc tries to allocate way more memory than it should,
> I don't think that's the problem.

Unfortunately that allocation seems just "sizeof(pr_response_t)",
so I guess it is not an unusual big allocation.

Kind regards,
Bernhard

Bug#951412: proftpd-basic: segfault when logging in through sftp

[Bernhard Übelacker]

Dear Maintainer,
I just tried to reconstruct the line informations from a
running process with an attached gdb and installed dbgsym package.

0x7f373b3ad458 in __memset_sse2_unaligned at 
../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:120
0x55d7e2f68a64 in pcalloc at pool.c:620
0x55d7e2f8c778 in pr_response_add at response.c:281
0x7f373ab45822 in handle_userauth_req at auth.c:1502
0x7f373ab2de69 in sftp_ssh2_packet_handle at packet.c:1608
0x7f373ab29f12 in sftp_cmd_loop at mod_sftp.c:302
0x55d7e2f65222 in fork_server at main.c:1481
0x55d7e2f65acd in daemon_loop at main.c:1718
0x55d7e2f639bf in standalone_main at main.c:1903
0x7f373b32f09b in __libc_start_main () at ../csu/libc-start.c:308
0x55d7e2f63fca in _start () at main.c:2332

https://sources.debian.org/src/proftpd-dfsg/1.3.6-4+deb10u3/src/pool.c/#L620
https://sources.debian.org/src/proftpd-dfsg/1.3.6-4+deb10u3/src/response.c/#L281

Could the call to palloc just before have failed to allocate memory?

Kind regards,
Bernhard

Bug#950535: iptables-restore segfaults on nat table

[Bernhard Übelacker]

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

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

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

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

Kind regards,
Bernhard


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

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

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

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

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

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


apt update
apt dist-upgrade


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



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

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

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





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


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



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





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

Bug#950669: cups-browsed: segfault at 0 ip 00000000f79ffb5b sp 00000000fffd3828 error 4 in libc-2.29.so

[Bernhard Übelacker]

Hello Thorsten,


Am 06.02.20 um 19:19 schrieb Thorsten Glaser:
> On Thu, 6 Feb 2020, Bernhard Übelacker wrote:
> 
>> Hello Thorsten,
>> getting the source of such an address is possible, even with ASLR,
>> if the library versions are known and dbgsyms are available,
>> like in attached file.
> 
> This is great. Do you mind writing this up and posting it somewhere
> so people can link and bookmark it? Perhaps even in a place aggregated
> on Planet Debian?

I made an attempt in [1], hopefully my english is not too bad...


>> It looks like a null pointer is given to strncasecmp_l.
>>
>> But you are right, this information might still not be very useful,
>> because the location is in libc - if it would be in cups-browsed it
>> would be more useful.
> 
> Yeah, at least a backtrace… sorry I can’t be more helpful.

Maybe a core could be collected with one of the
three core-dump-handler providing packages installed in [2]?

Kind regards,
Bernhard


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

Bug#949710: /usr/bin/plasmashell: segfaults sporadically but only when using app dropdown menu

[Bernhard Übelacker]

Hello Sarah,
I am sorry, but the given information might not be enough
for the maintainers to solve the crash.

Usually when a segfault happens in 'dmesg' output should
appear two lines about this event. Maybe you could forward
these to the report too.

If it is possible to install systemd-coredump a backtrace
would be automatically added to the journal, which could
be viewed by 'journalctl --no-pager'.

'coredumpctl gdb' could also show these information and if
the package gdb is also installed a '(gdb)' prompt should
appear, where the command 'thread apply all bt full'
should provide detailed information where the crash happened.

This information would be much better if the package
plasma-workspace-dbgsym and maybe some for shared libraries
get installed from the repository described here [1].
(If output gets too much pages, maybe attach as file.)


Kind regards
Bernhard

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

Bug#950669: cups-browsed: segfault at 0 ip 00000000f79ffb5b sp 00000000fffd3828 error 4 in libc-2.29.so

[Bernhard Übelacker]

Hello Thorsten,
getting the source of such an address is possible, even with ASLR,
if the library versions are known and dbgsyms are available,
like in attached file.

It looks like a null pointer is given to strncasecmp_l.

But you are right, this information might still not be very useful,
because the location is in libc - if it would be in cups-browsed it
would be more useful.

Kind regards,
Bernhard


# From submitter:
cups-browsed[20400]: segfault at 0 ip f79ffb5b sp fffd3828 
error 4 in libc-2.29.so[f78d2000+145000]
Code: 66 0f 6f 25 37 7c 03 00 66 0f 6f 2d 3f 7c 03 00 66 0f 6f 35 47 7c 03 00 
83 f9 30 0f 87 8e 00 00 00 83 f8 30 0f 87 85 00 00 00  0f 6f 0f f3 0f 6f 16 
66 0f 6f f9 66 44 0f 6f c5 66 44 0f 6f ca



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

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

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


"error 4" == 0x4 == 0b100

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



##


# Unstable amd64 qemu VM with x32 userland 2020-02-06

apt update
apt dist-upgrade

apt install systemd-coredump gdb cups-browsed cups-browsed-dbgsym



dpkg -l | grep -i libc6
dpkg -l | grep 2.29-10

wget 
https://snapshot.debian.org/archive/debian-ports/20200111T150052Z/pool-x32/main/g/glibc/libc6_2.29-9_x32.deb
wget 
https://snapshot.debian.org/archive/debian-ports/20200111T150052Z/pool-x32/main/g/glibc/libc6-dbg_2.29-9_x32.deb
wget 
https://snapshot.debian.org/archive/debian-ports/20200111T150052Z/pool-x32/main/g/glibc/libc-bin_2.29-9_x32.deb
wget 
https://snapshot.debian.org/archive/debian/20200111T032041Z/pool/main/g/glibc/libc-l10n_2.29-9_all.deb
wget 
https://snapshot.debian.org/archive/debian/20200111T032041Z/pool/main/g/glibc/locales_2.29-9_all.deb
dpkg -i "*_2.29-9_*"



gdb -q
file /sbin/cups-browsed
b main
run
generate-core /tmp/core
kill
y
q


gdb -q | grep "libc\."
file /sbin/cups-browsed
core /tmp/core
set width 0
set pagination off
info share
q

#   0xf7920320  0xf7a634db  Yes /lib/x86_64-linux-gnux32/libc.so.6





echo -n "find /b ..., ..., 0x" && \
{
echo "66 0f 6f 25 37 7c 03 00 66 0f 6f 2d 3f 7c 03 00 66 0f 6f 35 47 7c 03 
00 83 f9 30 0f 87 8e 00 00 00 83 f8 30 0f 87 85 00 00 00  0f 6f 0f f3 0f 6f 
16 66 0f 6f f9 66 44 0f 6f c5 66 44 0f 6f ca"
} | sed 's/[<>]//g' | sed 's/ /, 0x/g'

#   find /b ..., ..., 0x66, 0x0f, 0x6f, 0x25, 0x37, 0x7c, 0x03, 0x00, 0x66, 
0x0f, 0x6f, 0x2d, 0x3f, 0x7c, 0x03, 0x00, 0x66, 0x0f, 0x6f, 0x35, 0x47, 0x7c, 
0x03, 0x00, 0x83, 0xf9, 0x30, 0x0f, 0x87, 0x8e, 0x00, 0x00, 0x00, 0x83, 0xf8, 
0x30, 0x0f, 0x87, 0x85, 0x00, 0x00, 0x00, 0xf3, 0x0f, 0x6f, 0x0f, 0xf3, 0x0f, 
0x6f, 0x16, 0x66, 0x0f, 0x6f, 0xf9, 0x66, 0x44, 0x0f, 0x6f, 0xc5, 0x66, 0x44, 
0x0f, 0x6f, 0xca




gdb -q
file /sbin/cups-browsed
core /tmp/core
set width 0
set pagination off
find /b 0xf7920320, 0xf7a634db, 0x66, 0x0f, 0x6f, 0x25, 0x37, 0x7c, 0x03, 0x00, 
0x66, 0x0f, 0x6f, 0x2d, 0x3f, 0x7c, 0x03, 0x00, 0x66, 0x0f, 0x6f, 0x35, 0x47, 
0x7c, 0x03, 0x00, 0x83, 0xf9, 0x30, 0x0f, 0x87, 0x8e, 0x00, 0x00, 0x00, 0x83, 
0xf8, 0x30, 0x0f, 0x87, 0x85, 0x00, 0x00, 0x00, 0xf3, 0x0f, 0x6f, 0x0f, 0xf3, 
0x0f, 0x6f, 0x16, 0x66, 0x0f, 0x6f, 0xf9, 0x66, 0x44, 0x0f, 0x6f, 0xc5, 0x66, 
0x44, 0x0f, 0x6f, 0xca
disassemble /r 0xf7a4db31, 0xf7a4db31 + 62
b * (0xf7a4db31 + 42)
info b


benutzer@debian:~$ gdb -q
(gdb) file /sbin/cups-browsed
Reading symbols from /sbin/cups-browsed...
Reading symbols from 
/usr/lib/debug/.build-id/30/1088ae63113870879be52401bc26cac176081b.debug...
(gdb) core /tmp/core
[New LWP 4218]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnux32/libthread_db.so.1".
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
...
(gdb) set width 0
(gdb) set pagination off
(gdb) find /b 0xf7920320, 0xf7a634db, 0x66, 0x0f, 0x6f, 0x25, 0x37, 0x7c, 0x03, 
0x00, 0x66, 0x0f, 0x6f, 0x2d, 0x3f, 0x7c, 0x03, 0x00, 0x66, 0x0f, 0x6f, 0x35, 
0x47, 0x7c, 0x03, 0x00, 0x83, 0xf9, 0x30, 0x0f, 0x87, 0x8e, 0x00, 0x00, 0x00, 
0x83, 0xf8, 0x30, 0x0f, 0x87, 0x85, 0x00, 0x00, 0x00, 0xf3, 0x0f, 0x6f, 0x0f, 
0xf3, 0x0f, 0x6f, 0x16, 0x66, 0x0f, 0x6f, 0xf9, 0x66, 0x44, 0x0f, 0x6f, 0xc5, 
0x66, 0x44, 

Bug#942055: ghostscript in buster partly broken on armel?

[Bernhard Übelacker]

Hello Jonas,
thanks for taking time for this bug.


Am 05.02.20 um 11:02 schrieb Jonas Smedegaard:
> Hi Alexander,
> 
> Quoting Alexander Reichle-Schmehl (2020-02-05 08:45:05)
>> Am 2020-02-04 22:09, schrieb Jonas Smedegaard:
>>
>>> Most notable change between 9.22 and 9.24 - and also applied to 
>>> various degree in security updates - was a security fix affecting 
>>> interpretation of Postscript code.
>>
>> Maybe a stupid question, but does that fix work?  I'm just wondering, 
>> if the firx triggers a problem on one arm but not on amd64, is it 
>> working?
> 
> Fair question.
> 
> Ghostscript is (mainly) a Postscript interpreter.
> 
> To investigate if the cause for this issue is a) Ghostscript 
> _interpreting_ differently on arm than on amd64, or a tool further back 
> in the chain _producing_ different code for Ghostscript to interpret, it 
> seems to me that we need someone to isolate the actual code fed into 
> Ghostscript.
>
> I maintain the Ghostscript package, but am not skilled in the various 
> tools using Ghostscript.  It seems more sensible to me to first 
> investigate toolchain problems further back in the chain, where (I 
> assume) it is better known how to isolate the data forwarded down the 
> chain.


I guess this is what I did in previous message 33 ?

There I attached file foomatic-9RyCd0 which is fed by cups into ghostscript.
I have put the ghostscript command line parameter also in message 33.

This file, seems to be just a PDF,
is interpreted by ghostscript at amd64 without issue.
But gives the message "Can't handle format 4" at an armv5tel/armel
(real hardware, QNAP, Feroceon 88FR131).

And even worse it might manifests just on armv5tel/armel,
in my qemu armv7/armel VM it works without problems too.

Therefore I guess you are right and this is not an issue of
ghostscript, but could be compiler related.

I continued testing and a package "9.25~dfsg-7" compiled
in an unstable chroot as of date 2017-12-07 produces a working package.
But a package "9.25~dfsg-7" built inside a unstable chroot as of
date 2018-01-01 crashes in gx_filter_edgebuffer, like current
version in buster 9.27~dfsg-2+deb10u3 with "-dDEBUG" set.

Therefore I guess this could be related to the switch from
gcc-7 7.2.0-16 to gcc-7 7.2.0-18 in that time frame.
(The -18 raised the baseline to armv5te.)
That would at least explain why the stretch stable update
packages do not show the problem (e.g. 9.26a~dfsg-0+deb9u6),
as they should be built with stretch's gcc-6.

But without pointing to an exact instruction or function I
cannot prove it. So are there any hints how to
further debug ghostscript in that regard?

Kind regards,
Bernhard

Bug#942055: ghostscript in buster partly broken on armel?

[Bernhard Übelacker]

Control: fixed -1 9.26a~dfsg-0+deb9u6
Control: fixed -1 9.26a~dfsg-0+deb9u1
Control: fixed -1 9.25~dfsg-0+deb9u1
Control: found -1 9.27~dfsg-3.1
Control: found -1 9.27~dfsg-3
Control: found -1 9.26a~dfsg-2
Control: found -1 9.26a~dfsg-1
Control: found -1 9.26~dfsg-2
Control: found -1 9.26~dfsg-1
Control: found -1 9.25~dfsg-7
Control: found -1 9.25~dfsg-2
Control: found -1 9.24~~rc2~dfsg-1
Control: fixed -1 9.22~dfsg-1
Control: fixed -1 9.21~dfsg-1
Control: fixed -1 9.20~dfsg-3.2


Hello,
tried to get a little further.

The last version from sid that did not show this error
was 9.22~dfsg-1. All other good version seem to be created
as security updates, where I cannot find the build logs.

Kind regards,
Bernhard

Bug#948287: bash: *** stack smashing detected *** ( SIGABRT crash )

[Bernhard Übelacker]

Control: reassign -1 libc6 2.29-9
Control: affects -1 bash


Dear Maintainer,
reassigning to get hold of libc6 maintainer about the issue
of incompatible tunables indices between libc6 versions.

Therefore applications could crash when libc is from
previous package version, then a package update gets installed,
and then libpthread is from new version is loaded.

Kind regards,
Bernhard

Bug#950537: lxterminal: wrong default PATH for superuser

[Bernhard Übelacker]

Hello Jan,
please leave the bugs email in the recipients or cc list to
have all information attached to the bug e.g. by using "reply all".

Nice to hear it works.
You can close a bug by just changing the email recipient from
'950...@bugs.debian.org' to '950537-d...@bugs.debian.org'.

Kind regards,
Bernhard



Am 03.02.20 um 15:55 schrieb Schweik Josef:
> Well, you are quite correct, "su -" is working fine!
> ...
> 
> Thanks. Jan
> 
> Please, how can I close this bug report?
> 
> 

Bug#950537: lxterminal: wrong default PATH for superuser

[Bernhard Übelacker]

Hello Jan,
your issue might originate not from the terminal but from su itself.

This might be an interesting read:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904988#20

But in short, is instead of 'su' using 'su -' working
for you like expected?

Kind regards,
Bernhard

Bug#948708: Further information

[Bernhard Übelacker]

Dear Maintainer,
I found this upstream bug report [1].

The SIGILL causing instruction seems to consist
just of four zeros. [2]

The instruction before is [3].

Version 68.4.2esr-1 in unstable does not show this crash.

Kind regards,
Bernhard


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1609535


[2]
(gdb) disassemble /r 0x7da711f0-60,0x7da711f0+60
...
   0x7da711ec:  1f 20 03 d5 nop
=> 0x7da711f0 :00 00 00 00 .inst   
0x ; undefined
   0x7da711f4 :85 ff ff 17 b   
0x7da71008 
   0x7da711f8:  00 00 00 00 .inst   0x ; undefined
...


[3]
1: x/i $pc
=> 0xf2ab9004:  b   0xf2ab91f0
(gdb) stepi
0xf2ab91f0 in ?? () from /usr/lib/firefox-esr/libxul.so
1: x/i $pc
=> 0xf2ab91f0:  .inst   0x ; undefined

#0  0xf2ab9004 in nsCommandLine::EnumerateHandlers 
(this=this@entry=0xe75edaf0, aCallback=aCallback@entry=0xf2ab77d0 
, 
aClosure=aClosure@entry=0x0) at ./build-browser/dist/include/nsCOMPtr.h:331

https://sources.debian.org/src/firefox-esr/68.4.2esr-1/xpcom/base/nsCOMPtr.h/#L331
https://sources.debian.org/src/firefox-esr/68.4.2esr-1/xpcom/base/nsCOMPtr.h/#L91

Bug#949952: tilix does not start on arm64 (maybe libunwind related)

[Bernhard Übelacker]

Hello Birger Schacht,
I tried to get some more information from this issue.

To be sure where your tilix aborts you would need to
install gdb and at least tilix-dbgsym [1] and
run it this way:

gdb -q -ex 'set pagination off' -ex run -ex bt -ex detach -ex quit --args 
tilix

Then I guess you see an backtrace like this:

(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0xf690aea8 in __GI_abort () at abort.c:79
#2  0xf6b3f544 in _d_throw_exception () from 
/lib/aarch64-linux-gnu/libdruntime-ldc-shared.so.88
#3  0xaac73528 in 
_D3std9exception__T7bailOutHTC9ExceptionZQwFNaNfAyamMAxaZv (line=, msg=..., file=...) at 
/usr/lib/ldc/aarch64-linux-gnu/include/d/std/exception.d:516
#4  _D3std9exception__T7enforceZ__TQmTbZQrFNaNfbLAxaAyamZb 
(value=, msg=..., file=..., line=) at 
/usr/lib/ldc/aarch64-linux-gnu/include/d/std/exception.d:436
#5  0xf6e44610 in std.process.environment.opIndex(scope 
const(char)[]) () from /lib/aarch64-linux-gnu/libphobos2-ldc-shared.so.88
#6  0xaac2874c in D main (args=...) at app.d:127

After looking at the source [2] I assume this might not be
fatal and the program not be aborted.

You might be able to confirm if this workaround works
for you too, by starting with this LD_PRELOAD:

LD_PRELOAD=/lib/aarch64-linux-gnu/libgcc_s.so.1 tilix

This might be related to exceptions in libunwind.so.8.
There exists a similar ticket which is also related to
exception handling with the same workaround [3].

Unfortunately there was not yet much response from
libunwind downstream or upstream.

Kind regards,
Bernhard


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

[2] https://sources.debian.org/src/tilix/1.9.3-4/source/app.d/#L127

[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932499
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923962
https://github.com/libunwind/libunwind/issues/129

# Bullseye/testing arm64 qemu VM 2020-02-01


apt update
apt dist-upgrade


apt install systemd-coredump psmisc net-tools strace gdb tilix tilix-dbgsym 
libphobos2-ldc-shared88-dbgsym libgtkd-3-0-dbgsym libsecret-1-0 xserver-xephyr 
x11vnc tigervnc-standalone-server xterm openbox


# Even without DISPLAY set
tilix

coredumpctl list
journalctl --no-pager
coredumpctl gdb 2251

set width 0
set pagination off
bt




apt install libsecret-1-0

gdb -q --args tilix




###


$ tilix
dwarfeh(363) fatal error
Aborted (core dumped)


# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Sat 2020-02-01 01:05:31 CET2251  1000  1000   6 present   /usr/bin/tilix


Feb 01 01:05:29 debian systemd[1]: Started Process Core Dump (PID 2252/UID 0).
Feb 01 01:05:31 debian systemd-coredump[2253]: Process 2251 (tilix) of user 
1000 dumped core.
   
   Stack trace of thread 2251:
   #0  0x9440db88 raise 
(libc.so.6 + 0x35b88)
   #1  0x943fbea8 abort 
(libc.so.6 + 0x23ea8)
   #2  0x94630544 
_d_throw_exception (libdruntime-ldc-shared.so.88 + 0xbd544)
   #3  0x956b43d0 
_D4gtkd6Loader6Linker11loadLibraryFAyaZv (libgtkd-3.so.0 + 0x9ec3d0)
   #4  0xcb23872c n/a 
(tilix + 0x17b72c)
   #5  0x94638b34 
_D2rt5minfo13rt_moduleCtorUZ14__foreachbody1MFKSQBu19sections_elf_shared3DSOZi 
(libdruntime-ldc-shared.so.88 + 0xc5b34)
   #6  0x94639d8c 
_D2rt19sections_elf_shared3DSO7opApplyFMDFKSQBqQBqQyZiZi 
(libdruntime-ldc-shared.so.88 + 0xc6d8c)
   #7  0x9462f7fc rt_init 
(libdruntime-ldc-shared.so.88 + 0xbc7fc)
   #8  0x9462fd80 
_D2rt6dmain212_d_run_main2UAAamPUQgZiZ6runAllMFZv (libdruntime-ldc-shared.so.88 
+ 0xbcd80)
   #9  0x9462fbb8 
_d_run_main2 (libdruntime-ldc-shared.so.88 + 0xbcbb8)
   #10 0x9462fa5c 
_d_run_main (libdruntime-ldc-shared.so.88 + 0xbca5c)
   #11 0x943fc2ec 
__libc_start_main (libc.so.6 + 0x242ec)
   #12 0xcb2385ec n/a 
(tilix + 0x17b5ec)
   #13 0xcb2385ec n/a 
(tilix + 0x17b5ec)
Feb 01 01:05:31 debian systemd[1]: systemd-coredump@0-2252-0.service: Succeeded.


# coredumpctl gdb 2251
   PID: 2251 (tilix)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 6 (ABRT)
 Timestamp: Sat 

Bug#948288: gnome-shell reproducibly crashes on boot, and the boot process gets stuck

[Bernhard Übelacker]

Hello Md Ayquassar,


Am 31.01.20 um 02:23 schrieb Md Ayquassar:

> Second, is a reassignment to some Mesa package required?

I guess mesa maintainer would have more insight if
that function pointer is allowed to be NULL, there
possibly yes.

I wonder if the content of /var/log/Xorg.0.log* would
reveal some more error messages?
Just for a workaround, does giving nomodeset on the kernel prompt
a different result?


> Third, is there anything else I can do as a user to help the developers
> to bugfix this? Bug at line 1017 is strange: if there is a NULL
> dereference there, there should also probably be one in line 1016 unless
> someone has a deterministic concurrent access to that data.

> https://sources.debian.org/src/mesa/18.3.6-2/src/egl/drivers/dri2/egl_dri2.c/#L1017

I assume line 1017, 1018 and 1019 are one statement, therefore gdb shows 1017.
Further I think the function pointer "dri2_dpy->dri2->allocateBuffer"
contains the NULL, therefore the "ip " in your dmesg output.
A "regular" segfault should still show a sane instruction pointer value.


Kind regards,
Bernhard

Bug#948288: gnome-shell reproducibly crashes on boot, and the boot process gets stuck

[Bernhard Übelacker]

Hello Md Ayquassar,
sorry, I did not recognize that you
seem to have a usrmerge'd system.

Then I get following backtraces from your
core dump, with and without debug symbols.

It looks like a function pointer gets called
unconditionally, while containing NULL.
Seems to be graphics driver related.

Kind regards,
Bernhard



https://sources.debian.org/src/mesa/18.3.6-2/src/egl/drivers/dri2/egl_dri2.c/#L1017



(gdb) bt
#0  0x in ?? ()
#1  0xaf7d2c74 in ?? () from /lib/i386-linux-gnu/libEGL_mesa.so.0
#2  0xaf7d755e in ?? () from /lib/i386-linux-gnu/libEGL_mesa.so.0
#3  0xade2d004 in ?? () from /usr/lib/i386-linux-gnu/dri/radeon_dri.so
#4  0xade2d812 in ?? () from /usr/lib/i386-linux-gnu/dri/radeon_dri.so
#5  0xade9232f in ?? () from /usr/lib/i386-linux-gnu/dri/radeon_dri.so
#6  0xaf7d29ba in ?? () from /lib/i386-linux-gnu/libEGL_mesa.so.0
#7  0xaf7c061c in eglMakeCurrent () from /lib/i386-linux-gnu/libEGL_mesa.so.0
#8  0xb4cd8b58 in ?? () from /lib/i386-linux-gnu/libEGL.so.1
#9  0xb674a1bd in _cogl_winsys_egl_make_current () from 
/usr/lib/i386-linux-gnu/mutter/libmutter-cogl-3.so
#10 0xb6d8f1f6 in ?? () from /lib/i386-linux-gnu/libmutter-3.so.0
#11 0xb6ceaca4 in meta_renderer_rebuild_views () from 
/lib/i386-linux-gnu/libmutter-3.so.0
#12 0xb6d920fa in meta_stage_native_rebuild_views () from 
/lib/i386-linux-gnu/libmutter-3.so.0
#13 0xb6d83ba7 in ?? () from /lib/i386-linux-gnu/libmutter-3.so.0
#14 0xb6ccf11a in ?? () from /lib/i386-linux-gnu/libmutter-3.so.0
#15 0xb6ccff40 in ?? () from /lib/i386-linux-gnu/libmutter-3.so.0
#16 0xb6d83f98 in ?? () from /lib/i386-linux-gnu/libmutter-3.so.0
#17 0xb6cd053a in meta_clutter_init () from /lib/i386-linux-gnu/libmutter-3.so.0
#18 0xb6d20323 in meta_init () from /lib/i386-linux-gnu/libmutter-3.so.0
#19 0x004ad53d in ?? ()
#20 0xb6aa2b41 in __libc_start_main (main=0x4ad430, argc=1, argv=0xbff2c2a4, 
init=0x4adfa0, fini=0x4ae000, rtld_fini=0xb7f97520 <_dl_fini>, 
stack_end=0xbff2c29c) at ../csu/libc-start.c:308
#21 0x004ad8d1 in ?? ()
(gdb) 




Core was generated by `/usr/bin/gnome-shell'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x in ?? ()
[Current thread is 1 (Thread 0xb1f2eb80 (LWP 899))]
(gdb) set width 0
(gdb) set pagination off
(gdb) bt
#0  0x in ?? ()
#1  0xaf7d2c74 in dri2_egl_surface_alloc_local_buffer (dri2_surf=0x1b8e9f0, 
att=9, format=32) at ../src/egl/drivers/dri2/egl_dri2.c:1017
#2  0xaf7d755e in dri2_drm_get_buffers_with_format (driDrawable=0x1b73580, 
width=0x1b73598, height=0x1b7359c, attachments=0xbff2bb04, count=2, 
out_count=0xbff2baf8, loaderPrivate=0x1b8e9f0) at 
../src/egl/drivers/dri2/platform_drm.c:344
#3  0xade2d004 in radeon_update_renderbuffers (context=0x19e7d60, 
drawable=0x1b73580, front_only=0 '\000') at 
../src/mesa/drivers/dri/radeon/radeon_common_context.c:421
#4  0xade2d812 in radeonMakeCurrent (driContextPriv=0x19e7d60, 
driDrawPriv=0x1b73580, driReadPriv=0x1b73580) at 
../src/mesa/drivers/dri/radeon/radeon_common_context.c:616
#5  0xade9232f in driBindContext (pcp=0x19e7d60, pdp=0x1b73580, prp=0x1b73580) 
at ../src/mesa/drivers/dri/common/dri_util.c:579
#6  0xaf7d29ba in dri2_make_current (drv=0x19e5120, disp=0x19e49c0, 
dsurf=0x1b8e9f0, rsurf=0x1b8e9f0, ctx=) at 
../src/egl/drivers/dri2/egl_dri2.c:1516
#7  0xaf7c061c in eglMakeCurrent (dpy=0x19e49c0, draw=0x1b8e9f0, 
read=0x1b8e9f0, ctx=0x19fe5c0) at ../src/egl/main/eglapi.c:860
#8  0xb4cd8b58 in InternalMakeCurrentVendor (dpy=0x19e3dd0, 
draw=draw@entry=0x1b8e9f0, read=0x1b8e9f0, read@entry=0x19c3310, 
context=0x19fe5c0, apiState=0x19fe360, vendor=) at 
../../../src/EGL/libegl.c:861
#9  0xb4cd9606 in eglMakeCurrent (dpy=, draw=, 
read=0x1b8e9f0, context=0x19fe5c0) at ../../../src/EGL/libegl.c:727
#10 0xb674a1bd in _cogl_winsys_egl_make_current (display=0x19ca4d8, 
draw=0x1b8e9f0, read=0x1b8e9f0, context=0x19fe5c0) at 
winsys/cogl-winsys-egl.c:300
#11 0xb6d8f1f6 in meta_renderer_native_create_view (renderer=0x19c8610, 
logical_monitor=0x19bbf20) at backends/native/meta-renderer-native.c:2949
#12 0xb6ceaca4 in meta_renderer_create_view (logical_monitor=, 
renderer=0x19c8610) at ./backends/meta-renderer.h:36
#13 meta_renderer_rebuild_views (renderer=0x19c8610) at 
backends/meta-renderer.c:73
#14 0xb6d920fa in meta_stage_native_rebuild_views (stage_native=0x19c2470) at 
backends/native/meta-stage-native.c:141
#15 0xb6d83ba7 in meta_backend_native_update_screen_size (backend=0x19a48b8, 
width=1024, height=768) at backends/native/meta-backend-native.c:493
#16 0xb6ccf11a in meta_backend_sync_screen_size 
(backend=backend@entry=0x19a48b8) at backends/meta-backend-private.h:52
#17 0xb6ccff40 in meta_backend_real_post_init (backend=0x19a48b8) at 
backends/meta-backend.c:442
#18 0xb6d83f98 in meta_backend_native_post_init (backend=0x19a48b8) at 
./backends/meta-backend-private.h:52
#19 0xb6cd053a in meta_backend_post_init (backend=) at 
backends/meta-backend-private.h:52
#20 meta_clutter_init () at backends/meta-backend.c:1239
#21 

Bug#924507: ksplashqml: hits its hard timeout of 30 seconds

[Bernhard Übelacker]

Control: found -1 plasma-workspace/4:5.14.5.1-5


Dear Maintainer,
I found today another device affected by this issue.
It got switched a few days ago from stable to current testing.

It shows the same 30 second splash screen.
A package build with the given patch did show the
splash just 14 seconds.

plasma-workspace version 5.15 or later contain this patch
and should much less likely show this issue.

Kind regards,
Bernhard

Bug#950175: grub-common: Grub delays 23 seconds to show the menu.

[Bernhard Übelacker]

Package: grub-common
Version: 2.04-5
Severity: wishlist


Dear Maintainer,
I noticed some moths ago a delay between Grub gets
started ("Welcome to GRUB!") and Grub shows the menu.
I switched a few days ago from stable to Bullseye/testing
at this device and tried to find out where this 23 seconds
delay is coming from.

After some tests I found that /etc/grub.d/05_debian_theme
is convinced that the root partition is readable by Grub.

Unfortunately this is not the case, as root is on a micro-sd card,
just boot is on the internal MMC. Also the EFI shell did
not recognize the partition table of that micro-sd, as far as I see.
The "search" command below takes these 23 seconds.

As a workaround I copied grub-16x9.png from
/usr/share/desktop-base/futureprototype-theme/grub
to /boot/grub/ and did "update-grub".

Now the delay is gone and the background image is shown by Grub.

I wonder why the background image is not
copied to the boot partition by default?

Kind regards,
Bernhard



-- /boot/grub/grub.cfg:
...
### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod ext2
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root  ...
else
...



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

Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages grub-common depends on:
ii  gettext-base0.19.8.1-10
ii  libc6   2.29-9
ii  libdevmapper1.02.1  2:1.02.167-1
ii  libefiboot1 37-2
ii  libefivar1  37-2
ii  libfreetype62.10.1-2
ii  libfuse22.9.9-2
ii  liblzma55.2.4-1+b1

Versions of packages grub-common recommends:
ii  os-prober  1.77

Versions of packages grub-common suggests:
ii  console-setup  1.194
ii  desktop-base   10.0.3
pn  grub-emu   
pn  multiboot-doc  
pn  xorriso

-- no debconf information