On Wed, 20 Feb, 2013 at 16:21:26 GMT, Tom Tromey wrote:
> FWIW we're adding direct support for this to gdb.
> You'll be able to supply backtrace filters with your project just as you
> currently can provide value and type pretty-printers.
Are there docs for this anywhere?
--Ben
--
devel mailing
On 02/26/2013 04:25 AM, Rahul Sundaram wrote:
Hi
On Mon, Feb 25, 2013 at 8:59 AM, Jiri Moskovcak mailto:jmosk...@redhat.com>> wrote:
- yes, the naming is a bit unfair, the stats are not meant to point
fingers or blame some package for being unstable, it's meant to show
which packa
Hi
On Mon, Feb 25, 2013 at 8:59 AM, Jiri Moskovcak wrote:
>
> - yes, the naming is a bit unfair, the stats are not meant to point
> fingers or blame some package for being unstable, it's meant to show which
> packages causes the most problems so we could focus on them
You could use a more neu
> > Are you going to let bugzilla maintainers know somehow? I would
> > assume that once the crash count surpasses a certain threshold,
> > you could add a comment to the bugzilla report:
> >
> > "This has crashed for 100 users, see [FAF URL] for details."
> > "This has crashed for 1000 users, see
On 02/25/2013 12:53 PM, Kamil Paral wrote:
Hi,
since we opened the question of the most buggy applications I would
like
to introduce you the Fedora crash statistics generated from ABRT
reports. It actually doesn't show the most buggy applications, but
the
number of crashes per application encount
On Mon, Feb 25, 2013 at 7:53 PM, Kamil Paral wrote:
> Are you going to let bugzilla maintainers know somehow? I would assume
> that once the crash count surpasses a certain threshold, you could add a
> comment to the bugzilla report:
>
> "This has crashed for 100 users, see [FAF URL] for details.
> Hi,
> since we opened the question of the most buggy applications I would
> like
> to introduce you the Fedora crash statistics generated from ABRT
> reports. It actually doesn't show the most buggy applications, but
> the
> number of crashes per application encountered by users in some period
>
On Thu, 2013-02-21 at 22:41 +, Ian Malone wrote:
> On 21 February 2013 18:24, David Malcolm wrote:
> > On Wed, 2013-02-20 at 08:04 +, Ian Malone wrote:
> >> On 19 February 2013 12:13, David Malcolm wrote:
>
> >>
> >> Question: does a python segfault from a broken script indicate a
> >> p
On 21 February 2013 18:24, David Malcolm wrote:
> On Wed, 2013-02-20 at 08:04 +, Ian Malone wrote:
>> On 19 February 2013 12:13, David Malcolm wrote:
>>
>> Question: does a python segfault from a broken script indicate a
>> python bug as well? The scripting engine shouldn't really be crashin
David> In particular, for scripting languages,
David> it's most useful to be able to extract the script-level backtrace from
David> the C-level stack (i.e. "what was the Python code doing?")
Tom> FWIW we're adding direct support for this to gdb.
Tom> You'll be able to supply backtrace filters with
On 02/20/2013 05:21 PM, Tom Tromey wrote:
"David" == David Malcolm writes:
David> In particular, for scripting languages,
David> it's most useful to be able to extract the script-level backtrace from
David> the C-level stack (i.e. "what was the Python code doing?")
FWIW we're adding direct su
> "David" == David Malcolm writes:
David> In particular, for scripting languages,
David> it's most useful to be able to extract the script-level backtrace from
David> the C-level stack (i.e. "what was the Python code doing?")
FWIW we're adding direct support for this to gdb.
You'll be able t
On 02/20/2013 03:04 AM, Ian Malone wrote:
Question: does a python segfault from a broken script indicate a
python bug as well? The scripting engine shouldn't really be crashing.
Of course--I'd argue such thing is really a blessing in disguise and the
offending script should be added to the Py
On 20/02/13 09:40, Jiri Moskovcak wrote:
> One thing we're struggling with now is the normalization of stacktraces
> which means deciding which functions are important and which are not.
> e.g. for kernel there are stacktraces with a lot of warn_* functions and
> only a few functions are differe
Thank you Dave!
That's exactly the kind of ideas I was looking for.
Just a short summary what we can do on the server (now) to get this
brainstorm going:
- it has all the rpm debuginfo packages, so getting the symbol names or
lines is not a problem (actually we do that even now)
- it can ext
On Tue, Feb 19, 2013 at 10:10:38PM +0100, Jiri Moskovcak wrote:
> >>So if you want to hack this into a tool for use on kernel bugs, go for
> >>it.
> >...and please integrate with abrt! Let's have it all working together :)
>
> - I am all for it, the abrt server is exactly the place where the
On 02/19/2013 10:06 PM, Adam Williamson wrote:
On 19/02/13 10:38 AM, David Malcolm wrote:
On Tue, 2013-02-19 at 11:43 -0500, Dave Jones wrote:
On Tue, Feb 19, 2013 at 07:13:27AM -0500, David Malcolm wrote:
> I have a script that automates some of the workload of
reassigning the
> component
On 19/02/13 10:38 AM, David Malcolm wrote:
On Tue, 2013-02-19 at 11:43 -0500, Dave Jones wrote:
On Tue, Feb 19, 2013 at 07:13:27AM -0500, David Malcolm wrote:
> I have a script that automates some of the workload of reassigning the
> component back to where the bug really is, but it current
On Tue, 2013-02-19 at 11:43 -0500, Dave Jones wrote:
> On Tue, Feb 19, 2013 at 07:13:27AM -0500, David Malcolm wrote:
>
> > I have a script that automates some of the workload of reassigning the
> > component back to where the bug really is, but it currently requires
> > some manual interventi
On Tue, Feb 19, 2013 at 07:13:27AM -0500, David Malcolm wrote:
> I have a script that automates some of the workload of reassigning the
> component back to where the bug really is, but it currently requires
> some manual intervention:
> http://fedorapeople.org/cgit/dmalcolm/public_git/triage.
I've hit gnomeshell problem for 13 times and rtythmbox for 7 times.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
21 matches
Mail list logo
