from:"Bernhard Übelacker"

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

Kind regards,
Bernhard


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

Bug#946699: wine: Lotus Notes 6.5 font drop down list corrupt after upgrade to buster

Hello Wolfgang,
I am not involved in packaging wine in debian, but
may have some hints.


Unfortunately I could not find any download for a trial version,
is there one known? Otherwise this can just be debugged
by users having access to that software.


Then a file containing some more output could be of some help.
E.g. start from a terminal the application similar to this:

cd "/home/user/.wine/drive_c/path/to/application"
script -c "WINEDEBUG=+pid,+tid,+timestamp,+font wine 'application.exe'" -a 
"-a ~/wine_$(date +%Y-%m-%d_%H-%M-%S).log"

Such a file should contain all API calls to windows font functions,
maybe that would already show something.


As you tested already WineHQ packages too, and these showed the
same error you might also go ahead an open an upstream bug there.
(If you do so please send here the bug number too.)


Kind regards,
Bernhard

Bug#946714: gimp: GIMP crashed with a fatal error when a was editing an image

Hello Jesús,

> Version: 2.10.12-0.1~mx19+1

Could not find a dbgsym package for that gimp version.
Is your system a MX Linux installation or a plain Debian?
At least in the first case, I guess, the MX Linux forums
can give better support.

And if the crash is reproducible it would help if you
could describe in detail the steps leading to the crash.

Kind regards,
Bernhard

Bug#943335: aeolus throws std::bad_alloc on first launch

Dear Maintainer,
I tried to have a look at this issue. I got this also on amd64 [2].

It looks like this is related to aeolus requesting its
memory never getting swapped out. [1]
Without this line a process does not give this fault.

But there is a "max locked memory" of 65536 kbytes
in place (ulimit -a).
Unfortunately aeolus need this limit at least raised
to 85000 kbytes.


I tested to raise this limit by doing following changes:

/etc/security/limits.conf
*-   memlock 10

/etc/pam.d/common-session
session required pam_limits.so


Kind regards,
Bernhard


[1] main.cc:195 if (mlockall (MCL_CURRENT | MCL_FUTURE)) fprintf (stderr, 
"Warning: memory lock failed.\n");

[2]
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7f185578f535 in __GI_abort () at abort.c:79
#2  0x7f1855b57983 in __gnu_cxx::__verbose_terminate_handler () at 
../../../../src/libstdc++-v3/libsupc++/vterminate.cc:95
#3  0x7f1855b5d8c6 in __cxxabiv1::__terminate (handler=) at 
../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:47
#4  0x7f1855b5d901 in std::terminate () at 
../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:57
#5  0x7f1855b5db34 in __cxxabiv1::__cxa_throw (obj=, 
tinfo=0x7f1855c40690 , dest=0x7f1855b5be60 
) at 
../../../../src/libstdc++-v3/libsupc++/eh_throw.cc:95
#6  0x7f1855b5e01c in operator new (sz=sz@entry=13004) at 
/build/gcc-8-Ev0Tjh/gcc-8-8.3.0/build/x86_64-linux-gnu/libstdc++-v3/include/bits/exception.h:63
#7  0x7f1855b5e075 in operator new[] (sz=sz@entry=13004) at 
../../../../src/libstdc++-v3/libsupc++/new_opv.cc:32
#8  0x561c3ea56477 in Pipewave::genwave (this=this@entry=0x7f18526c44a8, 
D=D@entry=0x7f1854328010, n=, fsamp=fsamp@entry=48000, 
fpipe=) at rankwave.cc:225
#9  0x561c3ea5771b in Rankwave::gen_waves (this=0x7f1854269010, 
D=0x7f1854328010, fsamp=48000, fbase=263.181396, scale=0x561c3ec5e2e0 
) at rankwave.cc:414
#10 0x561c3ea5015c in Slave::thr_main (this=0x561c40190d00) at slave.cc:53
#11 0x7f1855f9ba3a in P_thread_entry_point (arg=) at 
p_thread.cc:38
#12 0x7f1855c5dfa3 in start_thread (arg=) at 
pthread_create.c:486
#13 0x7f18558664cf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Bug#946641: stops: Mark stops as 'Multi-Arch: foreign'

Hello Daniel,

Am 12.12.19 um 18:27 schrieb Daniel James:
> Hi Bernhard,
>> Marking stops as 'Multi-Arch: foreign' should make
>> that installation possible.
> 
> The package 'stops' contains binary instrument data, which as far as I
> know, is uniquely created by the undocumented and well-hidden instrument
> editor feature in aeolus (hold down Ctrl then left-mouse-click on any
> stop in the aeolus GUI to open the instrument editor).
> 
> This instrument data works fine when copied to Debian systems running
> other arches (I have tested amd64 -> armhf).

That's great to hear, as far as I understand you, the package
does not contain architecture dependent data, so the proposed
change should be no problem.

Kind regards,
Bernhard

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

Control: tags -1 + upstream fixed-upstream patch


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

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

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

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

1707
1708break;
1709
1710case NL80211_CMD_SCAN_ABORTED:


Upstream git [1] has a fix committed.


Kind regards,
Bernhard


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

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

(Forgot to attach some more debugging details.)


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





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

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

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


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

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



#



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


apt update
apt dist-upgrade


apt install systemd-coredump mc gdb iwd iwd-dbgsym

apt build-dep iwd




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




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


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


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


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


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


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

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

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

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

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

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


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

1707
1708break;
1709
1710case NL80211_CMD_SCAN_ABORTED:


(gdb) ptype struct scan_request
type = struct scan_request {

Bug#946641: stops: Mark stops as 'Multi-Arch: foreign'

Package: stops
Version: 0.3.0-2
Severity: wishlist

Dear Maintainer,
I was trying to look at 943335, tried to look at it
with the rr debugger which is in the archive just for amd64.

Therefore tried to install aeolus:i386 which required
a package stops:i386.

Marking stops as 'Multi-Arch: foreign' should make
that installation possible.

Kind regards,
Bernhard



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

Kernel: Linux 4.19.0-6-amd64 (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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

stops depends on no packages.

Versions of packages stops recommends:
ii  aeolus  0.9.5-1

stops suggests no packages.

-- no debconf information

Bug#942257: phonon-backend-gstreamer: Cannot upgrade phonon-backend-gstreamer-common to 4:4.9.1-2, this package requires 4:4.9.1-1

Control: tags -1 - upstream


Hello Felix,
maybe the information from following bug is
relevant in this case too.

https://bugs.debian.org/942860

Kind regards,
Bernhard

Bug#942860: 942860: phonon: no functional current backend

Hello Karl,
I am not involved in the packaging of phonon, but
still a few questions.

Have you any Qt4 applications installed?

Because src:phonon in version 4:4.10.3-2 was the last
version that built the Qt4 parts.

Since src:phonon 4:4.10.3-3 just the Qt5 packages
get build anymore.

And therefore I guess phonon and phonon-backend
got replaced by phonon4qt5 and phonon4qt5-backend
some time ago.

Maybe there should exist a transitional package
for upgrading phonon to phonon4qt5?

Kind regards,
Bernhard

Bug#944017: libsoxr: autopkgtest regression: segmentation fault

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

/usr/bin/autopkgtest libsoxr -- null


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

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

In the end it runs:

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

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


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

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

Kind regards,
Bernhard


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

# Unstable amd64 qemu VM 2019-12-12

apt update
apt dist-upgrade


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



##


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




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



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

Bug#946606: libc-bin: catchsegv does not handle backtraces with parentheses

Dear Maintainer,
sorry, did attempt to output the build-id unconditionally,
fixed in attached patch version.

Kind regards,
Bernhard
>From 0a4a73d4eeaa45acdbeb6ea8fea878e134cbc11b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
Date: Wed, 11 Dec 2019 19:56:39 +0100
Subject: Make catchsegv work again after format changed and add build-ids.

https://sourceware.org/bugzilla/show_bug.cgi?id=21830
---
 debug/backtracesymsfd.c | 32 +-
 debug/catchsegv.sh  | 50 -
 2 files changed, 70 insertions(+), 12 deletions(-)

diff --git a/debug/backtracesymsfd.c b/debug/backtracesymsfd.c
index 5751d62f..9bc058fb 100644
--- a/debug/backtracesymsfd.c
+++ b/debug/backtracesymsfd.c
@@ -35,13 +35,14 @@
 void
 __backtrace_symbols_fd (void *const *array, int size, int fd)
 {
-  struct iovec iov[9];
+  struct iovec iov[12];
   int cnt;
 
   for (cnt = 0; cnt < size; ++cnt)
 {
   char buf[WORD_WIDTH];
   char buf2[WORD_WIDTH];
+  char buf3[WORD_WIDTH];
   Dl_info info;
   struct link_map *map;
   size_t last = 0;
@@ -96,6 +97,35 @@ __backtrace_symbols_fd (void *const *array, int size, int fd)
    - (char *) iov[last].iov_base);
 	  ++last;
 
+	  /* Even when we have a symbol name, print the file offset to
+	 make processing in addr2line possible. */
+	  if (info.dli_sname != NULL)
+		{
+		  iov[last].iov_base = (void *) ",";
+		  iov[last].iov_len = 1;
+		  ++last;
+
+		  if (array[cnt] >= (void *) map->l_addr)
+		{
+		  iov[last].iov_base = (void *) "+0x";
+		  diff = array[cnt] - (void *) map->l_addr;
+		}
+		  else
+		{
+		  iov[last].iov_base = (void *) "-0x";
+		  diff = (void *) map->l_addr - array[cnt];
+		}
+		  iov[last].iov_len = 3;
+		  ++last;
+
+		  iov[last].iov_base = _itoa_word ((unsigned long int) diff,
+		   &buf3[WORD_WIDTH], 16, 0);
+		  iov[last].iov_len = (&buf3[WORD_WIDTH]
+		   - (char *) iov[last].iov_base);
+		  ++last;
+
+		}
+
 	  iov[last].iov_base = (void *) ")";
 	  iov[last].iov_len = 1;
 	  ++last;
diff --git a/debug/catchsegv.sh b/debug/catchsegv.sh
index 245c100f..fd6a232a 100755
--- a/debug/catchsegv.sh
+++ b/debug/catchsegv.sh
@@ -52,6 +52,7 @@ Written by Ulrich Drepper.'
 fi
 
 segv_output=`mktemp ${TMPDIR:-/tmp}/segv_output.XX` || exit
+used_libs=`mktemp ${TMPDIR:-/tmp}/used_libs.XX` || exit
 
 # Redirect stderr to avoid termination message from shell.
 (exec 3>&2 2>/dev/null
@@ -87,21 +88,48 @@ if test -s "$segv_output"; then
   sed '/Backtrace/q' "$segv_output"
   sed '1,/Backtrace/d' "$segv_output" |
   (while read line; do
- line=`echo $line | sed "s@^$prog\\(\\[.*\\)@\1@"`
  case "$line" in
-   \[*) addr=`echo "$line" | sed 's/^\[\(.*\)\]$/\1/'`
-	complete=`addr2line -f -e "$prog" $addr 2>/dev/null`
-	if test $? -eq 0; then
-	  echo "`echo "$complete"|sed 'N;s/\(.*\)\n\(.*\)/\2(\1)/;'`$line"
-	else
-	  echo "$line"
-	fi
-	;;
-	 *) echo "$line"
-	;;
+   *\(*\)\[*\])
+ lib=`echo $line  | sed "s@^\(.*\)(\(.*\))\[\(.*\)\]\\$@\1@"`
+ offs=`echo $line | sed "s@^\(.*\)(\(.*\))\[\(.*\)\]\\$@\2@"`
+ addr=`echo $line | sed "s@^\(.*\)(\(.*\))\[\(.*\)\]\\$@\3@"`
+ func=""
+ case "$offs" in
+   *,*) func=`echo $offs | sed "s@\(.*\),\(.*\)\\$@\1,@"`
+offs=`echo $offs | sed "s@\(.*\),\(.*\)\\$@\2@"`
+;;
+ esac
+ case "$offs" in
+   +*) case "$prog" in
+ */$lib)
+   lib="$prog"
+   ;;
+   esac
+   complete=`addr2line -p -i -f -e "$lib" $offs 2>/dev/null`
+   if test $? -eq 0; then
+ echo " [$addr] $complete $lib($func$offs)"
+   else
+ echo " $line"
+   fi
+   ;;
+   *) echo " $line"
+  ;;
+ esac
+ echo "$lib" >> "$used_libs"
+ ;;
+*) echo "$line"
+   ;;
  esac
done)
+  objdumptest=`objdump --version 2>/dev/null`
+  if test $? -eq 0; then
+echo "\nBuild-IDs:"
+sort -u "$used_libs" | while read lib; do
+  objdump -s -j .note.gnu.build-id "$lib"
+done
+  fi
 fi
 rm -f "$segv_output"
+rm -f "$used_libs"
 
 exit $exval
-- 
2.24.0

Bug#946606: libc-bin: catchsegv does not handle backtraces with parentheses

Dear Maintainer,
while I was at it, I attempted to change the output to
deliver the before mentioned information for addr2line too.

Attached is a improved patch, that would now output following:

Backtrace:
 [0x55f317f9175b] main at 
/usr/share/doc/libsoxr-dev/examples/3-options-input-fn.c:79 (discriminator 4) 
/tmp/tmp.sSrfzsTKpn/3-options-input-fn(+0x175b)
 [0x7fd67920fbbb] __libc_start_main at 
/root/source/glibc/try1/glibc-2.29/csu/../csu/libc-start.c:342 
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb,+0x26bbb)
 [0x55f317f911ba] _start at ??:? /tmp/tmp.sSrfzsTKpn/3-options-input-fn(+0x11ba)

At the end there is another small change to add the build-ids
of the in the backtrace involved binaries to the output.

Kind regards,
Bernhard
>From cb1fdbd4e5a7fbeb1de27b72a7945a0b4789d251 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
Date: Wed, 11 Dec 2019 19:56:39 +0100
Subject: Make catchsegv work again after format changed and add build-ids.

https://sourceware.org/bugzilla/show_bug.cgi?id=21830
---
 debug/backtracesymsfd.c | 32 +-
 debug/catchsegv.sh  | 51 -
 2 files changed, 71 insertions(+), 12 deletions(-)

diff --git a/debug/backtracesymsfd.c b/debug/backtracesymsfd.c
index 5751d62f..9bc058fb 100644
--- a/debug/backtracesymsfd.c
+++ b/debug/backtracesymsfd.c
@@ -35,13 +35,14 @@
 void
 __backtrace_symbols_fd (void *const *array, int size, int fd)
 {
-  struct iovec iov[9];
+  struct iovec iov[12];
   int cnt;
 
   for (cnt = 0; cnt < size; ++cnt)
 {
   char buf[WORD_WIDTH];
   char buf2[WORD_WIDTH];
+  char buf3[WORD_WIDTH];
   Dl_info info;
   struct link_map *map;
   size_t last = 0;
@@ -96,6 +97,35 @@ __backtrace_symbols_fd (void *const *array, int size, int fd)
    - (char *) iov[last].iov_base);
 	  ++last;
 
+	  /* Even when we have a symbol name, print the file offset to
+	 make processing in addr2line possible. */
+	  if (info.dli_sname != NULL)
+		{
+		  iov[last].iov_base = (void *) ",";
+		  iov[last].iov_len = 1;
+		  ++last;
+
+		  if (array[cnt] >= (void *) map->l_addr)
+		{
+		  iov[last].iov_base = (void *) "+0x";
+		  diff = array[cnt] - (void *) map->l_addr;
+		}
+		  else
+		{
+		  iov[last].iov_base = (void *) "-0x";
+		  diff = (void *) map->l_addr - array[cnt];
+		}
+		  iov[last].iov_len = 3;
+		  ++last;
+
+		  iov[last].iov_base = _itoa_word ((unsigned long int) diff,
+		   &buf3[WORD_WIDTH], 16, 0);
+		  iov[last].iov_len = (&buf3[WORD_WIDTH]
+		   - (char *) iov[last].iov_base);
+		  ++last;
+
+		}
+
 	  iov[last].iov_base = (void *) ")";
 	  iov[last].iov_len = 1;
 	  ++last;
diff --git a/debug/catchsegv.sh b/debug/catchsegv.sh
index 245c100f..8d8a38f0 100755
--- a/debug/catchsegv.sh
+++ b/debug/catchsegv.sh
@@ -52,6 +52,7 @@ Written by Ulrich Drepper.'
 fi
 
 segv_output=`mktemp ${TMPDIR:-/tmp}/segv_output.XX` || exit
+used_libs=`mktemp ${TMPDIR:-/tmp}/used_libs.XX` || exit
 
 # Redirect stderr to avoid termination message from shell.
 (exec 3>&2 2>/dev/null
@@ -87,21 +88,49 @@ if test -s "$segv_output"; then
   sed '/Backtrace/q' "$segv_output"
   sed '1,/Backtrace/d' "$segv_output" |
   (while read line; do
- line=`echo $line | sed "s@^$prog\\(\\[.*\\)@\1@"`
  case "$line" in
-   \[*) addr=`echo "$line" | sed 's/^\[\(.*\)\]$/\1/'`
-	complete=`addr2line -f -e "$prog" $addr 2>/dev/null`
-	if test $? -eq 0; then
-	  echo "`echo "$complete"|sed 'N;s/\(.*\)\n\(.*\)/\2(\1)/;'`$line"
-	else
-	  echo "$line"
-	fi
-	;;
-	 *) echo "$line"
-	;;
+   *\(*\)\[*\])
+ lib=`echo $line  | sed "s@^\(.*\)(\(.*\))\[\(.*\)\]\\$@\1@"`
+ offs=`echo $line | sed "s@^\(.*\)(\(.*\))\[\(.*\)\]\\$@\2@"`
+ addr=`echo $line | sed "s@^\(.*\)(\(.*\))\[\(.*\)\]\\$@\3@"`
+ func=""
+ case "$offs" in
+   *,*) func=`echo $offs | sed "s@\(.*\),\(.*\)\\$@\1,@"`
+offs=`echo $offs | sed "s@\(.*\),\(.*\)\\$@\2@"`
+;;
+ esac
+ case "$offs" in
+   +*) case "$prog" in
+ */$lib)
+   lib="$prog"
+   ;;
+   esac
+   complete=`addr2line -p -i -f -e "$lib" $offs 2>/dev/null`
+   if test $? -eq 0; then
+ echo " [$addr] $complete $lib($func$offs)"
+   else
+ echo " $line"
+   fi
+   ;;
+   *) echo " $line"
+  ;;
+ esac
+ echo "$lib" >> "$used_libs"
+ ;;
+*) echo "$line"
+   ;;
  esac
done)
 fi
 rm -f "$segv_output"
 
+objdumptest=`objdump --version 2>/dev/null`
+if test $? -eq 0; then
+  echo "\nBuild-IDs:"
+  sort -u /tmp/used_libs.kUDu9V | while read lib; do
+objdump -s -j .note.gnu.build-id "$lib"
+  don

Bug#946606: libc-bin: catchsegv does not handle backtraces with parentheses

Package: libc-bin
Version: 2.29-3
Severity: wishlist
Tags: upstream patch


Dear Maintainer,
since upstream commit in 2012 [1] the function __backtrace_symbols_fd
seems to outputs in one of this formats:

program(+)[]
program(function+)[]

Therefore the /usr/bin/catchsegv cannot find the backtrace lines
and produces less useful outputs (see below)

There exists an upstream bug about the issue [2].

Attached patch is an attempt to parse the offset instead of the
address, which seems now less important due to ASLR.


Known symbols are currently written by __backtrace_symbols_fd
as such with the offset in relation to the function instead
of the library section.
To get for these also sourcefile and line information
either __backtrace_symbols_fd needs to be changed to
output the library section offset to the backtrace too,
or addr2line (binutils) needs a change to lookup the symbol and
calculate from there, but both would be different issues.

What do you think?

Kind regards,
Bernhard


Current:
Backtrace:
/tmp/tmp.sSrfzsTKpn/3-options-input-fn(+0x175b)[0x557275eb775b]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f4f8194ebbb]
/tmp/tmp.sSrfzsTKpn/3-options-input-fn(+0x11ba)[0x557275eb71ba]


With proposed changes:
Backtrace:
 [0x5578ceb0575b] main at 
/usr/share/doc/libsoxr-dev/examples/3-options-input-fn.c:79 (discriminator 4) 
/tmp/tmp.sSrfzsTKpn/3-options-input-fn(+0x175b)
 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7fcf5f243bbb]
 [0x5578ceb051ba] _start at ??:? /tmp/tmp.sSrfzsTKpn/3-options-input-fn(+0x11ba)


[1] 
https://sourceware.org/git/?p=glibc.git;a=commit;h=1d6c3d237d10606121c959b9bd2ae722f79ea899
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=21830



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

Kernel: Linux 5.3.0-2-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 libc-bin depends on:
ii  libc6  2.29-3

Versions of packages libc-bin recommends:
ii  manpages  5.04-1

libc-bin suggests no packages.

-- no debconf information
>From fca03cd9af5ffaea1e4968fa27a7b28ee80903ef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
Date: Wed, 11 Dec 2019 19:56:39 +0100
Subject: Make catchsegv work again after format changed.

https://sourceware.org/bugzilla/show_bug.cgi?id=21830
---
 debug/catchsegv.sh | 34 +++---
 1 file changed, 23 insertions(+), 11 deletions(-)

diff --git a/debug/catchsegv.sh b/debug/catchsegv.sh
index 245c100f..da87122c 100755
--- a/debug/catchsegv.sh
+++ b/debug/catchsegv.sh
@@ -87,18 +87,30 @@ if test -s "$segv_output"; then
   sed '/Backtrace/q' "$segv_output"
   sed '1,/Backtrace/d' "$segv_output" |
   (while read line; do
- line=`echo $line | sed "s@^$prog\\(\\[.*\\)@\1@"`
  case "$line" in
-   \[*) addr=`echo "$line" | sed 's/^\[\(.*\)\]$/\1/'`
-	complete=`addr2line -f -e "$prog" $addr 2>/dev/null`
-	if test $? -eq 0; then
-	  echo "`echo "$complete"|sed 'N;s/\(.*\)\n\(.*\)/\2(\1)/;'`$line"
-	else
-	  echo "$line"
-	fi
-	;;
-	 *) echo "$line"
-	;;
+   *\(*\)\[*\])
+ lib=`echo $line  | sed "s@^\(.*\)(\(.*\))\[\(.*\)\]\\$@\1@"`
+ offs=`echo $line | sed "s@^\(.*\)(\(.*\))\[\(.*\)\]\\$@\2@"`
+ addr=`echo $line | sed "s@^\(.*\)(\(.*\))\[\(.*\)\]\\$@\3@"`
+ case "$offs" in
+   +*) case "$prog" in
+ */$lib)
+   lib="$prog"
+   ;;
+   esac
+   complete=`addr2line -p -i -f -e "$lib" $offs 2>/dev/null`
+   if test $? -eq 0; then
+ echo " [$addr] $complete $lib($offs)"
+   else
+ echo " $line"
+   fi
+   ;;
+ *) echo " $line"
+;;
+ esac
+ ;;
+*) echo "$line"
+   ;;
  esac
done)
 fi
-- 
2.24.0

Bug#944205: spacefm: 100% cpu when creating files/folders

Hello Jack Barns,
I am not involved in packaging spacefm, but just tried
to reproduce the issue. "Unfortunately" for my test it
did not freeze.

If you still can reproduce it, maybe you can execute
following command while a single spacefm process is in
the system and hangs:

script -a "spacefm-gdb_$(date +%Y-%m-%d_%H-%M-%S).txt" -c "ps -C spacefm 
-mo %cpu,pid,tid,user,args; gdb -q --pid $(pidof spacefm) -ex 'set width 0' -ex 
'set pagination off' -ex 'thread apply all bt full' -ex 'detach' -ex 'quit'"

This should generate a file spacefm-gdb*.txt which could be
forwarded to this bug.

Even better if the dbgsym packages could be installed before,
like described in [1].

   spacefm-dbgsym libgtk2.0-0-dbgsym libglib2.0-0-dbgsym

Kind regards,
Bernhard

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

Bug#942214: thunar/nautilus crash navigate directory "cifs mounted" containing opened libreoffice writer file

2019-12-10 Thread Bernhard Übelacker

Hello David,
I fear that output is not sufficient for that
type of application.


Maybe you could install following packages:

thunar-dbgsym gdb libglib2.0-0-dbgsym libgtk-3-0-dbgsym

For this you would need to add a matching package archive
like described in this link:

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


And then running following command (all in one line)
and trigger the crash again.
This should generate a a file thunar-gdb_*.txt that could be
forwarded to this bug.


script -a "thunar-gdb_$(date +%Y-%m-%d_%H-%M-%S).txt" -c "thunar -q; gdb -q -ex 
'set width 0' -ex 'set pagination off' -ex 'set backtrace past-main' -ex 'run' 
-ex 'backtrace no-filter' -ex 'print range_start' -ex 'print range_length' -ex 
'print data_length' -ex 'print data_offset' -ex 'print mask_offset' -ex 'print 
i' -ex 'print j' -ex 'print/x cache' -ex 'print/x cache->buffer' -ex 'print/x 
data' -ex 'print/x offset' -ex 'print/x len' -ex 'info share' -ex 'info reg' 
-ex 'thread apply all bt full' -ex 'detach' -ex 'quit' --args thunar"


Kind regards,
Bernhard

Bug#945443: git-svn fails with "error: git-svn died of signal 11"

2019-12-10 Thread Bernhard Übelacker

=std::memory_order_relaxed, this=0x75a23280) at 
/usr/include/c++/8/bits/atomic_base.h:390
#1  0x758e3e64 in QAtomicOps::load(std::atomic const&) 
(_q_value=...) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qatomic_cxx11.h:227
#2  0x758e3e64 in QBasicAtomicInteger::load() const 
(this=0x75a23280) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qbasicatomic.h:103
#3  0x758e3e64 in QtPrivate::RefCount::deref() (this=0x75a23280) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qrefcount.h:66
#4  0x758e3e64 in QString::~QString() (this=0x569742d0, 
__in_chrg=) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qstring.h:1130
#5  0x758e3e64 in KAboutData::Private::~Private() (this=0x569742d0, 
__in_chrg=) at ./src/lib/kaboutdata.cpp:460
#6  0x758e3e64 in KAboutData::~KAboutData() (this=0x56972700, 
__in_chrg=) at ./src/lib/kaboutdata.cpp:581
#7  0x758e410d in KAboutDataRegistry::~KAboutDataRegistry() 
(this=0x7595a6e0 <(anonymous 
namespace)::Q_QGS_s_registry::innerFunction()::holder>, __in_chrg=) at ./src/lib/kaboutdata.cpp:1040
#8  0x758e410d in (anonymous 
namespace)::Q_QGS_s_registry::Holder::~Holder() (this=0x7595a6e0 
<(anonymous namespace)::Q_QGS_s_registry::innerFunction()::holder>, 
__in_chrg=) at ./src/lib/kaboutdata.cpp:1040
#9  0x77c87d8c in __run_exit_handlers (status=0, listp=0x77e09718 
<__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, 
run_dtors=run_dtors@entry=true) at exit.c:108
#10 0x77c87eba in __GI_exit (status=) at exit.c:139
#11 0x555883f6 in main (argc=, argv=, 
env=) at perlmain.c:166
(gdb) kill
Kill the program being debugged? (y or n) y
[Inferior 1 (process 607) killed]
(gdb) q












cd /home/benutzer/source/libsvn1
cp orig try2 -a
cd try2/subversion-1.10.4




945443_Avoid-crash-in-__run_exit_handlers-by-using-QString-instead-of-QStringLiteral.patch

Description: Avoid crash in __run_exit_handlers by using QString instead of 
QStringLiteral
 If QStringLiteral is used then pointer to segments in the
 shared library libsvn_auth_kwallet-1.so.1 are passed to
 the KAboutData::Private object, which unfortuantely makes
 no deep copy.
 Later in the exit handler when the KAboutData object gets
 destroyed, that pointer are again accessed and trigger the
 crash.

Author: Bernhard Übelacker 

Bug-Debian: https://bugs.debian.org/945443
Bug-Kde: https://bugs.kde.org/show_bug.cgi?id=407271
Bug-Arch: https://bugs.archlinux.org/task/60005

Forwarded: no
Last-Update: 2019-12-10



# dpkg-buildpackage
DEB_BUILD_OPTIONS='nocheck' dpkg-buildpackage


dpkg -i 
/home/benutzer/source/libsvn1/try1/{subversion,libsvn1-dbgsym,libsvn1,libsvn-perl}_1.10.4-1+deb10u1_amd64.deb





###





https://bugs.archlinux.org/task/60005

https://bugs.kde.org/show_bug.cgi?id=407271

https://sources.debian.org/src/subversion/1.13.0-1/subversion/libsvn_auth_kwallet/kwallet.cpp/#L230
https://sources.debian.org/src/subversion/1.13.0-1/subversion/libsvn_auth_kwallet/kwallet.cpp/#L312

https://sources.debian.org/src/kcoreaddons/5.54.0-1/src/lib/kaboutdata.cpp/#L598


https://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_auth_kwallet/kwallet.cpp?view=markup#l230
https://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_auth_kwallet/kwallet.cpp?view=markup#l312

https://cgit.kde.org/kcoreaddons.git/tree/src/lib/kaboutdata.cpp#n600

Bug#945375: gnome-control-center: Segmentation fault when selecting display on secondary GPU.

Control: tags -1 + patch upstream fixed-upstream


Hello Mladen Mijatov, dear Maintainer,
the first frames would be translated by addr2line to following [1].

This looks like the crash is caused by an invalid pointer pself/self
in function cc_display_mode_dbus_is_supported_scale [112].
This pointer is retrieved by cc_display_monitor_get_mode in [399].

That led me to this upstream bug [2] which got
already fixed in [3]. Either of the upstream tags 3.34.2 or 3.35.2
contains that patch.

Kind regards,
Bernhard



[1]
  #apt install systemd-coredump gnome binutils gdb gnome-control-center-dbgsym 
libglib2.0-0-dbgsym libgtk-3-0-dbgsym
  cat backtrace.txt | tr '()[]' ' ' | while read -ra line; do
  if [[ ${line[1]:0:1} == "+" ]] ; then
  if [[ ${line[0]:0:1} == "/" ]] ; then
  F=${line[0]};
  else
  F=$(which ${line[0]});
  fi;
  echo ${line[2]} at $(addr2line --exe=$F  ${line[1]}) from ${line[0]} 
${line[1]};
  else
  echo ${line[2]} in ${line[1]} from ${line[0]};
  fi;
  done

  0x56214d26c2de at 
./obj-x86_64-linux-gnu/../panels/display/cc-display-config-dbus.c:112 from 
gnome-control-center +0xa82de
  0x56214d26c425 at 
./obj-x86_64-linux-gnu/../panels/display/cc-display-config-dbus.c:1217 from 
gnome-control-center +0xa8425
  0x56214d269206 at 
./obj-x86_64-linux-gnu/../panels/display/cc-display-settings.c:399 from 
gnome-control-center +0xa5206
  0x56214d269b73 in cc_display_settings_set_selected_output+0x13 from 
gnome-control-center
  0x56214d262970 at 
./obj-x86_64-linux-gnu/../panels/display/cc-display-panel.c:733 from 
gnome-control-center +0x9e970
  0x56214d263780 at 
./obj-x86_64-linux-gnu/../panels/display/cc-display-panel.c:546 from 
gnome-control-center +0x9f780
  0x7fb21bc370e6 at ../../../gobject/gclosure.c:294 from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 +0x140e6
  ...

[2] https://gitlab.gnome.org/GNOME/gnome-control-center/issues/675
[3] 
https://gitlab.gnome.org/GNOME/gnome-control-center/commit/0fa4d11477076c9d06af218795cd8c6194fa5dff

[112]  
https://sources.debian.org/src/gnome-control-center/1:3.34.1-1/panels/display/cc-display-config-dbus.c/#L112
[1217] 
https://sources.debian.org/src/gnome-control-center/1:3.34.1-1/panels/display/cc-display-config-dbus.c/#L1217
[399]  
https://sources.debian.org/src/gnome-control-center/1:3.34.1-1/panels/display/cc-display-settings.c/#L399

Bug#944603: Attempt to print checks crashes gnucash

Hello local10,
if you still get this crash, maybe if you start it like below
there would be more information about the crash.

catchsegv gnome-control-center

Alternatively you could install systemd-coredump and look
at the end of 'journalctl --no-pager' if there is some debug
information of the crash.

Kind regards,
Bernhard

Bug#945375: gnome-control-center: Segmentation fault when selecting display on secondary GPU.

Hello Mladen Mijatov,
if you still get this crash, maybe if you start it like below
there would be more information about the crash.

catchsegv gnome-control-center

Alternatively you could install systemd-coredump and look
at the end of 'journalctl --no-pager' if there is some debug
information of the crash.

Kind regards,
Bernhard

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

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

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

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

export LIBGL_ALWAYS_SOFTWARE=1
nextcloud

Or maybe this:

export QT_XCB_FORCE_SOFTWARE_OPENGL=1
nextcloud


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

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


Kind regards,
Bernhard



  From submitter  |
Reconstructed
 #0  0x7fe16d9b6bde  | 0x7f1811853bde 

 #1  0x7fe16d9b6cf0  | 0x7f1811853cf0 

 #2  0x7fe16d9b7327  | 0x7f1811854327 

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

Bug#945443: git-svn fails with "error: git-svn died of signal 11"

Hello Christian,
if you still see this crash, maybe you could install the
package systemd-coredump.

If then a process crashes again some more information
should be visible at the end of:

journalctl --no-pager

Kind regards,
Bernhard

Bug#944771: GNOME Shell crashes when selecting "About" from top bar menu in Midori



Hello Andrew,

On Sun, 8 Dec 2019 15:17:45 -0500 Andrew Engelbrecht  wrote:

> I was able to reproduce and to get a backtrace, which I attached to this
> email.

Your backtrace with full debug symbols should read like below [4].
This seems to point to the upstream issue [1].
Unfortunately I could not find any hint of a solution there.
Another occourence seems to be in fedora,
but also without solution [2].

At least it looks like the pointer "observer" contained in your
gnome-shell crash an invalid pointer.

The crash before in midori seems to be in webkitWebViewBaseMakeGLContextCurrent.
In my test VM I never reached that function.


> I tried clearing out the ~/.config/midori/ directory. After doing so, I
> no longer get a crash when selecting the "About" menu option.
> 
> If needed, I can try to recover the bad config from backups, for the
> sake of testing future versions of Midori and GNOME Shell.

Thats maybe up to the maintainer if this is still desired,
as you found already a workaround.

Kind regards,
Bernhard


[1] https://gitlab.gnome.org/GNOME/gnome-shell/issues/365

[2] https://bugzilla.redhat.com/show_bug.cgi?id=1642473

[3]
https://sources.debian.org/src/gnome-shell/3.30.2-11%7Edeb10u1/src/gtkactionobserver.c/#L155
(gdb) list 
150 void
151 gtk_action_observer_action_removed (GtkActionObserver   *observer,
152 GtkActionObservable *observable,
153 const gchar *action_name)
154 {
155   g_return_if_fail (GTK_IS_ACTION_OBSERVER (observer));
156
157   GTK_ACTION_OBSERVER_GET_IFACE (observer)
158 ->action_removed (observer, observable, action_name);
159 }
(gdb) print observer
$2 = (GtkActionObserver *) 0x562a598364c0
(gdb) print/x $rbx
$3 = 0x562a598364c0


[4]
(gdb) bt no-filters
#0  0x7fc15234e9a7 in gtk_action_observer_action_removed at 
../src/gtkactionobserver.c:155
#1  0x7fc15234d206 in gtk_action_muxer_action_removed at 
../src/gtkactionmuxer.c:313
#2  0x7fc15234d26f in gtk_action_muxer_action_removed_from_group at 
../src/gtkactionmuxer.c:326
#3  0x7fc15234dce0 in gtk_action_muxer_remove at ../src/gtkactionmuxer.c:763
#4  0x7fc15234dd28 in gtk_action_muxer_insert at ../src/gtkactionmuxer.c:712
#5  0x7fc1534238a4 in shell_app_update_window_actions at 
../src/shell-app.c:472
#6  0x7fc153432aee in update_focus_app at ../src/shell-window-tracker.c:487
#7  0x7fc1531ecc8d in g_closure_invoke at ../../../gobject/gclosure.c:810
#8  0x7fc153200365 in signal_emit_unlocked_R at 
../../../gobject/gsignal.c:3635
#9  0x7fc1532092be in g_signal_emit_valist at 
../../../gobject/gsignal.c:3391
#10 0x7fc15320997f in g_signal_emit at ../../../gobject/gsignal.c:3447
#11 0x7fc1531f1364 in g_object_dispatch_properties_changed at 
../../../gobject/gobject.c:1088
#12 0x7fc1531f3921 in g_object_notify_by_spec_internal at 
../../../gobject/gobject.c:1181
#13 g_object_notify_by_pspec at ../../../gobject/gobject.c:1291
#14 0x7fc1513258ee in ffi_call_unix64 at ../src/x86/unix64.S:76
#15 0x7fc1513252bf in ffi_call at ../src/x86/ffi64.c:525
#16 0x7fc14f8ccb2d in wl_closure_invoke at ../src/connection.c:1006
#17 0x7fc14f8c95a9 in wl_client_connection_data at 
../src/wayland-server.c:420
#18 0x7fc14f8cab72 in wl_event_loop_dispatch at ../src/event-loop.c:641
#19 0x7fc1526263a7 in wayland_event_source_dispatch at 
wayland/meta-wayland.c:90
#20 0x7fc15310af2e in g_main_dispatch at ../../../glib/gmain.c:3182
#21 g_main_context_dispatch at ../../../glib/gmain.c:3847
#22 0x7fc15310b1c8 in g_main_context_iterate at ../../../glib/gmain.c:3920
#23 0x7fc15310b4c2 in g_main_loop_run at ../../../glib/gmain.c:4116
#24 0x7fc1525ed06c in meta_run at core/main.c:689
#25 0x562a53f1e782 in main at ../src/main.c:501
#26 0x7fc15237a09b in __libc_start_main at ../csu/libc-start.c:308
#27 0x562a53f1e8da in _start

Bug#944771: GNOME Shell crashes when selecting "About" from top bar menu in Midori

2019-12-08 Thread Bernhard Übelacker

Hello Andrew,
I tried to reproduce this crash but it did not show up for me.

Maybe you could install systemd-coredump, then a backtrace
would be written automatically into the journal:

journalctl --no-pager

Kind regards,
Bernhard

Bug#942214: thunar/nautilus crash navigate directory "cifs mounted" containing opened libreoffice writer file

2019-12-08 Thread Bernhard Übelacker

Hello David,
I tried to reproduce the issue but I did not receive a crash.

There should have been two lines in the syslog - the line with "Code"
would at least help to identify in which function the crash happened.

Maybe you could also start thunar or nautilus from a terminal by e.g.

thunar -q; catchsegv thunar
or
nautilus -q; catchsegv nautilus

Then trigger the crash and in the terminal should be more information
that would help with this issue.

Kind regards,
Bernhard

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

2019-12-08 Thread Bernhard Übelacker

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

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

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

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

Kind regards,
Bernhard


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

Bug#946158: lightdm-gtk-greeter or libcairo2 segfault immediately after submitting password, unlocking session

2019-12-07 Thread Bernhard Übelacker

Hello dinar qurbanov,
I am guessing you are using Buster/stable i386?
If reportbug would be used for reporting bugs, such
information gets added automatically to the report.

Then the "Code" in the syslog the crash most probably
happened in _cairo_surface_set_error [1].

Unfortunately I doubt that information is enough for the
maintainer to fix this issue.

If it would be possible to install systemd-coredump,
then a backtrace for each crashing app would be added
to the journal, that could be of help.

And I cannot judge if this could be due to bad sectors on
your disk, therefore at least below the md5sums [2] of the files
I got installed. Maybe you want to lookup smartctl, if your
disk recorded itself some errors.

Kind regards,
Bernhard


[1] https://sources.debian.org/src/cairo/1.16.0-4/src/cairo-surface.c/#L201

[2]
# md5sum /usr/lib/i386-linux-gnu/libcairo.so.2.11600.0
273f0014984b9f43abbed04cd9e0bc0c  /usr/lib/i386-linux-gnu/libcairo.so.2.11600.0
# md5sum /usr/sbin/lightdm-gtk-greeter
dbfa2151ff036c85f4659358d7a5f392  /usr/sbin/lightdm-gtk-greeter

# from submitter:
Dec  4 14:28:08 localhost kernel: [ 5707.165413] lightdm-gtk-gre[9162]: 
segfault at 8 ip b73a92e4 sp bfa6f59c error 4 in 
libcairo.so.2.11600.0[b733d000+dd000]
Dec  4 14:28:08 localhost kernel: [ 5707.165431] Code: 51 14 89 54 24 04 e9 1b 
e5 fa ff 8d 76 00 31 c0 c3 8d 74 26 00 90 89 d0 c3 8d b4 26 00 00 00 00 8d b6 
00 00 00 00 8b 44 24 04 <8b> 40 08 c3 8d b4 26 00 00 00 00 90 8b 44 24 04 8b 40 
0c c3 8d b4


###

Buster/stable i386 qemu VM 2019-12-07

apt update
apt dist-ugprade


apt install mc gdb lightdm-gtk-greeter lightdm-gtk-greeter-dbgsym 
libcairo2-dbgsym


gdb -q --args lightdm-gtk-greeter

set width 0
set pagination off
b main
run

info share

0xb73f26a0  0xb74cd724  Yes /usr/lib/i386-linux-gnu/libcairo.so.2

find /b 0xb73f26a0, 0xb74cd724, 0x51, 0x14, 0x89, 0x54, 0x24, 0x04, 0xe9, 0x1b, 
0xe5, 0xfa, 0xff, 0x8d, 0x76, 0x00, 0x31, 0xc0, 0xc3, 0x8d, 0x74, 0x26, 0x00, 
0x90, 0x89, 0xd0, 0xc3, 0x8d, 0xb4, 0x26, 0x00, 0x00, 0x00, 0x00, 0x8d, 0xb6, 
0x00, 0x00, 0x00, 0x00, 0x8b, 0x44, 0x24, 0x04, 0x8b, 0x40, 0x08, 0xc3, 0x8d, 
0xb4, 0x26, 0x00, 0x00, 0x00, 0x00, 0x90, 0x8b, 0x44, 0x24, 0x04, 0x8b, 0x40, 
0x0c, 0xc3, 0x8d, 0xb4

0xb745d2ba <_cairo_surface_tag+4294956810>
1 pattern found.


(gdb) disassemble 0xb745d2a0,0xb745d2ba+20
Dump of assembler code from 0xb745d2a0 to 0xb745d2ce:
   0xb745d2a0 <_cairo_surface_set_error+0>: mov0x8(%esp),%edx
   0xb745d2a4 <_cairo_surface_set_error+4>: mov0x4(%esp),%ecx
   0xb745d2a8 <_cairo_surface_set_error+8>: cmp$0x66,%edx
   0xb745d2ab <_cairo_surface_set_error+11>:je 0xb745d2c8 
<_cairo_surface_set_error+40>
   0xb745d2ad <_cairo_surface_set_error+13>:lea-0x1(%edx),%eax
   0xb745d2b0 <_cairo_surface_set_error+16>:cmp$0x29,%eax
   0xb745d2b3 <_cairo_surface_set_error+19>:ja 0xb745d2d0 
<_cairo_surface_set_error+48>
   0xb745d2b5 <_cairo_surface_tag+-10491>:  xor%eax,%eax
   0xb745d2b7 <_cairo_surface_tag+-10489>:  lock cmpxchg %edx,0x14(%ecx)
   0xb745d2bc <_cairo_surface_set_error+28>:mov%edx,0x4(%esp)
   0xb745d2c0 <_cairo_surface_set_error+32>:jmp0xb740b7e0 <_cairo_error>
   0xb745d2c5 <_cairo_surface_set_error+37>:lea0x0(%esi),%esi
   0xb745d2c8 <_cairo_surface_set_error+40>:xor%eax,%eax
   0xb745d2ca <_cairo_surface_set_error+42>:ret
   0xb745d2cb <_cairo_surface_set_error+43>:lea0x0(%esi,%eiz,1),%esi
End of assembler dump.

(gdb) b *0xb745d2bc
Breakpoint 3 at 0xb745d2bc: file ../../../../src/cairo-surface.c, line 201.


(gdb) info b
Num Type   Disp Enb AddressWhat
2   breakpoint keep y   0xb745d2ba in _cairo_atomic_int_cmpxchg_impl at 
../../../../src/cairo-atomic-private.h:118
3   breakpoint keep y   0xb745d2bc in _cairo_surface_set_error at 
../../../../src/cairo-surface.c:201


https://sources.debian.org/src/cairo/1.16.0-4/src/cairo-surface.c/#L201

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

2019-12-07 Thread Bernhard Übelacker

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

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

Kind regards,
Bernhard

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

Buster/stable i386 qemu VM 2019-12-07

apt update
apt dist-ugprade

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

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

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

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

reboot
# to kernel 3.16

# to have another ssh available
dropbear -p 80

# failed login attempt

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

gdb -q --pid $(pidof sshd)

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

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

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

# enter password

info proc
bt
display/i $pc

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

Bug#946308: /usr/games/fs2_open: fs2_open crashes immediately (illegal instruction)

2019-12-07 Thread Bernhard Übelacker

Dear Maintainer,
I tried to reproduce inside a minimal Buster i386 qemu VM
and received also an "Illegal instruction" message.

It looks like it tries to execute an AVX instruction that
my CPU should support, but is not enabled inside the VM.

The usage of AVX might originate from the compiler
flag "-march=native".
This might be added in configure.ac, lines 149 or 163.

The solution could be to just add this configure flag:
-CONF_O=--bindir=/usr/games --disable-silent-rules --enable-speech
+CONF_O=--bindir=/usr/games --disable-silent-rules --enable-speech 
--enable-generic-architecture

Then these flags get used instead:
  -mtune=generic -mfpmath=sse -msse -msse2
Do these also violate the i386 Buster baseline?

Kind regards,
Bernhard


(gdb) bt
#0  0x005eec8f in std::vector, 
std::allocator > >::operator[] (this=, 
__n=) at /usr/include/c++/7/bits/stl_vector.h:798
#1  factor_table::resize (this=0xce84d8 , size=6) at 
io/keycontrol.cpp:159
#2  0x005eed94 in factor_table::factor_table (this=0xce84d8 , size=6) 
at io/keycontrol.cpp:112
#3  0x00448a8e in __static_initialization_and_destruction_0 (__priority=65535, 
__initialize_p=1) at io/keycontrol.cpp:171
#4  _GLOBAL__sub_I__ZN12factor_tableC2Ej () at io/keycontrol.cpp:2912
#5  0x00952f8b in __libc_csu_init ()
#6  0xb761dad3 in __libc_start_main (main=0x43c4f0 , argc=1, 
argv=0xbf8b8554, init=0x952f40 <__libc_csu_init>, fini=0x952fa0 
<__libc_csu_fini>, rtld_fini=0xb7ef4520 <_dl_fini>, stack_end=0xbf8b854c) at 
../csu/libc-start.c:264
#7  0x0046c58b in _start ()

(gdb) display/i $pc
1: x/i $pc
=> 0x5eec8f :   vmovd  %ebx,%xmm2

# Buster/stable i386 qemu VM 2019-12-07

# enable non-free

apt update
apt dist-upgrade

apt install systemd-coredump xserver-xorg sddm openbox xterm mc fakeroot gdb 
freespace2 freespace2-dbgsym libstdc++-7-dev
apt build-dep freespace2


reboot




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




export DISPLAY=:0
/usr/games/fs2_open
catchsegv /usr/games/fs2_open


coredumpctl list
coredumpctl gdb [PID]

set width 0
set pagination off
directory /home/benutzer/source/freespace2/orig/freespace2-3.7.4+repack/code
bt
display/i $pc





###


benutzer@debian:~$ /usr/games/fs2_open
Ungültiger Maschinenbefehl (Speicherabzug geschrieben)

benutzer@debian:~$ catchsegv /usr/games/fs2_open
Illegal instruction (core dumped)

benutzer@debian:~$ /usr/games/fs2_open_DEBUG 
Ungültiger Maschinenbefehl (Speicherabzug geschrieben)

benutzer@debian:~$ catchsegv /usr/games/fs2_open_DEBUG 
Illegal instruction (core dumped)


###


dmesg:
[  219.663592] traps: fs2_open[883] trap invalid opcode ip:684c8f sp:bf9bce50 
error:0 in fs2_open_3.7.4[4d+51a000]
[  226.887618] traps: fs2_open[891] trap invalid opcode ip:5d4c8f sp:bfbbbcc0 
error:0 in fs2_open_3.7.4[42+51a000]
[  473.081117] traps: fs2_open_DEBUG[1059] trap invalid opcode ip:69bc0f 
sp:bfaecb20 error:0 in fs2_open_3.7.4_DEBUG[4cb000+571000]
[  502.160726] traps: fs2_open_DEBUG[1075] trap invalid opcode ip:5f1c0f 
sp:bfd2c050 error:0 in fs2_open_3.7.4_DEBUG[421000+571000]


###


root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Sat 2019-12-07 13:34:07 CET 883  1000  1000   4 present   
/usr/games/fs2_open_3.7.4
Sat 2019-12-07 13:34:15 CET 891  1000  1000   4 present   
/usr/games/fs2_open_3.7.4
Sat 2019-12-07 13:38:21 CET1059  1000  1000   4 present   
/usr/games/fs2_open_3.7.4_DEBUG
Sat 2019-12-07 13:38:50 CET1075  1000  1000   4 present   
/usr/games/fs2_open_3.7.4_DEBUG


root@debian:~# coredumpctl gdb 1140   
   PID: 1140 (fs2_open)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 4 (ILL)
 Timestamp: Sat 2019-12-07 13:53:45 CET (6min ago)
  Command Line: /usr/games/fs2_open
Executable: /usr/games/fs2_open_3.7.4
 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: 7a7eca3571374b3ca58ef7f657194b9c
Machine ID: 45f49504b47f4e5690bc479adf67aa5b
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.fs2_open.1000.7a7eca3571374b3ca58ef7f657194b9c.1140.157572322500.lz4
   Message: Process 1140 (fs2_open) of user 1000 dumped core.

Stack trace of thread 1140:
#0  0x005eec8f _ZNSt6vectorI10SCP_vectorIjESaIS1_EEixEj 
(fs2_open_3.7.4)
#1  0x005eed94 _ZN12factor_tableC2Ej (fs2_open_3.7.4)
#2  0x00448a8e 
__static_initialization_and_destruction_0 (fs2_open_3.7.4)
#3  0x00952f8b __libc_csu_init (fs2_open_3.7.4)
#4  0xb761dad3 __libc_start_main (libc.so.6)
#5  0x0046c58b _start (fs2_open_3.7.4)

GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 Free Software Fo

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

2019-12-03 Thread Bernhard Übelacker

Control: tags -1 + upstream patch


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

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

Attached patch allocates two such arrays from the heap.
With this "unhide brute" could finish without crash.

Another workaround would be to increase stacksize
by "ulimit -s 40960" before running unhide.

Kind regards,
Bernhard




dmesg by submitter:
Nov 30 01:39:48 heisenberg kernel: unhide[208429]: segfault at 7ffd06cfec58 ip 
55c15aa077d3 sp 7ffd06cfec60 error 6 in unhide-linux[55c15aa07000+6000]
Nov 30 01:39:48 heisenberg kernel: Code: 00 48 89 45 c8 31 c0 48 63 05 5d 98 00 
00 48 8d 04 85 0f 00 00 00 48 83 e0 f0 48 29 c4 48 89 65 98 48 29 c4 31 c0 48 
89 65 90  d8 3e 00 00 31 c0 66 0f 1f 44 00 00 48 8b 4d 98 48 8b 55 90 c7



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

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

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


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

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





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

apt update
apt dist-upgrade

apt install systemd-coredump mc devscripts dpkg-dev gdb unhide unhide-dbgsym


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



gdb -q --args unhide

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

info target

find /b 0x63e0, 0xb001, 0x00, 0x48, 0x89, 0x45, 0xc8, 
0x31, 0xc0, 0x48, 0x63, 0x05, 0x5d, 0x98, 0x00, 0x00, 0x48, 0x8d, 0x04, 0x85, 
0x0f, 0x00, 0x00, 0x00, 0x48, 0x83, 0xe0, 0xf0, 0x48, 0x29, 0xc4, 0x48, 0x89, 
0x65, 0x98, 0x48, 0x29, 0xc4, 0x31, 0xc0, 0x48, 0x89, 0x65, 0x90, 0xe8, 0xd8, 
0x3e, 0x00, 0x00, 0x31, 0xc0, 0x66, 0x0f, 0x1f, 0x44, 0x00, 0x00, 0x48, 0x8b, 
0x4d, 0x98, 0x48, 0x8b, 0x55, 0x90, 0xc7



root@debian:~# gdb -q --args unhide
Reading symbols from unhide...
Reading symbols from 
/usr/lib/debug/.build-id/41/d7d39535f738606ad3acf0611a8397925762b3.debug...
(gdb) set width 0
(gdb) set pagination off
(gdb) directory /home/benutzer/source/unhide/orig/unhide-20130526
Source directories searched: 
/home/benutzer/source/unhide/orig/unhide-20130526:$cdir:$cwd
(gdb) b main
Breakpoint 1 at 0x23e0: file /usr/include/x86_64-linux-gnu/bits/stdio2.h, line 
107.
(gdb) run
Starting program: /usr/sbin/unhide 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, main (argc=1, argv=0x7fffed18) at 
/usr/include/x86_64-linux-gnu/bits/stdio2.h:107
warning: Source file is more recent than executable.
107   return __printf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, __va_arg_pack 
());
(gdb) dele 1
(gdb) info target
Symbols from "/usr/sbin/unhide-linux".
Native process:
Using the running image of child Thread 0x77de5740 (LWP 13520).
While running this, GDB does not access memory from...
Local exec file:
`/usr/sbin/unhide-linux', file type elf64-x86-64.
Entry point: 0x6660
...
0x63e0 - 0xb001 is .text
...
(gdb) find /b 0x63e0, 0xb001, 0x00, 0x48, 0x89, 0x45, 
0xc8, 0x31, 0xc0, 0x48, 0x63, 0x05, 0x5d, 0x98, 0x00, 0x00, 0x48, 0x8d, 0x04, 
0x85, 0x0f, 0x00, 0x00, 0x00, 0x48, 0x83, 0xe0, 0xf0, 0x48, 0x29, 0xc4, 0x48, 
0x89, 0x65, 0x98, 0x48, 0x29, 0xc4, 0x31, 0xc0, 0x48, 0x89, 0x65, 0x90, 0xe8, 
0xd8, 0x3e, 0x00, 0x00, 0x31, 0xc0, 0x66, 0x0f, 0x1f, 0x44, 0x00, 0x00, 0x48, 
0x8b, 0x4d, 0x98, 0x48, 0x8b, 0x55, 0x90, 0xc7
0x67a9 
1 pattern found.

(gdb) b *(0x67a9 + 42)
Breakpoint 3 at 0x67d3: file unhide-linux-bruteforce.c, line 73.

(gdb) x/10xb 0x67d3
0x67d3 :  0xe80xd80x3e0x000x000x31
0xc00x66
0x67db :  0x0f0x1f

(gdb) info b
Num Type   Disp Enb AddressWhat
3   breakpoint keep y   0x67d3 in brute at 
unhide-linux-br

Bug#946073: libkf5kiocore5: Several KDE applications crash when creating multiple nested new folders in the save as dialog.

2019-12-03 Thread Bernhard Übelacker

Package: libkf5kiocore5
Version: 5.54.1-1
Severity: normal
Tags: patch upstream


Dear Maintainer,
in the last year I hit a few crashes with kate,
without knowing how to reproduce the crash.

Today I found this upstream reports [1] and several
duplicates. With that information it was easy to reproduce
the crash by just creating several nested folders in the
save as dialog of okteta.

It got fixed upstream in [2] and is included in
upstream version 5.63.0.

As this may affect all users of the KDE save as dialog,
this might be considered for inclusion to stable?

Kind regards,
Bernhard


[1] https://bugs.kde.org/show_bug.cgi?id=401916
https://bugs.kde.org/show_bug.cgi?id=411310

[2] 
https://cgit.kde.org/kio.git/commit/src/core/kcoredirlister.cpp?id=f539b17ceec2a8c7a453228b7db62a7919b849be



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

Kernel: Linux 4.19.0-6-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 libkf5kiocore5 depends on:
ii  libacl12.2.53-4
ii  libc6  2.28-10
ii  libkf5auth55.54.0-2
ii  libkf5configcore5  5.54.0-1+deb10u1
ii  libkf5coreaddons5  5.54.0-1
ii  libkf5crash5   5.54.0-1
ii  libkf5dbusaddons5  5.54.0-1
ii  libkf5i18n55.54.0-1
ii  libkf5service-bin  5.54.0-1
ii  libkf5service5 5.54.0-1
ii  libqt5core5a   5.11.3+dfsg1-1+deb10u1
ii  libqt5dbus55.11.3+dfsg1-1+deb10u1
ii  libqt5network5 5.11.3+dfsg1-1+deb10u1
ii  libqt5xml5 5.11.3+dfsg1-1+deb10u1
ii  libstdc++6 8.3.0-6

libkf5kiocore5 recommends no packages.

libkf5kiocore5 suggests no packages.

-- no debconf information

# Buster/stable amd64

Thread 1 (Thread 0x7f25debb0c80 (LWP 2619)):
[KCrash Handler]
#6  0x7f25e4e16426 in KFileItem::~KFileItem() () from 
/usr/lib/x86_64-linux-gnu/libKF5KIOCore.so.5
#7  0x7f25e4eea06a in ?? () from 
/usr/lib/x86_64-linux-gnu/libKF5KIOCore.so.5
#8  0x7f25e4ee19cd in ?? () from 
/usr/lib/x86_64-linux-gnu/libKF5KIOCore.so.5
#9  0x7f25e381e9a3 in QMetaObject::activate(QObject*, int, int, void**) () 
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x7f25e382a3f7 in QTimer::timeout(QTimer::QPrivateSignal) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x7f25e381f09b in QObject::event(QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#12 0x7f25e42e14c1 in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#13 0x7f25e42e8970 in QApplication::notify(QObject*, QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#14 0x7f25e37f54f9 in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#15 0x7f25e3845ba8 in QTimerInfoList::activateTimers() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x7f25e3846404 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#17 0x7f25e1547f2e in g_main_context_dispatch () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#18 0x7f25e15481c8 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#19 0x7f25e154825c in g_main_context_iteration () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#20 0x7f25e3846797 in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#21 0x7f25de7ec401 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#22 0x7f25e37f41cb in 
QEventLoop::exec(QFlags) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#23 0x7f25e37fc1a2 in QCoreApplication::exec() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#24 0x559a5cc4aa25 in ?? ()
#25 0x7f25e326809b in __libc_start_main (main=0x559a5cc48ac0, argc=3, 
argv=0x7fffb1e60268, init=, fini=, 
rtld_fini=, stack_end=0x7fffb1e60258) at ../csu/libc-start.c:308
#26 0x559a5cc4c0ba in _start ()
[Inferior 1 (process 2619) detached]


gdb -q --pid 2619

generate-core-file /coredumps/core.kate.20191114.2619


##


apt install dpkg-dev devscripts xserver-xorg plasma-desktop gdb kate 
kate-dbgsym libkf5kiocore5-dbgsym libqt5core5a-dbgsym libqt5widgets5-dbgsym 
libglib2.0-0-dbgsym libqt5gui5-dbgsym

gdb -q /usr/bin/kate --core core.kate.20191114.2619

set width 0
set pagination off
bt

(gdb) bt
#0  0x7f25e330a720 in __GI___nanosleep (requested_time=0x7fffb1e5eee0, 
remaining=0x7fffb1e5eee0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
#1  0x7f25e330a62a in __sleep (seconds=0) at ../sysdeps/posix/sleep.c:55
#2  0x7f25e482deea in ?? () from /usr/lib/x86_64-linux-gnu/libKF5Crash.so.5
#3  0x7f25e482e68e in ?? () from /usr/lib/x86_64-li

Bug#942305: gimp: crashes when key press on numeric keys to rotate

2019-11-27 Thread Bernhard Übelacker

... a short addition:

This issue might also the the same as
described in this upstream issue:
 
https://github.com/scim-im/scim/issues/26

Kind regards,
Bernhard

Bug#942305: gimp: crashes when key press on numeric keys to rotate

2019-11-27 Thread Bernhard Übelacker

Control: reassign -1 scim-gtk-immodule 1.4.18-2.1
Control: affects -1 + gimp


Hello Masa O,
I tried to reproduce the crash you describe in a Buster/stable VM,
but was not able to reach the crash.

>From your backtrace there are some modules for scim input method
visible, but failed also to setup it correctly to have it loaded
into the gimp process. Some hints how to configure scim correctly
might be good.

I try to reassign this bug to the scim package, maybe you can
also confirm you are using the version above.

Bug #674827 could be related.

Kind regards,
Bernhard



Reconstructed backtrace:
  libgimpbase-2.0.so.0(gimp_stack_trace_print+0x397)[0x7f85411e3e27]   in 
gimp_stack_trace_print at gimputils.c:1378
  gimp(+0xd14a0)[0x5632946ef4a0]   in 
gimp_eek at errors.c:377
  gimp(+0xd18d8)[0x5632946ef8d8]   in 
gimp_fatal_error at errors.c:234
  gimp(+0xd2037)[0x5632946f0037]   in 
gimp_sigfatal_handler at signals.c:165
   libpthread.so.0(+0x12730)[0x7f85404eb730]   ??:?
 libgdk-x11-2.0.so.0(gdk_x11_drawable_get_xdisplay+0x49)[0x7f85412a3369]   in 
IA__gdk_x11_drawable_get_xdisplay at ./gdk/x11/gdkdrawable-x11.c:908
im-scim.so(scim_bridge_key_event_gdk_to_bridge+0xde)[0x7f8522e50d5e]   in 
scim_bridge_key_event_gdk_to_bridge at 
../scim-bridge-client-key-event-utility-gtk.c:123
 im-scim.so(+0x76df)[0x7f8522e506df]   in 
filter_key_event at ../scim-bridge-client-imcontext-gtk.c:130
 im-scim.so(+0x799c)[0x7f8522e5099c]   in 
scim_bridge_client_imcontext_filter_key_event at 
../scim-bridge-client-imcontext-gtk.c:787
  libgtk-x11-2.0.so.0(+0x11bc63)[0x7f854141ec63]   in 
gtk_im_multicontext_filter_keypress at ./gtk/gtkimmulticontext.c:333
   libgtk-x11-2.0.so.0(+0xc8da4)[0x7f85413cbda4]   in 
gtk_entry_key_press at ./gtk/gtkentry.c:4073
  libgtk-x11-2.0.so.0(+0x1331eb)[0x7f85414361eb]   in 
_gtk_marshal_BOOLEAN__BOXED at ./gtk/gtkmarshalers.c:84
  libgobject-2.0.so.0(g_closure_invoke+0xb1)[0x7f85407b1ba1]   in 
g_closure_invoke at ../../../gobject/gclosure.c:810
   libgobject-2.0.so.0(+0x23bbd)[0x7f85407c4bbd]   in 
signal_emit_unlocked_R at ../../../gobject/gsignal.c:3673
 libgobject-2.0.so.0(g_signal_emit_valist+0x47b)[0x7f85407cd9ab]   in 
g_signal_emit_valist at ../../../gobject/gsignal.c:3401
 libgobject-2.0.so.0(g_signal_emit+0x8f)[0x7f85407ce97f]   in 
g_signal_emit at ../../../gobject/gsignal.c:3447
  libgtk-x11-2.0.so.0(+0x249cac)[0x7f854154ccac]   in 
gtk_widget_event_internal at ./gtk/gtkwidget.c:5010
libgtk-x11-2.0.so.0(gtk_window_propagate_key_event+0xa8)[0x7f85415604e8]   in 
IA__gtk_window_propagate_key_event at ./gtk/gtkwindow.c:5199
 gimp(+0x2ccdbb)[0x5632948eadbb]   in 
gimp_window_key_press_event at gimpwindow.c:185
  libgtk-x11-2.0.so.0(+0x1331eb)[0x7f85414361eb]   in 
_gtk_marshal_BOOLEAN__BOXED at ./gtk/gtkmarshalers.c:84
 libgobject-2.0.so.0(g_closure_invoke+0x19d)[0x7f85407b1c8d]   in 
g_closure_invoke at ../../../gobject/gclosure.c:810
   libgobject-2.0.so.0(+0x23bbd)[0x7f85407c4bbd]   in 
signal_emit_unlocked_R at ../../../gobject/gsignal.c:3673
 libgobject-2.0.so.0(g_signal_emit_valist+0x47b)[0x7f85407cd9ab]   in 
g_signal_emit_valist at ../../../gobject/gsignal.c:3401
 libgobject-2.0.so.0(g_signal_emit+0x8f)[0x7f85407ce97f]   in 
g_signal_emit at ../../../gobject/gsignal.c:3447
  libgtk-x11-2.0.so.0(+0x249cac)[0x7f854154ccac]   in 
gtk_widget_event_internal at ./gtk/gtkwidget.c:5010
  libgtk-x11-2.0.so.0(gtk_propagate_event+0x17d)[0x7f854143455d]   in 
IA__gtk_propagate_event at ./gtk/gtkmain.c:2477
libgtk-x11-2.0.so.0(gtk_main_do_event+0x2eb)[0x7f854143487b]   in 
IA__gtk_main_do_event at ./gtk/gtkmain.c:1698
   libgdk-x11-2.0.so.0(+0x5bbac)[0x7f85412a7bac]   in 
gdk_event_dispatch at ./gdk/x11/gdkevents-x11.c:2425
 libglib-2.0.so.0(g_main_context_dispatch+0x2ae)[0x7f85406cff2e]   in 
g_main_dispatch at ../../../glib/gmain.c:3182
  libglib-2.0.so.0(+0x4e1c8)[0x7f85406d01c8]   in 
g_main_context_iterate at ../../../glib/gmain.c:3920
  libglib-2.0.so.0(g_main_loop_run+0xb2)[0x7f85406d04c2]   in 
g_main_loop_run at ../../../glib/gmain.c:4116
 gimp(app_run+0x357)[0x5632946eecb7]   in 
app_run at app.c:440
gimp(main+0x395)[0x5632946ee5b5]   in 
main at main.c:524
   libc.so.6(__libc_start_main+0xeb)[0x7f854033a09b]   in 
__libc_start_main at ../csu/libc-start.c:308

Bug#943505: mousepad: crashes when changing search direction

2019-11-24 Thread Bernhard Übelacker

Hello Geoff Tree,
I am not involved in packaging mousepad, but tried to reproduce
the issue. Unfortunately I could not trigger the crash.

Maybe you could install a coredump collector like systemd-coredump.
The last lines of the output of the command 'journalctl --no-pager'
should give the location where the next crash happened.

Some other hints about collecting more information
are in the following document:

https://wiki.debian.org/HowToGetABacktrace

Kind regards,
Bernhard

Bug#944284: xchm crashes on search

2019-11-22 Thread Bernhard Übelacker

Dear Maintainer,
I reported the issue upstream:

https://github.com/rzvncj/xCHM/issues/9

Kind regards,
Bernhard

Bug#944284: xchm crashes on search

2019-11-22 Thread Bernhard Übelacker

Control: tags -1 + upstream patch


Dear Maintainer,
I could reproduce the crash with some old versions of
php_enhanced_en.chm I found on the net [1].

The current version from php.net [2] does not crash.
While it looks like the search is also not working
and gives no results.

With a package built with the attached patch I could
search in both versions, and received the same results
like in windows.

Kind regards,
Bernhard


[1]
http://jftp.just.edu.tw/Edoc/php_enhanced_en.chm
http://ftp.ntu.edu.tw/php/distributions/manual/php_enhanced_kr.chm

[2]
https://www.php.net/distributions/manual/php_enhanced_en.chm

Backtrace:
(gdb) bt
#0  0x004a166e in memcpy (__len=, __src=, 
__dest=0xa2f4e0) at /usr/include/i386-linux-gnu/bits/string_fortified.h:34
#1  CHMFile::GetLeafNodeOffset (this=, text=..., 
initialOffset=, buffSize=, treeDepth=, ui=) at chmfile.cpp:974
#2  0x004a657f in CHMFile::IndexSearch (this=0xa5e720, text=..., 
wholeWords=true, titlesOnly=false, results=0xbf9b2848) at chmfile.cpp:818
#3  0x004be8a4 in CHMSearchPanel::OnSearch (this=0x97c060) at 
/usr/include/wx-3.0/wx/checkbox.h:63
#4  0xb75e9cdf in wxAppConsoleBase::CallEventHandler(wxEvtHandler*, 
wxEventFunctor&, wxEvent&) const () from 
/usr/lib/i386-linux-gnu/libwx_baseu-3.0.so.0
#5  0xb777c5f8 in wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase 
const&, wxEvtHandler*, wxEvent&) () from 
/usr/lib/i386-linux-gnu/libwx_baseu-3.0.so.0
#6  0xb777c716 in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) () 
from /usr/lib/i386-linux-gnu/libwx_baseu-3.0.so.0
#7  0xb777caac in wxEvtHandler::TryHereOnly(wxEvent&) () from 
/usr/lib/i386-linux-gnu/libwx_baseu-3.0.so.0
#8  0xb777cb3a in wxEvtHandler::ProcessEventLocally(wxEvent&) () from 
/usr/lib/i386-linux-gnu/libwx_baseu-3.0.so.0
...
Description: Avoid crash and make search work for specific file
 This is an attempt to start the search at the begin
 every time a block is received from chm_retrieve_object.
 Delivers the same search results as Windows 7 CHM viewer.

Author: Bernhard Ãbelacker 

Bug-Debian: https://bugs.debian.org/944284
Forwarded: no
Last-Update: 2019-11-22

--- xchm-1.23.orig/src/chmfile.cpp
+++ xchm-1.23/src/chmfile.cpp
@@ -985,6 +985,7 @@ uint32_t CHMFile::GetLeafNodeOffset(cons
 			if(text.CmpNoCase(word) <= 0) {
 cursor32 = buffer.get() + i + word_len + 1;
 initialOffset = UINT32ARRAY(cursor32);
+i = sizeof(uint16_t);
 break;
 			}
 

# Buster/stable i386 qemu VM 2019-11-22

apt update
apt dist-upgrade

apt install dpkg-dev devscripts systemd-coredump xserver-xorg lightdm openbox 
xterm mc gdb xchm xchm-dbgsym
apt build-dep libchm1
apt build-dep xchm

reboot


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

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


export LANG=C
export DISPLAY=:0





dmesg:
[78147.255491] xchm[18096]: segfault at 2749000 ip 0046d66e sp bfa35c30 error 4 
in xchm[46+3c000]
[78147.255515] Code: 04 0f 82 a5 fd ff ff 8b 06 8b 95 3c ff ff ff 89 02 8b 44 
0e fc 8d 7a 04 83 e7 fc 89 44 0a fc 89 d0 29 f8 01 c1 29 c6 c1 e9 02  a5 e9 
8d fd ff ff 8d 76 00 85 c0 0f 84 10 02 00 00 50 8b 85 10

0x0046d66e - 0x46 + 0x3c000 = 0x4966E

benutzer@debian:~$ addr2line --function --demangle --exe=/usr/bin/xchm 0x4966E
wxNavigationEnabled::AcceptsFocusRecursively() const
/usr/include/wx-3.0/wx/buffer.h:44


gdb -q --args /usr/bin/xchm

set width 0
set pagination off
directory /home/benutzer/source/xchm/orig/xchm-1.23/src
b main
run
dele 1

(gdb) info target
0x004196b0 - 0x00453d34 is .text

(gdb) find /b 0x004196b0, 0x00453d34, 0x04, 0x0f, 0x82, 0xa5, 0xfd, 0xff, 0xff, 
0x8b, 0x06, 0x8b, 0x95, 0x3c, 0xff, 0xff, 0xff, 0x89, 0x02, 0x8b, 0x44, 0x0e, 
0xfc, 0x8d, 0x7a, 0x04, 0x83, 0xe7, 0xfc, 0x89, 0x44, 0x0a, 0xfc, 0x89, 0xd0, 
0x29, 0xf8, 0x01, 0xc1, 0x29, 0xc6, 0xc1, 0xe9, 0x02, 0xf3, 0xa5, 0xe9, 0x8d, 
0xfd, 0xff, 0xff, 0x8d, 0x76, 0x00, 0x85, 0xc0, 0x0f, 0x84, 0x10, 0x02, 0x00, 
0x00, 0x50, 0x8b, 0x85, 0x10

0x425644 
1 pattern found.

(gdb) disassemble /r 0x425644,0x425644+62
Dump of assembler code from 0x425644 to 0x425682:
   0x00425644 :  04 0f   add$0xf,%al
   0x00425646 :  82 a5 fd ff ff 8b 06
andb   $0x6,-0x7403(%ebp)
   0x0042564d :  8b 95 3c ff ff ff   
mov-0xc4(%ebp),%edx
   0x00425653 :  89 02   mov
%eax,(%edx)
   0x00425655 :  8b 44 0e fc mov
-0x4(%esi,%ecx,1),%eax
   0x00425659 :  8d 7a 04lea
0x4(%edx),%edi
   0x0042565c :  83 e7 fcand
$0xfffc,%edi
   0x0042565f :  89 44 0a fc mov
%eax,-0x4(%edx,%ecx,1)
   0x00425663 :  89 d0   mov%edx,%eax
   0x00425665 :  29 f8   sub%edi,%eax
   0x00425667 :  01 c1   add%eax,%ecx
   0x00425669 :  29 c6   sub%eax,%esi
   0x0042566b :  c1 e9 02shr
$0x2,%ecx
   0x0042566e :  f3 a5   rep movsl 
%ds:(%esi),%es:(%edi)
   0

Bug#944858: qemu update causes FreeNAS VM to hang when vm is booted

Hello Stuart Lindley,
I am not involved in packaging qemu and just looking
through some bug reports.

Some informations that might be interesting for the
maintainer might be, which version of freenas you are running?

Based on your screenshot you start it via libvirt?

Maybe you could deliver the comand line of qemu
shown by e.g. "ps aux | grep -i qemu" on the host.

Are there any suspicious messages in the host 'dmesg'?

Do you know which last qemu version did not show the hang?
Maybe that was also running on a previous kernel package version?

Kind regards,
Bernhard

Bug#942086: xpdf: Memory leak on large document (even w/ continuousView turned off)

Hello Jean-Paul,
this might be the same issue as in following bug, which
has some more information and a patch:

https://bugs.debian.org/945188

Kind regards,
Bernhard

Bug#926501: xpdf: continuousView memory leak

Hello all,
this might be the same issue as in following bug, which
has some more information and a patch:

https://bugs.debian.org/945188

Kind regards,
Bernhard

Bug#945188: xpdf: memory leak when changing page

Control: tags -1 + patch


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

This issue might be in the package since poppler-0.71.patch.
This patch makes some changes how containers get accessed.

Following I found and tried to change in attached patch:
- std::erase, std::clear, std::remove:
  These methods of STL containers containing pointer to objects do
  not delete the objects pointed to.
- In continuousView in PDFCore::addPage the next page was inserted
  at the first position.

For running with valgrind it was nice to have the additional cflag
HAVE_XTAPPSETEXITFLAG set, as then the application cleans up
instead of just exit(0).

Bug #942086 and #926501 might be related.

Kind regards,
Bernhard

# Unstable amd64 qemu VM 2019-11-21

apt update
apt dist-upgrade


apt install dpkg-dev devscripts quilt systemd-coredump xserver-xorg lightdm 
openbox xterm htop mc gdb valgrind heaptrack heaptrack-gui pari-doc xpdf 
xpdf-dbgsym libfreetype6-dbgsym libpoppler82-dbgsym
apt build-dep xpdf



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

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




export LANG=C
export DISPLAY=:0

/usr/bin/xpdf.real /usr/share/pari/doc/users.pdf

# ~10 times next page and previous page - memory usage doubles.





##


# wget 
https://github.com/WuBingzheng/memleax/releases/download/v1.1.1/memleax_1.1.1-1_amd64.deb
# dpkg -i memleax_1.1.1-1_amd64.deb
# memleax $(pidof xpdf.real)
# gdb -q --args xpdf.real /usr/share/pari/doc/users.pdf
#   Reading symbols from 
/usr/lib/debug/.build-id/ab/a6d385be8071a6a44247a89331bee9f0494091.debug...
# memleax -d 
/usr/lib/debug/.build-id/ab/a6d385be8071a6a44247a89331bee9f0494091.debug 
$(pidof xpdf.real)
# Had no output at all.


##


script -a valgrind-xpdf.real_$(date +%Y-%m-%d_%H-%M-%S).txt -c 'valgrind 
/usr/bin/xpdf.real /usr/share/pari/doc/users.pdf'

script -a valgrind-xpdf.real_$(date +%Y-%m-%d_%H-%M-%S).txt -c 'valgrind 
--leak-check=full --show-reachable=yes --leak-resolution=high --num-callers=100 
--trace-children=yes /usr/bin/xpdf.real /usr/share/pari/doc/users.pdf'


==35071== 34,438,272 bytes in 11 blocks are possibly lost in loss record 1,608 
of 1,608
==35071==at 0x483577F: malloc (vg_replace_malloc.c:309)
==35071==by 0x11F82C: gmalloc (gmem.h:41)
==35071==by 0x11F82C: gmallocn (gmem.h:115)
==35071==by 0x11F82C: XPDFCore::updateTileData(PDFCoreTile*, int, int, int, 
int, bool) (XPDFCore.cc:1276)
==35071==by 0x119C5C: PDFCore::clippedRedrawRect(PDFCoreTile*, int, int, 
int, int, int, int, int, int, int, int, bool, bool) (PDFCore.cc:2171)
==35071==by 0x119D5F: PDFCore::redrawCbk(void*, int, int, int, int, bool) 
(PDFCore.cc:2068)
==35071==by 0x1166F5: dump (CoreOutputDev.cc:53)
==35071==by 0x1166F5: CoreOutputDev::dump() (CoreOutputDev.cc:46)
==35071==by 0x4E6016F: Gfx::go(bool) (Gfx.cc:827)
==35071==by 0x4E6049D: Gfx::display(Object*, bool) (Gfx.cc:714)
==35071==by 0x4EB6940: Page::displaySlice(OutputDev*, double, double, int, 
bool, bool, int, int, int, int, bool, bool (*)(void*), void*, bool (*)(Annot*, 
void*), void*, bool) (Page.cc:548)
==35071==by 0x11AD82: PDFCore::needTile(PDFCorePage*, int, int) 
(PDFCore.cc:924)
==35071==by 0x11BBB0: PDFCore::update(int, int, int, double, int, bool, 
bool, bool) (PDFCore.cc:724)
==35071==by 0x122380: XPDFCore::update(int, int, int, double, int, bool, 
bool, bool) (XPDFCore.cc:297)
==35071==by 0x11734E: gotoNextPage (PDFCore.cc:963)
==35071==by 0x11734E: PDFCore::gotoNextPage(int, bool) (PDFCore.cc:947)
==35071==by 0x1223E1: XPDFCore::gotoNextPage(int, bool) (XPDFCore.cc:325)
==35071==by 0x127937: XPDFViewer::nextPageCbk(_WidgetRec*, void*, void*) 
(XPDFViewer.cc:2451)
==35071==by 0x49361BA: ??? (in /usr/lib/x86_64-linux-gnu/libXm.so.4.0.4)
==35071==by 0x505F4DE: ??? (in /usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)
==35071==by 0x5060552: _XtTranslateEvent (in 
/usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)
==35071==by 0x5038479: XtDispatchEventToWidget (in 
/usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)
==35071==by 0x5038ED1: ??? (in /usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)
==35071==by 0x5039030: XtDispatchEvent (in 
/usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)
==35071==by 0x5044CFF: XtAppProcessEvent (in 
/usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)
==35071==by 0x503944C: XtAppMainLoop (in 
/usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)
==35071==by 0x11626C: main (xpdf.cc:310)



gdb -q --args /usr/bin/xpdf.real /usr/share/pari/doc/users.pdf

set width 0
set pagination off
directory /home/benutzer/source/xpdf/orig/xpdf-3.04/xpdf
directory /home/benutzer/source/libpoppler82/orig/poppler-0.71.0
b CoreOutputDev::CoreOutputDev
y
run


###


try1:

debian/rules
HAVE_XTAPPSETEXITFLAG 
--> XPDFApp::~XPDFApp get now reached

xpdf/XPDFApp.cc
void XPDFApp::

Bug#945130: mingw-w64-x86-64-dev: strftime fails on %e and gives incorrect string for %z

Am 21.11.19 um 16:13 schrieb Marius Mikučionis:
> 2019-11-21, th, 13:14 Bernhard Übelacker  <mailto:bernha...@mailbox.org>> wrote:
> 
> 
> I forgot to mention that I used a local built wine-4.20.
> There were lately some changes in that area in Wine, therefore
> if you use an older Wine version it might behave different.
> 
>     https://source.winehq.org/git/wine.git/history/HEAD:/dlls/msvcrt
> 
> 
> OK.
>  
> 
> But does the executable with -lucrt print the expected
> output in Windows?
> 
> 
> Interesting: in windows with -lucrt prints correctly, but not in wine-4.0.2.
> I see that Debian has wine64-development-4.19 and 4.20, I will test those.
> 
> Summary for %e:
>            | no -lucrt  | with -lucrt
> windows    | fail       | pass
> wine-4.0.2 | fail       | fail
> wine-4.19  | fail       | pass
> wine-4.20  | fail*      | pass
> 
> Summary for %z:
>            | no -lucrt  | with -lucrt
> windows    | fail       | pass
> wine-4.0.2 | fail       | fail
> wine-4.19  | fail       | fail
> wine-4.20  | fail       | pass
> 
> * wine-4.20 also prints extra debug information for %e without -lucrt:
> 0009:err:msvcrt:MSVCRT__invalid_parameter (null):0 (null): (null) 0
> 
> Looks like the issue is with the runtime environment and not with mingw.
> I still would like to understand if/why -lucrt is necessary in this case.
> The documentation does not mention any libraries, only headers.
>  
> 
> >     At least the binaries produced in my tests behave the same
> >     in Wine and Windows.
> >
> > Even without -lucrt ?
> > The ucrt adds those api-ms-win-crt-* dependencies, which do not
> seem to
> > be necessary.
> 
> Looking at the complete output of i686-w64-mingw32-objdump shows that
> without -lucrt strftime is imported from msvcrt.dll.
> With -lucrt it imports strftime from api-ms-win-crt-time-l1-1-0.dll.
> That is what I guess makes the difference.
> 
> 
> Does that mean that strftime implementation in msvcrt.dll is faulty?
> 

>From my point of view, Microsoft cannot change msvcrt.dll because plenty
legacy software may rely on the "old" behaviour.
Therefore we got then msvcr90.dll and so on. And now they invented UCRT.
As Stephen wrote in message 20, if you compile with visual studio the
binary will link also against these UCRT libraries.

And documentation seems just to cover supported development
environments...

> -- 
> Marius

Kind regards,
Bernhard

Bug#945130: mingw-w64-x86-64-dev: strftime fails on %e and gives incorrect string for %z



Am 21.11.19 um 12:09 schrieb Marius Mikučionis:
> 
> 2019-11-21, kt, 01:16 Bernhard Übelacker  <mailto:bernha...@mailbox.org>> rašė:

>     $ wine strftime-ucrt-7.exe
>     [%a]: [Tue]
>     [%e]: [ 5]
>     [%d]: [05]
>     [%-d]: (empty) errno=22
>     [%#d]: [5]
>     [%b]: [Nov]
>     [%Y]: [2019]
>     [%H]: [03]
>     [%M]: [02]
>     [%S]: [01]
>     [%z]: [+0100]
>     [%Z]: [Mitteleuropõische Zeit]
>     [%b%e, %Y, %H:%M:%S %z]: [Nov 5, 2019, 03:02:01 +0100]
> 
> (msvcrt.dll still appears; the same result for 7.0.0-2 and 6.0.0-3.)
> 
> Your output is correct, but I am not getting that, very strange.
> 

I forgot to mention that I used a local built wine-4.20.
There were lately some changes in that area in Wine, therefore
if you use an older Wine version it might behave different.

https://source.winehq.org/git/wine.git/history/HEAD:/dlls/msvcrt

But does the executable with -lucrt print the expected
output in Windows?


> At least the binaries produced in my tests behave the same
> in Wine and Windows.
> 
> Even without -lucrt ?
> The ucrt adds those api-ms-win-crt-* dependencies, which do not seem to
> be necessary.

Looking at the complete output of i686-w64-mingw32-objdump shows that
without -lucrt strftime is imported from msvcrt.dll.
With -lucrt it imports strftime from api-ms-win-crt-time-l1-1-0.dll.
That is what I guess makes the difference.

> Thank you for the effort, perhaps something strange is happening with my
> setup, I could not find anyone else on internet with this issue.
> 
> -- 
> Marius

Kind regards,
Bernhard

Bug#945130: mingw-w64-x86-64-dev: strftime fails on %e and gives incorrect string for %z

2019-11-20 Thread Bernhard Übelacker

Hello Marius Mikucionis,
I am not anyhow involved in maintaining mingw-w64.
But I guess I found something.

First I fear that mingw-w64 does not link as much static
as you expect it to.
All crossbuilt executables still dynamically link to msvcrt.dll.

$ i686-w64-mingw32-objdump -p strftime-6.exe | grep 'DLL Name:'
DLL Name: KERNEL32.dll
DLL Name: msvcrt.dll

And the Microsoft page might just be right for later versions
of c runtimes they provide.

Further I found this information [2], which is as far as
I understand about recompiling mingw.
But I tried just to modify the compile/link command,
which I guess is kind of the expected output?

$ i686-w64-mingw32-gcc -static -O3 -Wall -o strftime-ucrt-7.exe strftime.c 
-lucrt
$ i686-w64-mingw32-objdump -p strftime-ucrt-7.exe | grep 'DLL Name:'
DLL Name: KERNEL32.dll
DLL Name: msvcrt.dll
DLL Name: api-ms-win-crt-environment-l1-1-0.dll
DLL Name: api-ms-win-crt-heap-l1-1-0.dll
DLL Name: api-ms-win-crt-private-l1-1-0.dll
DLL Name: api-ms-win-crt-runtime-l1-1-0.dll
DLL Name: api-ms-win-crt-stdio-l1-1-0.dll
DLL Name: api-ms-win-crt-string-l1-1-0.dll
DLL Name: api-ms-win-crt-time-l1-1-0.dll

$ wine strftime-ucrt-7.exe
[%a]: [Tue]
[%e]: [ 5]
[%d]: [05]
[%-d]: (empty) errno=22
[%#d]: [5]
[%b]: [Nov]
[%Y]: [2019]
[%H]: [03]
[%M]: [02]
[%S]: [01]
[%z]: [+0100]
[%Z]: [Mitteleuropõische Zeit]
[%b%e, %Y, %H:%M:%S %z]: [Nov 5, 2019, 03:02:01 +0100]

(msvcrt.dll still appears; the same result for 7.0.0-2 and 6.0.0-3.)


So maybe you could examine this binaries from 2014 if they
need also some Dlls?

At least the binaries produced in my tests behave the same
in Wine and Windows.

Kind regards,
Bernhard


[1] 
https://stackoverflow.com/questions/55728544/how-to-avoid-msvcrt-dll-compiling-with-mingw64

Bug#945115: armagetronad does not find itself (and fails to start)

2019-11-20 Thread Bernhard Übelacker

Control: tags -1 + upstream fixed-upstream patch


Dear Maintainer,
the issue seems to be with newer gcc versions string literals
get not put into memory mappings " r-xp ",
instead they are mapped " r--p ".

Such a string literal is used to determine the location
of the executable.

Upstream fixed it already [1] [2].
The issue points also to a fallback if reading from
memory fails, which might be worth to consider [3].

Kind regards,
Bernhard


[1] https://gitlab.com/armagetronad/armagetronad/issues/6
[2] 
https://gitlab.com/armagetronad/armagetronad/commit/aad48287a98d32112c8600ee8d1b96de25500987
[3] 
https://gitlab.com/armagetronad/armagetronad/commit/90036a889d6ca9fbcf4ce950e0e803eb2204e06b


(gdb) bt
#0  br_locate (symbol=symbol@entry=0x556bc1f8) at 
../../src/thirdparty/binreloc/prefix.c:103
#1  0x556af4be in tPathToExecutable::Set (this=0x55749a80 
, defaultPath=) at 
../../src/tools/tDirectories.cpp:1272
#2  tDirectoriesCommandLineAnalyzer::DoInitialize (this=, 
parser=...) at ../../src/tools/tDirectories.cpp:1471
#3  0x556ba06d in tCommandLineAnalyzer::Initialize (parser=..., 
this=0x55749a30 ) at ../../src/tools/tCommandLine.h:112
#4  tCommandLineData::Analyse (this=this@entry=0x7fffe040, 
argc=argc@entry=1, argv=argv@entry=0x7fffe598) at 
../../src/tools/tCommandLine.cpp:115
#5  0x5558a0be in main (argc=1, argv=0x7fffe598) at 
../../src/tron/gArmagetron.cpp:509
(gdb) finish
Run till exit from #0  br_locate (symbol=symbol@entry=0x556bc1f8) at 
../../src/thirdparty/binreloc/prefix.c:103
0x556af4be in tPathToExecutable::Set (this=0x55749a80 
, defaultPath=) at 
../../src/tools/tDirectories.cpp:1272
1272char const * bestGuess = SELFPATH;
Value returned is $1 = 0x0

Bug#935098: nmap 7.80: random segfaults while scanning

Dear Maintainer,
I tried to get some more information and was able
to record a crash with rr.

When continuing from below backtrace [2] it continues
into a recursion until the segfault is reached.
Therefore this might not be an nmap bug.

This led me to this bug report [1], which mentions
upstream lua-lpeg version 1.0.1 fixes this issue,
or alternatively has a patch for lua-lpeg 1.0.0.

Kind regards
Bernhard


[1] https://bugs.debian.org/942031


[2]
(rr) bt
#0  0x7f233d19d4cc in hascaptures (tree=0x556ae6cfca74, 
tree@entry=0x556ae6cfca94) at lpcode.c:144
#1  0x7f233d19d4cc in hascaptures (tree=tree@entry=0x556ae6cfca8c) at 
lpcode.c:144
#2  0x7f233d19d4cc in hascaptures (tree=0x556ae6cfca84, 
tree@entry=0x556ae6cfca94) at lpcode.c:144
#3  0x7f233d19d4cc in hascaptures (tree=tree@entry=0x556ae6cfca8c) at 
lpcode.c:144
#4  0x7f233d19d4cc in hascaptures (tree=0x556ae6cfca84, 
tree@entry=0x556ae6cfc9fc) at lpcode.c:144
#5  0x7f233d19d4cc in hascaptures (tree=tree@entry=0x556ae6cfc9f4) at 
lpcode.c:144
#6  0x7f233d19e1ec in codecapture (fl=0x7f233d19f280 , tt=-1, 
tree=0x556ae6cfc9ec, compst=0x73bd2930) at lpcode.c:720
#7  codegen (compst=compst@entry=0x73bd2930, 
tree=tree@entry=0x556ae6cfc9ec, opt=opt@entry=0, tt=tt@entry=-1, 
fl=fl@entry=0x7f233d19f280 ) at lpcode.c:905
#8  0x7f233d19e7f9 in codegrammar (compst=compst@entry=0x73bd2930, 
grammar=grammar@entry=0x556ae6cfc974) at lpcode.c:850
#9  0x7f233d19e17b in codegen (compst=compst@entry=0x73bd2930, 
tree=tree@entry=0x556ae6cfc974, opt=opt@entry=0, tt=tt@entry=-1, 
fl=fl@entry=0x7f233d19f280 ) at lpcode.c:907
#10 0x7f233d19e30c in codecapture (fl=0x7f233d19f280 , tt=-1, 
tree=0x556ae6cfc96c, compst=0x73bd2930) at lpcode.c:726
#11 codegen (compst=compst@entry=0x73bd2930, 
tree=tree@entry=0x556ae6cfc96c, opt=opt@entry=0, tt=tt@entry=-1, 
fl=fl@entry=0x7f233d19f280 ) at lpcode.c:905
#12 0x7f233d19e30c in codecapture (fl=0x7f233d19f280 , tt=-1, 
tree=0x556ae6cfc964, compst=0x73bd2930) at lpcode.c:726
#13 codegen (compst=compst@entry=0x73bd2930, tree=0x556ae6cfc964, 
tree@entry=0x556ae6cfc86c, opt=opt@entry=0, tt=tt@entry=-1, 
fl=fl@entry=0x7f233d19f280 ) at lpcode.c:905
#14 0x7f233d19e30c in codecapture (fl=0x7f233d19f280 , tt=-1, 
tree=0x556ae6cfc864, compst=0x73bd2930) at lpcode.c:726
#15 codegen (compst=compst@entry=0x73bd2930, 
tree=tree@entry=0x556ae6cfc864, opt=opt@entry=0, tt=tt@entry=-1, 
fl=fl@entry=0x7f233d19f280 ) at lpcode.c:905
#16 0x7f233d19e7f9 in codegrammar (compst=compst@entry=0x73bd2930, 
grammar=grammar@entry=0x556ae6cfc704) at lpcode.c:850
#17 0x7f233d19e17b in codegen (compst=compst@entry=0x73bd2930, 
tree=tree@entry=0x556ae6cfc704, opt=opt@entry=0, tt=tt@entry=-1, 
fl=fl@entry=0x7f233d19f280 ) at lpcode.c:907
#18 0x7f233d19e973 in compile (L=L@entry=0x556ae88bb058, p=0x556ae6cfc6f8) 
at lpcode.c:977
#19 0x7f233d19bbc4 in prepcompile (L=L@entry=0x556ae88bb058, p=, idx=1) at lptree.c:1099
#20 0x7f233d19d01b in lp_match (L=0x556ae88bb058) at lptree.c:1154
#21 0x7f233d16a585 in luaD_precall (L=L@entry=0x556ae88bb058, 
func=func@entry=0x556ae88bb190, nresults=nresults@entry=-1) at ldo.c:365
#22 0x7f233d16a735 in luaD_precall (L=L@entry=0x556ae88bb058, 
func=func@entry=0x556ae88bb190, nresults=nresults@entry=-1) at ldo.c:344
#23 0x7f233d1775d5 in luaV_execute (L=L@entry=0x556ae88bb058) at lvm.c:1149
#24 0x7f233d16a820 in unroll (L=0x556ae88bb058, ud=) at 
ldo.c:555
#25 0x7f233d169d82 in luaD_rawrunprotected (L=L@entry=0x556ae88bb058, 
f=f@entry=0x7f233d16a830 , ud=ud@entry=0x73bd2e1c) at ldo.c:142
#26 0x7f233d16aa35 in lua_resume (L=L@entry=0x556ae88bb058, 
from=from@entry=0x556ae673a328, nargs=, nargs@entry=2) at 
ldo.c:662
#27 0x7f233d17cc57 in auxresume (L=L@entry=0x556ae673a328, 
co=co@entry=0x556ae88bb058, narg=2) at lcorolib.c:39
#28 0x7f233d17cfa7 in luaB_coresume (L=0x556ae673a328) at lcorolib.c:60
#29 0x7f233d16a585 in luaD_precall (L=L@entry=0x556ae673a328, 
func=func@entry=0x556ae84e7620, nresults=nresults@entry=3) at ldo.c:365
#30 0x7f233d16a735 in luaD_precall (L=L@entry=0x556ae673a328, 
func=func@entry=0x556ae84e7620, nresults=nresults@entry=3) at ldo.c:344
#31 0x7f233d177355 in luaV_execute (L=L@entry=0x556ae673a328) at lvm.c:1134
#32 0x7f233d16a998 in luaD_call (L=L@entry=0x556ae673a328, func=, nResults=nResults@entry=0) at ldo.c:496
#33 0x7f233d16a9c1 in luaD_callnoyield (L=L@entry=0x556ae673a328, 
func=, nResults=nResults@entry=0) at ldo.c:506
#34 0x7f233d1664cc in lua_callk (L=L@entry=0x556ae673a328, 
nargs=nargs@entry=2, nresults=nresults@entry=0, ctx=ctx@entry=0, k=k@entry=0x0) 
at lapi.c:924
#35 0x556ae5dfd773 in run_main (L=0x556ae673a328) at nse_main.cc:668
#36 0x7f233d16a585 in luaD_precall (L=L@entry=0x556ae673a328, 
func=0x556ae84e73d0, nresults=0) at ldo.c:365
#37 0x7f233d16a963 in luaD_precall (nresults=, 
func=, L=0x556ae673a32

Bug#944137: neomutt: Fail on launch with "munmap_chunk(): invalid pointer"

Control: tags -1 + moreinfo


Hello Parleur,
is this still an problem with current version in unstable?

If yes, you could maybe supply some more informations.

One way would be to install the package systemd-coredump
and see if in 'journalctl --no-pager' appear some backtraces
of the issue, which could be forwarded to this bug.

Alternatively you might have a look in [1] to get
more information for the maintainer.

Kind regards,
Bernhard

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

Bug#944284: xchm crashes on search

Control: tags -1 + moreinfo


Hello dinar,
I tried to reproduce the crash inside a minimal
i386 buster VM, but could not get xchm to crash
on my downloaded version of php_enhanced_en.chm [1].

Is this the file you are using, too?

Without further information the maintainer is maybe
not able to resolve this issue.

Maybe you could forward the last few lines of
'dmesg' output after the crash happened?

Or start xchm from a terminal and forward the output
of that?

Another way would be to install e.g. "systemd-coredump"
and forward the related lines "journalctl --no-pager",
after the crash happened.

Further information on providing more information could
be found in [1].

Kind regards,
Bernhard


[1] https://www.php.net/distributions/manual/php_enhanced_en.chm
[2] https://wiki.debian.org/HowToGetABacktrace

Bug#944914: libgpgme11: Buffer overflow while using claws-mail

Hello Lars,

> in fact they all happen with the same program (claws-mail).

> Besides the claws-mail crashes I did not notice any other unexpected behavior.

Yes, if crashes are just in one application then it seems less
likely to be an hardware issue.


Maybe it is of some help, following seem to be locations with the
missing symbols:
...
#8  0xb6441a7a in __fdelt_chk (d=194142480) at fdelt_chk.c:25
#9  0xb27e5281 in  () at libgpgme.so.11, in _gpgme_io_select at 
../../src/posix-io.c:788
#10 0xb27bf7fc in  () at libgpgme.so.11, in _gpgme_wait_on_condition at 
../../src/wait-private.c:87
#11 0xb27bf9ec in  () at libgpgme.so.11, in _gpgme_wait_one at 
../../src/wait-private.c:170
#12 0xb27c5201 in gpgme_op_verify () at libgpgme.so.11, ../../src/verify.c, 
line 1197.
...


Another question, which version of claws-mail and plugins are you running?
(And are they the binaries from debian or self-built?)


Maybe a run with valgrind could shed some light on some wrong memory accesses.
(But may also write many unrelated accesses,
and slow the application down to an unusable speed.)

I found this upstream feature request, which could fit,
but there is also a change mentioned that should avoid that crash,
that is already included ...
Are you maybe hitting this limit?

https://dev.gnupg.org/T2385

Kind regards,
Bernhard

Bug#944915: libldap-2.4-2: Segmentation fault in "ldap_unbind_ext"

Hello Lars,
just a wild guess - is claws-mail doing these ldap queries
in parallel in different threads? This in combination with
the unsteady connection to the server could make two threads
operate on the same structures?

In that case following gdb output would show all
threads with their backtraces:
(gdb) thread apply all bt

Or with showing also the variables:
(gdb) thread apply all bt full


And how do you get the backtraces? Are you running
with a gdb attached to it permanently?
Then you could create a core when the crash happened with
(gdb) generate-core-file /home/someone/corefile

Otherwise you could have a look at a coredump collector
like systemd-coredump and its setting Storage=external.

With these files someone could examine them later
for some more details, if the matching package and dbgsyms
are installed.

Kind regards,
Bernhard

Bug#944585: gimp: Unable to upgrade

Hello Nicolas Patrois,
following page demonstrates better what I tried to say:

  https://buildd.debian.org/status/package.php?p=gimp

There the architecture dependent packages for i386 got built
and "installed" to unstable, but the arch :all packages,
like gimp-data, failed to build because of an issue
with libgegl-dev.

Kind regards,
Bernhard

Bug#944369: edid-decode crashes with division-by-zero for incorrect EDID

Hello Alex Riesen,
I am not the maintainer of edid-decode, but was just
looking through some random issues.

Your attached output of the current upstream might
point to this commit [1].

But to be sure either you should attach a copy of
your input file, or if that is now wanted, 
a backtrace like described in [2]

Kind regards,
Bernhard

[1] 
https://git.linuxtv.org/edid-decode.git/commit/?id=0da30bd8cbe8c023236f22ad2a8477a1f0b96679
[2] https://wiki.debian.org/HowToGetABacktrace

Bug#944372: mailutils: "mail" command segfaults

Hello Steve Newcomb,
I am not the mailutils maintainer, but just came across you report.

The information you supplied might not be enough
for the maintainer to track down the issue, and
it might be related to the content of your mail directory.

You supplied the dmesg output, but even when the crash shows up
in libc-2.28.so, the problem normally is the
application calling into libc.

Maybe you could install a core dump collector like 'systemd-coredump'?
That way you should receive a maybe helpfull backtrace
in the output of your journalctl.
When installing the debug symbols like described in [1] that
information should be even better.

Kind regards,
Bernhard

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

Bug#944585: gimp: Unable to upgrade

Hello Nicolas Patrois,
not being a gimp maintainer, but might this just the
the nature of unstable - gimp:i386 got installed for some
reason, but gimp-data:all did not get installed
to the FTPs, maybe because of an failure of gegl, I guess,
which failed on most of the architecures except i386.

Kind regards,
Bernhard

Bug#944914: libgpgme11: Buffer overflow while using claws-mail

Hello Lars,
because you mention repeating crashes which, as far as I see, are
in different programs in different backtraces.

Maybe the problems are created by a bad memory module?
Therefore could you please run a tester like memtest86+, just
to rule out an hardware issue?

Kind regards,
Bernhard

Bug#944915: libldap-2.4-2: Segmentation fault in "ldap_unbind_ext"

On Sun, 17 Nov 2019 10:33:10 -0800 Ryan Tandy  wrote:
> On Sun, Nov 17, 2019 at 05:11:13PM +0100, Lars Kruse wrote:
> >  #0  0xb77acbea in ldap_unbind_ext () at 
> > /usr/lib/i386-linux-gnu/libldap_r-2.4.so.2
> 
> Please could you install libldap-2.4-2-dbgsym and obtain the backtrace 
> again:
> 
> https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols
> 

Hello Lars, hello Ryan,
having a proper backtrace with symbols installed would be better,
but I think that last address translates to:

  0x.bea in ldap_unbind_ext at unbind.c:46

That would be that line:

  46  assert( LDAP_VALID( ld ) );

Therefore this function might have received ld pointing to
existing memory, but the ld->ldc might point to an invalid address.

So having that crash with gdb attached, the output of
following commands might be interesting too:

  print ld
  print ld->ldc
  print *ld
  print *(ld->ldc)

Kind regards,
Bernhard

Bug#944431: Segfault on startup

Hello Markus, hello Enrico,
I am sorry to be late, but I guess I have found the issue.
The function SetThreadPriority does not return properly
therefore the following function gets executed which writes
to somewhere, that causes later the crash below.

The build logs show a warning for this issue:

tmp/compat_mini.cpp: In function ‘int SetThreadPriority(THREAD_HANDLE, 
int)’:
tmp/compat_mini.cpp:106:1: warning: no return statement in function 
returning non-void [-Wreturn-type]
  106 | }
  | ^

Attached patch adds return statements for all functions
currently triggering this warning.

Kind regards,
Bernhard


(gdb) bt
#0  0x562c7679292e in flip () at komat/Berusky3d_ini.cpp:46
#1  0x562c767ea5e4 in ddxPublish () at tmp/compat.cpp:196
#2  0x562c767ea6a9 in DisplayFrame () at tmp/compat.cpp:120
#3  0x562c76737374 in RunMenu (p_File_Name=p_File_Name@entry=0x562c76888c8b 
"mainmenu.txt", hWnd=hWnd@entry=0x0, p_ad=, cpu=cpu@entry=8304) 
at kofola/Menu.cpp:5810
#4  0x562c767771b7 in winmain_Game_Run (p_Level_Name=0x562c76bf3148 
 "") at kofola/game_main.cpp:252
#5  0x562c7671b293 in main (argc=, argv=) at 
komat/Berusky3d_ini.cpp:360
Description: Avoid 'no return statement in function returning non-void'
Author: Bernhard Ãbelacker 

Bug-Debian: https://bugs.debian.org/944431
Forwarded: no
Last-Update: 2019-11-18

--- berusky2-0.10.orig/src/tmp/compat_mini.cpp
+++ berusky2-0.10/src/tmp/compat_mini.cpp
@@ -92,7 +92,7 @@ THREAD_HANDLE CreateThread(void *lpThrea
 
 int CloseHandle(THREAD_HANDLE handle)
 {
-
+  return 1;
 }
 
 void ExitThread(dword dwExitCode)
@@ -103,10 +103,12 @@ void ExitThread(dword dwExitCode)
 
 int SetThreadPriority(THREAD_HANDLE hThread, int nPriority)
 {
+  return 1;
 }
 
 int GetThreadPriority(THREAD_HANDLE hThread)
 {
+  return 0/*THREAD_PRIORITY_NORMAL*/;
 }
 
 int GetExitCodeThread(THREAD_HANDLE hThread, dword *lpExitCode)

# Buster/stable amd64 qemu VM 2019-11-15


apt update
apt dist-upgrade


apt install systemd-coredump dpkg-dev devscripts xserver-xorg lightdm openbox 
xterm gdb valgrind rr berusky2 berusky2-dbgsym
apt build-dep berusky2

reboot

echo 1 > /proc/sys/kernel/perf_event_paranoid


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



export DISPLAY=:0
export LANG=C


berusky2
# crashes

rr berusky2
# does not crash

valgrind berusky2
# crashes

valgrind --track-origins=yes berusky2
# crashes

gdb -q --args berusky2
# crashes




$ berusky2 
Berusky 2 v.0.10 (C) Anakreon 2011, http://www.anakreon.cz/
...
Kofola: - Load bitmap pro herni menu
--Total load time 0.2 s -
APAK: font_en.pak
Velikost AFAT: 2.6KB
Velikost Archivu: 0.4MB
Souboru: 7
Adresaru: 0
Uzlu: 2
b2_2d_font.pTTable = 0x563f6ddc1160
set font = font_en.pak
APAK: font_system_en.pak
Velikost AFAT: 2.6KB
Velikost Archivu: 0.1MB
Souboru: 7
Adresaru: 0
Uzlu: 2
b2_2d_font.pTTable = 0x563f70bd40f0
set font = font_system_en.pak
Segmentation fault (core dumped)


#


Nov 15 17:22:58 debian systemd-coredump[647]: Process 627 (berusky2) of user 
1000 dumped core.
  
  Stack trace of thread 627:
  #0  0x563f6b62b92e n/a 
(berusky2)
  #1  0x563f6b6835e4 n/a 
(berusky2)
  #2  0x563f6b6836a9 n/a 
(berusky2)
  #3  0x563f6b5d0374 n/a 
(berusky2)
  #4  0x563f6b6101b7 n/a 
(berusky2)
  #5  0x563f6b5b4293 main 
(berusky2)
  #6  0x7f2f6423a09b 
__libc_start_main (libc.so.6)
  #7  0x563f6b5b450a n/a 
(berusky2)
  
  Stack trace of thread 642:
  #0  0x7f2f64304819 __poll 
(libc.so.6)
  #1  0x7f2f63bdd9af n/a 
(libasound.so.2)
  #2  0x7f2f63bddccb 
snd_pcm_wait (libasound.so.2)
  #3  0x7f2f6498d2ff n/a 
(libopenal.so.1)
  #4  0x7f2f6499bb67 n/a 
(libopenal.so.1)
  #5  0x7f2f64701fa3 
start_thread (libpthread.so.0)
  #6  0x7f2f6430f4cf __clone 
(libc.so.6)
  
  Stack trace of thread 643:
  #0  0x7f2f6470a896 
do_futex_wait.constprop.1 (libpthread.so.0)

Bug#944658: mailavenger: FTBFS on i386

2019-11-15 Thread Bernhard Übelacker

Dear Maintainer,
I tried to find out what happens and I think it is
related to the changes from #928467.
Because of these the configure script searches now
for libdb-5.3.a in directory /usr/lib/i686-linux-gnu
(in configure "$dir/lib/${host_cpu}-${host_os}").

Unfortunately that library lives in /usr/lib/i386-linux-gnu.

Changing in debian/rules the --host and --build arguments
to DEB_..._MULTIARCH would make the package build in i386,
but I cannot say if that would defeat the whole purpose
of the change in #928467, therefore I hope its ok CCing
to Helmut Grohne.

Kind regards,
Bernhard

Bug#944541: Fcitx: frequently crashes

2019-11-14 Thread Bernhard Übelacker

Dear Maintainer,
the above backtrace lacks symbols but should
match something like below.

Kind regards,
Bernhard


>From submitter:   | Reconstructed:
   fcitx(+0x1927)[0x5568b6236927] | 0x55b5bef8e927 
in OnException at ./src/core/errorhandler.c:173
  libc.so.6(+0x3a100)[0x7f4d1a437100] | 0x7f7093046100 
<__restore_rt>
  libc.so.6(+0xa362d)[0x7f4d1a4a062d] | 0x7f70930af62d 
../sysdeps/x86_64/multiarch/strstr-sse2-unaligned.S:40
fcitx-cloudpinyin.so(+0x7097)[0x7f4d18ae5097] | 0x7f7090f59097 
in BaiduParsePinyin at ./src/parse.c:164
fcitx-cloudpinyin.so(+0x4a1c)[0x7f4d18ae2a1c] | 0x7f7090f56a1c 
in CloudPinyinHandleRequest at ./src/cloudpinyin.c:505
  libfcitx-core.so.0(+0xa38a)[0x7f4d1a61838a] | 0x7f709322738a 
in RunInstance () at ./src/lib/fcitx/instance.c:331
libfcitx-core.so.0(FcitxInstanceRun+0x57)[0x7f4d1a618b27] | 0x7f7093227b27 
in FcitxInstanceRun () at ./src/lib/fcitx/instance.c:140
   fcitx(+0x12bf)[0x5568b62362bf] | 0x55b5bef8e2bf 
in main () at ./src/core/fcitx.c:80
libc.so.6(__libc_start_main+0xeb)[0x7f4d1a423bbb] | 0x7f7093032bbb 
in __libc_start_main () at ../csu/libc-start.c:308
   fcitx(+0x133a)[0x5568b623633a] | 0x55b5bef8e33a 
in _start ()

# Buster/unstable amd64 qemu VM 2019-11-14


apt update
apt dist-upgrade


apt install systemd-coredump xserver-xorg sddm lxqt xterm dbus-x11 binutils gdb 
fcitx fcitx-module-cloudpinyin fcitx-bin-dbgsym libfcitx-core0-dbgsym 
fcitx-module-cloudpinyin-dbgsym

systemctl stop sddm
systemctl start sddm
# Login


#export DISPLAY=:0
#export LANG=C
#
#gdb -q --args /usr/bin/fcitx
#set width 0
#set pagination off
#set backtrace past-main
#b main
#run
#b FcitxInstanceRun
#cont
#b RunInstance
#cont


gdb -q -ex 'set width 0' -ex 'set pagination off' -ex 'set backtrace past-main' 
-ex "attach $(pidof fcitx)"





FCITX 4.2.9.6 -- Get Signal No.: 11
Date: try "date -d @1573485580" if you are using GNU date ***
ProcessID: 3149

From submitter:   | Reconstructed:
   fcitx(+0x1927)[0x5568b6236927] | 0x55b5bef8e927 
in OnException at ./src/core/errorhandler.c:173
  libc.so.6(+0x3a100)[0x7f4d1a437100] | 0x7f7093046100 
<__restore_rt>
  libc.so.6(+0xa362d)[0x7f4d1a4a062d] | 0x7f70930af62d 
../sysdeps/x86_64/multiarch/strstr-sse2-unaligned.S:40
fcitx-cloudpinyin.so(+0x7097)[0x7f4d18ae5097] | 0x7f7090f59097 
in BaiduParsePinyin at ./src/parse.c:164
fcitx-cloudpinyin.so(+0x4a1c)[0x7f4d18ae2a1c] | 0x7f7090f56a1c 
in CloudPinyinHandleRequest at ./src/cloudpinyin.c:505
  libfcitx-core.so.0(+0xa38a)[0x7f4d1a61838a] | 0x7f709322738a 
in RunInstance () at ./src/lib/fcitx/instance.c:331
libfcitx-core.so.0(FcitxInstanceRun+0x57)[0x7f4d1a618b27] | 0x7f7093227b27 
in FcitxInstanceRun () at ./src/lib/fcitx/instance.c:140
   fcitx(+0x12bf)[0x5568b62362bf] | 0x55b5bef8e2bf 
in main () at ./src/core/fcitx.c:80
libc.so.6(__libc_start_main+0xeb)[0x7f4d1a423bbb] | 0x7f7093032bbb 
in __libc_start_main () at ../csu/libc-start.c:308
   fcitx(+0x133a)[0x5568b623633a] | 0x55b5bef8e33a 
in _start ()



0x5568b6236927 - 0x5568b623633a = 0x5ED   | 0x55b5bef8e33a 
+ 0x5ED = 0x55B5BEF8E927
0x7f4d18ae5097 - 0x7f4d18ae2a1c = 0x267B  | 0x7f7090f56a1c 
+ 0x267B = 0x7F7090F59097
0x7f4d1a4a062d - 0x7f4d1a423bbb = 0x7CA72 | 0x7f7093032bbb 
+ 0x7CA72 = 0x7F70930AF62D
0x7f4d1a437100 - 0x7f4d1a423bbb = 0x13545 | 0x7f7093032bbb 
+ 0x13545 = 0x7F7093046100



addr2line --exe=/usr/bin/fcitx 0x1927   
addr2line: DWARF error: unable to read alt ref 1211 ??:0
addr2line --exe=/usr/lib/x86_64-linux-gnu/libc.so.6 0x3a100 
??:?
addr2line --exe=/usr/lib/x86_64-linux-gnu/libc.so.6 0xa362d 
/build/glibc-suXNNi/glibc-2.29/string/../sysdeps/x86_64/multiarch/strstr-sse2-unaligned.S:40
addr2line --exe=/usr/lib/x86_64-linux-gnu/fcitx/fcitx-cloudpinyin.so 0x7097 
./obj-x86_64-linux-gnu/src/./src/parse.c:164
addr2line --exe=/usr/lib/x86_64-linux-gnu/fcitx/fcitx-cloudpinyin.so 0x4a1c 
./obj-x86_64-linux-gnu/src/./src/cloudpinyin.c:505
addr2line --exe=/usr/lib/x86_64-linux-gnu/libfcitx-core.so.0 0xa38a 
./obj-x86_64-linux-gnu/src/lib/fcitx/./src/lib/fcitx/instance.c:329

FcitxInstanceRun+0x57
addr2line --exe=/usr/bin/fcitx 0x12bf   
./src/core/fcitx.c:82

Bug#943588: libllvm9 version differs between amd64 and i386

2019-10-30 Thread Bernhard Übelacker

Hello,
this seems to be caused by a build failure in 1:9.0.0-1
for i386 while amd64 succeeded.
The build failure seems related to #942864.

Next upload 1:9.0.0-2 succeeded for both architectures.

Kind regards,
Bernhard


https://buildd.debian.org/status/logs.php?pkg=llvm-toolchain-9&arch=i386
https://buildd.debian.org/status/logs.php?pkg=llvm-toolchain-9&arch=amd64
https://bugs.debian.org/942864

Bug#940931: Gimp bug

2019-10-14 Thread Bernhard Übelacker

Control: forcemerge 939754 940931

On Sun, 22 Sep 2019 10:19:59 +0530 Darshan Narayan  
wrote:> ```
> ...
> using GEGL version 0.4.12 (compiled against version 0.4.14)
> ...
> #7  0x561237ca0411 in gimp_gegl_mask_is_empty ()
> ...

Hello Darshan Narayan
this issue is tracked in Debian bug #939754 and
should disappear by installing latest updates
to libgegl-0.4-0 in version 0.4.14-2.

This was caused by gimp 2.10.8-2+b1 being built
against libgegl-0.4-0 in version 0.4.14-1,
but running with version 0.4.12-2 causes a crash.

Kind regards,
Bernhard

Bug#941275: GIMP crashed with a fatal error: fatal error: Segmentation fault

2019-10-14 Thread Bernhard Übelacker

Control: forcemerge 939754 941275

On Fri, 27 Sep 2019 19:28:25 +0530 Lalit Kumar  
wrote:
> ...
> using GEGL version 0.4.12 (compiled against version 0.4.14)
> ...
> #7  0x5634ba3aa411 in gimp_gegl_mask_is_empty ()
> ...

Hello Lalit Kumar,
this issue is tracked in Debian bug #939754 and
should disappear by installing latest updates
to libgegl-0.4-0 in version 0.4.14-2.

This was caused by gimp 2.10.8-2+b1 being built
against libgegl-0.4-0 in version 0.4.14-1,
but running with version 0.4.12-2 causes a crash.

You seem to run Kali Linux, so I cannot say if the
updates are already available there.
This issue was raised in their bug tracker too in [1].

Kind regards,
Bernhard

[1]
   https://bugs.kali.org/view.php?id=5695
   https://bugs.kali.org/view.php?id=5698
   https://bugs.kali.org/view.php?id=5710

Bug#940849: Upgrade the package to 1.9.3

2019-09-22 Thread Bernhard Übelacker

Dear Maintainer,
I guess this has to do with the package libgtkd-3-0.

Currently testing contains the version 3.8.5-1+b2.
That one got compiled with ldc 1:1.17.0-2.

The version 3.8.5-1 got compiled with ldc 1:1.12.0-1.
Installing that version from [1] makes tilix at least
run and open its window.
That might be another workaround, until tilix 1.9.3-1
transitions to testing.

This situation might be a side effect of the rebuilt +b2
of tilix 1.8.9-1 failing against ldc 1:1.17.0-2.
That was taken care of by uploading tilix 1.9.3-1,
that currently waits for gtk-d to transition and
the armhf build before it transitions to testing.

Kind regards,
Bernhard

[1] 
https://snapshot.debian.org/archive/debian/20190107T030854Z/pool/main/g/gtk-d/libgtkd-3-0_3.8.5-1_amd64.deb
[2] https://buildd.debian.org/status/logs.php?pkg=tilix&arch=amd64

Bug#940907: gimp: Gimp crashes on loading a .png image file.

2019-09-21 Thread Bernhard Übelacker

Control: forcemerge 939754 940907


Hello Stefan Pietzonke,
this issue is tracked in bug #939754 and should
disappear by installing latest updates
to libgegl-0.4-0 in version 0.4.14-2.

This was caused by gimp 2.10.8-2+b1 being built
against libgegl-0.4-0 in version 0.4.14-1,
but running with version 0.4.12-2 causes a crash.

Kind regards,
Bernhard

Bug#940808: gimp: File Open Image immediately crashes

2019-09-20 Thread Bernhard Übelacker

Control: forcemerge 939754 940808


Hello Jeff,
this issue is tracked in bug #939754 and should
disappear by installing latest updates
to libgegl-0.4-0 in version 0.4.14-2.

This was caused by gimp 2.10.8-2+b1 being built
against libgegl-0.4-0 in version 0.4.14-1, but
running with version 0.4.12-2 causes a crash.

Kind regards,
Bernhard

Bug#934897: rdesktop: 1.8.6 crashes after login in Windows XP, rdp_recv(), unexpected stream overrun, 1.8.4 works

2019-09-20 Thread Bernhard Übelacker

Dear Maintainer,
upstream issue [1] got closed with commit [2] in the master branch,
and should be contained in the upcoming release 1.9.0.

Unfortunately I guess the upstream 1.8.x branch will not
get an update for this, so either the patch in my previous
mail should work, or the change proposed in pull request [3].

Kind regards,
Bernhard

[1] https://github.com/rdesktop/rdesktop/issues/342
[2] 
https://github.com/rdesktop/rdesktop/commit/a646a5cce2ece3acc07ccead1e5f971cacc0db81
[3] https://github.com/rdesktop/rdesktop/pull/346/commits

Bug#939754: gimp: Crashes when I try to open an image or create a new one

2019-09-18 Thread Bernhard Übelacker

Control: forcemerge 939754 939768 939876 939977 939985 940008 940011 940042 
940044 940088 940174 940177 940285 940472 940525 940561 940610


Hello,
I hope it is ok to merge all such bugs.
All of them show gimp_gegl_mask_is_empty at an
instruction address ending in 411.

Now that gegl 0.4.14-2 transitioned to testing,
gimp 2.10.8-2+b1 should work as expected in testing.
(User confirmation in [1].)

If there is nothing that could be done in gimp to avoid
such situations (fxied version dependency to gegl?),
I guess this bugs can be closed?

Kind regards,
Bernhard

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

Bug#940309: tmux: Random segfaults

2019-09-16 Thread Bernhard Übelacker

Dear Maintainer,
just in case it may be of any help.

I guess the dmesg line points to function screen_write_collect_end
in screen-write.c:1240.

Kind regards,
Bernhard

# Bullseye/testing amd64 qemu VM 2019-09-16

apt update
apt dist-upgrade


# testing -> unstable


apt update
apt dist-upgrade

reboot


apt install systemd-coredump fakeroot gdb tmux tmux-dbgsym
apt build-dep tmux


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



tmux


gdb -q --pid $(pidof tmux)

set width 0
set pagination off
directory /home/benutzer/source/tmux/orig/tmux-2.9a

info target
...
0x55d3db9adc80 - 0x55d3dba0c921 is .text
...


# [173131.642703] Code: 48 c7 85 30 01 00 00 00 00 00 00 89 45 00 41 8b 47 1c 
48 c1 e0 04 48 03 47 18 bf 01 00 00 00 48 8b 50 08 48 89 95 38 01 00 00 <48> 89 
2a 48 8d 95 30 01 00 00 48 89 50 08 e8 79 55 02 00 8b 55 08
# 48 c7 85 30 01 00 00 00 00 00 00 89 45 00 41 8b 47 1c 48 c1 e0 04 48 03 47 18 
bf 01 00 00 00 48 8b 50 08 48 89 95 38 01 00 00 48 89 2a 48 8d 95 30 01 00 00 
48 89 50 08 e8 79 55 02 00 8b 55 08
# 0x48, 0xc7, 0x85, 0x30, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x89, 0x45, 
0x00, 0x41, 0x8b, 0x47, 0x1c, 0x48, 0xc1, 0xe0, 0x04, 0x48, 0x03, 0x47, 0x18, 
0xbf, 0x01, 0x00, 0x00, 0x00, 0x48, 0x8b, 0x50, 0x08, 0x48, 0x89, 0x95, 0x38, 
0x01, 0x00, 0x00, 0x48, 0x89, 0x2a, 0x48, 0x8d, 0x95, 0x30, 0x01, 0x00, 0x00, 
0x48, 0x89, 0x50, 0x08, 0xe8, 0x79, 0x55, 0x02, 0x00, 0x8b, 0x55, 0x08


(gdb) find /b 0x55d3db9adc80, 0x55d3dba0c921, 0x48, 0xc7, 0x85, 0x30, 
0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x89, 0x45, 0x00, 0x41, 0x8b, 0x47, 
0x1c, 0x48, 0xc1, 0xe0, 0x04, 0x48, 0x03, 0x47, 0x18, 0xbf, 0x01, 0x00, 0x00, 
0x00, 0x48, 0x8b, 0x50, 0x08, 0x48, 0x89, 0x95, 0x38, 0x01, 0x00, 0x00, 0x48, 
0x89, 0x2a, 0x48, 0x8d, 0x95, 0x30, 0x01, 0x00, 0x00, 0x48, 0x89, 0x50, 0x08, 
0xe8, 0x79, 0x55, 0x02, 0x00, 0x8b, 0x55, 0x08
0x55d3db9e417a 
1 pattern found.
(gdb) print/x 0x55d3db9e417a + 42
$1 = 0x55d3db9e41a4

(gdb) b *0x55d3db9e41a4
Breakpoint 1 at 0x55d3db9e41a4: file screen-write.c, line 1240.
(gdb) info break
Num Type   Disp Enb AddressWhat
1   breakpoint keep y   0x55d3db9e41a4 in screen_write_collect_end 
at screen-write.c:1240

(gdb) list screen-write.c:1240
1235if (ci->used == 0)
1236return;
1237ci->data[ci->used] = '\0';
1238
1239ci->x = s->cx;
1240TAILQ_INSERT_TAIL(&ctx->list[s->cy].items, ci, entry);
1241ctx->item = xcalloc(1, sizeof *ctx->item);
1242
1243log_debug("%s: %u %s (at %u,%u)", __func__, ci->used, ci->data, 
s->cx,
1244s->cy);

(gdb) print/x $rdx
$2 = 0x55d3dd642800

(gdb) print ctx->list[1]
$3 = {items = {tqh_first = 0x0, tqh_last = 0x55d3dd642800}}

(gdb) print ctx->s->cy
$4 = 1

Bug#940190: gegl: FTBFS on mips64el and mipsel while it did built before

2019-09-15 Thread Bernhard Übelacker

Hello,
I have created a new upstream issue:
https://gitlab.gnome.org/GNOME/gegl/issues/206

Kind regards,
Bernhard

Bug#940190: gegl: FTBFS on mips64el and mipsel while it did built before

2019-09-13 Thread Bernhard Übelacker

Dear Maintainer,
I guess this issue caused also gegl not transitioning to testing and
therefore another issue within the package gimp e.g. bug #939768
and a few more.

I tried to reproduce it in a qemu VM for mips64el
and hit the same issue.

Running just the mentioned test it returns a timeout message.
Therefore I guess that this test has just a too short timeout.
Increasing it from 3 to 40 seconds make it succeed also in my
(very slow) VM.

Kind regards,
Bernhard


benutzer@debian:~/source/gegl/try1/gegl-0.4.12/tests/simple$ export 
GEGL_PATH=/home/benutzer/source/gegl/try1/gegl-0.4.12/operations
benutzer@debian:~/source/gegl/try1/gegl-0.4.12/tests/simple$ export 
GEGL_SWAP=RAM
benutzer@debian:~/source/gegl/try1/gegl-0.4.12/tests/simple$ 
./test-node-exponential
timeout expired. failing.


benutzer@debian:~/source/gegl$ diff -Nurp 
orig/gegl-0.4.12/tests/simple/test-node-exponential.c 
try1/gegl-0.4.12/tests/simple/test-node-exponential.c
--- orig/gegl-0.4.12/tests/simple/test-node-exponential.c   2018-07-12 
00:15:19.0 +0200
+++ try1/gegl-0.4.12/tests/simple/test-node-exponential.c   2019-09-14 
05:58:25.992956588 +0200
@@ -37,7 +37,7 @@
 #define SUCCESS  0
 #define FAILURE -1
 
-#define TIMEOUT (3 * G_TIME_SPAN_SECOND)
+#define TIMEOUT (40 * G_TIME_SPAN_SECOND)
 
 static GMutexmutex;
 static GCond cond;


benutzer@debian:~/source/gegl/try1/gegl-0.4.12/tests/simple$ time 
./test-node-exponential
real0m31.117s
user0m29.467s
sys 0m0.548s

Bug#939559: x86_64-w64-mingw32-g++-win32: program compiled with -march=native crashes on same CPU

Hello Stephen, hello Claude,
following that previous idea of just replacing the aligned
instruction with the unaligned one the hacky patch below got
created, just replacing vmovapd by vmovupd.
Not considering any side effects and maybe other
instructions with alignment requirements.
At least a mingw-w64 built with it builds an executable that
would not crash in that situation.
(Currentyl just meant as a proof of concept.)
Maybe at least better than disabling AVX2 entirely?

Kind regards,
Bernhard
--- a/src/gcc/config/i386/i386.md	2019-09-07 15:04:12.391156632 +0200
+++ b/src/gcc/config/i386/i386.md	2019-09-07 15:07:17.316822891 +0200
@@ -3521,9 +3521,9 @@
 	case MODE_V4SF:
 	  return "%vmovaps\t{%1, %0|%0, %1}";
 	case MODE_V8DF:
-	  return "vmovapd\t{%g1, %g0|%g0, %g1}";
+	  return "vmovupd\t{%g1, %g0|%g0, %g1}";
 	case MODE_V2DF:
-	  return "%vmovapd\t{%1, %0|%0, %1}";
+	  return "%vmovupd\t{%1, %0|%0, %1}";
 
 	case MODE_V2SF:
 	  gcc_assert (!TARGET_AVX);
--- a/src/gcc/config/i386/sse.md	2019-09-07 15:04:12.399156531 +0200
+++ b/src/gcc/config/i386/sse.md	2019-09-07 15:07:09.420922575 +0200
@@ -1004,7 +1004,7 @@
 		return "vmovaps\t{%g1, %g0|%g0, %g1}";
 	  case MODE_V4DF:
 	  case MODE_V2DF:
-		return "vmovapd\t{%g1, %g0|%g0, %g1}";
+		return "vmovupd\t{%g1, %g0|%g0, %g1}";
 	  case MODE_OI:
 	  case MODE_TI:
 		return "vmovdqa64\t{%g1, %g0|%g0, %g1}";
@@ -1031,7 +1031,7 @@
 	  || misaligned_operand (operands[1], mode))
 	return "%vmovupd\t{%1, %0|%0, %1}";
 	  else
-	return "%vmovapd\t{%1, %0|%0, %1}";
+	return "%vmovupd\t{%1, %0|%0, %1}";
 
 	case MODE_OI:
 	case MODE_TI:
@@ -18952,11 +18952,11 @@
 	case MODE_V16SF:
 	  return "vmovaps\t{%1, %t0|%t0, %1}";
 	case MODE_V8DF:
-	  return "vmovapd\t{%1, %t0|%t0, %1}";
+	  return "vmovupd\t{%1, %t0|%t0, %1}";
 	case MODE_V8SF:
 	  return "vmovaps\t{%1, %x0|%x0, %1}";
 	case MODE_V4DF:
-	  return "vmovapd\t{%1, %x0|%x0, %1}";
+	  return "vmovupd\t{%1, %x0|%x0, %1}";
 	case MODE_XI:
 	  if (which_alternative == 2)
 	return "vmovdqa\t{%1, %t0|%t0, %1}";

Bug#939559: x86_64-w64-mingw32-g++-win32: program compiled with -march=native crashes on same CPU

Hello Stephen, hello Claude,
following discussion seems also related and raises the question
if the variable cannot be aligned, could then mingw-w64 just emit
the unaligned instructions, even if slower than the aligned ones,
which are faster but also crash.

https://sourceforge.net/p/mingw-w64/discussion/723797/thread/bc936130/

Kind regards,
Bernhard

Bug#935698: amule-utils-gui: amulegui crashing with current libwxgtk3.0-0v5 3.0.4+dfsg-9 and friends

Hello Martintxo,
your last attachement confirms we get into a recursion in 
mwxWindow::DoClientToScreen in the suspected line [L3158].

Further it looks like this==m_parent at this state, so
this window is its own parent ?

I guess entering the recursion in that case is clearly wrong,
therefore following hack to line 3156 could help:
(Have not tested it, maybe to line 3230 too.)

-if ((!m_useCachedClientSize || source == NULL) && !IsTopLevel() && 
m_parent)
+if ((!m_useCachedClientSize || source == NULL) && !IsTopLevel() && 
m_parent && m_parent != this)

But I guess a proper solution needs someone with deeper
knowledge of wxWidgets.

Kind regards,
Bernahrd


[L3158] 
https://sources.debian.org/src/wxwidgets3.0/3.0.4+dfsg-9/src/gtk/window.cpp/#L3158

Bug#939559: x86_64-w64-mingw32-g++-win32: program compiled with -march=native crashes on same CPU

Control: tags -1 + upstream


Hello Claude Heiland-Allen,
I tried just to collect some more information for the maintainer.

The issue could be reproduced in a qemu VM
with '-cpu host' on a Ryzen 7 1700.

The resulting binary crashes on Windows at the same instruction,
so I guess Wine can be ruled out.

It seems that the vmovapd instruction expects a 32-byte aligned 
value in register $rcx. Unfortunately it is just 16-byte aligned
and therefore the SIGSEGV.
This could be confirmed by setting a breakpoint to that instruction
and set $rcx to the next aligned value below, then the vmovapd
could be executed.

I think following upstream reports and messages are releated,
mostly 54412. There are also some workarounds mentioned.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49001
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61730
https://sourceforge.net/p/mingw-w64/mailman/message/36287627/

Kind regards,
Bernhard



$ wine winedbg --gdb a.exe 4
...
Wine-gdb> cont
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x0040166d in ?? ()
Wine-gdb> bt
#0  0x0040166d in ?? ()
#1  0x004031a8 in ?? ()
#2  0x in ?? ()
Wine-gdb> print/x $rcx
$1 = 0x33fa10
Wine-gdb> print/x $rcx % 32
$2 = 0x10
Wine-gdb> print/x $rcx % 16
$3 = 0x0



$ x86_64-w64-mingw32-objdump --disassemble a.exe
...
00401665 <_Z9broadcastIDv4_ddET_T0_>:
  401665:   c4 e2 7d 19 c9  vbroadcastsd %xmm1,%ymm1
  40166a:   48 89 c8mov%rcx,%rax
  40166d:   c5 fd 29 09 vmovapd %ymm1,(%rcx)
  401671:   c5 f8 77vzeroupper 
  401674:   c3  retq   
...
00402e90 :
...
  40319b:   48 8d 8c 24 e0 00 00lea0xe0(%rsp),%rcx
  4031a2:   00 
  4031a3:   e8 bd e4 ff ff  callq  401665 
<_Z9broadcastIDv4_ddET_T0_>
  4031a8:   c5 fd 28 94 24 e0 00vmovapd 0xe0(%rsp),%ymm2
...



That function _Z9broadcastIDv4_ddET_T0_ should unmangled look like:
double __vector(4) broadcast(double)
That should be line 53:
51 template <>
52 __attribute__ ((noinline))
53 double4  broadcast(double x) { double4 r = { x, x, x, x 
}; return r; }

Bug#933202: xfdesktop4: SEGV in g_slice_alloc

2019-09-06 Thread Bernhard Übelacker

Hello sixerjman,
the maybe same bug #934105 got closed and mentions the issue
is no longer visible in 4.14, I guess you upgraded too and
I want to ask if you still can observe that crash.

If not you could also close this bug by sending your answer
to 933202-d...@bugs.debian.org

Kind regards,
Bernhard

Bug#936064: gimp: Gimp crash using filling tool

2019-09-06 Thread Bernhard Übelacker

Hello Stephane,
sorry for the delay, you might use for Debian bugs reply all, to
get the information recorded in the bug and notify the real person.

As not being involved in packaging gimp I really just tried to get
some more information from the backtrace, which led to the
bug reports in gimp's own bug tracker.

I have just forwarded that this may be related to ClipIt in some way
from these these upstream reports.

If possible you could try to disable ClipIt temporarily and see if
the crashes continue to happen?

Kind regards,
Bernhard

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

2019-09-01 Thread Bernhard Übelacker

Dear Maintainer,
I guess the actual segmentation fault is fixed since kamoso 3.2.4-1.
Instead it should print this message:

The webcam controller was unable to find or load wrappercamerabinsrc plugin;
please make sure all required gstreamer plugins are installed.

The last question would be, is this sufficient to close the bug,
or does kamoso need a dependency or recommends to
gstreamer1.0-plugins-bad?

Kind regards,
Bernhard

Bug#935885: fuse installtion postinst script syntax error

Dear Maintainer,
migth this be related to this bug:
https://bugs.debian.org/935496

Kind regards,
Bernhard

Bug#935984: freerdp-x11: crashes with illegal instruction, winpr libraries contain SSE2 instructions on i386

Hello Ondrej Zary,
while looking through bug reports for some random
packages I got to your report.
I guess your system got updated at least from Stretch to Buster,
therefore you might have freerdp-x11 installed while that
is not part of the official Buster release.
It got also removed from Sid, therefore this report
would just be a concern for Stretch.

If I see it right, it got replaced by freerdp2-x11.
As far as I see that contains (from your short objdump test)
no SSE2 instructions. Maybe that works for your purpose.

Attached patch shows an incomplete attempt to build without
sse2, but unfortunately that fails, would need some more work.

Kind regards,
Bernhard


benutzer@debian:~$ objdump -d /usr/lib/i386-linux-gnu/libwinpr2.so.2.0.0 | grep 
xmm
benutzer@debian:~$ objdump -d /usr/bin/xfreerdp | grep xmm
benutzer@debian:~$
Description: Disable SSE2 and SSE3
Bug-Debian: https://bugs.debian.org/935984
Last-Update: 2019-08-31

--- freerdp-1.1.0~git20140921.1.440916e+dfsg1.orig/CMakeLists.txt
+++ freerdp-1.1.0~git20140921.1.440916e+dfsg1/CMakeLists.txt
@@ -153,7 +153,7 @@ if(CMAKE_COMPILER_IS_GNUCC)
 		set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -g")
 	endif()
 	if(WITH_SSE2)
-		set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -msse2")
+		set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ")
 	endif()
 endif()
 
--- freerdp-1.1.0~git20140921.1.440916e+dfsg1.orig/libfreerdp/codec/CMakeLists.txt
+++ freerdp-1.1.0~git20140921.1.440916e+dfsg1/libfreerdp/codec/CMakeLists.txt
@@ -62,7 +62,7 @@ if(WITH_SSE2)
 	set(${MODULE_PREFIX}_SRCS ${${MODULE_PREFIX}_SRCS} ${${MODULE_PREFIX}_SSE2_SRCS})
 
 	if(CMAKE_COMPILER_IS_GNUCC)
-		set_source_files_properties(${${MODULE_PREFIX}_SSE2_SRCS} PROPERTIES COMPILE_FLAGS "-msse2")
+		set_source_files_properties(${${MODULE_PREFIX}_SSE2_SRCS} PROPERTIES COMPILE_FLAGS "")
 	endif()
 
 	if(MSVC)
--- freerdp-1.1.0~git20140921.1.440916e+dfsg1.orig/libfreerdp/primitives/CMakeLists.txt
+++ freerdp-1.1.0~git20140921.1.440916e+dfsg1/libfreerdp/primitives/CMakeLists.txt
@@ -50,7 +50,7 @@ endif()
 
 if(WITH_SSE2)
 	if(CMAKE_COMPILER_IS_GNUCC)
-		set(OPTIMIZATION "${OPTIMIZATION} -msse2 -mssse3 -Wdeclaration-after-statement")
+		set(OPTIMIZATION "${OPTIMIZATION} -Wdeclaration-after-statement")
 	endif()
 
 	if(MSVC)
--- freerdp-1.1.0~git20140921.1.440916e+dfsg1.orig/libfreerdp/primitives/test/CMakeLists.txt
+++ freerdp-1.1.0~git20140921.1.440916e+dfsg1/libfreerdp/primitives/test/CMakeLists.txt
@@ -84,7 +84,7 @@ endif()
 
 if(WITH_SSE2)
 	if(CMAKE_COMPILER_IS_GNUCC)
-		set(OPTFLAGS "${OPTFLAGS} -msse2 -mssse3 -O2 -Wdeclaration-after-statement")
+		set(OPTFLAGS "${OPTFLAGS} -O2 -Wdeclaration-after-statement")
 	endif()
 
 	if(MSVC)

Bug#932550: qemu-system-x86: WinXP no longer boots with --enable-kvm, stops at \Windows\System32\Drivers\Mup.sys

fixed 932550 4.19.67-1

Bug#936064: gimp: Gimp crash using filling tool

Dear Maintainer,
this backtrace is identical to that one reported in #935604.
Also the expected message appears in this report:
...
"[xcb] Unknown sequence number while processing queue"


This time I found also this upstream bugs that may be related:
https://gitlab.gnome.org/GNOME/gimp/issues/3076
https://gitlab.gnome.org/GNOME/gimp/issues/1475

@Stephane: By any chance, had you ClipIt running at the
   time of the crash?

Kind regards,
Bernhard

Bug#936098: Buster test, error with fuse installing qemu-kvm

Hello,
this sounds related to these bugs:
https://bugs.debian.org/935496
https://bugs.debian.org/935972
https://bugs.debian.org/935916

Kind regards,
Bernhard

Bug#939029: pcmanfm: SIGSEGV, Segmentation fault on opening folder

Control: submitter 939029 Nicola 
Control: fixed 939029 librsvg/2.44.14-1
Control: tags 939029 + upstream fixed-upstream


Hello,
this clone is just to handle the issue described in
messages #18, #36, #48, #73.
Last contains upstream bug and patch.

This should be fixed in testing already and just affects
Buster (or maybe older).

Kind regards,
Bernhard


https://sources.debian.org/src/librsvg/2.44.10-2.1/gdk-pixbuf-loader/io-svg.c/#L134
https://sources.debian.org/src/librsvg/2.44.14-1/gdk-pixbuf-loader/io-svg.c/#L134

Bug#914150: pcmanfm: SIGSEGV, Segmentation fault on opening folder

reassign 914150 libfm/1.3.0-1

Bug#935980: jackd2: Segfaults when qjackctl patchbay is activated