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
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
Dear Maintainer,
as far as I found is the problem related to:
debian/patches/generate/icons.patch
That strips away the ico files from being included in the
resources in regedit. But the treeview seems just to be shown when
programs/regedit/treeview.c:InitTreeViewImageLists was able to
load the
Hello Christian Schrötter,
not being involded in dovecot packaging I looked at this crash.
That address in event_unref seems to point here:
(gdb) disassemble /m event_unref,event_unref+370
Dump of assembler code from 0x77f33d70 to 0x77f33ee2:
...
210
211 void event
Dear Maintainer, hello Mark Buranyi,
tried to reproduce inside a Stretch amd64 qemu VM.
I assume the first is calling the
SIGTERM handler [frame #9].
Unfortunately it looks like the module containing sig_term was already
unloaded at that time (mod_mpm_event.so).
Therefore executing that now unloa
Dear maintainer,
is this bug currently causing not being able to install gkrellm in a
current buster system where some packages depending on libsensors5 are
already installed?
I guess this is an unfortunate situation if it stays until the buster
release, as following is currently not possible in t
Dear Maintainer, hello Philipp Marek
tried to have a look at this backtrace.
Unfortunately I could not reproduce a crash with a random test file.
See the same backtrace with all needed debug symbols below.
It points to following line 147:
(gdb) list
144 /* If this edge of the f
Hello Ian, hello Ted,
yesterday I tried to reinstall that device with the latest
buster installer - but unfortunately I was already too late,
the archive moved already too far away:
No kernel modules were found.
Therefore I did the reinstall with the stretch installer
and upgraded to buster, l
Control: reassign 892871 libasan4 7.3.0-5
Control: found 892871 7.3.0-12
Control: fixed 892871 7.3.0-13
Dear Maintainer,
did some tests with snapshot.debian.org and found
that crash does not happen anymore since libasan4:i386 (7.3.0-13).
Kind regards,
Bernhard
Hello Adam Knapp,
you might run octave inside gdb to retrieve a backtrace of the crash.
Run below command inside a terminal application and you should
receive a file gdb-octave*.log that you might forward to this bug.
gdb -q -batch -ex 'set pagination off' -ex 'set width 0' -ex run -ex 'bt
ful
Hello Michael Tokarev,
I am sorry, I have missed your mail from december.
Thanks for the information, I will report back
when I have tested it. (Forwarding to the submitter too.)
Kind regards,
Bernhard
Am 03.01.19 um 21:02 schrieb Michael Tokarev:
> Control: tag -1 + moreinfo
>
> Adding a bit
Hello Michael Tokarev, hello Theo
I have now another machine at hand where I currently have
buster installed, where today qemu-user-static in
version 3.1 appeared.
So I did some tests.
It still shows the issue reported by Theo:
root@qnap-119p-ii:~# chroot /tmp/buster-chroot-i386 /bin/bash
Hello Dominik Röttsches,
the missing debug symbols for libmariadbclient.so.18
might hide in libmariadb3-dbgsym.
You may also want to install these packages too:
dovecot-core-dbgsym dovecot-mysql-dbgsym
They should be available in a different debug symbol
repository described in [1].
I had a lo
Control: reassign 918370 krita 1:4.1.7+dfsg-1
Control: tags 918370 + upstream fixed-upstream patch
Hello Johnny, dear Maintainer
I tried to get some more information, but I think it is not
reproducable without that tablet hardware.
For future bug reports it would be very helpful if debug symbols
Hello Johannes,
thanks for your fast respone.
Can you repeat that gdb command with following additional
dbgsym packages installed, to complete the backtraces:
libxcb1-dbgsym libqt5gui5-dbgsym libqt5widgets5-dbgsym libqt5gui5-dbgsym
libqt5dbus5-dbgsym libqt5core5a-dbgsym libglib2.0-0-dbgsym
Dear Maintainer,
I tried to have a look at this segfault.
It seems this is a case of pointer truncation.
In following location [1] a pointer gets casted to int (pogl_glut.xs:1021)
and stored in freeglut_callbacks.c:115 into field ID of a SFG_Timer struct.
This leads later [2] to the crash when i
Package: dizzy
Version: 0.3-3
Severity: normal
Dear Maintainer,
this is the output of dizzy when started
on a desktop PC with amd graphics
or a qemu amd64 VM, both running current buster:
$ dizzy
GPU features: [x] GLSL [x] FBOs
Your vendor has not defined OpenGL macro GL_FRAMEBUFFER_EX
Hello Johannes,
On Mon, 07 Jan 2019 21:06:28 +0100 Johannes Zarl-Zierl wrote:
> Hello Bernhard,
>
> Am Montag, 7. Jänner 2019, 01:00:13 CET schrieb Bernhard Übelacker:
> > Can you repeat that gdb command with following additional
> > dbgsym packages installed, to co
Hello Joe Ma,
On Mon, 7 Jan 2019 15:45:27 +0800 Joe Ma wrote:
> Here is the log after executing your command.
Unfortunately I cannot see a difference to a kate process
that runs normal.
Was this file created while your kate process was frozen?
> The whole screen (plasmashell) freeze after righ
Control: tags 918696 + upstream patch
Hello Bill Allombert, dear Maintainer,
I tried to have a look at this crash and could
reproduce it inside a Buster amd64 qemu VM.
See below a backtrace of the crash with debug symbols installed.
Running with valgrind revealed accesses to uninitialized memo
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:
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 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
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 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 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 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 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 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
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
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
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 + 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
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
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
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
&
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
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
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 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
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
Dear Maintainer,
I reported the issue upstream:
https://github.com/rzvncj/xCHM/issues/9
Kind regards,
Bernhard
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
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
... 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
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
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
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
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
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
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 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
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
Package: doomsday
Version: 1.15.8-5+b1
Severity: wishlist
Tags: patch
Dear Maintainer,
Doomsday released upstream version 2.0.3.
Please find in [1] a first try to upgrade this package.
Changelog so far:
* New upstream release.
* Switch to Qt 5. (Closes: #874870)
* Drop patches perms, pack
Dear Maintainer,
looks like the submitter opened in response to the last
mail bug #930649 against src:linux.
Therefore this one might be closed?
Kind regards,
Bernhard
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930649
Hello Avinash Sonawane,
unfortunately in my test setup I still get not near that location.
Therefore maybe the maintainer or upstream would need to have a look.
But I fear, as the buster release is in sight and libwebkitgtk
got replaced by libwebkit2gtk, the time that gets invested into
this versi
Control: tags -1 + moreinfo
Hello Iris,
I tried to collect some more information for the maintainer.
But I could not find a problem installing and running
zenity inside a minimal Stretch qemu VM,
that has no SSE support (-cpu pentium2 -no-kvm).
Therefore some more information might be needed:
Dear Maintainer,
I just tried to help triaging this bug.
This bug manifests in current Stretch/9.9 and
also in Buster/testing.
In the call to function setMultiStats a temporary
PLAYERSTATS object gets constructed from the
reference returned by getMultiStats.
Therefore the copy constructor of EcKe
Dear Maintainer,
I tried to reproduce this issue and received the below backtrace.
This seems the same issue as in following bugs:
https://bugs.debian.org/924499
https://bugs.debian.org/928264
(And a few other reported just against current testing.)
Kind regards,
Bernhard
(gdb) bt
#0
Hello David,
I am not involved in packaging, just tried to collect some more
information to this old bug.
I guess your issue migth not be that one discussed in this bug.
At least you might be able to provide the output of 'dmesg',
if in your case konsole really crashes.
Or after installing the pac
Hello Francis Laniel,
I am just looking at some crashes in some random packages,
and found this nouveau issue familiar.
I guess __pthread_cond_wait_common should be able to
handle a NULL for abstime - e.g. should "Block without a timeout".
https://sources.debian.org/src/glibc/2.28-10/nptl/pthr
Package: orca
Version: 3.30.1-1
Severity: normal
Dear Maintainer,
I was trying to triage another bug by using orca
inside a minimal Buster amd64 qemu VM.
On that minimal system I installed just:
apt install systemd-coredump xserver-xorg sddm plasma-desktop orca
When I tried to start orca in
Package: libqt5gui5
Version: 5.11.3+dfsg1-1
Severity: wishlist
Tags: upstream
Affects: konsole orca
Dear Maintainer,
I noted some recent additions to bug #594506 which I guess
describe a different problem. I did some investigations and
tripped on the issue with following steps:
- Installed in a
Hello David,
I could find an issue with konsole freezing
and reported it in this bug:
https://bugs.debian.org/931844
Maybe you want to have a look if you find your issue there.
Kind regards,
Bernhard
Control: forwarded -1 https://bugreports.qt.io/browse/QTBUG-77017
Dear Maintainer,
I created an upstream bug report and forward this bug to it.
Kind regards,
Bernhard
Hello David,
that was not the link I sent in my mail,
I sent a plain link to bugs.debian.org.
Maybe you are viewing my mail via google webmail client,
and that is adding something unwanted?
Kind regards,
Bernhard
Hello
the issue you observed might be already reported in:
https://bugs.debian.org/924925
Kind regards,
Bernhard
Hello Jeffrey Hundstad,
just looking at some crashes in some random packages,
I just tried to reproduce this issue inside a minimal qemu VM.
But hit just the line "Couldn't open...", not the segfault.
Also with a simple test printer configured and a test page job.
If it is possible you could insta
Hello Jeffrey Hundstad,
sorry, I forget to mention that it would help with the
backtrace if the debug symbols would be installed.
For jobs.cgi I assume this would be cups-dbgsym.
These packages are in a separate repository.
Details are about it are in this page:
https://wiki.debian.org/HowToGetAB
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,
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 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
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
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: tags -1 patch upstream
Dear Maintainer,
I tried to have a look at this crash and I think I found something.
It seems to be caused by this function in class NoSpecial:
float radius() const {}
It is declared as returning float, but does not return a value.
In the build logs is
Am 28.05.19 um 11:56 schrieb Fabian Greffrath:
> Is it just my MUA again or is this indeed missing the patch?
I am sorry but this time it might be your MUA.
The patch is now visible on the bug's page:
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=929513;filename=0001-Avoid-crash-because-
Control: tags -1 moreinfo
Hello Bardot Jerome,
I am just looking at some random bug reports with crashes.
The last page of the strace output might point into the
direction of the graphic driver, you are using the free
nouveau driver?
For more information you might consider adding the dbgsym
re
Control: tags -1 patch
Dear Maintainer,
I am just looking at some random bug reports with crashes.
In this case I think atril is or was not prepared to run
in a wayland session.
Attached patch is based on some porting guide to wayland and
with that atril shows its main window. Nothing more was
Control: tags -1 - moreinfo
Hello Bardot Jerome,
unfortunately the debug information did not yet cover
all functions in the backtrace.
The backtrace would be perfect if libdrm-nouveau2-dbgsym
would be installed.
But from the visible parts, following issues seem simliar,
at least the "Assertion `
Dear Maintainer,
I just tried to have a look at this
backtrace by the submitter:
Thread 1 (Thread 0x7f81021b1e00 (LWP 3464)):
...
#6 0x7f810411f 730 in () at libpthread.so.0
#7 0x56302b0c9 97f in ()
#8 0x56302b0c9 c28 in ()
#9 0x7f8104303 dd8 in g_main_context_dispat
Control: tags -1 + moreinfo
Hallo James Henried,
was just looking through some random bug reports.
Maybe you could install the package systemd-coredump.
That way in the journal would appear a backtrace that
could give some hints where the segmentation fault happens.
Visible in the output of:
Control: tags -1 + moreinfo
Hello Shawn Landden,
where exactly do you enter this ctrl-z?
In the graphical user interface of ddd ctrl-z is the shortcut for the
Edit - Undo action. So that is not supposed to end ddd, I guess.
Or do you enter it in a terminal from which you started ddd?
>From ma
Dear Maintainer,
I just tried to reproduce this crash and may have
found some more information.
It looks like this memory got freed already at
this location [1].
Then on the second free attempt the talloc
recognises this and aborts [2].
Could not find a related upstream bug report in [3].
It do
Control: tags -1 - moreinfo
Hello Shawn Landden,
> Good point. I started ddd from a terminal. Ctrl-c is ignored.
I just saw that Ctrl-c is not terminating ddd, but
in the debugger console following is shown:
(gdb) Quit
(gdb) Quit
So it looks like it just get forwarded to the gdb process.
This
Control: tags -1 + moreinfo
Hello Saša Janiška,
I just tried to reproduce the issue but for me it did not show up.
Therefore a few more information may be required.
Your desktop is running a xorg or wayland session?
Was this just crashing once or can you reproduce it again?
Maybe you could inst
Hello James Henried,
I guess this issue could be related to following shared library.
> 0x77b6a0e0 0x77b7af47 Yes (*)
> /usr/local/lib/libimobiledevice.so.6
It looks like this file is a manual installed version,
while the debian version of that library should be loaded
from
Hello Andy Dorman,
the new location seems to be in the following directory:
root@debian:~# dpkg -L libtcmalloc-minimal4 | sort
...
/usr/lib/x86_64-linux-gnu/libtcmalloc_minimal_debug.so.4
/usr/lib/x86_64-linux-gnu/libtcmalloc_minimal_debug.so.4.5.3
/usr/lib/x86_64-linux-gnu/lib
Hello Saša Janiška,
thanks for your fast response.
Maybe you could also install following debug symbol packages:
libpixman-1-0-dbgsym libcairo2-dbgsym libchamplain-0.12-0-dbgsym
libffi6-dbg libgjs0g-dbgsym libglib2.0-0-dbgsym libgtk-3-0-dbgsym gjs-dbgsym
(and if size does not matter: lib
"libpixman|libcairo2|libchamplain|libffi6|libgjs0g|libmozjs|libglib2.0|libgtk-3|gnome-maps"
| sort
Kind regards,
Bernhard
Am 01.06.19 um 08:16 schrieb Saša Janiška:
> Bernhard Übelacker writes:
>
>> And send another output of journalctl, that way the function
>> names fo
Dear Maintainer,
I just tried to reproduce the crash and succeeded
in a wayland session.
Following are the last frames where gedit aborts,
with debug symbol.
When debugging the issue it looks like we reach already line 327
with the pointer in "start" being higher that that in "end".
Therefore th
Hello Avinash Sonawane,
I just tried to help triaging this crash.
Unfortunately I could not reproduce this crash
in a minimal stretch VM.
If you can still reproduce the crash, maybe you could
install the following debug information packages before,
and repeat the 'midori -g' step:
midori-dbgs
Hello Gulfstream,
are you by any chance running the proprietary nvidia drivers?
I guess the output of following commands could be
helpful for the maintainer to diagnose this issue.
Could you run them and forward the output to this bug?
which freecad
ldd /usr/bin/freecad
dpkg -S /lib/x86_64-linux
Dear Maintainer,
unfortunately I got the impression that upstream bugs [1] and [2]
would really have been the same and therefore assumed the patch
[2] would actually fix this bug too.
Actually I guess just [1] is the right one - based on the
linked retrace.fedoraproject.org backtrace.
However, on
Control: fixed -1 tigervnc/1.9.0+dfsg-1
Dear Maintainer,
I tried to have another look at it and collected some more details.
I found version 1.9.0+dfsg-1 did not suffer from this crash
(and had no dependency to libunwind8).
I wondered how there the exception handling worked there and found
that
Dear Maintainer,
I tried to get some more information to this crash and
could reproduce it on a Raspberry 3 running a Debian Buster armhf
image created by following script (with "arch: armhf" and linux-image-armmp):
https://salsa.debian.org/raspi-team/image-specs
The crash seems to happen at
Hello Jiang Jun,
I just tried to reproduce the crash. Unfortunately it
did not happen in a minimal VM.
This package google-chrome-stable is from a third-party repository?
Therefore you might be able to have a look at the
output of "coredumpctl list".
There should be a line for the crash with pid
Dear Maintainer,
this seems related to the ATA_DMA=y configuration.
With a seabios package built with ATA_DMA=n,
a directory listing of the install cdrom is possible again.
Also this setting seems to be introduced just with seabios
package version 1.12.0-1.
A google search returned following inf
Dear Maintainer,
I found that I could also reproduce this issue on my AMD Ryzen 7.
Based on the modification date of my VM it was working
with Buster/testing at least at 2018-08-24 at this hardware.
I tested the binaries qemu-system-x86_64 down to 2.12+dfsg-2 and
also current qemu git, all show t
Control: tags -1 + moreinfo
Hello Leos Pohl,
you write when you execute "balooctl enable" you receive
some lines starting with "KCrash: ...".
When this happened, is there a small sad smiley [1] in the
system tray (normally at the bottom, left of the clock)?
If yes, you should receive by clicking
Dear Maintainer,
might this issue be the same as described in this bug:
https://bugs.debian.org/932767
Kind regards,
Bernhard
801 - 900 of 1328 matches
Mail list logo
