On Mon, 27 May 2024 11:22:02 +0100 Jack Beckitt-Marshall
wrote:
When I perform certain actions on my GNOME desktop, such as using the Location
bar (Ctrl+L) in Nautilus, clicking on System Information in GNOME Control
Center, or click Fonts in GNOME Tweaks, the programs close with a
On Tue, 19 Dec 2023 20:22:43 +0100 Eduard Bloch wrote:
#7 0x7fb14945a510 __restore_rt (libc.so.6 + 0x3c510)
#8 0x7fb149186702 n/a (amdgpu_drv.so + 0x16702)
#9 0x7fb149186c96 n/a (amdgpu_drv.so + 0x16c96)
#10
On Mon, 20 Mar 2023 11:34:43 +0100 Christophe Lohr
wrote:
Package: libgl1-mesa-dri
Version: 22.3.3-1
Severity: normal
X-Debbugs-Cc: christophe.l...@cegetel.net
Dear Maintainer,
Xorg is carshing with a segfault:
(EE) Backtrace:
(EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139)
Dear Maintainer,
I tried to add source line information to the Xorg backtrace:
fdd in inl at /usr/include/x86_64-linux-gnu/sys/io.h:83
(pci_device_linux_sysfs_read32+93)
f1a in x86emuOp_in_word_AX_DX at
../../../../../../hw/xfree86/int10/../x86emu/ops.c:10364
024 in X86EMU_exec at
Dear Maintainer,
I tried to add line information using the dbgsym packages.
That led me to libc trying to print the
message "double free or corruption (out)".
Kind regards,
Bernhard
https://sources.debian.org/src/glibc/2.36-8/malloc/malloc.c/
4584malloc_printerr ("double free or corruption
Forwarding, as the email from TJ possibly did not reach Felix.
On Fri, 21 Oct 2022 11:43:07 +0100 TJ wrote:
On Sat, 12 Feb 2022 08:21:55 + Felix Leimbach wrote:
> I noticed that vgamem_mb was still low (32 MB).
> So I changed to this (slightly wasteful) command-line and am now running
On Sat, 03 Dec 2022 11:48:55 -0800 Jeremiah Mahler wrote:
[14.027] (EE) Backtrace:
[14.028] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x562070f40c59]
[14.028] (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40)
[0x7f12c3a5af90]
[14.029] (EE) unw_get_proc_name
Dear Maintainer, hello Kenneth,
Kenneth, if you still experience this issue, please check if
dmesg contains messages about missing firmwares.
E.g. by this command: dmesg | grep -i firmware
At least in this bug a similar backtrace was shown and
the user reported it got solved by
installing
After updating mesa from 22.2.0-1 to 22.3.0-2 (according to dpkg.log)
earlier today U.S. time as part of a routine upgrade to up-to-date sid,
the greeter stopped appearing, and over the course of the last two hours
we chased it down to that upgrade, which made X.org die with
iris_dri.so
Dear Maintainer,
this issue was also discussed upstream in [1] [2].
There the reason was given, that running the application
inside a KDE plasma session makes Qt pick up some KDE
shared libraries (KDEPlasmaPlatformTheme.so),
which does its own GL interactions, which is
not expected by qrenderdoc
On Fri, 5 Aug 2022 05:50:34 +0100 Sam James wrote:
It looks like this might be
https://gitlab.freedesktop.org/mesa/demos/-/issues/27 /
https://gitlab.freedesktop.org/mesa/demos/-/merge_requests/84.
Hello Antonio,
above Mesa issue 27 referenced another debian bug #1016363,
in which a new
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 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,
I tried to get a backtrace containing the source line
information from the core provided by the submitter.
It shows the backtrace below.
This backtrace leads to some upstream issues. Some
of them showing "proxy" being a null pointer.
In this case it shows 0x1 which seems causing
Dear Maintainer,
due to having in the backtrace the same offsets from function
nouveau_pushbuf_data, I assume this is similar to the bug #975990,
which is currently assigned to the xorg package and contains now
the line information I added with the help of the dbgsym packages.
Kind regards,
Dear Maintainer,
I tried to reconstruct the line number information with
the dbgsym packages from the backtrace provided by the submitter.
This points to the assert in this line of code: [1]
There are already some other references showing a similar assert below:
../nouveau/pushbuf.c:723:
Dear Maintainer,
the patches got accepted upstream hit now testing
with xserver-xorg-core 2:1.20.10-1.
I made a test similar to the initial attached file and
function addresses printed by gdb match now xservers backtrace.
Therefore I guess this bug can then be closed?
Kind regards,
Bernhard
Am 28.09.20 um 09:45 schrieb Michel Dänzer:
> Can you create an upstream merge request at
> https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests ?
Hello Michel,
thanks for looking at the issue.
I created this merge request:
Package: xserver-xorg-core
Version: 2:1.20.8-2
Severity: wishlist
Dear Maintainer,
in the past I was trying to make sense of some backtraces written
by Xorg, but failed, e.g. in #969739.
I did now some debugging and found that in function xorg_backtrace
the function begin retrieved by
Dear Maintainer,
I could not reproduce the crash, but I could modify the process under
gdb to reach a point of execution, which prints a similar backtrace.
Therefore I guess the crash described in Christophe's first message
is really located in [1], caused by "xf86_platform_devices[i].pdev"
Dear Maintainer,
the given backtraces are similar to the ones attached in this message:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955747#15
Kind regards,
Bernhard
Hello Felix Rublack,
I do not know if the maintainer are able to reproduce this issue,
but instead or additional to the strace a backtrace of the crash
might help them. The easiest way might be to install systemd-coredump
and look at "journalctl -e" after a crash. More info in [1].
(Even better
Hello Jamie Heilman,
I just tried to retrieve some line information from the backtrace.
Unfortunately I could not match the addresses with the
binary from the debian repository.
Was this backtrace by any chance built with a local
rebuild of the xserver-xorg-core package?
Kind regards,
Bernhard
Dear Maintainer,
I could reproduce the issue in a minimal bullseye VM.
>From my observations I guess the USR2 signal is sent
by logrotate:
/etc/logrotate.d/xdm:
kill -s USR2 $(cat /var/run/xdm.pid); \
If I read [1] right, then USR2 has a default action of
process termination.
Dear Maintainer,
might this issue be the same as described in this bug:
https://bugs.debian.org/932767
Kind regards,
Bernhard
Dear Maintainer,
looks like the submitter opened in response to the last
mail bug #930649 against src:linux.
Therefore this one might be closed?
Kind regards,
Bernhard
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930649
Dear Maintainer,
just trying to get some more information from the attached core.
It looks like the pointer stored in pPixmap->drawable.pScreen got
somehow overwritten and was then invalid, therefore received a SIGSEGV.
Kind regards,
Bernhard
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at
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
Hello Alain,
just saw your report and though it sounds similar to another one [1].
Do you have linux-image in version 4.9.130-2 installed?
Were older kernels working like expected?
If possible you might want also check if reverting back
to 4.9.110-3+deb9u6 gives you a not hanging system on eject.
Hello Massimo,
Am 24.10.2018 um 15:54 schrieb Massimo MANGHI:
> ... and the new patch will be
> included in the next upload, is it correct? Am I supposed to take any
> further action? Something like changing the bug status or applying some
> extra tag to the bug in order to specify the
Hello Massimo Manghi,
just tried to reproduce the issue inside a debian buster amd64 qemu VM.
I never hit the crash and found you were probably running inside a VirtualBox.
Nevertheless with installed debug informations I think the crash shown
in the Xorg.log points to that location:
(gdb) bt
tags 897390 = moreinfo
quit
On Wed, 02 May 2018 02:09:08 +0200 Manolinux wrote:
> #1 0x7f7cd8902231 in __GI_abort () at abort.c:79
> #2 0x5642194aaa5a in OsAbort ()
> #3 0x5642194b0573 in ?? ()
> #4 0x5642194b1395 in FatalError ()
> #5
Hello Philip,
probably your case is more an example for the problem described in bugs
#770130 and #776911.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770130
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776911
When you rebuilt your mesa packages did you apply the patch
33 matches
Mail list logo