Hello Jérémy,
Am 29.03.19 um 12:44 schrieb Jérémy Lal:
> This fails too:
> yarnpkg add electron-spellchecker@1.1.2
>
> Are you all doing this on qemu or on real hardware ?
> On i686 ?
> I'm asking because buster does not support i586, nor does nodejs,
> and it seems qemu defaults to something <
Control: fixed 902893 0.9.13-6
Dear Maintainer,
just tried to make a more readable stack out of these
backtraces.
This one points to function snapshot_stack_list,
and this one saw also a fix some time ago.
Therefore marking as fixed.
Kind regards,
Bernhard
Control: fixed 857498 0.9.13-6
Dear Maintainer,
just tried to make a more readable stack out of these
backtraces.
So that one points to function "record_CW" and a buffer
overflow in that function got fixed in [1],
like mentioned in last message.
Therefore marking as fixed.
Kind regards,
Control: retitle 925553 audacity: with ssh X-forwarding:
PaAlsaStreamComponent_BeginPolling: Assertion `ret == self->nfds' failed.
Hello Jeff Cliff,
I looked at this backtrace without deeper knowledge of
audacity and the problem might not be a segfault in
mentioned funciton, instead a SIGABRT
Control: tags 925577 + upstream patch
Dear Maintainer,
I tried to have a look at this crash and
could reproduce the issue.
It seems a pointer to the name-parameter value is queried
from libconfig9 and some lines later this pointer gets freed.
Unfortunately libconfig9 tries to free the pointer
Hello Jérémy Lal,
unfortunately yes, it still crashes.
Attached file shows a test starting with a minimal up-to-date
Buster i386 qemu VM, and as far as I see after the crash
/usr/local/lib/node_modules does not exist and following command
shows just these files in ~/node_modules, so I can assume
Hello Everyone,
I tried to track down when this crash got introduced into testing.
It still did not crash at 2019-01-31.
(While still not succeeding because of a linker error.)
The next day these packages transitioned into testing:
- apparmor iso-codes libapparmor1 libsqlite3-0 sysvinit-utils
Control: fixed 925539 3.26.1-1
Dear Maintainer,
unfortunately realised just now that there is
already a newer version 3.26.1-1 in unstable which
contains both patches - should therefore fix the issue.
Kind regards,
Bernhard
Hello Mattia,
Am 26.03.19 um 15:32 schrieb Mattia Rizzolo:
> On Tue, Mar 26, 2019 at 01:40:47AM +0100, Bernhard Übelacker wrote:
>> Therefore gdb may not show the line information I guess.
>>
>> Maybe you can please send the output of the disassemble
>> and x com
Hello David Bremner,
now the hint in the subject makes sense ;-)
I can perfectly reproduce the crash now.
I compared the arguments from the build log [1]
and reduced it until the crash happens and
the important part is the "-D BLISS_USE_GMP".
Therefore /usr/share/doc/bliss-doc/examples/Makefile
Hello Mattia Rizzolo,
I am just looking at some random crashes, and
tried to detect at which exact instruction
in libgtkmm-2.4.so.1 we are in the given backtrace.
That function contains just two instructions.
But the backtrace from the core dump tells we crashed
at ...459, which is in the middle
Hello David Bremner,
>> Maybe something got lost in the input file,
>> so you could attach it to the email?
> ok
Thanks for the file, but unfortunately that makes no
difference - works fine in my test VM.
>> Is the backtrace you copied all of the output or
>> did you remove the frame in
Hello Guenter Grodotzki,
I am not the maintainer for tilda, just got here and
tried to collect some more information.
For some reason your upstream report contains one
(interesting) lines more than made it into the debian report.
Just as a hint: the real important information has to be
queried
Hello David Bremner,
I just tried to reproduce this crash, while I am not
involved in packaging and without knowledge of bliss.
I always this output:
benutzer@debian:~$ bliss myciel3.col
Generator: (2,4)(3,5)(7,9)(8,10)
Generator: (1,2)(3,4)(6,7)(8,9)
Nodes: 6
Leaf
Hello Dimitris, hello di dit,
I think the issue is that freefem++s configure activate
AVX instructions when the build CPU supports it.
I could reproduce the crash in a Buster amd64 qemu VM, that
unintentionally did not support AVX (while the VM host would).
That led to following backtrace:
Control: tags + 924496 unreproducible
Hello Fred,
Am 20.03.19 um 22:22 schrieb Fred Korz:
> I loathe Heisenbugs! Sorry for the time waste.
>
> I tried the same IPod on my home system which runs vanilla debian
> testing and has the same version (3.4.3-2) of rhythmbox. I could not
> reproduce
Hello Thorsten,
Am 24.03.19 um 01:46 schrieb Thorsten Glaser:
> Bernhard Übelacker dixit:
>
>> Now I wonder if a x32 binary doing a syscall getrusage to a 64bit
>> kernel is supposed to supply memory like "long" would be 8 bytes?
>
> The x32 kernel i
Dear Maintainer,
I just tried to get some more information.
Following backtrace, little after the stack smashing happend, I could
reproduce with a amd64 qemu VM crossgraded from Buster amd64 to x32. :-)
That "struct rusage" has some elements of type "long" [1].
In gdb sizeof shows 4 bytes for
Forgot to attach the file with some more information.
# Buster amd64 qemu VM 2019-03-22
apt update
apt dist-upgrade
apt install dpkg-dev devscripts systemd-coredump xserver-xorg dbus-x11 lightdm
openbox evince gdb evince-dbgsym libglib2.0-0-dbgsym libevview3-3-dbgsym
libevdocument3-4-dbgsym
Control: reassign 924029 libpoppler-glib8 0.71.0-3
Control: affects 924029 evince
Control: tags 924029 + patch upstream fixed-upstream
Dear Maintainer,
I just tried to reproduce the issue and received the crash below.
For some reason poppler_annot_get_modified returns a null pointer,
instead of
Control: tags 924050 + upstream fixed-upstream patch
Dear Maintainer,
I tried to reproduce this crash, and received one with
this example file [1].
But due to the lack of the submitters original
file, this crash might be different.
However, following crash got already fixed upstream [2][3]
and
Dear Maintainer,
just tried to collect some more information.
I could reproduce the issue inside a qemu amd64 VM,
running current Buster.
Not every attempt resulted in a crash.
Indeed "file" seems to report just the first 80
character of the command line.
Like gdb does too when it opens a core
Dear Maintainer,
just trying to get some more information from the attached core.
It looks like the pointer stored in pPixmap->drawable.pScreen got
somehow overwritten and was then invalid, therefore received a SIGSEGV.
Kind regards,
Bernhard
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at
Dear Maintainer,
so both issues have the same root and upstream commited this,
to open the dbus interface as soon as possible.
https://cgit.kde.org/plasma-workspace.git/commit/?id=9a4bb220c162f031b4d45ed04f9e156b6d0b852e
Kind regards,
Bernhard
Control: tags 924402 + upstream
Hello Dimitry,
thanks for your quick response.
> Can I ask you to submit your patch upstream to [1], either as a pull
> request or as a simple issue?
I just created this pull request:
https://github.com/annulen/webkit/pull/803
Kind regards,
Bernhard
Hello Everyone,
I think the same issue manifested in bug #924402.
To me it looks like the problem started when -fpermissive
got added to get the i386 build working again.
Without that a compiler error "invalid conversion" got hit,
because a derived class missed the attribute fastcall.
In bug
Control: tags 924402 + patch
Hello Everyone,
I continued to look into the "invalid conversion" and think
the problem is member JSImageConstructor::construct is
missing the __attribute__((fastcall)) aka JSC_HOST_CALL.
Attached patch to qtwebkit-opensource-src-5.212.0~alpha2
removes the
Hello Everyone,
might this report be the same issue as following?
https://bugs.debian.org/922608
Kind regards,
Bernhard
Control: merge 908549 924448
Hello Kingsley,
> It's OK with me if you merge my bug report, #924448, with it.
Ok, I am trying to do so.
> ... why
> 1.) Frederic MASSOT wrote
> "The fix is built-in for versions 2.10"
> at
>
Hello Fred Korz,
I just tried to get some more information out of backtrace,
without having an iPod or being involved on packaging rhythmbox...
But am I right this "Debian Release: rodete" is a version
of gLinux - Googles internal rebuild of Debian testing?
Can this be downloaded somewhere?
And
Hello Kingsley G. Morse Jr.,
> My main concern?>> The normal way of eliciting a back trace from> within gdb
> didn't work.> > The non repeating lines were reported by defining> a function
> in gdb and logging output to a file.
You can start gimp that way to get a backtrace:
script -c
Hello Kingsley G. Morse Jr.,
the backtrace of the crash you reported seems to be quite
similar to another bug reported in #908549.
Can you confirm that you just forwarded the top 19 frames
and that they kind of repeat all the time?
Kind regards,
Bernhard
#908549:
reassign 923720 libappstreamqt2 0.10.6-2
Control: reassign 923720 libappstreamqt2/0.10.6-2
Control: affects 923720 plasma-discover
Control: fixed 923720 libappstreamqt2/0.11.3-1
Control: fixed 923720 plasma-discover/5.10.5-1
Control: tags 923720 + upstream fixed-upstream patch
Hello Everyone,
tried to get some more information from
Hello Andriy Grytsenko,
tried to reproduce but could not find the file "meteoCNS" anywhere on the net.
Instead found following file that triggers the same crash stacktrace:
openclipart-svg:
/usr/share/openclipart/svg/recreation/religion/christianity/coat_of_arms_of_anglica_01.svg
Control: tags 908549 + fixed-upstream
Hello,
Just adding the fixed-upstream tag.
The patch might be small enough to be
cherry-picked to version 2.8 in buster?
https://gitlab.gnome.org/GNOME/gimp/commit/a2c20b15392d456b36afdc9074d1176f02403b29
Kind regards,
Bernhard
Control: tags 920139 + unreproducible moreinfo
Hello Adrian Immanuel,
I am sorry for the late reply.
First a question: Do you still observe this fault?
I took a look today inside the md5sums you supplied
and tried to reproduce this setup inside a VM.
Unfortunately I found following old
Package: plasma-workspace
Version: 4:5.14.5.1-1
Severity: normal
Tags: patch upstream
Dear Maintainer,
I found that the splash screen takes longer than some month ago and did
some investigations that led to following two upstream bugs I reported.
Bug 405444 - ksplashqml hits its hard timeout
Hello Sandro,
Am 05.03.19 um 00:43 schrieb Sandro Knauß:
> Btw. please use the bugnumber-qu...@bugs.debian.org rarely, because than
> maintainers like me don't gets any mails, that's why I missed your
> conversation.
Sorry for using -quiet - Pino Toscano made me already
aware to avoid -quiet.
Control: reopen 921959
Control: reassign 921959 tftpd 0.17-22
Hello Everyone,
I hope it is ok to reopen and reassign this report to package tftpd,
which I assume Alison Chaiken has installed, based on the addresses
in the supplied backtrace.
I assume this is the result of some implicit "Object
Package: vlc-plugin-video-output
Version: 3.0.6-1
Severity: normal
Tags: upstream upstream-fixed patch
Dear Maintainer,
I received a "SIGFPE, Arithmetic exception." while the menu of a to
hard disk copied VIDEO_TS folder was playing and then pressing space.
For some reason I did not get that
Package: udisks2
Version: 2.8.1-3
Severity: normal
Dear Maintainer,
I received a crash of udevd by doing an unmount of a ntfs partition
of an usb stick via the plasma systray icon.
As far as I see in this case in function udisks_linux_drive_object_get_block
is a call to
Ok, so the package corekeeper would be an option?
Is gdb-minimal also already too much?
Kind regards,
Bernhard
PS.: please leave the bugs email as CC or To. ;-)
Hello Zac Morris,
you still may consider installed systemd-coredump and
when it happens again provide the complete lines reported
by journalctl related to the crash.
I, as I said not deeply involved in dnsmasq and just trying to
collect some information, tried to replicate your configuration,
but
Betreff:Re: Bug#921310: dnsmasq "segment fault" bug when total conf
files size is too large
Datum: Sat, 9 Feb 2019 15:31:52 -0500
Von:Zac Morris
An: Bernhard Übelacker
Yeah, I didn't know how to update the case. Is there a web front-end for
updating/tracking the case
Hello Adrian,
maybe one of the installed source files lead
to a bad gschemas.compiled file?
Could you create a file with the md5sums of all
the xml files that seem to get combined into that
gschemas.compiled file.
md5sum /usr/share/glib-2.0/schemas/* >
Hello Zac Morris,
I am not the maintainer and just trying to get some
more informations of the segfault.
Unfortunately I think you need to provide some more
details on your used configuration.
The line shown in dmesg about the segfault could
also be of help already.
Otherwise you could also
Hello Jiri Palecek,
I could reproduce this issue also on amd64.
It looks intentional and seems like a security consideration
to make no crash dumps and is caused by this line:
kdesu.cpp:83: prctl(PR_SET_DUMPABLE, 0);
However, you may temporarily add SUID to gdb, then gdb
will run
Hello Thomas,
Am 05.02.19 um 20:50 schrieb Thomas Gaugler:
...
> I thought to use the momentum around secure boot within Debian [2] for
> supporting it within win32-loader as well.
>
> The basic idea is to replicate the following commands in win32-loader:
> $ # Copy
Am 04.02.19 um 13:42 schrieb Didier 'OdyX' Raboud:
> Le mardi, 15 janvier 2019, 17.39:00 h CET Bernhard Übelacker a écrit :
>> If such a system is detected, maybe a warning could be added?
>
> Sure. I suggest this would be done very early, but have no clue how to detect
Control: tags 920139 + moreinfo
Hello Adrian,
Am 03.02.19 um 09:24 schrieb Adrian Immanuel Kiess:
> The bug is, like I see it, that the applications cannot find the
> gsettings schema directory.
>From my point of view it might be more the file gschemas.compiled
inside that directory. Does that
Hello Jean-Dominique Frattini,
I am not involved in packaging any of these packages,
but I noted that you opened the last three days nearly
the same issue against three different packages?
What are you trying to achive that way?
And you noted versions contained in current Buster,
but you claim it
Dear Maintainer, hello Wookey,
just tried to find out where this exception comes from.
And is looks like it originates in libTKTopAlgo.so.7
(libocct-modeling-algorithms-7.3 / opencascade).
Having no deeper knowledge of either freecad or opencascade,
I can just guess if the next step would be to
Control: fixed 920247 libreoffice/1:6.1.5~rc1-2
Hello Gennadiy,
> In 1:6.1.5~rc1-2 such files open just fine, thank you!
I am glad to hear that, your description sounded similar to
another bug #919297 that was also resolved by the new version.
But the thanks should go to the maintainer or to
Hello Everyone,
I own a qnap ts-119pII with a similar cpu.
See attached file with several debugging attempts.
With my limited assembly knowledge I got to this instruction,
where the backtrace command still shows all of the stack:
(gdb) bt
#0 0x03718a2c in stg_returnToStackTop$def ()
Hello Rokas,
I just tried to collect some more information and
could reproduce the crash with Qt 5.11.1+dfsg-8.
With version 5.11.2+dfsg-3 and current 5.11.3+dfsg-2
I was not able anymore to reproduce.
Can you confirm that the bug is not visible
anymore on your installation?
Kind regards,
Hello Adrian Immanuel Kiess,
I tried to search the net about this message:
"GLib-GIO-ERROR: No GSettings schemas are installed on the system"
And found results pointing to .../share/glib-2.0/schemas/.
Therefore renamed following file:
/usr/share/glib-2.0/schemas/gschemas.compiled
And
Hello Gennadiy Starostin,
just trying to collect some more information for the maintainer.
Can you observe this with the latest update to 1:6.1.5~rc1-2.
If yes, can you provide which desktop environment you use and
if it is running on Xorg or Wayland?
Kind regards,
Bernhard
Hello Piviul,
On Tue, 22 Jan 2019 19:23:57 +0100 Piviul wrote:
> Dear Maintainer,
> I have followed the Davide instructions and even my libreoffice was consuming
> all the amount of memory... it is very strange you couldn't reproduce it!
I am not a maintainer, I just tried to collect
some more
Hello Vincas Dargis,
I guess the provided information may not be enough for the
maintainer to find the cause or make a fix.
And I am just curious, but this "0x2f9b8" are just the "195000" from
the kernel log line? I am not sure, but would here not make
0x7f9cf2783000 - 0x7f9cf2803676 = 0x80676
Hello all,
> Note that other declarations changed between 1.44.4 and 1.44.5 so
> there may be other similar problems.
This looks related to upstream change to take care
of debian bug #99. This change looks like it got
reverted again.
Hello Everyone,
> > > > Is this supposed to work at the moment or already known,
> > > > or should I report it, if yes to which package.
> > >
> > > I think flash-kernel is probably the right starting point, although it
> > > might turn out to be a kernel issue.
> >
> > It's a kernel issue that
Hello Everyone,
I also tried to install current testing to a qnap ts-119P II.
On Tue, 29 Jan 2019 21:43:50 +0100 =?UTF-8?Q?Uwe_Kleine-K=c3=b6nig?=
wrote:
> On 1/27/19 12:13 PM, Lukas Straub wrote:
> > Package: linux
> > Version: 4.19.12-1
> >
> > Hello Everyone,
> > I tried the latest Buster
Hello all,
> Any idea how other programs are being patched to cope with this?
This issue sounds similar to following older bugs, but
the actions taken there might not be applicable here.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917293
Control: tags 920467 + upstream patch
Dear Maintainer,
tried to have a look at the stack smashing.
It happens inside a call to g_stat/stat64.
The reason is as far as I see that in nconfig.c the type
GStatBuf has just a size of 88 bytes, therefore no
more memory is reserved. Inside nstat or
Control: fixed 920235 apache2/2.4.23-4
Control: found 920235 apache2/2.4.23-5
Control: found 920235 apache2/2.4.37-1
Dear Maintainer,
I tried to find out when this started inside an amd64 qemu VM
and got to these versions:
Stretch/testing of date 2016-10-10 with apache2/2.4.23-4 was ok.
Hello marc, dear Maintainer,
a workaround could be to just to change the default stack
size in the script calling logrotate which is on stretch
maybe /etc/cron.daily/logrotate.
So maybe following line before calling
logrotate could be sufficient?
ulimit -s 16384
(I have not tested this.)
Control: tags 920179 + upstream patch
Dear Maintainer,
I tried to have a look at this and think I found something.
This seems to be a case of implicit function declaration
defaulting to int as return type but real function returns
a pointer. Therefore an invalid pointer gets later used.
This
Control: fixed 918106 logrotate/3.14.0-4
Control: tags 918106 = upstream fixed-upstream
Dear Maintainer, Hello Marc,
> (gdb) print log->numFiles
> $1 = 2122453
> stack size (kbytes, -s) 8192
That would match my assumption.
A maximum stack size of 8192 kb * 1024 /
Hello Davide,
> With the debug symbols libreoffice is becoming slow and a lot more
> memory have been used...
> I have killed calc when I have only 121 MB of free memory and the swap
> was partially used.
>
> The file generated: 919297_libreoffice_gdb_2019-01-21_11-01-29.txt is
> very small.
Hello Marc,
> but i don't see much more withour bt full, do i understand correctly ?
I just wanted to see the line from dmesg, where we can see which
address caused the error. And wanted to see all for the same crash.
And I had not realized that the callc instruction really have to
write its
Hello Ian,
additionally I found a new installer in [1].
Therefore I tried to install current buster directly.
The relevant part of qcontrol below.
Unfortunately the installation reported a failure later.
Is this supposed to work at the moment or already known,
or should I report it, if yes to
Dear Maintainer,
found while searching for another bug that upstream
report [1] that looked familiar.
That upstream report points to the same source line
and is written to be resolved by [2] with topic dateformat.
This patch seems included first in debian stretch with
version 3.11.0-0.1 [3].
My
Control: retitle 918106 logrotate: segfaults in rotateLogSet
Hello Marc,
I am sorry, but my advice to use 'bt full' makes
following commands to show the state of frame #1.
Therefore can you repeat the "coredumpctl gdb 754"
without the "bt full"?
Kind regards,
Bernhard
Control: forcemerge 886777 907972
Control: tags 886777 + upstream fixed-upstream
Dear Maintainer,
upstream applied a fix to this stack smashing.
If no new upstream version is released and enters buster,
this patch [1] might be a candidate for cherry-picking.
Kind regards,
Bernhard
[1]
Hello Francois Marier,
this looks like a duplicate of bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919765
Kind regards,
Bernhard
Dear Maintainer,
just a confirmation.
I tested a new Stretch installation and upgraded to current
Buster/testing and it went through without any issue.
Thank you very much.
Kind regards,
Bernhard
root@qnap-119p-ii:~# uname -a
Linux qnap-119p-ii 4.9.0-8-marvell #1 Debian 4.9.130-2 (2018-10-27)
Hello André Isidoro Fernandes Esteves,
one more possibly useful thing to consider:
If you could install a core dump collector like package
systemd-coredump, then the system would store a file of
each crash for later inspections.
Also it would already print a backtrace in the system journal.
Control: tags -1 + moreinfo
Hello Daniel Sutil,
just got to this bug report.
Do you still get this crash?
If it got solved for you, you could close this bug by sending
an email to 904094-d...@bugs.debian.org
If you still get it, you could follow these steps:
- install package gdb
- open a
Control: forward -1 https://bugs.kde.org/show_bug.cgi?id=359664
Control: tags -1 upstream fixed-upstream
Control: fixed -1 plasma-workspace/4:5.12.0-2
Dear Maintainer, hello Michael Meier,
from the segfault line I would suspect that this
crash happened in sniproxy.cpp, line 273.
There image may
Hello Pino,
On Sun, 20 Jan 2019 15:28:44 +0100 Pino Toscano wrote:
> What is the reason why you send the messages to nnn-quiet@, instead
> of nnn@? -quiet means that the maintainer does *not* get any
> notification, so none of your emails reach the maintainer mailing list.
> Also, if the user
Hello Steve,
I suspect this lookup error is because you have
knewstuff packages in version 5.54.0-1 installed,
which is not yet in testing (and barely in unstable).
Could reproduce it with packages below installed:
Dear Maintainer,
I tried to find out where this stack in message #25
would point to, if it may help.
The failing call to free, I guess, would be in
function rotateLogSet in logrotate.c, line 1749.
1748for (i = 0; i < log->numFiles; i++) {
1749free(rotNames[i]->firstRotated);
Hello Lisandro,
> Do we have an upstream bug number?
Mateus Barbosa mentioned this one already when opening the bug:
https://bugreports.qt.io/browse/QTBUG-72488
Kind regards,
Bernhard
signature.asc
Description: OpenPGP digital signature
Control: affects 919607 + krita
Dear Maintainer, hello Mateus Barbosa,
there is another debian bug report that looks similar [1].
As far as I see this is a Qt upstream bug, but not yet resolved.
Krita upstream has two commits [2] to workaround that issue
until a fixed Qt version gets available.
Control: tags 919030 + upstream
Dear Maintainer, hello John Scott,
I had a look and think I have found the issue.
Each open document has a object of type
KileDocument::TextInfo::TextInfo.
That contains a QMap "m_dictStructLevel".
This map is given by reference to the parser thread
in an object
Hello Fernando Toledo, Dear Maintainer,
On Wed, 16 Jan 2019 01:22:31 -0300 Fernando Toledo
wrote:
> > I need help to know how to get more info/debug.
Maybe you can install a core file collector.
On stable or testing I would propose systemd-coredump,
but that is not available in jessie.
The
Hello Tom Brown, dear Maintainer,
I just tried to reproduce this on a amd64 qemu EFI VM.
>From your description is not clear if you received on reboot
the menu to select between "Windows 10" or
"Debian GNU/Linux - Continue with install process"?
If that is missing you might add the output of
Package: crash
Version: 7.2.3+real-2
Severity: normal
Tags: upstream
Dear Maintainer,
I experienced a crash with kdump-tools installed and wanted to
report that crash (#919290).
I tried to have a look at the collected core and found that crash
gives an error message and exits (see below).
This
Package: src:linux
Version: 4.19.12-1
Severity: normal
Dear Maintainer,
I received following crash while having a cifs filesystem mounted
from a qemu VM running on the same host.
Unfortunately forgot to unmount and shut down the VM.
Then after some minutes system froze and restarted.
If it may
Control: fixed 918950 1:2.12+dfsg-3
Control: tags 918950 + upstream
Hello Jakub Wilk, dear Maintainer,
just tried to find out when this started and found it
working with 2.12.
Then tried to build it from git and a bisect leads to
following commit:
eeae6a596b0efc092f5101c67683053e245e6250
Hello Markus Blatt, dear Maintainer,
I just tried to reproduce the crash inside a minimal test VM,
with a new empty file, by these steps:
- Datei
- Neue Datei
- Weiter - Weiter - Weiter - Weiter - Weiter - Anwenden
- test.xml - Speichern
- Berichte - Steuer-Bericht & Elster Export
- Optionen
-
Hello Joe Ma,
just to be sure, you did execute the proposed gdb command
while kate was frozen?
Kind regards,
Bernhard
Control: fixed 911392 linux/4.19.12-1
Dear Maintainer,
did an update on that testsystem and the error
does not show up with at least 4.19.12-1.
Kind regards,
Bernhard
Hello Michael Hatzold,
I tried to have a look and guess gimp received from some
plugin feedback in form of a malformed GIMP_PDB_INT16ARRAY.
Unfortunately this may not be enough information
for the maintainer to fix it.
Could you please provide more details on which exact
steps you took to
Hello,
might this just another cases of similar bugs 908924/908382/911392?
Is this still an issue with current version 4.19.12-1 ?
Kind regards,
Bernhard
signature.asc
Description: OpenPGP digital signature
Hello Johannes, dear Maintainer,
tried to reproduce the hang here but just got
a NV4B and NV108, while your NVA5 is somewhere between,
and with both I did not get such a freeze ...
I fear I cannot help on this issue any deeper.
Maybe some Qt or Nouveau developer need to have a look.
Kind
Dear Maintainer,
the bugs 912921/913133 these two bugs should be merged with are already
archived. Is it ok to just close them by 91-cl...@bugs.debian.org ?
Kind regards,
Bernhard
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
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
801 - 900 of 1271 matches
Mail list logo
