Weitergeleitete Nachricht
Datum: Wed, 7 Aug 2019 15:44:44 -0400
Von:Leoš Pohl
Hello Bernhard,
since I could not find a way to forward the report directly
to this bug, please find screenshots here
https://snag.gy/mpTyWe.jpg and here https://snag.gy/lUKpRc.jpg
and the cop
Hello Leoš Pohl,
thanks for the additional information.
Please use the reply-all in your email program, to have
the ...@bugs.debian.org recipient in every answer, so
the debian bug tracker receives the messages too.
Just for future crashes (or if the Mainainter will requests it),
if you install t
Control: tags -1 - moreinfo
Dear Maintainer,
I think the top frames with debug symbols would look like this:
(gdb) bt
#0 memcpy () in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x7feaa926d05d in Baloo::PostingCodec::decode () at
./src/codecs/postingcodec.cpp:42
#2 0x0
Hello Damon Anton Permezel,
this USB disk, has it a gpt or msdos partition table?
Also, maybe if it is possible, you could install
the package systemd-coredump.
Then some more information about a crash would be
collected in the journal, and a the process state would
be saved into /var/lib/systemd/
Dear Maintainer,
this bug looks similar to following bug:
https://bugs.debian.org/934105
Kind regards,
Bernhard
Hello Jun Jiang,
thanks for the additional information.
> As for for question at the end about changing display resolution, I don't
> follow you. Pardon me if I am misunderstanding, are you asking whether I
> changed screen resolution when it happened? If that's what you mean, then
> no, I haven't
Weitergeleitete Nachricht
Datum: Thu, 8 Aug 2019 08:45:58 -0400
Von:sixerjman
Indeed it does. I will see if I can get more information after
installing debug syms
as instructed in #934105.
Dear Maintainer,
it seems this issue got reported now
also against package src:linux in:
https://bugs.debian.org/934304
Kind regards,
Bernhard
Control: found -1 linux/5.2.6-1
Dear Maintainer,
the bugreport https://bugs.debian.org/934292
seems about the same issue.
The issue can be reproduced by just accessing the file below.
root@debian:~# strace -f powertop
execve("/usr/sbin/powertop", ["powertop"], 0x7fff5df92d08 /* 11 vars */) = 0
Hello Ray Klassen,
without deeper knowledge of libreswan I tried to reproduce
this issue, but it did not show up for me.
It might be possible to install the package systemd-coredump.
Then in the journal should a backtrace be printed when you
repeat the checkconfig, which you could forward to this
Hello Jose Ortiz,
without deeper knowledge of unknown-horizons I tried to reproduce
this issue, but it did not show up for me.
It might be possible to install the package systemd-coredump.
Then in the journal should a backtrace be printed when you
repeat the checkconfig, which you could forward t
Dear Maintainer,
this issue seems to start since patch:
features/all/lockdown/0031-tracefs-Restrict-tracefs-when-the-kernel-is-locked-d.patch
Therefore a vanialla build does not show this issue.
With either of the following changes on top of all
debian patches, the exception does not happen.
Hello Seth Foley,
sorry for the delay.
I guess that "Core file was truncated to 2147483648 bytes." means that
the current configuration probihited to save the whole process.
So first you could try to start handbrake the following way:
ulimit -c 0
handbrake
(That might raise that limit and
Package: cdrom
Severity: wishlist
Tags: d-i
Hello,
when I tried to find something about #932149,
which got closed because the submitter received spam,
I found something that may still of interest.
When RAM is limited it might happen, that not the whole
initrd fits into RAM. But the kernel gets l
Control: reassign -1 libcurl4 7.65.1-1
Control: affects -1 + rtorrent
Control: tags -1 + upstream fixed-upstream
Control: fixed -1 7.65.3-1
Dear Maintainer,
I just tried to find some more information from the given backtrace.
That I guess would translate to something like below [1],
if it would
Hello Seth Foley,
if possible you could now install gdb
and the following debug symbol packages.
The latter are stored in a separate
repository, more details in [1]:
handbrake-dbgsym libavformat58-dbgsym
Then if you have not rebooted since the last
handbrake crash, you can use following comma
Dear Maintainer,
the bugs 912921/913133 these two bugs should be merged with are already
archived. Is it ok to just close them by 91-cl...@bugs.debian.org ?
Kind regards,
Bernhard
Hello Johannes, dear Maintainer,
tried to reproduce the hang here but just got
a NV4B and NV108, while your NVA5 is somewhere between,
and with both I did not get such a freeze ...
I fear I cannot help on this issue any deeper.
Maybe some Qt or Nouveau developer need to have a look.
Kind regards,
Hello,
might this just another cases of similar bugs 908924/908382/911392?
Is this still an issue with current version 4.19.12-1 ?
Kind regards,
Bernhard
signature.asc
Description: OpenPGP digital signature
Hello Michael Hatzold,
I tried to have a look and guess gimp received from some
plugin feedback in form of a malformed GIMP_PDB_INT16ARRAY.
Unfortunately this may not be enough information
for the maintainer to fix it.
Could you please provide more details on which exact
steps you took to trigger
Control: fixed 911392 linux/4.19.12-1
Dear Maintainer,
did an update on that testsystem and the error
does not show up with at least 4.19.12-1.
Kind regards,
Bernhard
Hello Joe Ma,
just to be sure, you did execute the proposed gdb command
while kate was frozen?
Kind regards,
Bernhard
Hello Markus Blatt, dear Maintainer,
I just tried to reproduce the crash inside a minimal test VM,
with a new empty file, by these steps:
- Datei
- Neue Datei
- Weiter - Weiter - Weiter - Weiter - Weiter - Anwenden
- test.xml - Speichern
- Berichte - Steuer-Bericht & Elster Export
- Optionen
- Rad
Control: fixed 918950 1:2.12+dfsg-3
Control: tags 918950 + upstream
Hello Jakub Wilk, dear Maintainer,
just tried to find out when this started and found it
working with 2.12.
Then tried to build it from git and a bisect leads to
following commit:
eeae6a596b0efc092f5101c67683053e245e6250 is
Package: src:linux
Version: 4.19.12-1
Severity: normal
Dear Maintainer,
I received following crash while having a cifs filesystem mounted
from a qemu VM running on the same host.
Unfortunately forgot to unmount and shut down the VM.
Then after some minutes system froze and restarted.
If it may b
Package: crash
Version: 7.2.3+real-2
Severity: normal
Tags: upstream
Dear Maintainer,
I experienced a crash with kdump-tools installed and wanted to
report that crash (#919290).
I tried to have a look at the collected core and found that crash
gives an error message and exits (see below).
This s
Hello Tom Brown, dear Maintainer,
I just tried to reproduce this on a amd64 qemu EFI VM.
>From your description is not clear if you received on reboot
the menu to select between "Windows 10" or
"Debian GNU/Linux - Continue with install process"?
If that is missing you might add the output of follo
Hello Fernando Toledo, Dear Maintainer,
On Wed, 16 Jan 2019 01:22:31 -0300 Fernando Toledo
wrote:
> > I need help to know how to get more info/debug.
Maybe you can install a core file collector.
On stable or testing I would propose systemd-coredump,
but that is not available in jessie.
The pa
Control: tags 919030 + upstream
Dear Maintainer, hello John Scott,
I had a look and think I have found the issue.
Each open document has a object of type
KileDocument::TextInfo::TextInfo.
That contains a QMap "m_dictStructLevel".
This map is given by reference to the parser thread
in an object
Control: affects 919607 + krita
Dear Maintainer, hello Mateus Barbosa,
there is another debian bug report that looks similar [1].
As far as I see this is a Qt upstream bug, but not yet resolved.
Krita upstream has two commits [2] to workaround that issue
until a fixed Qt version gets available.
Hello Lisandro,
> Do we have an upstream bug number?
Mateus Barbosa mentioned this one already when opening the bug:
https://bugreports.qt.io/browse/QTBUG-72488
Kind regards,
Bernhard
signature.asc
Description: OpenPGP digital signature
Dear Maintainer,
I tried to find out where this stack in message #25
would point to, if it may help.
The failing call to free, I guess, would be in
function rotateLogSet in logrotate.c, line 1749.
1748for (i = 0; i < log->numFiles; i++) {
1749free(rotNames[i]->firstRotated);
Hello Steve,
I suspect this lookup error is because you have
knewstuff packages in version 5.54.0-1 installed,
which is not yet in testing (and barely in unstable).
Could reproduce it with packages below installed:
http://ftp.de.debian.org/debian/pool/main/k/knewstuff/libkf5newstuff5_5.54.0-1_
Hello Pino,
On Sun, 20 Jan 2019 15:28:44 +0100 Pino Toscano wrote:
> What is the reason why you send the messages to nnn-quiet@, instead
> of nnn@? -quiet means that the maintainer does *not* get any
> notification, so none of your emails reach the maintainer mailing list.
> Also, if the user rep
Control: forward -1 https://bugs.kde.org/show_bug.cgi?id=359664
Control: tags -1 upstream fixed-upstream
Control: fixed -1 plasma-workspace/4:5.12.0-2
Dear Maintainer, hello Michael Meier,
from the segfault line I would suspect that this
crash happened in sniproxy.cpp, line 273.
There image may
Control: tags -1 + moreinfo
Hello Daniel Sutil,
just got to this bug report.
Do you still get this crash?
If it got solved for you, you could close this bug by sending
an email to 904094-d...@bugs.debian.org
If you still get it, you could follow these steps:
- install package gdb
- open a konsol
Hello André Isidoro Fernandes Esteves,
one more possibly useful thing to consider:
If you could install a core dump collector like package
systemd-coredump, then the system would store a file of
each crash for later inspections.
Also it would already print a backtrace in the system journal.
When
Dear Maintainer,
just a confirmation.
I tested a new Stretch installation and upgraded to current
Buster/testing and it went through without any issue.
Thank you very much.
Kind regards,
Bernhard
root@qnap-119p-ii:~# uname -a
Linux qnap-119p-ii 4.9.0-8-marvell #1 Debian 4.9.130-2 (2018-10-27) a
Hello Francois Marier,
this looks like a duplicate of bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919765
Kind regards,
Bernhard
Control: forcemerge 886777 907972
Control: tags 886777 + upstream fixed-upstream
Dear Maintainer,
upstream applied a fix to this stack smashing.
If no new upstream version is released and enters buster,
this patch [1] might be a candidate for cherry-picking.
Kind regards,
Bernhard
[1]
https:/
Control: retitle 918106 logrotate: segfaults in rotateLogSet
Hello Marc,
I am sorry, but my advice to use 'bt full' makes
following commands to show the state of frame #1.
Therefore can you repeat the "coredumpctl gdb 754"
without the "bt full"?
Kind regards,
Bernhard
Dear Maintainer,
found while searching for another bug that upstream
report [1] that looked familiar.
That upstream report points to the same source line
and is written to be resolved by [2] with topic dateformat.
This patch seems included first in debian stretch with
version 3.11.0-0.1 [3].
My l
Hello Ian,
additionally I found a new installer in [1].
Therefore I tried to install current buster directly.
The relevant part of qcontrol below.
Unfortunately the installation reported a failure later.
Is this supposed to work at the moment or already known,
or should I report it, if yes to whi
Hello Marc,
> but i don't see much more withour bt full, do i understand correctly ?
I just wanted to see the line from dmesg, where we can see which
address caused the error. And wanted to see all for the same crash.
And I had not realized that the callc instruction really have to
write its ret
Package: plasma-workspace
Version: 4:5.14.5.1-1
Severity: normal
Tags: patch upstream
Dear Maintainer,
I found that the splash screen takes longer than some month ago and did
some investigations that led to following two upstream bugs I reported.
Bug 405444 - ksplashqml hits its hard timeout o
Control: tags 920139 + unreproducible moreinfo
Hello Adrian Immanuel,
I am sorry for the late reply.
First a question: Do you still observe this fault?
I took a look today inside the md5sums you supplied
and tried to reproduce this setup inside a VM.
Unfortunately I found following old packag
Control: tags 908549 + fixed-upstream
Hello,
Just adding the fixed-upstream tag.
The patch might be small enough to be
cherry-picked to version 2.8 in buster?
https://gitlab.gnome.org/GNOME/gimp/commit/a2c20b15392d456b36afdc9074d1176f02403b29
Kind regards,
Bernhard
Hello Andriy Grytsenko,
tried to reproduce but could not find the file "meteoCNS" anywhere on the net.
Instead found following file that triggers the same crash stacktrace:
openclipart-svg:
/usr/share/openclipart/svg/recreation/religion/christianity/coat_of_arms_of_anglica_01.svg
Navigating
Hello Chris,
I added it to your report guessing that it might be the issue
you observed. Now I see your setup is way more complex than my test.
To reveal some more information about your issue, you could install
the package systemd-coredump, then in the journal should a
backtrace appear after a cr
reassign 914150 libfm/1.3.0-1
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
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
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/GN
fixed 932550 4.19.67-1
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, th
Dear Maintainer,
migth this be related to this bug:
https://bugs.debian.org/935496
Kind regards,
Bernhard
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 b
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 o
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,
Bern
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
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 fol
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/disc
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 ming
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 mes
Hello,
I have created a new upstream issue:
https://gitlab.gnome.org/GNOME/gegl/issues/206
Kind regards,
Bernhard
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
r
Hello Davide,
> With the debug symbols libreoffice is becoming slow and a lot more
> memory have been used...
> I have killed calc when I have only 121 MB of free memory and the swap
> was partially used.
>
> The file generated: 919297_libreoffice_gdb_2019-01-21_11-01-29.txt is
> very small.
Control: fixed 918106 logrotate/3.14.0-4
Control: tags 918106 = upstream fixed-upstream
Dear Maintainer, Hello Marc,
> (gdb) print log->numFiles
> $1 = 2122453
> stack size (kbytes, -s) 8192
That would match my assumption.
A maximum stack size of 8192 kb * 1024 / 4/*sizeof(int)*
Control: tags 920179 + upstream patch
Dear Maintainer,
I tried to have a look at this and think I found something.
This seems to be a case of implicit function declaration
defaulting to int as return type but real function returns
a pointer. Therefore an invalid pointer gets later used.
This sh
Hello marc, dear Maintainer,
a workaround could be to just to change the default stack
size in the script calling logrotate which is on stretch
maybe /etc/cron.daily/logrotate.
So maybe following line before calling
logrotate could be sufficient?
ulimit -s 16384
(I have not tested this.)
K
Control: fixed 920235 apache2/2.4.23-4
Control: found 920235 apache2/2.4.23-5
Control: found 920235 apache2/2.4.37-1
Dear Maintainer,
I tried to find out when this started inside an amd64 qemu VM
and got to these versions:
Stretch/testing of date 2016-10-10 with apache2/2.4.23-4 was ok.
Stretch/
Control: tags 920467 + upstream patch
Dear Maintainer,
tried to have a look at the stack smashing.
It happens inside a call to g_stat/stat64.
The reason is as far as I see that in nconfig.c the type
GStatBuf has just a size of 88 bytes, therefore no
more memory is reserved. Inside nstat or g_sta
Hello all,
> Any idea how other programs are being patched to cope with this?
This issue sounds similar to following older bugs, but
the actions taken there might not be applicable here.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917293
https://bugs.debian.org/cgi-bin/bugreport.cgi?bu
Hello Everyone,
I also tried to install current testing to a qnap ts-119P II.
On Tue, 29 Jan 2019 21:43:50 +0100 =?UTF-8?Q?Uwe_Kleine-K=c3=b6nig?=
wrote:
> On 1/27/19 12:13 PM, Lukas Straub wrote:
> > Package: linux
> > Version: 4.19.12-1
> >
> > Hello Everyone,
> > I tried the latest Buster In
Hello Everyone,
> > > > Is this supposed to work at the moment or already known,
> > > > or should I report it, if yes to which package.
> > >
> > > I think flash-kernel is probably the right starting point, although it
> > > might turn out to be a kernel issue.
> >
> > It's a kernel issue that
Hello all,
> Note that other declarations changed between 1.44.4 and 1.44.5 so
> there may be other similar problems.
This looks related to upstream change to take care
of debian bug #99. This change looks like it got
reverted again.
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/log/m
Hello Vincas Dargis,
I guess the provided information may not be enough for the
maintainer to find the cause or make a fix.
And I am just curious, but this "0x2f9b8" are just the "195000" from
the kernel log line? I am not sure, but would here not make
0x7f9cf2783000 - 0x7f9cf2803676 = 0x80676 mor
Hello Piviul,
On Tue, 22 Jan 2019 19:23:57 +0100 Piviul wrote:
> Dear Maintainer,
> I have followed the Davide instructions and even my libreoffice was consuming
> all the amount of memory... it is very strange you couldn't reproduce it!
I am not a maintainer, I just tried to collect
some more i
Hello Gennadiy Starostin,
just trying to collect some more information for the maintainer.
Can you observe this with the latest update to 1:6.1.5~rc1-2.
If yes, can you provide which desktop environment you use and
if it is running on Xorg or Wayland?
Kind regards,
Bernhard
Hello Adrian Immanuel Kiess,
I tried to search the net about this message:
"GLib-GIO-ERROR: No GSettings schemas are installed on the system"
And found results pointing to .../share/glib-2.0/schemas/.
Therefore renamed following file:
/usr/share/glib-2.0/schemas/gschemas.compiled
And rece
Hello Rokas,
I just tried to collect some more information and
could reproduce the crash with Qt 5.11.1+dfsg-8.
With version 5.11.2+dfsg-3 and current 5.11.3+dfsg-2
I was not able anymore to reproduce.
Can you confirm that the bug is not visible
anymore on your installation?
Kind regards,
Bernha
Hello Everyone,
I own a qnap ts-119pII with a similar cpu.
See attached file with several debugging attempts.
With my limited assembly knowledge I got to this instruction,
where the backtrace command still shows all of the stack:
(gdb) bt
#0 0x03718a2c in stg_returnToStackTop$def ()
Control: fixed 920247 libreoffice/1:6.1.5~rc1-2
Hello Gennadiy,
> In 1:6.1.5~rc1-2 such files open just fine, thank you!
I am glad to hear that, your description sounded similar to
another bug #919297 that was also resolved by the new version.
But the thanks should go to the maintainer or to up
Dear Maintainer, hello Wookey,
just tried to find out where this exception comes from.
And is looks like it originates in libTKTopAlgo.so.7
(libocct-modeling-algorithms-7.3 / opencascade).
Having no deeper knowledge of either freecad or opencascade,
I can just guess if the next step would be to r
Hello Jean-Dominique Frattini,
I am not involved in packaging any of these packages,
but I noted that you opened the last three days nearly
the same issue against three different packages?
What are you trying to achive that way?
And you noted versions contained in current Buster,
but you claim it i
Hello Marc Lehmann,
are you able to reproduce this hang on a installation
with just stretch package versions, too.
(Or maybe on a buster installation)
I ask because at least following packages are more current as
the plain stretch versions:
| versions reported | currently in st
Hello Anton Avramov,
not involved in packaging of isc-kea I just read
your report and may have some points.
Why do you use the upstream binary of libmariadbclient.so.18.
Is the stretch packaged version 10.1.37-0+deb9u1 too old? [1]
And it looks like you installed the debug symbol package
kea-dhc
Hello Anton,
sorry, did completely miss the option that upstream could
also provide dbgsym packages ...
Just to be sure, the last backtrace was retrieved with upstream
binaries of version 10.2.19+maria~stretch?
And debug symbols are contained in libmariadb3-dbgsym?
Because your last backtrace sho
Hello Anton,
On Fri, 14 Dec 2018 16:34:23 -0500 Anton Avramov wrote:
> Hello Bernhard,
>
> Well no. I've actually installed. apt install
> libmariadbclient18=10.1.26-0+deb9u1 libmariadbclient18-dbgsym
>
> (gdb) display/i $pc
> 2: x/i $pc
> => 0x7479eccc : movzbl 0x451(%rax),%eax
At thi
Control: fixed 916200 1:2.30.2-0.3
Control: found 916200 1:2.31.1-0.1
Dear Maintainer,
I noticed this behaviour too and found last version that
normally exits is 2.30.2.
I did a git bisect that points to the upstream commit [1] below.
Kind regards,
Bernhard
[1]
https://git.kernel.org/pub/scm
Hello Nils Jarle Haugen,
these instructions are great to reproduce the crash.
Below is the backtrace with debug symbols installed.
It looks like the vector m_boardLed->m_pin contains invalid
data, and therefore we crash when calling methods on an
element retrieved from it.
Valgrind shows the same
Hello Vincas Dargis,
I just wanted to find out where in thread 4 this call to qTerminate
originates, without having deeper knowledge of akonadi ...
Unfortunately it looks like this backtrace just shows where we are in
the exception handler - effectively hiding where the exception really
happened i
Hello Anton,
> (gdb) print/x $rax
> $7 = 0x0
> (gdb) print stmt->mysql
> $8 = (MYSQL *) 0x0
> (gdb) print *stmt->mysql
> Cannot access memory at address 0x0
>> (gdb) list libmysql.c:4134
>> 4134 if (stmt->mysql->options.report_data_truncation)
That null pointer seems to be the problem her
Hello
when you find such a failing to close vlc, you might
consider to run following line.
That should give you a vlc_*.txt file which contains
all threads current backtrace and might point to where
the vlc process is waiting.
for pid in `pgrep vlc`; do gdb -q --pid $pid -ex "set pagination off" -
Hello Brian Potkin,
you might want to install a core dump collector like systemd-coredump.
With that in place you might get a more verbose message in journalctl.
Also a later inspection of the coredump might be possible:
coredumpctl list
coredumpctl gdb [PID]
bt
quit
And even better when hav
Hello Cristian Ionescu-Idbohrn,
following is what I get from a buster amd64 qemu VM,
with explicitly downgraded systemd packages to 239-13:
It has quite a similarity to upstream bug [1].
And upstream received a fix for that just a few days ago,
and is therefore not yet contained in an upstream rel
Hello Cristian Ionescu-Idbohrn,
Am 18.12.2018 um 09:35 schrieb Cristian Ionescu-Idbohrn:
> On Mon, 17 Dec 2018, Bernhard Übelacker wrote:
>>
>> Hello Cristian Ionescu-Idbohrn,
>> following is what I get from a buster amd64 qemu VM,
>> with explicitly downgraded
Hello,
probably you can also add following debug symbol packages:
/usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so ->
libgl1-mesa-dri-dbgsym
/usr/lib/x86_64-linux-gnu/libQt5DBus.so.5 ->
libqt5dbus5-dbgsym
/usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
Hello Brian Potkin,
I tried to have a look in a unstable VM, but unfortunately
I get different offsets ...
You might add the output of this command:
dpkg -l | grep -E "cups-browsed|libc6|libglib|libavahi|libdbus" | sort
And what output did you receive from this command
coredumpctl list
and f
Dear Maintainer, hello Brian Potkin,
> Thanks. All this is very new to me. I hope it is what is needed and
>
> someone can interpret it!
Thanks for the information, in my first attempts I was under the impression
you are on a amd64 system becau
901 - 1000 of 1320 matches
Mail list logo
