Hello Wolfgang,
could you please count how many true type fonts you have installed,
e.g. by 'find /usr/share/fonts/truetype -iname "*.ttf" | wc -l'.
Because in a minimal test environment the application started to
behave strange after that number went over ~1250.
That test was done with these deb
Dear Maintainer,
I just tried to reproduce the crash but did not get it.
Maybe some more details of the configuration details of
host.cfg and DNS server setup could help,
because in my test I never reached with my IPv6 config
the faulting instruction.
At least the instruction, at that address wher
Hello Wolfgang,
Am 16.12.19 um 18:18 schrieb Wolfgang Rosner:
> -8<---
> script: Ungültige Option
> -- Try 'script --help' for more information.
> -8<---
Sorry, there was a -a too much inside the quotation marks.
> I get a log file of 13 MB in Size.
>
Hello Wolfgang,
Am 16.12.19 um 11:42 schrieb Wolfgang Rosner:
> Hi Bernhard,
>
> Thanks for the debug instructions.
>
> I'll go to try them, maybe the next weekend.
>
> Notes is an essential tool of my daily work, so extended trials block
> me from productive offfice work for some hours, since
Dear Maintainer,
tried to reconstruct the given backtrace with debug symbols
in a gdb session and came to following, maybe it could be
of some help.
(Still a proper backtrace with dbgsym packages
installed would be better.)
Kind regards,
Bernhard
Reconstructed:
#0 0x7f78b4cfb92f in gnutls_a
Hello Wolfgang,
I am not involved in packaging wine in debian, but
may have some hints.
Unfortunately I could not find any download for a trial version,
is there one known? Otherwise this can just be debugged
by users having access to that software.
Then a file containing some more output could
Hello Jesús,
> Version: 2.10.12-0.1~mx19+1
Could not find a dbgsym package for that gimp version.
Is your system a MX Linux installation or a plain Debian?
At least in the first case, I guess, the MX Linux forums
can give better support.
And if the crash is reproducible it would help if you
coul
Dear Maintainer,
I tried to have a look at this issue. I got this also on amd64 [2].
It looks like this is related to aeolus requesting its
memory never getting swapped out. [1]
Without this line a process does not give this fault.
But there is a "max locked memory" of 65536 kbytes
in place (ulim
Hello Daniel,
Am 12.12.19 um 18:27 schrieb Daniel James:
> Hi Bernhard,
>> Marking stops as 'Multi-Arch: foreign' should make
>> that installation possible.
>
> The package 'stops' contains binary instrument data, which as far as I
> know, is uniquely created by the undocumented and well-hidden i
Control: tags -1 + upstream fixed-upstream patch
Dear Maintainer,
I tried to have a look at this crash
and I guess I found something.
The "Code:" sequence points to src/scan.c:1706.
There it seems like variable sr got a null pointer
and therefore the assignment crashes.
(gdb) list src/scan
(Forgot to attach some more debugging details.)
From submitter
Dec 12 09:40:11 lambda kernel: [55486.381334] iwd[202645]: segfault at 38 ip
55b1995e2056 sp 7ffc966c5360 error 6 in iwd[55b1995c4000+84000]
Dec 12 09:40:11 lambda kernel: [55486.381374] Code: 48 83 c4 20 e9 58 fe ff ff
0f 1
Package: stops
Version: 0.3.0-2
Severity: wishlist
Dear Maintainer,
I was trying to look at 943335, tried to look at it
with the rr debugger which is in the archive just for amd64.
Therefore tried to install aeolus:i386 which required
a package stops:i386.
Marking stops as 'Multi-Arch: foreign'
Control: tags -1 - upstream
Hello Felix,
maybe the information from following bug is
relevant in this case too.
https://bugs.debian.org/942860
Kind regards,
Bernhard
Hello Karl,
I am not involved in the packaging of phonon, but
still a few questions.
Have you any Qt4 applications installed?
Because src:phonon in version 4:4.10.3-2 was the last
version that built the Qt4 parts.
Since src:phonon 4:4.10.3-3 just the Qt5 packages
get build anymore.
And therefor
Hello Adrian, hello Paul,
I could reproduce the issue in a minimal
revertable Unstable qemu VM with this command:
/usr/bin/autopkgtest libsoxr -- null
As far as I see the test is called this way:
src/debian/tests/inst-check
src/inst-check
src/inst-check-soxr
$gen
Dear Maintainer,
sorry, did attempt to output the build-id unconditionally,
fixed in attached patch version.
Kind regards,
Bernhard
>From 0a4a73d4eeaa45acdbeb6ea8fea878e134cbc11b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?=
Date: Wed, 11 Dec 2019 19:56:39 +0100
Subject: Ma
Dear Maintainer,
while I was at it, I attempted to change the output to
deliver the before mentioned information for addr2line too.
Attached is a improved patch, that would now output following:
Backtrace:
[0x55f317f9175b] main at
/usr/share/doc/libsoxr-dev/examples/3-options-input-fn.c:79 (dis
Package: libc-bin
Version: 2.29-3
Severity: wishlist
Tags: upstream patch
Dear Maintainer,
since upstream commit in 2012 [1] the function __backtrace_symbols_fd
seems to outputs in one of this formats:
program(+)[]
program(function+)[]
Therefore the /usr/bin/catchsegv cannot find the ba
Hello Jack Barns,
I am not involved in packaging spacefm, but just tried
to reproduce the issue. "Unfortunately" for my test it
did not freeze.
If you still can reproduce it, maybe you can execute
following command while a single spacefm process is in
the system and hangs:
script -a "spacefm-
Hello David,
I fear that output is not sufficient for that
type of application.
Maybe you could install following packages:
thunar-dbgsym gdb libglib2.0-0-dbgsym libgtk-3-0-dbgsym
For this you would need to add a matching package archive
like described in this link:
https://wiki.debian
s=run_dtors@entry=true) at exit.c:108
#10 0x77c87eba in __GI_exit (status=) at exit.c:139
#11 0x555883f6 in main (argc=, argv=,
env=) at perlmain.c:166
(gdb) kill
Kill the program being debugged? (y or n) y
[Inferior 1 (process 607) killed]
(gdb) q
cd /home/ben
Control: tags -1 + patch upstream fixed-upstream
Hello Mladen Mijatov, dear Maintainer,
the first frames would be translated by addr2line to following [1].
This looks like the crash is caused by an invalid pointer pself/self
in function cc_display_mode_dbus_is_supported_scale [112].
This pointer
Hello local10,
if you still get this crash, maybe if you start it like below
there would be more information about the crash.
catchsegv gnome-control-center
Alternatively you could install systemd-coredump and look
at the end of 'journalctl --no-pager' if there is some debug
information of th
Hello Mladen Mijatov,
if you still get this crash, maybe if you start it like below
there would be more information about the crash.
catchsegv gnome-control-center
Alternatively you could install systemd-coredump and look
at the end of 'journalctl --no-pager' if there is some debug
informatio
Hello Ludovic,
I tried to collect some more information from your crash dump.
With debug symbols this backtrace should look like below.
I guess you are running a nvidia graphics card
with the nouveau drivers?
As a workaround it may work if you start the client
from a terminal by following:
e
Hello Christian,
if you still see this crash, maybe you could install the
package systemd-coredump.
If then a process crashes again some more information
should be visible at the end of:
journalctl --no-pager
Kind regards,
Bernhard
Hello Andrew,
On Sun, 8 Dec 2019 15:17:45 -0500 Andrew Engelbrecht wrote:
> I was able to reproduce and to get a backtrace, which I attached to this
> email.
Your backtrace with full debug symbols should read like below [4].
This seems to point to the upstream issue [1].
Unfortunately I could
Hello Andrew,
I tried to reproduce this crash but it did not show up for me.
Maybe you could install systemd-coredump, then a backtrace
would be written automatically into the journal:
journalctl --no-pager
Kind regards,
Bernhard
Hello David,
I tried to reproduce the issue but I did not receive a crash.
There should have been two lines in the syslog - the line with "Code"
would at least help to identify in which function the crash happened.
Maybe you could also start thunar or nautilus from a terminal by e.g.
thunar
Am 07.12.19 um 18:20 schrieb Colin Watson:
> On Sat, Dec 07, 2019 at 04:52:19PM +0100, Bernhard Übelacker wrote:
>> I could reproduce the issue in a i386 qemu VM with
>> a downgraded 3.16-3-686-pae kernel.
>> Attached file contains a debug session.
>>
>> At the
Hello dinar qurbanov,
I am guessing you are using Buster/stable i386?
If reportbug would be used for reporting bugs, such
information gets added automatically to the report.
Then the "Code" in the syslog the crash most probably
happened in _cairo_surface_set_error [1].
Unfortunately I doubt that
Dear Maintainer,
I could reproduce the issue in a i386 qemu VM with
a downgraded 3.16-3-686-pae kernel.
Attached file contains a debug session.
At the sysenter instruction in function shmdt
the signal SIGSYS is received.
Kind regards,
Bernhard
(gdb) bt
#0 shmdt (shmaddr=0xb774) at ../sysde
Dear Maintainer,
I tried to reproduce inside a minimal Buster i386 qemu VM
and received also an "Illegal instruction" message.
It looks like it tries to execute an AVX instruction that
my CPU should support, but is not enabled inside the VM.
The usage of AVX might originate from the compiler
flag
Control: tags -1 + upstream patch
Dear Maintainer,
I tried to have a look into this issue and guess I found something.
It looks like the application is exhausting its stack by
allocation an integer array with maxpid elements.
At least in my test VM this leads to 16 MB array size,
while stack has
Package: libkf5kiocore5
Version: 5.54.1-1
Severity: normal
Tags: patch upstream
Dear Maintainer,
in the last year I hit a few crashes with kate,
without knowing how to reproduce the crash.
Today I found this upstream reports [1] and several
duplicates. With that information it was easy to reprod
... a short addition:
This issue might also the the same as
described in this upstream issue:
https://github.com/scim-im/scim/issues/26
Kind regards,
Bernhard
Control: reassign -1 scim-gtk-immodule 1.4.18-2.1
Control: affects -1 + gimp
Hello Masa O,
I tried to reproduce the crash you describe in a Buster/stable VM,
but was not able to reach the crash.
>From your backtrace there are some modules for scim input method
visible, but failed also to setup i
Hello Geoff Tree,
I am not involved in packaging mousepad, but tried to reproduce
the issue. Unfortunately I could not trigger the crash.
Maybe you could install a coredump collector like systemd-coredump.
The last lines of the output of the command 'journalctl --no-pager'
should give the location
Dear Maintainer,
I reported the issue upstream:
https://github.com/rzvncj/xCHM/issues/9
Kind regards,
Bernhard
Control: tags -1 + upstream patch
Dear Maintainer,
I could reproduce the crash with some old versions of
php_enhanced_en.chm I found on the net [1].
The current version from php.net [2] does not crash.
While it looks like the search is also not working
and gives no results.
With a package built
Hello Stuart Lindley,
I am not involved in packaging qemu and just looking
through some bug reports.
Some informations that might be interesting for the
maintainer might be, which version of freenas you are running?
Based on your screenshot you start it via libvirt?
Maybe you could deliver the c
Hello Jean-Paul,
this might be the same issue as in following bug, which
has some more information and a patch:
https://bugs.debian.org/945188
Kind regards,
Bernhard
Hello all,
this might be the same issue as in following bug, which
has some more information and a patch:
https://bugs.debian.org/945188
Kind regards,
Bernhard
Control: tags -1 + patch
Dear Maintainer,
I tried to have a look and found something.
This issue might be in the package since poppler-0.71.patch.
This patch makes some changes how containers get accessed.
Following I found and tried to change in attached patch:
- std::erase, std::clear, std::r
Am 21.11.19 um 16:13 schrieb Marius Mikučionis:
> 2019-11-21, th, 13:14 Bernhard Übelacker <mailto:bernha...@mailbox.org>> wrote:
>
>
> I forgot to mention that I used a local built wine-4.20.
> There were lately some changes in that area in Wine, therefore
&
Am 21.11.19 um 12:09 schrieb Marius Mikučionis:
>
> 2019-11-21, kt, 01:16 Bernhard Übelacker <mailto:bernha...@mailbox.org>> rašė:
> $ wine strftime-ucrt-7.exe
> [%a]: [Tue]
> [%e]: [ 5]
> [%d]: [05]
> [%-d]: (empty
Hello Marius Mikucionis,
I am not anyhow involved in maintaining mingw-w64.
But I guess I found something.
First I fear that mingw-w64 does not link as much static
as you expect it to.
All crossbuilt executables still dynamically link to msvcrt.dll.
$ i686-w64-mingw32-objdump -p strftime-6.ex
Control: tags -1 + upstream fixed-upstream patch
Dear Maintainer,
the issue seems to be with newer gcc versions string literals
get not put into memory mappings " r-xp ",
instead they are mapped " r--p ".
Such a string literal is used to determine the location
of the executable.
Upstream fixed
Dear Maintainer,
I tried to get some more information and was able
to record a crash with rr.
When continuing from below backtrace [2] it continues
into a recursion until the segfault is reached.
Therefore this might not be an nmap bug.
This led me to this bug report [1], which mentions
upstream
Control: tags -1 + moreinfo
Hello Parleur,
is this still an problem with current version in unstable?
If yes, you could maybe supply some more informations.
One way would be to install the package systemd-coredump
and see if in 'journalctl --no-pager' appear some backtraces
of the issue, which
Control: tags -1 + moreinfo
Hello dinar,
I tried to reproduce the crash inside a minimal
i386 buster VM, but could not get xchm to crash
on my downloaded version of php_enhanced_en.chm [1].
Is this the file you are using, too?
Without further information the maintainer is maybe
not able to reso
Hello Lars,
> in fact they all happen with the same program (claws-mail).
> Besides the claws-mail crashes I did not notice any other unexpected behavior.
Yes, if crashes are just in one application then it seems less
likely to be an hardware issue.
Maybe it is of some help, following seem to
Hello Lars,
just a wild guess - is claws-mail doing these ldap queries
in parallel in different threads? This in combination with
the unsteady connection to the server could make two threads
operate on the same structures?
In that case following gdb output would show all
threads with their backtra
Hello Nicolas Patrois,
following page demonstrates better what I tried to say:
https://buildd.debian.org/status/package.php?p=gimp
There the architecture dependent packages for i386 got built
and "installed" to unstable, but the arch :all packages,
like gimp-data, failed to build because of an
Hello Alex Riesen,
I am not the maintainer of edid-decode, but was just
looking through some random issues.
Your attached output of the current upstream might
point to this commit [1].
But to be sure either you should attach a copy of
your input file, or if that is now wanted,
a backtrace like d
Hello Steve Newcomb,
I am not the mailutils maintainer, but just came across you report.
The information you supplied might not be enough
for the maintainer to track down the issue, and
it might be related to the content of your mail directory.
You supplied the dmesg output, but even when the cra
Hello Nicolas Patrois,
not being a gimp maintainer, but might this just the
the nature of unstable - gimp:i386 got installed for some
reason, but gimp-data:all did not get installed
to the FTPs, maybe because of an failure of gegl, I guess,
which failed on most of the architecures except i386.
Kin
Hello Lars,
because you mention repeating crashes which, as far as I see, are
in different programs in different backtraces.
Maybe the problems are created by a bad memory module?
Therefore could you please run a tester like memtest86+, just
to rule out an hardware issue?
Kind regards,
Bernhard
On Sun, 17 Nov 2019 10:33:10 -0800 Ryan Tandy wrote:
> On Sun, Nov 17, 2019 at 05:11:13PM +0100, Lars Kruse wrote:
> > #0 0xb77acbea in ldap_unbind_ext () at
> > /usr/lib/i386-linux-gnu/libldap_r-2.4.so.2
>
> Please could you install libldap-2.4-2-dbgsym and obtain the backtrace
> again:
>
>
Hello Markus, hello Enrico,
I am sorry to be late, but I guess I have found the issue.
The function SetThreadPriority does not return properly
therefore the following function gets executed which writes
to somewhere, that causes later the crash below.
The build logs show a warning for this issue:
Dear Maintainer,
I tried to find out what happens and I think it is
related to the changes from #928467.
Because of these the configure script searches now
for libdb-5.3.a in directory /usr/lib/i686-linux-gnu
(in configure "$dir/lib/${host_cpu}-${host_os}").
Unfortunately that library lives in /us
Dear Maintainer,
the above backtrace lacks symbols but should
match something like below.
Kind regards,
Bernhard
>From submitter: | Reconstructed:
fcitx(+0x1927)[0x5568b6236927] | 0x55b5bef8e927
in OnException at ./src/cor
Hello,
this seems to be caused by a build failure in 1:9.0.0-1
for i386 while amd64 succeeded.
The build failure seems related to #942864.
Next upload 1:9.0.0-2 succeeded for both architectures.
Kind regards,
Bernhard
https://buildd.debian.org/status/logs.php?pkg=llvm-toolchain-9&arch=i386
http
Control: forcemerge 939754 940931
On Sun, 22 Sep 2019 10:19:59 +0530 Darshan Narayan
wrote:> ```
> ...
> using GEGL version 0.4.12 (compiled against version 0.4.14)
> ...
> #7 0x561237ca0411 in gimp_gegl_mask_is_empty ()
> ...
Hello Darshan Narayan
this issue is tracked in Debian bug #93
Control: forcemerge 939754 941275
On Fri, 27 Sep 2019 19:28:25 +0530 Lalit Kumar
wrote:
> ...
> using GEGL version 0.4.12 (compiled against version 0.4.14)
> ...
> #7 0x5634ba3aa411 in gimp_gegl_mask_is_empty ()
> ...
Hello Lalit Kumar,
this issue is tracked in Debian bug #939754 and
sho
Dear Maintainer,
I guess this has to do with the package libgtkd-3-0.
Currently testing contains the version 3.8.5-1+b2.
That one got compiled with ldc 1:1.17.0-2.
The version 3.8.5-1 got compiled with ldc 1:1.12.0-1.
Installing that version from [1] makes tilix at least
run and open its window.
Control: forcemerge 939754 940907
Hello Stefan Pietzonke,
this issue is tracked in bug #939754 and should
disappear by installing latest updates
to libgegl-0.4-0 in version 0.4.14-2.
This was caused by gimp 2.10.8-2+b1 being built
against libgegl-0.4-0 in version 0.4.14-1,
but running with versi
Control: forcemerge 939754 940808
Hello Jeff,
this issue is tracked in bug #939754 and should
disappear by installing latest updates
to libgegl-0.4-0 in version 0.4.14-2.
This was caused by gimp 2.10.8-2+b1 being built
against libgegl-0.4-0 in version 0.4.14-1, but
running with version 0.4.12-2
Dear Maintainer,
upstream issue [1] got closed with commit [2] in the master branch,
and should be contained in the upcoming release 1.9.0.
Unfortunately I guess the upstream 1.8.x branch will not
get an update for this, so either the patch in my previous
mail should work, or the change proposed i
Control: forcemerge 939754 939768 939876 939977 939985 940008 940011 940042
940044 940088 940174 940177 940285 940472 940525 940561 940610
Hello,
I hope it is ok to merge all such bugs.
All of them show gimp_gegl_mask_is_empty at an
instruction address ending in 411.
Now that gegl 0.4.14-2 tran
Dear Maintainer,
just in case it may be of any help.
I guess the dmesg line points to function screen_write_collect_end
in screen-write.c:1240.
Kind regards,
Bernhard
# Bullseye/testing amd64 qemu VM 2019-09-16
apt update
apt dist-upgrade
# testing -> unstable
apt update
apt dist-upgrade
r
Hello,
I have created a new upstream issue:
https://gitlab.gnome.org/GNOME/gegl/issues/206
Kind regards,
Bernhard
Dear Maintainer,
I guess this issue caused also gegl not transitioning to testing and
therefore another issue within the package gimp e.g. bug #939768
and a few more.
I tried to reproduce it in a qemu VM for mips64el
and hit the same issue.
Running just the mentioned test it returns a timeout mes
Hello Stephen, hello Claude,
following that previous idea of just replacing the aligned
instruction with the unaligned one the hacky patch below got
created, just replacing vmovapd by vmovupd.
Not considering any side effects and maybe other
instructions with alignment requirements.
At least a ming
Hello Stephen, hello Claude,
following discussion seems also related and raises the question
if the variable cannot be aligned, could then mingw-w64 just emit
the unaligned instructions, even if slower than the aligned ones,
which are faster but also crash.
https://sourceforge.net/p/mingw-w64/disc
Hello Martintxo,
your last attachement confirms we get into a recursion in
mwxWindow::DoClientToScreen in the suspected line [L3158].
Further it looks like this==m_parent at this state, so
this window is its own parent ?
I guess entering the recursion in that case is clearly wrong,
therefore fol
Control: tags -1 + upstream
Hello Claude Heiland-Allen,
I tried just to collect some more information for the maintainer.
The issue could be reproduced in a qemu VM
with '-cpu host' on a Ryzen 7 1700.
The resulting binary crashes on Windows at the same instruction,
so I guess Wine can be ruled
Hello sixerjman,
the maybe same bug #934105 got closed and mentions the issue
is no longer visible in 4.14, I guess you upgraded too and
I want to ask if you still can observe that crash.
If not you could also close this bug by sending your answer
to 933202-d...@bugs.debian.org
Kind regards,
Bern
Hello Stephane,
sorry for the delay, you might use for Debian bugs reply all, to
get the information recorded in the bug and notify the real person.
As not being involved in packaging gimp I really just tried to get
some more information from the backtrace, which led to the
bug reports in gimp's o
Dear Maintainer,
I guess the actual segmentation fault is fixed since kamoso 3.2.4-1.
Instead it should print this message:
The webcam controller was unable to find or load wrappercamerabinsrc plugin;
please make sure all required gstreamer plugins are installed.
The last question would b
Dear Maintainer,
migth this be related to this bug:
https://bugs.debian.org/935496
Kind regards,
Bernhard
Hello Ondrej Zary,
while looking through bug reports for some random
packages I got to your report.
I guess your system got updated at least from Stretch to Buster,
therefore you might have freerdp-x11 installed while that
is not part of the official Buster release.
It got also removed from Sid, th
fixed 932550 4.19.67-1
Dear Maintainer,
this backtrace is identical to that one reported in #935604.
Also the expected message appears in this report:
...
"[xcb] Unknown sequence number while processing queue"
This time I found also this upstream bugs that may be related:
https://gitlab.gnome.org/GN
Hello,
this sounds related to these bugs:
https://bugs.debian.org/935496
https://bugs.debian.org/935972
https://bugs.debian.org/935916
Kind regards,
Bernhard
Control: submitter 939029 Nicola
Control: fixed 939029 librsvg/2.44.14-1
Control: tags 939029 + upstream fixed-upstream
Hello,
this clone is just to handle the issue described in
messages #18, #36, #48, #73.
Last contains upstream bug and patch.
This should be fixed in testing already and just
reassign 914150 libfm/1.3.0-1
Hello Chris,
I added it to your report guessing that it might be the issue
you observed. Now I see your setup is way more complex than my test.
To reveal some more information about your issue, you could install
the package systemd-coredump, then in the journal should a
backtrace appear after a cr
Dear Maintainer,
I tried to reproduce the issue, but unfortunately I
receive no segmentation fault, instead a floating point exception.
(By using the button with the play symbol at the middle bottom.)
This happens there because the divisor frame_rate is zero.
For this issue I could not find an ups
Hello,
this sounds related to these bugs:
https://bugs.debian.org/935916
https://bugs.debian.org/935496
Kind regards,
Bernhard
Control: reassign -1 fuse 2.9.9-1
Dear Maintainer,
installing fuse in a minimal Bullseye qemu VM fails the same way.
It seems that /var/lib/dpkg/info/fuse.postinst contains a
call to udevadm that fails like this:
root@debian:~# udevadm test --action -p /devices/virtual/misc/fuse
test: in
Hello,
I guess #921959 describes also the same problem.
Attached patch tries to workaround that issue by not
using the the original buf pointer increased by the
offset of member th_msg.
That way at least the warning "overflows the destination"
is not written anymore at build time and a package bu
Hello Martintxo,
I am just looking at crashes of some random packages and
found your backtrace. Thats already a good start.
As I it looks like you had installed the package
amule-utils-gui-dbgsym maybe you could also install these packages:
libwxbase3.0-0v5-dbgsym libwxgtk3.0-0v5-dbgsym libgtk
Hello steph,
I tried to get some more information from the backtrace and think
it would look like shown below [1].
It would show at least that there was some issue with the communication
to the X-server and it points to xcb_io.c, line 260 [2]:
throw_thread_fail_ass
Hello Alf Gaida,
I am just looking through crashees of some random
packages and stopped on this bug.
I found that you used at least following packages from experimental:
evolution libglib2.0-0 libsoup2.4-1
And unfortunately there are no dbgsym packages for the
versions of that time of libgli
Control: tags -1 + upstream
Control: fixed -1 4.89+dfsg-0.1
Dear Maintainer,
I just tried to find some more informations about this issue.
The lsof version 4.89+dfsg-0.1 did not show this issue, therefore
Stretch is not affected. It started with version 4.91+dfsg-1 which
is already contained in
Hello,
maybe the following report is related:
https://bugs.debian.org/928736
Kind regards,
Bernhard
Control: reassign -1 src:linux 4.19.37-5
Control: affects -1 qemu-system-x86
Control: fixed -1 4.19.37-4
Hello Guido,
thanks for the confirmation.
So I try to reassign this bug to the kernel package.
Kind regards,
Bernhard
Control: tags -1 + upstream
Dear Maintainer,
I tried to get some information to this issue.
The error is given within this backtrace [1].
This is also present in the upstream git 1.8.x branch.
A git bisect points to upstream commit 82fce18.
However that commit seems to just add some checks to
Hello Seth Foley,
if possible you could now install gdb
and the following debug symbol packages.
The latter are stored in a separate
repository, more details in [1]:
handbrake-dbgsym libavformat58-dbgsym
Then if you have not rebooted since the last
handbrake crash, you can use following comma
601 - 700 of 1318 matches
Mail list logo
