Hello Kody,
I had in the past also a working crash kernel setup.
But that started to fail with and after kernel 5.5.
Unfortunately I did not yet come to report this to debian.
If that is also the case for you, a workaround could be to
install the old 5.4.19 bpo kernel [1].
And modify
Dear Maintainer,
I tried to have a look and could reproduce the issue.
It seems this got already fixed upstream in [1].
Also a related upstream issue exists [2].
A package built with this patch applied does
not show the fault.
Kind regards,
Bernhard
[1]
Hello Simon,
I guess #982049 is about the same issue.
At least function name and address offset is equal.
Kind regards,
Bernhard
Package: gdb
Version: 10.1-1.7
Severity: wishlist
X-Debbugs-Cc: bernha...@mailbox.org
Dear Maintainer,
while investigating an issue in the test suite of rr-debugger,
I found that the libbfd part of gdb is not built with debug information,
therefore the dbgsym package also lacks this information.
Hello Helge,
I just tried to collect some information for the Maintainer.
Might this be the expected behaviour?
This image seems to have a stored Delay and Duration value:
$ identify -verbose 2006_08262.gif
Image:
Filename: 2006_08262.gif
...
Delay: 20x100
Duration: 20
...
These 20
Hello Jerome,
could you please add a few more details for the Maintainer?
What shows the "bt full" command in gdb, when the crash is reached?
Is the package dconf-service installed and
when you login a process dconf-service running?
Kind regards,
Bernhard
Hello Jim,
I am not involved in packaging, but came to this report by chance.
The attached file contains all the changes you devs have made in the kernel
configs from 5.10.28 (-6 package) to 5.10.38/.40 (-7 package). It was made with
meld.
~10 kernel parameters have changed and led to this
Hello Juan,
the last lines of your backtrace end in nouveau_dri.so.
Therefore this might not be a fault in solvespace.
Maybe you could install the package libgl1-mesa-dri-dbgsym where
the file nouveau_dri.so originates from, and provide
another backtrace from such a crash.
I would expect that
Dear Maintainer,
I could reproduce the issue, but mostly just on the first run
after a reboot of my test VM.
When the issue appears the context menu opens for the favorites,
but the entry to create a new folder is wrongly enabled.
Clicking in that state leads to the error message:
Error while
Am 01.06.21 um 14:31 schrieb Bernhard Übelacker:
Dear Maintainer,
there is an upstream bug that shows a similar backtrace
and is also about clipboard interaction.
Maybe more likely to happen with larger selections.
https://gitlab.gnome.org/GNOME/gimp/-/issues/2357
And copyq upstream has also
Dear Maintainer,
there is an upstream bug that shows a similar backtrace
and is also about clipboard interaction.
Maybe more likely to happen with larger selections.
https://gitlab.gnome.org/GNOME/gimp/-/issues/2357
Kind regards,
Bernhard
Am 31.05.21 um 21:49 schrieb Adrian Bunk:
#975977 comes into my mind as a similar bug in a different package.
Unfortunately in this bug it was possible to do a side by side
debugging, that way the exact instruction could be identified,
and the relation to the alignment was found.
But with
Hello Mr. T,
I tried to reproduce the issue inside a small VM.
I hit an issue when copying something, mostly larger areas, in gimp.
If I started gimp from a terminal I got this message [1].
Maybe you could confirm when you start gimp from a terminal
you see the same message, when the error
Dear Maintainer,
this backtrace looks quite similar to the reports
from following link from fedora, which started
to appear end of march.
Unfortunately I could not find a related
entry in their bug tracker.
https://retrace.fedoraproject.org/faf/problems/41770/
Kind regards,
Bernhard
Hello Ray,
Warning, a coredump from this system would be immense. Or, well anyway
pretty darn large.
systemd-coredump should limit the core to 2G.
And as a first target, the journal output might have a backtrace
from which one could start looking.
Maybe running openuniverse with a memory
Dear Maintainer,
I did a little further investigation and found that it could be
reproduced with just the following line, inside the arm64 chroot:
for i in {1..100}; do echo $i; python3.9 -c "exit()"; done
This produced 13 crashes for the 100 runs.
But the crashes stop to appear when /proc
Am 22.05.21 um 00:11 schrieb Bernhard Übelacker:
Maybe systemd-coredump would collect a core of such a crash?
And I did a debootstrap in a loop and got three crashes out of 20 tries.
A core was collected and shows the stack below.
It is strange that exec_path shows just "/arm64"
Hello Diederik,
I am not involved in packaging, just
trying to collect some information.
Architecture: amd64 (x86_64)
The subject on the email mentions "on arm64".
From the Architecture line I assume this should read "on amd64"?
[44932.698657] python3.9[313800]: segfault at 2524310 ip
Hello Guilhem, hello Jonas,
might this be a similar or the same issue as in #942055 ?
I took the example file from this issue,
created an armel buster chroot and ran it once at my arm5tel device,
and once at a armv7l cpu android device (unfortunately with
a non-debian kernel).
- with the
Hello,
just a small note about the toolbars in the screenshot
may be looking similar to these in bug#986821.
Kind regards,
Bernhard
https://bugs.debian.org/986821
Hello Torbjørn Birch Moltu,
I tried to reproduce this issue inside a virtual machine.
But there the menu opens without the issue.
Does this happen to you if you startup without the wacom input attached?
Next thing you could try is to startup krita this way:
export MALLOC_CHECK_=3
krita
Hello Chris,
I am not involved in packaging, just trying to give some
pointers to get better information for the maintainers.
In [1] are several possible actions listed, that could be
used to get more informations.
Just to clarify, host heisenberg is your local system,
from which the connection
Hello,
just for the record.
Upstream seems to have fixed this in [1] which
is included in kernel v5.8 and later.
Kind regards,
Bernhard
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/tools/perf/ui/browsers/hists.c?id=d61cbb859b45fdb6b4997f2d51834fae41af0e94
Control: fixed -1 linux/5.10.28-1
Dear Maintainer,
I got that Thinkpad T60 back, and did upgrade
the installation to bullseye.
I can now confirm that the nokaslr workaround is not
needed any more, hibernate and resume is working for
me with current kernel 5.10.0-6-686-pae/5.10.28-1 in testing.
Hello,
just for anyone coming here through internet searches.
The "caught XIO error:" leads to this upstream bug reports:
https://github.com/LibVNC/x11vnc/issues/147
https://github.com/LibVNC/x11vnc/issues/154
With the mentioned option "-noxdamage" I could stop getting this error.
I
Hello Simon,
Am 21.04.21 um 20:19 schrieb Simon McVittie:
On Tue, 20 Apr 2021 at 22:17:58 +0200, Chris Born wrote:
This looks like #953880/#953854/#953794, ...
Do you see enough similarity to #968005 and #954739
to justify closing or merging them too?
Kind regards,
Bernhard
Just for reference, why g++ does not error here,
this gcc bug might be interesting:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43943
Kind regards,
Bernhard
Dear Maintainer,
I tried to have a look, but got no clue why a Unwind should take place
until I saw the old build log [1].
There I found this warning:
Levels.cpp: In member function ‘bool Levels::addLevel(const string&, int,
int)’:
Levels.cpp:118:1: warning: no return statement in function
Dear Maintainer,
...
#3 0x559e07a698d8 in gimp_fatal_error ()
#4 0x559e07a6a037 in ?? ()
#5
#6 0x559e07dd1e3b in gimp_param_spec_layer_id ()
#7 0x559e07cf57ed in gimp_pdb_compat_param_spec ()
#8 0x559e07d02077 in gimp_plug_in_handle_message ()
#9 0x559e07d10501
Attached patch just renames the global variable blits to tmblits.
A package tuxmath built with this patch does not show this crash.
Sorry, forgot to attach.
Bug-Debian: https://bugs.debian.org/986623
Forwarded: no
Last-Update: 2021-04-20
--- tuxmath-2.0.3.orig/src/titlescreen.c
+++
Dear Maintainer,
I tried to have a look at this crash and
got this backtrace [1].
It looks like there is a disaggreement about the size of the blits structure,
one inside tuxmath and one inside libt4k-common0:
tuxmath-2.0.3/src/titlescreen.h:65:#define MAX_UPDATES
180
Dear Maintainer,
with the help of the dbgsym package the "Code:" line
points to this line [1]:
0x7fffebed7f9c in camel_imapx_folder_set_mailbox at
./src/camel/providers/imapx/camel-imapx-folder.c:1371
The function camel_imapx_folder_set_mailbox then points
to this upstream bug report
Hello Jérémy,
Am 19.04.21 um 16:35 schrieb Jérémy Lal:
Meanwhile, i suspect the other bug i reported is similar
you are right, at least the backtrace is also showing some 'valist'.
This bug seems to lead to this upstream bug:
https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1007
Dear Maintainer,
I tried to have a look and I could reproduce the crash [1].
I think this is caused by a call to gtk_list_store_set
in totem_playlist_steal_current_starttime [2].
There a variadic argument list contains a plain 0,
which might occupy just 32 bit, but gets later interpreted
as
Hello Ray,
from the "Code:" line you supplied I think the segfault happens
in create_cache_trans at ../src/mesa/state_tracker/st_cb_bitmap.c:402.
https://sources.debian.org/src/mesa/20.3.5-1/src/mesa/state_tracker/st_cb_bitmap.c/#L402
But I guess this information is not enough for the
Dear Maintainer,
I tried to have a look and the segfault is really a result of the
previous g_param_spec_is_valid_name failures.
It looks like g_param_spec_is_valid_name got tightened lately to
not accept names with dashes anymore.
The following malloc corruption seems to originate in the
Hello till,
I tried to reproduce this inside a minimal VM,
but the crash did not show for me.
Maybe you could provide some more details, e.g.
by installing systemd-coredump and inspecting the
journal after a crash happened and adding the lines
of the crash time to this bug.
Please see more
Hello Russel,
thank you for the detailed backtraces.
Unfortunately they point into Qt's javascript module,
finally trying to copy memory to a null pointer.
I have not found a hint to similar crashes in
upstream bug tracker.
Could you please provide which theme you are using,
or if there are
Hello Nenad Cvetkovic,
> Hi Bernhard Übelacker,
> I hope I managed to create a proper backtrace, this is my first time.
>
> As for your question about rebuilt packages, I have no idea when this
happened. I didn't build many things, I remember building ubuntu's Yaru theme.
>
Hello Antonio,
this directory should contain a file: /etc/gconf/2/path
The content should most probably what is shown here:
https://sources.debian.org/src/gconf/3.2.6-7/debian/default.path/
(And can be downloaded in the upper right corner.)
Kind regards,
Bernhard
Am 09.04.21 um 15:26
Hello Russel,
thanks for the fast answer, unfortunately the
backtrace is not yet enough expressive.
Maybe you could also install the following debug symbol packages?
libqt5qml5-dbgsym libqt5core5a-dbgsym libqt5widgets5-dbgsym libqt5gui5-dbgsym
kwin-common-dbgsym kwin-x11-dbgsym
These are
Hello Silvério,
Reading symbols from /usr/bin/kwin_wayland...
(No debugging symbols found in /usr/bin/kwin_wayland)
BFD: warning: /tmp/user/1000/coredump-ySV5m6 is truncated: expected core file
size >= 2365169664, found: 2147483648
it looks like for some reason the kwin_wayland exceeds
the
Hello Antonio,
thank you for the detailed informations.
Am 01.04.21 um 19:15 schrieb Antonio:
$ gdb gsettings-data-convert
Starting program: /usr/bin/gsettings-data-convert
(gsettings-data-convert:4756): GConf-CRITICAL **: 19:00:31.514:
gconf_engine_get_local_for_addresses: assertion
Hello Russell,
could you still see this issue?
Stack trace of thread 120123:
#0 0x7f49c3823ce1 n/a (/lib/x86_64-linux-gnu/libc-2.31.so
(deleted) + 0x3bce1)
Were there more lines following in the "Stack trace of thread 120123"?
And as
Hello Markus,
I tried to fill in the symbol information that were missing
in the above backtrace by using the available dbgsym
packages python3-cryptography-dbgsym and libssl1.1-dbgsym.
With these installed your gdb would show line information too [3].
I found following ticket [2] that shows in
Dear Maintainer,
I wondered why the first two allocators would fail
and tried to step into.
At least the alloc_malloc seems to use the
regular glibc-malloc, and should succeed therefore [1]?
So might there be a size restriction in place how much memory
totem-video-thumbnailer is allowed to
Hello Gregor,
I am not sure if my last mail reached you. [1]
There I did not notice a line for libboost_nowide in ldd output.
Also I tested by the last two modifications which
made XS.so to be linked to libboost_nowide and made
slic3r not fail with the unknown symbol error.
Kind regards,
Dear Maintainer,
I was trying to collect some more information for bug #973811.
There it looks like openblas does its own memory management seems
therefore affected by some sandboxing disallowing a SYS_bind syscall.
With the test VM I used there I get with current testing this
output for a
Hello Roderich,
I looked a little around and found Debian bug #967941.
There the media file is a video file that led
to loading libopenblas.so. This seems to be caused
by the file gstreamer-1.0/libgstlibav.so.
I could reproduce it now within a VM with current testing.
By creating a mkv video
Package: ddrutility
Version: 2.8-1.1
Severity: normal
X-Debbugs-Cc: bernha...@mailbox.org
Dear Maintainer,
I found on some attempts to use ddru_findbad are
failing for me like this:
...
/usr/bin/ddru_findbad: 1027: arithmetic expression: expecting primary: "
(300-/dev/loop0:) "
I
Hello Joe,
thanks for the backtrace. It enabled me to reproduce it.
You have configured a post processing step in your printer settings?
Then this setenv function is tried to be located in the loaded
shared objects. Unfortunately Slic3r/XS/XS.so does not show to be
linked to libboost_nowide.so,
Hello Joël,
I guess I have a similar setup and had similar
lock-ups as your video shows.
I had opened this upstream bug [1].
Either with latest bios updates the situation improved,
or last year I started to do after each cold boot another
warm boot and have the feeling that way this issue does
Dear Maintainer,
I tried to fill the gaps in the given backtrace with
the matching dbgsym packages, see below.
Might this be a kind of sandbox, not allowing
to allocate memory the way libopenblas.so does/did?
Kind regards,
Bernhard
#0 syscall () at
Hello Chris,
Am 04.04.21 um 22:33 schrieb Chris Hofstaedtler:
Hello Bernhard, Marc,
Some more questions:
1) which kernel version is this?
My test was just inside a temporary VM with current testing.
But I can still reproduce this with current testing kernel at the host too:
Linux rechner
Dear Maintainer,
tried to locate the exact smashing.
It looks like the ioctl(EXT2_IOC_GETFLAGS) takes an int* parameter,
but writes 8 bytes instead of just sizeof(int) to the given address.
Kind regards,
Bernhard
Old value = (void *) 0xf759b62c03711000
New value = (void *)
Dear Maintainer,
I tried to have a look at this savegame and when loaded
shows these freezes to me too.
An attached gdb shows that leaving VertexPathfinder::ComputeShortPath
takes some minutes, while the game is frozen.
Upstream might have already some optimizations
for this issue in [1].
At
Dear Maintainer,
tried to export the example files delivered with prusa-slicer
e.g. AK_Bed.stl, but could not reproduce the fault inside
a minimal qemu VM.
My resulting process has /usr/lib/slic3r/auto/Slic3r/XS/XS.so
mapped, the function _ZN5boost6nowide6setenvEPKcS2_i
would be printed by gdb
Dear Maintainer,
I could reproduce the issue inside a minimal stable VM.
It crashes with following backtrace [1].
This crash does not show up with the same input in current testing.
The resulting png file shows a "mesh" on top of a map.
The method GribDecoder::visit changed a bit [2].
Kind
Hello Antonio,
was this line in dmesg maybe followed by a "Code:" line?
Could you provide that too?
Otherwise maybe you could install systemd-coredump and after
the next crash journal should contain more info about it and
collect a core for later inspection.
More details here:
Hello Enrico,
I am not involved in packaging python3-magics++,
just tried to reproduce this fault.
Unfortunately it did not show up in my minimal test VM.
It produced a png with a frame and a text and a symbol
at the bottom. Is there something more expected to
be in the rendered png?
Do I have
Hello Silvério,
Am 31.03.21 um 20:42 schrieb Silvério Santos:
Hallo Bernhard,
Here is it:
Mär 31 20:11:25 systemname kernel: kwin_wayland[1834]: segfault at e8 ip
7fe70ba08268 sp 7ffc9bbf64d0 error 4 in
libKWaylandServer.so.5.20.5[7fe70b9b+b6000]
Mär 31 20:11:25 systemname
Control: fixed -1 1:3.0-2
Control: tags -1 + upstream fixed-upstream
Dear Maintainer,
I tried to reproduce this issue and got this backtrace:
(gdb) bt
#0 0x7f52d57cf7e4 in _IO_new_fclose (fp=0x0) at iofclose.c:48
#1 0x55884d86fec0 in shutdown_events () at
Hello Santos,
I tried to reproduce this issue but did not see it inside a minimal VM.
Therefore tried to some more information from the Code bytes printed in
you journal/dmesg.
This should point to this instruction:
0x7f6e16bd5268
Dear Maintainer,
I tried to have a look at this segfault.
As far as I can see the issue here is a memory access after the
php heap, where this memory was allocated from, got unmapped.
Below are the backtraces for allocation [1], unmapping [2]
and the segfault [3].
Some more details in attached
Hello Nenad Cvetkovic,
I tried to have a look at your core file.
It shows a crash with following backtrace [1].
The reason seems to be an invalid function pointer in variable "prepare".
The upstream issue in [2] shows a similar backtrace, but I
am not sure if they are related about what is
Dear Maintainer,
I tried to have a look at the core file and a backtrace
with all needed symbols looks like in [1].
In the end it looks like in refresh_combo_devices [2] it
is attempted to load a harddisk icon.
This failed for some reason in [3], therefore a local variable
"theme_icon" contains
Hello everyone,
I added it, and now I got one:
Tue 2021-03-23 20:20:40 CET2000 109 115 11 present
/usr/bin/sddm-greeter
If I extract it, I get:
Executable: /usr/bin/sddm-greeter
...
#9 0x7fe7b41f5def __clone (libc.so.6 + 0xfddef)
With this "coredumpctl
Dear Maintainer,
On Mon, 08 Mar 2021 15:49:55 +0100
=?utf-8?q?IOhannes_m_zm=C3=B6lnig_=28Debian/GNU=29?=
wrote:
#4 0x554359e8 in PatchageCanvas::index_port(PortID const&,
PatchagePort*) (this=0x0, id=..., port=0x557233c0) at
../src/PatchageCanvas.hpp:59
#5 0x55450837
Am 20.03.21 um 21:44 schrieb Helge Kreutzmann:
If I should install a -dbg version or something else please
inform me.
Thank you for the additional information.
There might really be something more. If you have not, is it possible
to install the package "systemd-coredump".
If then a crash
Hello Julian,
On Thu, 10 Dec 2020 16:52:14 +0100 Julian Andres Klode wrote:
... install libapt-pkg5.0-dbgsym and apt-dbgsym
from the dbgsym repository and try again.
Unfortunately there are just dbgsym packages for 1.4.10.
I guess the dbgsym packages for 1.4.11 never got published,
because
Hello Celelibi,
unfortunately, if I try to reproduce I reach the exact same stack,
but in case of my VM ctx->pipe->set_shader_buffers contains a
valid function pointer.
Maybe you could add some information about which graphics card
you use and maybe running with 'export LIBGL_DEBUG=verbose'
Dear Maintainer,
I tried to reproduce, and it got it crashing too
when trying to move a window just by keyboard, before
moving any windows by mouse.
It looks like in that case the variable currentClient
never got set, therefore the access in UpdateDesktop
dereferences a null pointer.
This seems
Dear Maintainer,
this segfault seems to happen in [1].
It looks like upstream is not
yet prepared to work with Wayland.
There is an upstream issue about wayland support [2].
Kind regards,
Bernhard
[1]
(gdb) bt
#0 0x7f50f93c5caf in XGetKeyboardMapping (dpy=0x55a910fa20d0,
Dear Maintainer,
I tried to reconstruct the given backtrace in [1].
So the actual issue seems to be a "movq" instruction which
seems to be due to [3] a SSE2 instruction, which might
the "Pentium III M" is lacking, like Stefan already noted.
I am not sure where the current Debian baseline could
Dear Maintainer,
just a side note:
The visible segfaults might be related to #977945.
Unknown if they have any effect on suspending.
Kind regards,
Bernhard
Dear Maintainer,
I have tried to reproduce these segfaults and received them
when redshift-gtk is installed and lightdm is used as login manager.
It looks like redshift-gtk installs a systemd user unit,
which is executed also for the lightdm login screen.
But it looks like the 'systemd --user'
Hello Helge,
do you still see these messages in your logging?
If yes could you maybe add the surrounding logging
of one such fault? E.g. by something like this:
journalctl | grep "traps:" -C20
Kind regards,
Bernhard
Hello Helge,
do you still see these messages in your logging?
If yes could you maybe add the surrounding logging
of one such fault? E.g. by something like this:
journalctl | grep "traps:" -C20
Kind regards,
Bernhard
Control: reassign -1 libvtk9 9.0.1+dfsg1-8
Control: affects -1 python3-vedo
Dear Maintainer,
I tried to reproduce this issue and got also a crash.
Digging further it looks like in FireTimers an iterator "timer"
of the map LocalToTimer currently points to the element
with id=1, which gets
Am 15.03.21 um 16:36 schrieb John Bowman:
A SIGFPE
Hello John,
sorry, I noted the details for the SIGFPE in my
second mail just for completeness about debugging.
The issue starting it all seems the SIGSEGV from my first mail.
On a second look it seems that the descructor of
the
Am 15.03.21 um 14:10 schrieb Bernhard Übelacker:
otherwise I got a SIGFPE
A short offtopic side note to rr sensing this SIGFPE,
not directly related to the malloc message:
This can also be seen in a process without being
recorded by rr by setting LP_NUM_THREADS to zero, so
operations take
Hello everyone,
I tried to reproduce this issue inside a minimal qemu VM,
with an available X server, and investigate with the help
of rr-debugger and valgrind.
First in camp::picture::shipout3, line 1404 the process asy
forks, and following failure happens in the child thereof.
In the
Hello Sandro, hello Norbert,
this sounds like the feature "Highlight lines coming into view" [1].
There is an option that looks like it could be disabled in:
Profiles - Scrollbars - "Highlight the lines coming into view"
Kind regards,
Bernhard
Hello Ryutaroh Matsumoto, dear Maintainer,
I am not involved in packaging valgrind, just trying to
help with some random bug reports.
For this report #983377 I cannot follow, how #928224 is blocking it?
#928224 is about valgrind not running at all,
with "a function redirection ... cannot be set
Hello Martin-Éric,
without being involved in packaging fwupd I tried to
have a look at this issue.
I could not reproduce it inside a i386 qemu VM (not even
with "-cpu pentium"). Have not tested on real hardware.
Looking up the endbr32 instruction, it seems it belongs to something
called
Dear Maintainer,
tried to reproduce this issue inside a minimal qemu VM and
found that this starts to manifest with kernel version 5.9.
Using a kernel 5.8 with current testing userland does
not show this issue.
These tests were done with qemu parameter "-cpu host".
Without any cpu parameter I
Hello Celelibi,
does this happen with current version
in testing 0.228+dfsg.1-1, too?
Kind regards,
Bernhard
Dear Maintainer,
this crash happens because this executable is expecting
at command line a parameter month and year.
Doing so produces a calendar at stdout in postscript format.
Kind regards,
Bernhard
(gdb) bt
#0 __GI_strtol_l_internal (nptr=0x0, endptr=0x0, base=10, group=0,
Dear Maintainer,
this issue might be following upstream bug [1].
Because of that winepath "emits DOS-style instead of
UNIX-style line endings".
Therefore the carriage return character got part of
the filename and could therefore not be found.
This got fixed already in upstream wine-5.7.
Kind
Control: reassign -1 gnome-shell 3.38.3-3
Control: affects -1 python3-pygame
Hello Richard,
wonderful, thanks, thats a great backtrace.
It is highly similar to that one in upstream bug [3491]
and still quite similar to [3785].
Some commits entered the upstream 3.38 branch to fix the first bug,
Hello Richard,
thanks for the new information, but really
the dbgsym packages were meant.
They are available in a separate repository.
Nevertheless, if adding this repository is not possible,
then there is another way, but that would download
unknown size of files into directory
Hello Richard,
thanks for the fast response.
I failed to tell you the -b0 means the current boot,
therefore if you rebooted with -b-1 might the boot that
contains the crash.
But maybe you could improve the output of coredumpctl
quite a bit.
Could you please add the debug symbol package
Dear Maintainer,
I tried to get some more information from the kernel message.
This led me to this line:
at 0x5556ee99: file gpm-engine.c, line 540.
There the array is dereferenced unconditionally:
https://sources.debian.org/src/mate-power-manager/1.24.2-1/src/gpm-engine.c/#L540
539
Hello Richard,
I tried the steps below [1] but it did not trigger
a crash inside a gnome/wayland test VM.
Maybe you could install the package systemd-coredump, trigger
the crash once more and retrieve the logging from the current
boot by 'journalctl -b0 > journalctl.txt' and forward the
lines
Hello Joe,
this information might not be sufficient for the maintainer.
Could you try following to collect some more informations?
- install packages:
gdb psmisc konqueror-dbgsym
- stop all running instances of konqueror:
killall konqueror
- then start konqueror inside a debugger:
Dear Maintainer,
I investigated a bit further and came across this document [1].
There it is stated that in Linux usually a single qxl device with
multiple outputs [2] is used and in Windows multiple qxl devices with
a single output each [3].
Using with a Linux guest the suggested multiple
Package: libmutter-7-0
Version: 3.38.3-2
Severity: normal
X-Debbugs-Cc: bernha...@mailbox.org
Dear Maintainer,
I tried to replicate #982572, therefore
setup a qemu VM with two qxl devices [1].
This is currently running a kernel 5.2 due to #983934.
Inside I have trouble with mouse input,
Dear Maintainer,
I tried to have a look at the kernel message and if I could
retrieve some more information with the help of the dbgsym
package, like described in [1].
And I came up with the following location:
at 0x5557997c: file imap-notify.c, line 305.
0x55579976 :41
Hello Mikael,
maybe you could install systemd-coredump and look into output
of "journalctl -e" after such a crash happened again.
For more information please have a look at [1] about several
ways to collect some more information that might help the
maintainers.
Kind regards,
Bernhard
[1]
Dear Maintainer,
I tried to reproduce this issue and received a backtrace like in [1].
This looks like being fixed upstream in commit [2].
A package built with this patch does not crash any more.
The reason seems to be because this macro defines a variable
in a block local scope while it should
201 - 300 of 1271 matches
Mail list logo
