t;
> > > > > -- Původní zpráva --
Od: SérgioBasto
Komu: d
On 01/02/2017 07:26 PM, jfi...@fedoraproject.org wrote:
Isn't this related to no free disk space?
I've seen some strange mmap related crashes when a process mmaped a sparse
file and disk ran out of free space.
This can only happen with writes. This one is a read, if I pieced the
available
eport must be anonymous and
automatically submitted.
Regards,
Jakub
-- Původní zpráva --
Od: Florian Weimer
Komu: Development discussions related to Fedora
Datum: 29. 12. 2016 10:29:37
Předmět: Interpreting FAF reports
"Any idea what this i
vodní zpráva --
Od: SérgioBasto
Komu: devel@lists.fedoraproject.org
Datum: 29. 12. 2016 15:53:51
Předmět: Re: Interpreting FAF reports
"BTW
I received ABRT report for package mlt has reached 100 occurrences
Packages: mlt
Function: QObject::disconnect(QObject const*, char const*, QOb
On Thu, 29 Dec 2016 14:52:29 +, Sérgio Basto wrote:
> BTW
> I received ABRT report for package mlt has reached 100 occurrences
> Packages: mlt
> Function: QObject::disconnect(QObject const*, char const*, QObject
> const*, char const*)
> First occurrence: 2016-12-17
> Type: core
> Count:
Hi,
>
> Is there a way to discover who is submitting these crash reports and
> what they are trying to do?
Unfortunately, there is no full report (e.g. bugzilla) created via ABRT yet,
so there is no way to discover who is submitting these crash reports.
FAF reports are created from uReports wh
BTW
I received ABRT report for package mlt has reached 100 occurrences
Packages: mlt
Function: QObject::disconnect(QObject const*, char const*, QObject
const*, char const*)
First occurrence: 2016-12-17
Type: core
Count:100
URL:
http://retrace.fedoraproject.org/faf/reports/bthash/43f
Any idea what this is about?
https://retrace.fedoraproject.org/faf/reports/1154372/
To me that looks like a combination of several factors. First of all,
the backtrace generation likely used incorrect debuginfo data because
the backtrace is impossible. Stack corruption is unlikely to yield
