Hello,
tries to find a way to underclock the gpu of an HP elitebook 8460p
with a radeon HD 6470M, because it does not handle well the 3d
requirements of a current plasma desktop and leads to the laptop
turning just off. (Turning off the compositor as a workaround.)
So "rovclock -i" leads on that s
Package: kodi-bin-dbgsym
Version: 2:18.6+dfsg1-1
Severity: normal
Dear Maintainer,
I attempted to add line information to bug 954782.
Unfortunately I found that kodi-bin-dbgsym does not contain
the debug information for the kodi-x11 binary.
It does just contain debug information for
kodi-xrandr
Hello Michael,
that is great news, just two points I want to mention:
If you want to forward information to certain people,
please send email to both, the bugs address and the person,
e.g. use "reply all" in your mail client.
And if you get e.g. "/lib/libdislocker.so.0.7" in your backtrace
instea
> #6 0x5614726b3f04 in gimp_param_spec_layer_id ()
> #7 0x5614725cea67 in gimp_pdb_compat_param_spec ()
> #8 0x5614725db487 in gimp_plug_in_handle_message ()
Hello Andre,
I think this is the same thing as #953880, #953854, #953794. Please
upgrade the gimp package to version 2.10.14-
Dear Maintainer,
I tried to collect some more information and might have found something.
The allocator aborts at the backtrace below.
A valgrind run points to the same function txt_add_fragment.
There is seems that in line 2121 the allocation takes place with
12 bytes total, then a memset is do
Dear Maintainer,
I tried to start looking at the given backtrace, but could
not find the winbind-dbgsym packages for 2:4.9.5+dfsg-5+deb10u1
like they are availabe for 2:4.9.5+dfsg-5.
At least apt did not find it in buster-proposed-updates-debug
and at snapshot.debian.org they are also not listed.
I
Hello Michael,
I am not involved in packaging dislocker but might have some points.
This "error 14" should mean it cannot read from memory the next
instruction to execute. This makes sense as the "ip" or "RIP" has
a value of 0xbb6 which is unlikely to contain program code.
If it is possible to in
Hello Gulfstream,
> Thanks for your reply! My next question is How to connect the xrdp server
> using remmina client? I don't find where to set the glyph cache.
in the previous mentioned upstream link to the remmina bug
tracker in comment [1] is written that they added such flags,
but I guess t
Hello,
this seems to be caused by xrdp using glyph cache even
when the client does not advertise it.
Additionally freerdp does now stricter checks.
Upstream bugs are here [1].
A workaround could be to use xfreerdp like this:
xfreerdp +glyph-cache /relax-order-checks /v:hostname
Kind regards
Hello,
I just tried to get some more information from the
second dmesg line the submitter added.
I think it crashed inside function getmissingattr because
tupleDesc->constr contains an invalid pointer e.g. -1
Maybe this is of any help, but still a proper
backtrace or core would be better.
Kind r
Hello,
tried to collect some more details.
Found that the failure started with the migration
of these packages into testing:
libvte-2.91-0 libvte-2.91-common (0.60.0-2)
The monitor worked before with 0.58.3-1.
Kind regards,
Bernhard
# Bullseye/testing amd64 qemu VM 2020-03-20
apt update
apt
Hello Till,
I am not the initial reporter of the issue and I cannot reproduce it,
therefore cannot test the suggested change.
Just tried to share my results.
Kind regards,
Bernhard
Hello,
the stack trace should look like this with line numbers, if it helps:
0x7...671 in __strlen_avx2 at
../sysdeps/x86_64/multiarch/strlen-avx2.S:65
0x7...2f4 in _cups_strlcpy at string.c:739
0x5...a31 in main at rastertopwg.c:274
0x7...e09 in __libc_start_main
Hello Valentin,
this looks similar to bug #953794, #953854 or #953880.
Kind regards,
Bernhard
Hello,
I tried to locate the source line of the address shown
in the /var/log/messages output.
But that failed but I found in the strace output that
it loads for some reason two libapt-pkg.so files ...
...
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libapt-pkg.so.6.0",
O_RDONLY|O_CLOEXEC) = 3
Package: cups
Version: 2.2.10-6+deb10u2
Severity: normal
Dear Maintainer,
I found today some suspicious segfault line in dmesg output and
could reproduce it every time I loaded the finished jobs of a printer
with this URL:
http://localhost:631/printers/Samsung_CLX-3180_Series?which_jobs=co
Dear Maintainer,
I tried to debug this issue.
(gdb) bt
#0 tidy_path (path=0x55f0c81ea140 "/../") at symlinks.c:96
#1 0x55f0c7fe6908 in fix_symlink (my_dev=2049, path=0x55f0c81ec1e0
"/tmp/tmp.tlVVwIgOZQ/mylink") at symlinks.c:185
#2 0x55f0c7fe6e81 in dirwalk (pathlen=,
Hello Tomas,
Am 16.02.20 um 17:30 schrieb Tomas Janousek:
> So unless that palloc tries to allocate way more memory than it should,
> I don't think that's the problem.
Unfortunately that allocation seems just "sizeof(pr_response_t)",
so I guess it is not an unusual big allocation.
Kind regards,
Dear Maintainer,
I just tried to reconstruct the line informations from a
running process with an attached gdb and installed dbgsym package.
0x7f373b3ad458 in __memset_sse2_unaligned at
../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:120
0x55d7e2f68a64 in pcalloc at pool.c:620
Dear Maintainer,
I tried to collect some more information and got
the following backtrace with the restore command
from the submitter.
It looks like "expr->ops" contains a null pointer
that gets dereferenced.
Unfortunately I still see the same crash after
upgrading to the versions in backports in
Hello Thorsten,
Am 06.02.20 um 19:19 schrieb Thorsten Glaser:
> On Thu, 6 Feb 2020, Bernhard Übelacker wrote:
>
>> Hello Thorsten,
>> getting the source of such an address is possible, even with ASLR,
>> if the library versions are known and dbgsyms are available,
Hello Sarah,
I am sorry, but the given information might not be enough
for the maintainers to solve the crash.
Usually when a segfault happens in 'dmesg' output should
appear two lines about this event. Maybe you could forward
these to the report too.
If it is possible to install systemd-coredump
Hello Thorsten,
getting the source of such an address is possible, even with ASLR,
if the library versions are known and dbgsyms are available,
like in attached file.
It looks like a null pointer is given to strncasecmp_l.
But you are right, this information might still not be very useful,
becaus
Hello Jonas,
thanks for taking time for this bug.
Am 05.02.20 um 11:02 schrieb Jonas Smedegaard:
> Hi Alexander,
>
> Quoting Alexander Reichle-Schmehl (2020-02-05 08:45:05)
>> Am 2020-02-04 22:09, schrieb Jonas Smedegaard:
>>
>>> Most notable change between 9.22 and 9.24 - and also applied to
>
Control: fixed -1 9.26a~dfsg-0+deb9u6
Control: fixed -1 9.26a~dfsg-0+deb9u1
Control: fixed -1 9.25~dfsg-0+deb9u1
Control: found -1 9.27~dfsg-3.1
Control: found -1 9.27~dfsg-3
Control: found -1 9.26a~dfsg-2
Control: found -1 9.26a~dfsg-1
Control: found -1 9.26~dfsg-2
Control: found -1 9.26~dfsg-1
Co
Control: reassign -1 libc6 2.29-9
Control: affects -1 bash
Dear Maintainer,
reassigning to get hold of libc6 maintainer about the issue
of incompatible tunables indices between libc6 versions.
Therefore applications could crash when libc is from
previous package version, then a package update ge
Hello Jan,
please leave the bugs email in the recipients or cc list to
have all information attached to the bug e.g. by using "reply all".
Nice to hear it works.
You can close a bug by just changing the email recipient from
'950...@bugs.debian.org' to '950537-d...@bugs.debian.org'.
Kind regards,
Hello Jan,
your issue might originate not from the terminal but from su itself.
This might be an interesting read:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904988#20
But in short, is instead of 'su' using 'su -' working
for you like expected?
Kind regards,
Bernhard
Dear Maintainer,
I found this upstream bug report [1].
The SIGILL causing instruction seems to consist
just of four zeros. [2]
The instruction before is [3].
Version 68.4.2esr-1 in unstable does not show this crash.
Kind regards,
Bernhard
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=16095
Hello Birger Schacht,
I tried to get some more information from this issue.
To be sure where your tilix aborts you would need to
install gdb and at least tilix-dbgsym [1] and
run it this way:
gdb -q -ex 'set pagination off' -ex run -ex bt -ex detach -ex quit --args
tilix
Then I guess you se
Hello Md Ayquassar,
Am 31.01.20 um 02:23 schrieb Md Ayquassar:
> Second, is a reassignment to some Mesa package required?
I guess mesa maintainer would have more insight if
that function pointer is allowed to be NULL, there
possibly yes.
I wonder if the content of /var/log/Xorg.0.log* would
re
Hello Md Ayquassar,
sorry, I did not recognize that you
seem to have a usrmerge'd system.
Then I get following backtraces from your
core dump, with and without debug symbols.
It looks like a function pointer gets called
unconditionally, while containing NULL.
Seems to be graphics driver related.
Control: found -1 plasma-workspace/4:5.14.5.1-5
Dear Maintainer,
I found today another device affected by this issue.
It got switched a few days ago from stable to current testing.
It shows the same 30 second splash screen.
A package build with the given patch did show the
splash just 14 seconds
Package: grub-common
Version: 2.04-5
Severity: wishlist
Dear Maintainer,
I noticed some moths ago a delay between Grub gets
started ("Welcome to GRUB!") and Grub shows the menu.
I switched a few days ago from stable to Bullseye/testing
at this device and tried to find out where this 23 seconds
de
Dear Maintainer,
today I received this stack smashing also in one of my VMs.
I could reproduce the isse when ever a bash is started
while 2.29-7 got started and left open.
Then in a different shell the packages get upgraded,
especially glibc packages to version 2.29-9.
Then get back to the open
Control: reassign -1 zynaddsubfx-dssi 3.0.3-1
Control: affects -1 + audacity
Hello Tjeerd,
> Thanks for coming back, I'm not in a hurry...
>
> The problem is that I can not trigger specific bugs (they seem to happen
> somewhat random). So a made some more valgrinds: valgrind.dat
Because the e
Hello Tjeerd,
sorry for the delay.
I would have expected more output from catchsegv.
I guess the first valgrind run would have been better
placed in an attachement too.
The file audacity_coredumps.log points to
libzynaddsubfx_dssi.so that belongs to package zynaddsubfx-dssi.
That seems to be invo
Hello Paul,
> That was my first thought; as explained in my initial bug report:
>>> If run from the terminal there is no printed output of any kind.
Sorry I missed that one.
>> Otherwise maybe it is related to the used desktop environment,
>> if xorg or wayland is in use
>
> I'm using xorg and
Dear Maintainer,
crash happened again today when stopping a qemu VM with
the quit command at the qemu prompt.
Found the "refcount_t: underflow" already once at 2020-01-07,
but there the system could continue to run more than a day.
All occourences are with:
[0.00] Linux version 4.19.0-7-a
Dear Maintainer,
a short addition. I got some help that AddressSanitizer
and Valgrind could be squeezed to delay returning previously
free'd addresses from the allocator.
Then both tools point to the mentioned first allocation directly.
Kind regards,
Bernhard
AddressSanitizer: export ASAN_OPTIO
Control: forwarded -1 https://marc.info/?l=linux-kernel&m=157973791626377&w=2
Control: tags -1 + upstream
Hello Salvatore,
thanks for the link.
I tried to get in contact with upstream.
Kind regards,
Bernhard
https://www.spinics.net/lists/kernel/msg3384013.html
https://marc.info/?l=linux-kernel&
Dear Maintainer,
I tried to look into this issue without being involved
in packaging fontforge.
I found it most reproducible when building with
"-fsanitize=address", and then always failing on accessing
the same address. [1]
As far as I see this is what happens:
- Address 0x6048a210 gets ret
Hello Salvatore,
> Can you report the issue directly upstream?
Will do, but I am not sure exactly to where.
I found the MAINTAINERS file and I guess if there
is no "B:" line it has to be reported to the "L:" list ?
Kind regards,
Bernhard
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/
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
Hello Md Ayquassar,
could you please additionally run following and attach the
output to this bug:
reportbug --template gnome-shell
I am asking because trying to open the coredump shows
following warning inside a minimal uptodate Buster/stable
VM, which could point to a incompatibility of some
Hello Bernd,
I could further isolate the cmake failing issue.
It starts failing when the package qtbase5-dev is installed.
This gets installed as build dependency for libgps26.
A workaround would be to temporarily uninstall qtbase5-dev.
Maybe better would be to add following to navit to
allow bui
Hello Bernd,
my navit know-how is also limited, but I remebered I saw this
while having build-deps of navit and libgps installed.
Below are the packages which got installed additionally in
a minimal test VM on top of navit's build-deps.
If there are just build-deps's of navit installed the build r
Control: found -1 0.17.0-1
Dear Maintainer,
I tried to collect some more information and could
reproduce the issue.
I guess the interesting thread is not that with
the main function.
Instead it is that thread with the tox_kill / __GI_abort.
There I think that tox_kill in libtoxcore2 is reached
Sorry, forget the right email.
Forwarded Message
Betreff: Re: Bug#945814: audacity: various segfaults of audacity on startup
Datum: Tue, 14 Jan 2020 11:46:06 +0100
Von: Bernhard Übelacker
An: 945...@bugs.debian.org
Hello Tjeerd,
If this issue still exists on your system, you
Hello Tjeerd,
If this issue still exists on your system, you might try
to rename $HOME/.audacity-data to test if it depends on
some settings stored there.
If it still crashes then you might start it by following
and forward the output:
$ catchsegv audacity
Better would be if you could install
Dear Maintainer, hello Benjamin,
the core seems at least related to the "Too many open files" lines.
Unfortunately I cannot get the whole backtrace (see below).
The crash seems to be the same as already reported in #851498, which
got forwarded to upstream in [1].
I guess in "Gnome - Settings - Pri
Hello Asher, hello Markus,
sorry, I wasn't aware of that patch being applied at Salsa as
there was no more activity in 944431, so I thought it went
through unnoticed.
Sorry for the noise.
Kind regards,
Bernhard
Hello Gulfstream,
On Mon, 17 Jun 2019 11:17:48 +0800 (GMT+08:00) wg...@china.com wrote:
>
> I have install the proprietary nvidia drivers and it runs well.
>
Another user reported the same error and he had installed the nvidia
driver by their installer. He could solve the issue by uninstallin
Dear Maintainer,
I could reproduce using linux-perf-5.2 and it is
also visible in linux-perf-5.4 5.4.8-1,
by just pressing enter.
The crash happens because in line 3172
function hist_browser__selected_entry returns
browser->he_selection, which is at this time a
null pointer.
This null pointer gets
Hello Jean-Luc,
thanks for your information.
Please use the reply-to-all button to have the
information forwarded to the bug report.
Am 08.01.20 um 17:21 schrieb Jean-Luc Lacroix:
> Hallo Bernhard,
>
> My system only has a single GPU (Nvidia GTX 970, see attached config)
> installed on a robust
Hello Paul,
in that case I guess kicad is really trying to leave
the process for some reason.
That reason is maybe written to stdout. Therefore maybe you
can run kicad from a terminal and attach its output.
Probably that could give any hints.
Otherwise maybe it is related to the used desktop envi
Hello Asher,
maybe you want to incorporate the changes given here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944431#31
Unfortunately I was too late there.
Then the call to e.g. SetThreadPriority would not needed to get
commented out, and the "-O0" fix in #944431 could be removed
again,
Dear Maintainer,
I could reproduce this issue.
Upstream fixed this crash with this upstream commit:
https://gitlab.gnome.org/GNOME/gnome-logs/commit/7d0062a4ab36d457b74fe17b8d494570d4a0334b
A package build with this patch applied still crashes,
which got fixed in this upstream commit:
h
Hello luca,
this bug might be related: https://bugs.debian.org/948671
Kind regards,
Bernhard
Hello Горбешко Богдан,
I am not involved in packaging samba but tried to get
some more details.
Currently smblcient fails with that message:
$ smbclient --user=testuser --ip-address=127.0.0.1 //testhost/C testtest
Unable to initialize messaging context
protocol negotiation failed: NT_
Hello Paul,
I am not involved in packaging kicad or wxwidgets,
just trying to collect some more information.
Could you recheck - could it be that this pid 309563
was still running from a previous kicad session and
your hanging kicad was another, newer process?
Because, I guess, the __run_exit_han
Dear Maintainer,
I could reproduce the crash now in an minimal unstable VM with the
given config and the command line from the coredumpctl output.
It seems that the function conf_parse_line is not prepared
for missing quotation marks for the argument in the section head [1].
Therefore, if quotes
Hello Miriam,
thanks for the backtraces, just the one from "coredumctl gdb" is enough.
Have you by any chance a file "/etc/nfsmount.conf" at this system?
If there are no secrets inside, could you attach that too?
Kind regards,
Bernhard
Hello Vincent,
I tried to find some more details about this issue.
In the regular case the resulting exe seems to link
to msvcrt.dll!_vsnprintf:
$ i686-w64-mingw32-objdump --private-headers test.c.exe
DLL Name: msvcrt.dll
vma: Hint/Ord Member-Name Bound-To
63e8 76
Hello Miriam,
if possible, you could install the additional package
systemd-coredump. Then in the output of 'journalctl --no-pager'
at the bottom should the known 'segfault at' line appear.
This and the following lines at that time would be of interest.
This would get better if the additional nfs-
Dear Maintainer,
the given code from dmesg points to this function:
LIBMTP_GetPartialObject at libmtp.c:9070
The related code [1] looks like function LIBMTP_Get_Filemetadata
returns a null pointer which get dereferenced unconditionally
in line 9070.
This part of the function seems unchanged ups
Hello Boris,
I am not involved in packaging gdm or orca
but tried to get more information.
I added also the a11y tag in the hope to get
the attention of the right people.
I tested inside a minimal VM with the gnome package installed.
In the gdm3 login screen I also got no reaction from the
Ctrl-A
|| ...635
<+261>: pop%r12
|| ...637
<+263>: pop%r13
...639
<+265>: pop%r14
Hello Pascal,
now I see one thing that would be even better:
coredumpctl gdb
info reg
thread apply all bt full
Sorry for not saying this sooner.
Kind regards,
Bernhard
Am 09.01.20 um 22:18 schrieb Pascal Vibet - ADACIS:
> @Bernhard : I install 'systemd-coredump' and 'centreon-engine-dbgsym'
> packages. I restart centengine. What information do you need? When
> centengine process crashes ? Or i run a program in same time ? What do
> you want me to do?
Great. Ju
Am 09.01.20 um 17:56 schrieb crvi c:
> I am using the same bash / gnome-terminal as part of my daily work. The
> crash was random and it is not consistently reproducible. I have a
> couple of bash core files, if that would be of any help.
Ok, I see - had hoped it to be better reproducible.
In my
Dear Maintainer,
I got today the same crash as the submitter.
It happened short after disconnecting one android device,
connecting another and opening/retrying the MTP connection.
This upstream bug looks related:
https://bugs.kde.org/show_bug.cgi?id=415693
(Seems to be also from buster due to a
Am 09.01.20 um 17:05 schrieb crvi c:
> gdb -q -batch -command ~/gdb-cmds.bash.txt --args bash
> Function "__pthread_tunables_init" not defined.
> Breakpoint 1 (__pthread_tunables_init) pending.
> [Detaching after fork from child process 37973]
Sorry, wasn't clear about that.
The prompt then shown
Dear Maintainer,
I just tried to get some more info from the
dmesg line, which seems to point to:
file ./src/retention/dump.cc, line 127. [1]
@Pascal: More information could maybe retrieved from the journal
if 'systemd-coredump' could be installed, even better if additionally
package 'centreon
Hello Gulfstream, hello Jean-Luc,
this report got opened mentioning a "Thinkpad P1".
Reading through some pages about that device, it looks
like it contains some "hybrid graphics".
Maybe you both could confirm that your devices have such
"hybrid graphics", and if yes, maybe you could give some mo
Sorry, forgot to attach details.
# Bullseye/testing amd64 qemu VM 2020-01-08
apt update
apt dist-upgrade
apt install systemd-coredump xserver-xorg sddm openbox xterm net-tools mc
fakeroot gdb navit navit-dbgsym libgps25-dbgsym
apt build-dep navit
reboot
mkdir /home/benutzer/source/libgps2
Dear Maintainer,
I tried to gather some more information to this issue and
found below difference [1] [2] in sizes of struct gps_data_t,
by inspecting a running process in different stack frames.
Also I found that the current navit 0.5.3+dfsg.1-2+b1 was
built against libgps-dev 3.19-2 [6].
The cur
Dear Maintainer,
when comparing with a process while having debug symbols
installed, I guess the given backtrace would translate to
something like below.
Therefore I guess this crash is the same
as described in #929113.
Unfortunately I could not find a matching appearance of
function gimp_project
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. Therefo
Hello crvi c,
could you please add an example command
that you want to have completed?
And if you have changed the environment GLIBC_TUNABLES,
to which value?
Otherwise a gdb session driven by the two commands below
could maybe point to the exact location where the overwriting
takes place, if wat
Hello Md Ayquassar,
I am not involved in packaging gnome-shell, but may have
some pointers to gather some more informations for the
maintainer.
You could try to install the package systemd-coredump.
That way the output of 'journalctl --no-pager' should give
some information where the crash happene
Dear Maintainer,
I rebuilt a linux-image package with the patch applied
and the submitters' cryptsetup command finished
without visible error to me.
(console output and dmesg in second half of attached file.)
Due to my limited knowledge of cryptsetup I guess Jerad
could better judge if the resulti
Dear Maintainer,
just as a side note, a similar bug was submitted
against the basilisk2 package.
https://bugs.debian.org/922323
Another user of slirp is qemu, which had some changes in
that area, which seems to have evolved into this library:
https://gitlab.freedesktop.org/slirp/libslirp
Hello Milan,
thanks for the fast response - I currently try to build a
package with your patch, but I guess this could take some time...
And I don't know what the usual approach is,
but the original reporter is probably Jerad?
(@Jerad maybe you could confirm your issue is the
same that I was seein
Dear Maintainer,
I just tried to reproduce the issue, but always
got a kernel oops instead of a usermode exception.
Therefore I guess this issue might be reassigned to src:linux?
By further looking it seems that in crypto_tfm_alg_blocksize
the __crt_alg member is dereferenced unconditionally while
Short addition:
upstream changed that line urlbar.vala:109 in commit [1].
A locally built package including that patch
did not crash for me.
Kind regards,
Bernhard
[1]
https://github.com/midori-browser/core/commit/525f76c68fdde8a2d974c6975d9cc5ebe0cd594b
Dear Maintainer,
I tried to reproduce it also on amd64 and found it
crashing at the following location.
My knowledge of vala is limited, but is here the member
"suggestion_row.item.database" not yet set, but already accessed?
Kind regards,
Bernhard
Thread 1 received signal SIGSEGV, Segmentation
Hello David,
I guess the package "thunar-dbgsym gdb" are installed
on your system, but could you please recheck if
packages "libglib2.0-0-dbgsym libgtk-3-0-dbgsym"
are really installed, too?
Kind regards,
Bernhard
Hello Antonio,
thanks for your comprehensive investigation.
I was not aware that rdesktop did not yet have a dbgsym package,
have opened bug #948126 for this.
And unfortunately if the backtrace in catchsegv ommits function
names, its output is just of help when using the debian binary
with a dbgs
Package: rdesktop
Version: 1.9.0-1
Severity: normal
Dear Maintainer,
attempting to support triaging another rdesktop bug I found
there does not yet exist a dbgsym package.
I tried to find out why and guess this is caused by the
strip command done in the Makefile.
As stripping would be done by de
Hello Antonio,
could you please add to which windows version you
were trying to connect.
Maybe you could also try to start it that way:
catchsegv rdesktop ...
Even better would be if you could install debug symbols like
described in [1] and systemd-coredump.
Then after an application crashed
Short addition:
this upstream issue seems to match better:
https://gitlab.gnome.org/GNOME/gimp/issues/3630
Which got fixed in branches master and gimp-2-10
by these upstream commits:
https://gitlab.gnome.org/GNOME/gimp/commit/bbcc7ca5f55e62404bd69bf2e5b198039ad3f568
https://gitlab.gnome
Control: tags -1 + patch upstream
Dear Maintainer,
I tried to have a look at this crash and I guess I found the reason.
The plugin calls into libgs.so.9 by gsapi_new_instance/psapi_new_instance.
Unfortunately the instance pointer is given to that function
uninitialized. But documentation states
Control: notfound -1 4:18.04.1-1
Control: found -1 4:19.08.1-1
Control: tags -1 unreproducible moreinfo
Hello Hans,
I tried to reproduce inside a minimal plasma testing VM.
But I could not see a noticeable amount of messages in
.xsession_errors while playing kpat.
If this is still visible on y
Dear Maintainer,
I tried to reproduce this issue. And as far as I see
eog/cairo tries to allocate a pixmap from the xserver
in the size of the image file - in this case 44351x3013 pixel.
Unfortunately the xserver has a hard limit for such pixmap sizes:
Thread 1 "Xorg" hit Breakpoint 4, ProcShmC
Dear Maintainer,
the given backtrace should look like below with debug symbols installed.
For some reason it looks like the strchr at line 281 returns a null pointer.
Kind regards,
Bernhard
(gdb) bt no-filter
#0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
#1 0x76fc
Dear Maintainer,
the given valgrind backtrace should translate to something
like below (which did not crash for me).
The crashing instruction tries to read memory pointed by register $rdi,
that held in my test the address in parameters "v" / "key" / "name".
So I assume for some reason this regist
Dear Maintainer,
I tried to have a look and might have found something.
The crash happens because coroutine_stack_init returns NULL.
This is because of a buffer size check.
Building a package with doubled "DEFAULT_STATE_SIZE" went
through without crash (just tested on aarch64).
However, I am unfa
Control: tags -1 + fixed-upstream patch
Dear Maintainer,
upstream fixed this issue in git by following commit:
https://ezix.org/src/pkg/lshw/commit/89b3b6b9ed03f22ca98954712db5a90acf2c6755
Kind regards,
Bernhard
Control: tags -1 + upstream
Control: forwarded -1 https://www.ezix.org/project/ticket/755
Dear Maintainer,
I tried to forward this issue upstream, where it is tracked
in this bug report: https://www.ezix.org/project/ticket/755
Hope it is ok to set this bug to forwarded.
Kind regards,
Bernhard
501 - 600 of 1319 matches
Mail list logo
