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;
C+
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: fwup
> ... 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 getting
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 s
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 bookworm
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 migh
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]
/lib/aarch64-linux-gnu/libgobject-2.0.so
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 pac
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.
h
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 pr
/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]
/lib/x86_64-linux-gnu/libgobject-
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]
/usr/lib/x86_64-linux
#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/libgobject-
/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]
/lib/x86_64-linux-gnu/libgobject-
#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 g_object_new_with_propertie
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 s
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
ef3afb43092
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 (c
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
/build/l
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 mi
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 i
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 book
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 dow
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 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 "cod
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 thi
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, therefore
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 (s
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
../sysdeps/unix/sysv/linux/intern
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 -f'
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" address
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 t
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 /etc/defaul
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] https://github.com/gwsw/less/commit/520
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 ge
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 mess
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 the
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 gho
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 happe
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 li
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 000
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 arm5tel
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 --new
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 rece
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 r
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 in
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
+++ tuxmath-2.
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 [2]
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 gint6
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 maintiner
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 backtr
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 detail
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 mayb
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
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 schrie
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 locat
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 lib
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 l
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 alloc
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,
Bernhar
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 manual
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 cont
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 used
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, w
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
o
201 - 300 of 1319 matches
Mail list logo
