ary got
overwritten.
Unfortunately a core did alreay run over the interesting instruction
changing that stack canary, will therefore not of so much use.
Maybe just if the stack would be overwritten with some recognizable
values ...
Kind regards,
Bernhard
nction removed,
current testing 4:19.08.1-1 might be have this bug fixed.
One upstream mentions that Nautilus was working find,
this might be a workaround, as I guess MTP with KDE
will stay kind of fragile in Buster.
Kind regards,
Bernhard
Without debug symbols:
[KCrash Handler]
#6 0x7f9b37
The prompt then shown should belong to the bash being debugged,
have tried to trigger the crash in that prompt again?
Kind regards,
Bernhard
'centreon-engine-dbgsym' would be installed [1].
Kind regards,
Bernhard
[1]
https://sources.debian.org/src/centreon-engine/18.10.0-4/src/retention/dump.cc/#L127
[2] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols
dmesg submitter:
[ 5321.507438] centengine[26832]: segfault
yes, maybe you could give some more
information of both graphic devices and how the switching
between them is configured? (I don't have such a device accessible.)
Kind regards,
Bernhard
Sorry, forgot to attach details.
# Bullseye/testing amd64 qemu VM 2020-01-08
apt update
apt dist-upgrade
apt install systemd-coredump xserver-xorg sddm openbox xterm net-tools mc
fakeroot gdb navit navit-dbgsym libgps25-dbgsym
apt build-dep navit
reboot
mkdir
-1?
When repeating the test with libgps25 3.19-3 [8] installed,
the struct sizes match and no differenences in
gdb's ptype output exist.
Kind regards,
Bernhard
[1]
Breakpoint 1, gps_open (host=host@entry=0x556bc137 "localhost", port=0x0,
gpsdata=0x556d4a50) at libgps_co
'info reg'
and 'thread apply all bt full' could give some more insight.
Kind regards,
Bernhard
Submitter: |
Reconstructed:
[0x7f05c7726e27] libgimpbase-2.0.so.0(gimp_stack_trace_print+0x397) |
0x7fc6d8ca8e27 in gimp_stack_trace_print ()
nal (SIGUSR2, ReopenLogFileNotify);
Kind regards,
Bernhard
[1]
https://unix.stackexchange.com/questions/38589/why-does-sigusr1-cause-process-to-be-terminated
# Bullseye/testing amd64 qemu VM 2020-01-08
apt update
apt dist-upgrade
apt install systemd-coredump mc fakeroot xserver-xorg xdm openbox xt
, if watchpoint 5 is reached, and we assume
that __pthread_tunables_init is just called once...
Kind regards,
Bernhard
cat < /tmp/gdb-cmd.txt
set width 0
set pagination off
display/i \$pc
set breakpoint pending on
b __pthread_tunables_init
run
dele 1
b * (__pthread_tunables_init+30)
cont
del
debian.org/HowToGetABacktrace#Installing_the_debugging_symbols
Kind regards,
Bernhard
if the resulting device is working
properly afterwards.
Kind regards,
Bernhard
# Unstable amd64 qemu VM 2020-01-06
apt-mark hold kmod libkmod2 #Bug 948257
apt update
apt dist-upgrade
fdisk /dev/sdb
mkfs.ext4 /dev/sdX1
mkdir /home/benutzer/source
mount /dev/sdb1 /home/benutzer/source
chown
/libslirp
https://gitlab.freedesktop.org/slirp/libslirp/blob/master/src/ip.h#L214
Kind regards,
Bernhard
was seeing in dmesg?)
I hope the build finishes and I can report back then.
Kind regards,
Bernhard
while
containing a null pointer.
This could be reproduced in a minimal VM running
stable with 4.19.0-6-amd64 or unstable with 5.4.0-1-amd64.
Kind regards,
Bernhard
[Sa Jan 4 17:08:33 2020] alg: No test for authenc(hmac(sha256),xts(twofish))
(authenc(hmac(sha256-generic),xts(ecb-twofish-3way)))
[Sa
Short addition:
upstream changed that line urlbar.vala:109 in commit [1].
A locally built package including that patch
did not crash for me.
Kind regards,
Bernhard
[1]
https://github.com/midori-browser/core/commit/525f76c68fdde8a2d974c6975d9cc5ebe0cd594b
Dear Maintainer,
I tried to reproduce it also on amd64 and found it
crashing at the following location.
My knowledge of vala is limited, but is here the member
"suggestion_row.item.database" not yet set, but already accessed?
Kind regards,
Bernhard
Thread 1 received sign
Hello David,
I guess the package "thunar-dbgsym gdb" are installed
on your system, but could you please recheck if
packages "libglib2.0-0-dbgsym libgtk-3-0-dbgsym"
are really installed, too?
Kind regards,
Bernhard
with a dbgsym package available. However, your nice backtraces
made the Maintainer already solve the issue, I guess.
Kind regards,
Bernhard
by debhelper while packaging, I guess
simplifying 80_handle_nostrip_option.patch to following would do:
-STRIP = @STRIP@
+STRIP=/bin/true
Kind regards,
Bernhard
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500
you should receive a
backtrace at the end of this command:
journalctl --no-pager
[1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols
Kind regards,
Bernhard
://gitlab.gnome.org/GNOME/gimp/commit/2f2067a5aacae176f5aaf828e15bd4463879062a
Kind regards,
Bernhard
that it has to be NULL [1].
Building a gimp package with attached patch makes the import
not crash any longer.
Upstream seems to track this issue in [2].
Kind regards,
Bernhard
[1] https://www.ghostscript.com/doc/current/API.htm#new_instance
[2] https://gitlab.gnome.org/GNOME/gimp/issues/3636
on your system then
some more information could help.
- Which game have you played inside kpat?
- Some example lines of the messages in .xsession_errors
Kind regards,
Bernhard
reported against gtkmm seems to match:
https://gitlab.gnome.org/GNOME/gtkmm/issues/54
Complete backtraces with debug symbols in attached
file of eog and xserver.
Could remember I saw such a rejection from the xserver
already in (not strictly related): https://bugs.debian.org/858045
Kind r
Dear Maintainer,
the given backtrace should look like below with debug symbols installed.
For some reason it looks like the strchr at line 281 returns a null pointer.
Kind regards,
Bernhard
(gdb) bt no-filter
#0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
#1
.
So I assume for some reason this register $rdi and
parameter "v" / "key" / "name" contain a null pointer
leading to the crash seen by definetti.
Kind regards,
Bernhard
(gdb) bt
#0 0x77df6e20 in g_str_hash (v=0x7fffdc38d780) at
../../../glib/ghash.c:2324
#1 0x000
ever, I am unfamiliar with that package, therefore cannot
estimate other consequences of that change.
Kind regards,
Bernhard
(gdb) bt
#0 0xe0e16e30 in generator_new_ (fn=fn@entry=0xe0e18ed8
, retsize=48, retsize@entry=40) at
generator/generator.c:36
#1 0xe0e194c0 in traj
Control: tags -1 + fixed-upstream patch
Dear Maintainer,
upstream fixed this issue in git by following commit:
https://ezix.org/src/pkg/lshw/commit/89b3b6b9ed03f22ca98954712db5a90acf2c6755
Kind regards,
Bernhard
On Tue, Dec 17, 2019 at 10:44:42PM +0100, Bernhard Schmidt wrote:
> Pinging this bug to delay testing removal, the fix is in unstable but
> migration is currently blocked by several RC bugs in libxcrypt.
And again. Hopefully this will be solved soon.
Bernhard
Control: tags -1 + upstream
Control: forwarded -1 https://www.ezix.org/project/ticket/755
Dear Maintainer,
I tried to forward this issue upstream, where it is tracked
in this bug report: https://www.ezix.org/project/ticket/755
Hope it is ok to set this bug to forwarded.
Kind regards,
Bernhard
regards
Bernhard
U-Boot SPL 2020.01-rc5+dfsg-1 (Dec 18 2019 - 01:23:23 +)
DRAM: 2048 MiB
Trying to boot from MMC1
U-Boot SPL 2020.01-rc5+dfsg-1 (Dec 18 2019 - 01:23:23 +)
DRAM: 2048 MiB
Trying to boot from MMC1
U-Boot SPL 2020.01-rc5+dfsg-1 (Dec 18 2019 - 01:23:23 +)
DRAM: 2048
that regard,
and there are less things apt has to care about the way it is typically
used).
Accepting absurd input without confirmation is never a secure way to handle
things, though.
Bernhard R. Link
ta would
open all kind of security issues and require quite some hard to properly
test code. Most of the attacks enabled by having longer control chunks
might be able to mitigated some way, but that would require all kind of
different logic that can then have some new bugs.
So allowing arbitrary absurdly long control data is not something I want
to support.
Bernhard R. Link
(n=...) at scsi.cc:762
#7 0x555c9e75 in scan_scsi (n=...) at scsi.cc:909
#8 0x5558bffd in scan_system (system=...) at main.cc:134
#9 0x5557a50c in main (argc=, argv=) at
lshw.cc:247
Kind regards,
Bernhard
P.S.:
You compiled upstream package lshw-B.02.18.tar.gz
Pinging this bug to delay testing removal, the fix is in unstable but
migration is currently blocked by several RC bugs in libxcrypt.
links seem to describe a similar issue [1]
with newer versions of the application.
Kind regards,
Bernhard
[1]
http://blog.nashcom.de/nashcomblog.nsf/dx/notes-910-standard-client-issues-in-combination-wth-libreoffice-6-installed-fonts-noto.htm?opendocument
https://atnotes.de/index.php?topic=62177.20
ddr_list)
And maybe a 'bt full' should contain a part of the UDP response.
Kind regards,
Bernhard
(gdb) disassemble /m dns_simple_callback
Dump of assembler code for function dns_simple_callback:
111 {
0x55569ab0 <+0>: push %r13
0x55569ab2 <+2>: push
ore.
Both combined should create a wine-prefix populated by
the self-built wine, I guess.
Oh and what I forgot in my last email - to properly separate things,
you could create a different system user.
Grüße in den Nachbarlandkreis :-)
Bernhard
Hello Wolfgang,
Am 16.12.19 um 11:42 schrieb Wolfgang Rosner:
> Hi Bernhard,
>
> Thanks for the debug instructions.
>
> I'll go to try them, maybe the next weekend.
>
> Notes is an essential tool of my daily work, so extended trials block
> me from productive offfice wo
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
e 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
you
could describe in detail the steps leading to the crash.
Kind regards,
Bernhard
_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
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 undo
ASSIVE;
1705
1706sr->start_time_tsf = start_time_tsf;
<<<<<<<<<<<<
1707
1708break;
1709
1710case NL80211_CMD_SCAN_ABORTED:
Upstream git [1] has a fix committed.
Kind reg
(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
' 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
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
.
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
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 recei
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
Subj
-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
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
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
e' -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
.
Kind regards,
Bernhard
[1]
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
[2]
https://sources.debian.org/src/kcoreaddons/5.54.0-1/src
].
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
of the crash.
Kind regards,
Bernhard
information of the crash.
Kind regards,
Bernhard
-A5
Kind regards,
Bernhard
From submitter |
Reconstructed
#0 0x7fe16d9b6bde | 0x7f1811853bde
#1 0x7fe16d9b6cf0 | 0x7f1811853cf0
#2 0x7f
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
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
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
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
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
e 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
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
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_vec
Control: tags -1 upstream
Hi,
Is there any chance that this bug will get fixed?
Please file that bug upstream, nothing we as Debian maintainers can fix.
Unless of course there is already a patch we just have to import.
https://community.openvpn.net/openvpn/report
Bernhard
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 submit
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
... 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
tup 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
Reconstruc
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
Dear Maintainer,
I reported the issue upstream:
https://github.com/rzvncj/xCHM/issues/9
Kind regards,
Bernhard
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
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
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
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
, 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
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
&
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
behave the same
in Wine and Windows.
Kind regards,
Bernhard
[1]
https://stackoverflow.com/questions/55728544/how-to-avoid-msvcrt-dll-compiling-with-mingw64
ble.
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
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
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
ot;,
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
s 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
/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
ld because of an issue
with libgegl-dev.
Kind regards,
Bernhard
described in [2]
Kind regards,
Bernhard
[1]
https://git.linuxtv.org/edid-decode.git/commit/?id=0da30bd8cbe8c023236f22ad2a8477a1f0b96679
[2] https://wiki.debian.org/HowToGetABacktrace
in [1] that
information should be even better.
Kind regards,
Bernhard
[1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols
.
Kind regards,
Bernhard
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
ing too:
print ld
print ld->ldc
print *ld
print *(ld->ldc)
Kind regards,
Bernhard
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
rary 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
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 ./
On Thu, Aug 16, 2018 at 12:41:39AM +0200, Bernhard Schmidt wrote:
Hi,
> I also see this issue on several stretch VMs. In network segments where
> Router Advertisements are present but the machines have a gateway set
> the systems are occasionally not reachable after a reboot (<1% of
901 - 1000 of 4098 matches
Mail list logo
