On Tue, 13 Dec 2022 01:28:39 +0100 =?UTF-8?Q?Bernhard_=c3=9cbelacker?=
wrote:
Dear Maintainer,
I experienced since about a month ago sometimes crashes in applications
running in fullscreen, when doing display configuration changes
or lately when waking up the screen from power saving.
(See
Package: plasma-workspace
Version: 4:5.26.4.1-1
Severity: normal
X-Debbugs-Cc: bernha...@mailbox.org
Dear Maintainer,
I noticed since a week or so a change in behaviour of a plasma desktop.
If i install in a minimal VM the package task-kde-desktop after logging
into the desktop no wallpaper is
Am 18.12.22 um 16:58 schrieb Simon McVittie:
I was unable to reproduce this in a test VM, ...
..., but it is reproducible
on my laptop. Perhaps it's only reproducible if mutter has access to
some resource that my ssh login session to my test VM lacks, or perhaps
there's a race condition that
On Sat, 03 Dec 2022 20:40:57 +0200 Boris Shtrasman
wrote:
Package: nheko
Version: 0.8.0+really0.7.2-4
[2022-12-03 20:22:56.203] [net] [info] Autodiscovery: No .well-known.
terminate called after throwing an instance of 'std::invalid_argument'
what(): v1.1: invalid version
Aborted
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
Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=463052
Dear Maintainer,
I tried to have a look if I can find some more information,
and opened an issue upstream here:
https://bugs.kde.org/show_bug.cgi?id=463052
It looks like a double free because a pointer is hold in two lists.
Am 12.12.22 um 15:01 schrieb Dirk Eddelbuettel:
Ok, so including sys/types and not defining off_t locally looks very
promising -- this is likely something I bungled in that change to accomodate
gcc 10. It possibly was present before already, maybe 'team dieharder' never
knew about off_t being
Hello,
that will still not be enough for further investigation,
but the given byte sequence in conjunction the package from
snapshot.d.o including the dbgsym package points to this location:
0x...cfb in QThreadStorageData::get() const at thread/qthreadstorage.cpp:122
@piorunz: a first step
Package: libqt5core5a
Version: 5.15.6+dfsg-2
Severity: wishlist
X-Debbugs-Cc: bernha...@mailbox.org
Dear Maintainer,
I experienced since about a month ago sometimes crashes in applications
running in fullscreen, when doing display configuration changes
or lately when waking up the screen from
Hello Patrik,
I just tried to collect some information and reconstruct
the given backtrace with some line information [1].
This gimp_text_tool_move_cursor leads to this upstream
bug reports [2]. Unfortunately all closed without result.
There are a few more upstream reports with g_utf8_get_char
Am 12.12.22 um 00:39 schrieb Dirk Eddelbuettel:
On 11 December 2022 at 17:05, Bernhard Übelacker wrote:
| On Mon, 24 Oct 2022 12:22:13 -0500 Dirk Eddelbuettel wrote:
| > |diehard_birthdays| 0| 100| 100|0.99449351| PASSED
| > | ###CUT OUT BY ME###
| > |
just for convenience:
https://github.com/eddelbuettel/rdieharder/issues/3
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
On Mon, 24 Oct 2022 12:22:13 -0500 Dirk Eddelbuettel wrote:
|diehard_birthdays| 0| 100| 100|0.99449351| PASSED
| ###CUT OUT BY ME###
| sts_runs| 2|10| 100|0.93620636| PASSED
| ###AND THEN MANY EMPTY LINES APPEARING EVERY ~30 SEC###
Darn. Would you
The software outputs: "No access to printer device file".
Normal user should be added to lp group to make `mtink` work
and it has been added to it indeed, so it is in the /etc/group file
beside the `lp` and `lpadmin` groups, yet the software seems
to be unable to access device file from the
Am 10.12.22 um 22:58 schrieb Hilmar Preuße:
Am 10.12.2022 um 18:16 teilte Bernhard Übelacker mit:
Hi,
I have seen other packages that added a dependency
to package sse2-support in such cases.
That would not solve the issue, but would make it
visible at installation time for the user,
if I
Hello Hilmar,
I have seen other packages that added a dependency
to package sse2-support in such cases.
That would not solve the issue, but would make it
visible at installation time for the user,
if I understand it right.
Kind regards,
Bernhard
Hello Graeme Vetterlein,
I have reassigned the bug to package libwnck-3-0.
Just later I saw that there was already a release:
Changes:
libwnck3 (43.0-3) unstable; urgency=medium
.
* Backport four upstream commits to fix Xfce X2Go sessions.
(Closes: #1021685, #1025174)
Is your issue
Dear Maintainer, hello Nicolas,
tried to collect some more information from the two
given kernel lines [1].
I could find given the byte sequence in a similar two-GPU-equipped
laptop attaching to a runnig "optirun glxgears".
The "libGL.so.1" is the one from package primus-libs.
There it leads to
Dear Maintainer,
this SIGSEGV and also the valgrind "invalid read"
below ledger::journal_t::clear_xdata can also be
seen in a Debian 11 Bullseye VM.
Because valgrind points already to a use-after-free,
and the output "Done." is printed,
might the issue here be, that python does destruct the
Hello Nicolas,
the given backtrace points to below source locations.
Does starting gkrellm from a terminal maybe give some more output?
Module /home/nicolas/.gkrellm2/plugins/gkrellflynn.so without build-id.
Module /home/nicolas/.gkrellm2/plugins/gkrellflynn.so
Maybe you could also
Dear Gunnar,
I tried to collect some more information for the Maintainer.
First I need to create a .irbrc with the USE_SINGLELINE
set to true, to reach any function in libedit/readline.
Next I tried to reach the address given in _IO_new_file_overflow,
but was not able to. This might be related
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
Hello,
I tried to collect some informations.
The segfault happens because "workspace" contains a null pointer.
This null originates from "window->workspace".
Kind regards,
Bernhard
Core was generated by
`/usr/libexec/installed-tests/mutter-11/mutter-test-runner --all'.
Program terminated
Am 03.12.22 um 23:38 schrieb Bernhard Übelacker:
I thought if strace can observe the process in question, would gdb also
be able. And found starting nspawn with gdbserver, 'set follow-fork-mode
child'
and gdb from inside the container via plain chroot seems working well.
So it looks like
(Resent after subscription, as non-subscribers get rejected.)
Hello,
I opened the initial Debian bug report, but did took the time to
ask at systemd-devel and found this thread was already asked,
so I am trying to provide further information.
> Do you have any MACs in effect?
No SELinux or
Hello,
I opened the initial Debian bug report, but did took the time to
ask at systemd-devel and found this thread was already asked,
so I am trying to provide further information.
> Do you have any MACs in effect?
No SELinux or Apparmor active
As far as I see in my test VM with minimal
Dear Maintainer,
I tried to investigate a little further and think
I have found some details.
When starting inkscape from a terminal and opening the
given PDF shows a "double free" message.
A valgrind run [2] shows the causing lines at a first glance.
On a second look [3] it might be related
Dear Maintainer,
I tried to get some more information from the dmesg lines.
It leads to the function "boxes_libvirt_broker_real_add_source_co",
which is also written in the critical message before
and unfortunately line numbers are for the generated c files from vala sources.
There are several
Hello Kayim,
I am not involved in packaging or development of nftables or firewalld,
just trying to help debugging random crashes in Debian.
And want just to mention a maybe possible way of debugging this.
As this is a kind of rare issue and when the core is produced it is
hard to find the place
Hello Everyone,
I guess I see a similar same issue here.
First, for me works as a workaround if I click the slider somewhere
in the middle of the video and do pause it, then close vlc completely.
The next attempt to start the video with vlc works for me.
(Like after a reboot the very first video
Dear Maintainer,
it seems less a crash, instead it fails to find the
right drivers to use, therefore exits.
Looking at the Xorg.0.log from a bullseye netinst it looks
like it uses the /usr/lib/xorg/modules/drivers/modesetting_drv.so
driver inside a virtio equipped qemu VM,
which seems missing in
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
Dear Maintainer,
I could reproduce a crash inside a
minimal Bookworm/testing amd64 qemu VM.
There I took below backtrace [2].
Having msg_data->repl_buff equal NULL seems to be the issue.
Upstream commit [1] looks related and a package built
with this commit does not crash with the example
Dear Maintainer,
following is what I was able to extract from the dmesg lines
and the dbgsym packages.
It looks like it crashes in cmsSetHeaderRenderingIntent because
it was given a NULL pointer in parameter hProfile.
That's still not much information, but for this function name
an upstream bug
Just a short addition:
There is already an upstream bug reported:
https://github.com/csound/csound/issues/1651
Kind regards,
Bernhard
Dear Maintainer,
this looks like caused by a disaggrement about the size of type OPARMS.
In libcsound64-6.0 it has 264 bytes, but in csound-plugins
only 260 bytes.
This difference is caused by the last member "mp3_mode", that is missing
in the OPARMS type used in csound-plugins.
It got
plasma panel sometimes hangs, becomes irresponsive. this is preceded by
some notification appearing in the notification area, that becomes stuck
in the corner of the windows and cannot be dismissed. at the same time
all the panel becomes irresponsive to mouse clicks.
my only workaround is
Hello Shengjing Zhu,
I tried to collect some more information for the maintainer,
by running peek in a minimal VM.
There I got the same error message "default: No such process".
After a search I received this information [1] where it is proposed
to install pulseaudio.
And indeed the parameter
Dear Maintainer,
the original staden-io-lib seems to be built with
libhtscodecs2 in version 1.2.2-1 [1].
The rebuild seems to be using libhtscodecs2 in version 1.3.0-4.
Unfortunately htscodecs upstream integrated this commit [3],
which renamed e.g. function encode_names to tok3_encode_names.
It
Control: reassign -1 src:linux
On Fri, 21 Oct 2022 21:40:23 +1000 Rod Webster wrote:
Package: PREEMPT_RT
Version: 5.10 to 6.0
I hope it is right to reassign to src:linux because it looks
like there is no package PREEMPT_RT.
Kind regards,
Bernhard
Dear Maintainer,
I tried to collect some more information about this issue.
With the help of rr-debugger I reached this function,
which "returns" a pointer to a static variable buf:
(rr) bt
#0 0x563a2b2373b6 in menuSize (options=, mode=, width=0x7ffdd199be38,
Dear Maintainer,
in the meantime there got a merge request [1] accepted to libz3-4,
which might solve this issue by avoiding sse2 instructions,
and is still awaiting an upload to unstable.
[1] https://salsa.debian.org/pkg-llvm-team/z3/-/merge_requests/9
Kind regards,
Bernhard
On Wed, 5 Oct 2022 18:24:54 + Md Adil wrote:
Package: GIMP
Version: 2.10.32
I am Using Windows 10
Build: org.gimp.GIMP_official rev 1 for windows
# C compiler #
Using built-in specs.
COLLECT_GCC=W:\msys64-gtk2\mingw32\bin\gcc.exe
Hello Karo, hello Dill,
I tried to carry this issue to the llvm people, if it
might be possible to drop libz3 linking of libllvm at i386.
This should mitigate most visible issues,
but I am not sure what the downsides would be.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021926
Kind
Package: clang-14
Version: 1:14.0.6-2
Severity: normal
X-Debbugs-Cc: bernha...@mailbox.org
Dear Maintainer,
clang-14 is currently not able to run at a pre-SSE2 cpu.
This is because clang-14 links to libLLVM-14.so.1 which links to libz3.so.4.
Unfortunately libz3-4 is currently compiled with
Wow, what a splendid debugging! I hope you enjoyed it.
Thanks, yes, it was some interesting debugging,
and I was quite surprised when I saw the issue caused
by the very same instruction as the other bug ...
By the way with following sequence it should be possible
to see the impact on the FPU
Hello Karo, dear Maintainer,
I undusted my own "AMD Athlon(tm)" machine and got a current bookworm/testing
on it.
And could reproduce the assert shown in seat0-greeter.log.
It took some time, but I guess I found now the chain of events
that lead to lightdm-gtk-greeter not starting up.
At [1]
Am 10.10.22 um 17:21 schrieb karogyoker999:
Hello,
MR has been opened to "fix" this issue:
https://salsa.debian.org/pkg-llvm-team/z3/-/merge_requests/6
Eliminating SSE2 from z3 upstream is not feasible:
https://github.com/Z3Prover/z3/issues/6369#issuecomment-1259419466
The dependency chain I
If I move out those 3 .dri files from /usr/lib/i386-linux-gnu/dri -
what you have mentioned in the other bug report - would that make it
work? Did that fix the issue for you? GPU acceleration is not
available for me as the firmware cannot be loaded for the GPU and the
whole system relies on
Hello,
this might be solved by [1].
As far as I see the dependency chain goes through
education-desktop-other to chromium, which depended to
sse3-support.
It might have started with 7df9e46cc a few month ago and ended with 98718255f,
unfortunately it does not mention a specific bug.
Kind
Hello,
it looks like following line should expect the Get() call returning a nullptr,
which wxWidget documentation explicitly notes.
2079
wxTranslations::Get()->SetLanguage(wxLANGUAGE_DEFAULT);
I have raised this question to upstream here:
Dear Maintainer,
I tried to have a look and found unfortunately the dbgsym package
not containing useful files.
This seems related to CMAKE_CXX_FLAGS getting reset,
therefore loosing Qt related flags.
Before the application crashed already when trying to open
one leaf in the tree view, with the
Package: libhttrack-dev
Version: 3.49.2-1.1+b1
Severity: wishlist
X-Debbugs-Cc: bernha...@mailbox.org
Dear Maintainer,
currently the header htsglobal.h generates many warnings in
build of depending package httraqt.
/usr/include/httrack/htsglobal.h:211:28: warning: invalid suffix on literal;
Dear Maintainer,
Sep 23 09:58:10 leopard gnome-software[3304]: FIXME: Unknown progress handling
is not yet implemented for GsProgressButton
Sep 23 09:58:11 leopard fwupd[3397]: 06:58:11:0428 FuCommon
fu_common_read_uint16_safe: assertion 'buf != NULL' failed
Sep 23 09:58:11 leopard kernel:
> ... But what is this 2.0.8-2+b1 version?
> I can't find anything about what is this +b1, what are the changes?
Hello,
just a short addition to your question.
The +b1 version is just a rebuild against the current packages in
unstable, e.g. by some library transition.
The source package
Hello,
I tried to install just lightdm and openbox inside a minimal testing VM.
It was started by even "older" "qemu-system-i386 -enable-kvm -cpu pentium-v1".
Unfortunately I just hit bug #1020802.
When having those X drivers not being tried to load,
then login works to the openbox DE.
Can you
Dear Maintainer,
tried to have a look at another bug report, but found X not starting up.
I could reproduce this inside a qemu VM started with:
qemu-system-i386 -enable-kvm -cpu pentium-v1 ...
So due to the current documentation [1] it looks like plain Pentium will
not be supported in
Hello piorunz,
I tried to get some more information from your dmesg line and think
the crash takes place in function udisks_drive_ata_get_smart_enabled.
I could not find any crashes related to this function in udisks2
upstream bug tracker, but gnome-disks upstream tracker
contains [56], that
linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0x7f8d79e790]
/lib/aarch64-linux-gnu/libgobject-2.0.so.0(+0x27a18)[0x7f8c605a18]
/lib/aarch64-linux-gnu/libgobject-2.0.so.0(+0x1cd64)[0x7f8c5fad64]
/lib/aarch64-linux-gnu/libgobject-2.0.so.0(+0x1d594)[0x7f8c5fb594]
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,
this issue seems already be handled in bug #1019158,
and be caused by an unexpected ABI change in graphicsmagick.
This should already be fixed by graphicsmagick 1.4+really1.3.38+hg16739-1
in unstable. Unfortunately it did not yet migrate to testing
because of a test failure on mips64el.
Hello Tim,
I tried to have a look at those two dmesg lines and it seems
they point to the function print_arp_asset_screen, line 115 [1],
where parameter rec is dereferenced unconditionally.
However, if it would be possible to install systemd-coredump then
a backtrace of those crashes should be
/lib/x86_64-linux-gnu/libc.so.6(+0x3daf0)[0x7f73b843daf0]
/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x25103)[0x7f73b8995103]
/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x1b6d8)[0x7f73b898b6d8]
/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x1bf5a)[0x7f73b898bf5a]
Gimp crashes, when a text element is modified:
- open gimp, create new image
- create text element
- select some characters inside this text element
- change the font size
--> gimp crashes
Console errors:
gimp: fatal error: Speicherzugriffsfehler
(script-fu:16693): LibGimpBase-WARNING
#6 0x7f289e850af0 in () at
/lib/x86_64-linux-gnu/libc.so.6
#7 0x7f289ec56103 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#8 0x7f289ec4c6d8 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#9 0x7f289ec4cf5a in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#10
/lib/x86_64-linux-gnu/libc.so.6(+0x3daf0)[0x7ff46383daf0]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x25103)[0x7ff463d09103]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x1b6d8)[0x7ff463cff6d8]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x1bf5a)[0x7ff463cfff5a]
#6 0x7faef481caa0 in () at
/lib/x86_64-linux-gnu/libc.so.6
#7 0x7faef4c1c103 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#8 0x7faef4c126d8 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#9 0x7faef4c12f5a in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#10
/lib/x86_64-linux-gnu/libc.so.6(+0x3daf0)[0x7f9963443af0]
/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x25103)[0x7f996383d103]
/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x1b6d8)[0x7f99638336d8]
/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x1bf5a)[0x7f9963833f5a]
/lib/x86_64-linux-gnu/libc.so.6(+0x3daf0)[0x7f650123daf0]
/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x25103)[0x7f650178c103]
/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x1b6d8)[0x7f65017826d8]
/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x1bf5a)[0x7f6501782f5a]
#6 0x7fdea6e3daf0 in () at
/lib/x86_64-linux-gnu/libc.so.6
#7 0x7fdea736d103 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#8 0x7fdea73636d8 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#9 0x7fdea7363f5a in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#10
#6
#7 0x7fc0a0c3c103 in ?? () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#8 0x7fc0a0c326d8 in ?? () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#9 0x7fc0a0c32f5a in ?? () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#10 0x7fc0a0c343f4 in
Sep 09 08:31:01 seraph kernel: ssh-pkcs11-help[377564]: segfault at
7ffd01d23d90 ip 7f254d06b037 sp 7ffd01d23d90 error 6 in
libc.so.6[7f254d028000+16e000]
Hello Julien,
probably you could install systemd-coredump.
Then the journal should contain a backtrace where the process would
my pho e
Sent from my iPhone
On 24-Sep-2022, at 03:21, Aurelien Jarno wrote:
Hi,
On 2022-09-23 21:28, Bernhard Übelacker wrote:
On Fri, 23 Sep 2022 14:45:07 +0530 Vasudev Kamath wrote:
Package: libc6
Version: 2.34-8
I upgraded libc6 to latest released 2.35-1
Module ld
On Fri, 09 Sep 2022 11:25:50 + Christian Buhtz wrote:
installed "kde-config-cron" without having a full KDE desktop environment
enabled. I am using XFCE here but would like to have cron gui front-end.
After installation I can not find a binary for "kde-config-cron".
It seems to me that
On Fri, 23 Sep 2022 14:45:07 +0530 Vasudev Kamath wrote:
Package: libc6
Version: 2.34-8
I upgraded libc6 to latest released 2.35-1
Module ld-linux-x86-64.so.2 with build-id
a03c3b14d371da908a3f22007b3f0c73d1f9f634
Module libc.so.6 with build-id
Hello Christoph, hello tony,
#12 0x5586f25c0438 tucnak_crash (tucnak + 0xb0438)
#13 0x7febdc3589d4 z_sig_segv (libzia-4.36.so + 0x169d4)
#14 0x7febdaa3daf0 __restore_rt (libc.so.6 + 0x3daf0)
#15 0x7febd5ead5ee n/a
Hello Jan,
Am 20.09.22 um 10:24 schrieb Jan Korbel:
1.
(gdb) bt
#0 __kernel_vsyscall ()
at
/build/linux-q1ABpl/linux-5.10.136/arch/x86/entry/vdso/vdso32/system_call.S:72
#1 0xf7695333 in fstab_init (opt_rewind=0) at fstab.c:121
2.
(gdb) bt
#0 __kernel_vsyscall ()
at
Dear Maintainer,
I guess this crash might be a stack exhaustion.
Given the function treescan in dirs.c would allocate
for locname 4096 bytes, and this function is called recursively,
we would fill up a stack of 8MB, which 'ulimit -s' shows at
my system as default.
Therefore another workaround
Dear Maintainer,
I could reproduce this inside a minimal qemu VM.
Below [1] is a backtrace one instruction before the crash.
It looks like this "font" object has the create_hb_font
function pointer never initialized.
It also crashes with LANG=C set.
Unfortunately to me it is not certain if this
Hello Bob,
On Wed, 20 Oct 2021 15:33:47 +0800 Bob Wong wrote:
Hello, I am unable to downgrade the kdecoration, if I try to downgrade
kdecoration, the apt will remove the whole kde desktop. So the only choice
for me is to upgrade. When will the new version of the kdecoration be
available in
Control: merge -1 996859
Hello Achim,
I hope it is ok to try to merge those two bugs #996859 and #996860,
BTS takes some time to confirm creating a bug ...
Have you updated lately libkdecorations2-5v5 to 4:5.23.0-2 ?
Then you probably hit this bug #996726,
where a workaround is described by
Hello Francisco, hello Albert,
this might be the same as in bug #996726
and not directly related to the nvidia driver.
I hit a crash in kwin_x11 with an AMD graphics card
and could workaround by installing
libkdecorations2-5v5_5.21.5-2_amd64.deb like
mentioned in #996726.
Kind regards,
Bernhard
Hello Patrick,
I guess this is the same as described in bug #996726.
And I was able to workaround by installing
libkdecorations2-5v5_5.21.5-2_amd64.deb.
Kind regards,
Bernhard
Core was generated by `/usr/bin/kwin_x11 --replace'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0
On Tue, 28 Sep 2021 15:01:22 +0200 uninsubria.it
wrote:
example from 'dmesg' output:
[Tue Sep 28 11:05:22 2021] omshell[4604]: segfault at 0 ip 55623cdd06dc sp
7ffd5a2c7c78 error 4 in omshell[55623cd97000+45000]
Hello,
maybe you can add a few pairs of the
dmesg "segfault" and
Hello John,
this backtrace has strong similarities to that one
in bug #914249.
There I asked the submitter for the output when gimp is
started from the terminal, if the issue is reproducible,
but received no answer.
It would also good to know which steps were
taken to receive this crash.
But
Control: fixed -1 1.3.4.20200120-1
Dear Maintainer,
I just wondered why this bug not gets archived.
Due to [1], it is fixed in unstable and testing,
is installed for all architectures [2],
and is not release-critical.
So I guess it might be the version that existed
just in experimental,
Am 21.09.21 um 18:36 schrieb Florence Birée:
Hi,
I applied the patch and try it on hplip 3.21.6+dfsg0-1.
No more stack smashing. But at a random point during the scan,
simple-scan stop and display a message : « Failed to scan - Error
communicating with scanner ».
Nothing in the terminal nor in
regards,
Bernhard
Description: Resize buffer and try not to overrun it
Author: Bernhard Übelacker
Bug-Debian: https://bugs.debian.org/992721
Forwarded: no
Last-Update: 2021-09-20
Index: hplip-3.21.6+dfsg0/scan/sane/bb_ledm.c
.
Kind regards,
Bernhard
Description: Replace my_setjmp by original setjmp
Author: Bernhard Übelacker
Bug-Debian: https://bugs.debian.org/992871
Forwarded: no
Last-Update: 2021-09-18
Index: darkplaces-0~20180908~beta1/image_png.c
Dear Maintainer,
I tried to have a look and received the backtrace below [3].
As far as I see is 4.8.27 in current testing not affected.
And a 'git bisect' led to the upstream commit [1], which
is tracked in upstream bug [2].
A package 4.8.26 built with this commit is also
working as expected
Dear Maintainer,
this might be the same as reported
in #993293 against the xsane package.
Kind regards,
Bernhard
https://bugs.debian.org/993293
Am 16.09.21 um 00:29 schrieb Bernhard Übelacker:
exceeds what
is with these 7 places possible (would be 268 MB ?)
Short correction:
6 bytes for the hex number and 1 byte termination.
Would just give something around 16 MB as a maximum?
Kind regards,
Bernhard
Hello Florence, dear Maintainer,
Stack trace of thread 113079:
#0 0x7f858b12ae71 raise
(libc.so.6 + 0x3ce71)
Dear Maintainer, hello Mihai,
I tried to reconstruct the source line information of the top frames,
how they should look like if the packages
libgtk-3-0-dbgsym libglib2.0-0-dbgsym would have been installed.
#0 0x7fec909d1ce1 in __libc_signal_restore_set at
Hello Florence,
there might be still something that could be done
to retrieve some more information (if you have still
the versions installed that show the issue).
The easiest first thing might be to install the package
systemd-coredump, if possible.
Then open in another terminal 'journalctl
Hello Bjørn, hello Sudip,
I just tried to locate the line where the crash happens from
the dmesg output and got to this location [1].
Unfortunately the CVS tree seems not up to date or I was using the wrong one.
At least there was a change in geoip.c in line 166 [2] [3].
Kind regards,
Bernhard
0x563cebe97881 in svr4_exec_displacement (displacementp=) at /build/gdb-Nav6Es/gdb-10.1/gdb/solib-svr4.c:2577
#8 svr4_relocate_main_executable () at
/build/gdb-Nav6Es/gdb-10.1/gdb/solib-svr4.c:2960
...
Description: Add auxiliary vector to vgcore files
This enables gdb to get reloca
Looking a little further, it looks like gdb does "just" not
know where the executable was mapped in memory, therefore it
gets mapped to 0x0 instead of 0x108000 in my example below.
Debugging such a "pie vgcore" file would be possible
if the debug symbols are loaded manually to the "right"
Dear Maintainer,
I tried to find out when this started to happen.
And I found this issue in releases 11-bullseye, 10-buster and 9-stretch.
In 8-jessie such a vgcore shows in gdb the correct line information.
Further looking brought me to stretch/testing as of 29.10.2016,
where the issue starts
101 - 200 of 1271 matches
Mail list logo
