related work & correlation of problem data

[Paul Tagliamonte]

On Tue, Oct 01, 2013 at 03:48:47PM +0200, Martin Milata wrote:
> Hello firehose-devel,

Hey there Martin,

> I have recently stumbled upon the firehose format and surrounding
> ecosystem and realized that it somewhat overlaps with what we've been
> working on within the Automatic Bug Reporting Tool project [1]. I'll
> take the liberty of briefly introducing our format and software:
> 
>  * uReport is a JSON-based format for describing run-time software
>    problems. It aims to contain no anonymous data and be useful for
>    automatic processing. There's no formal specification but some
>    information can be found at [2].
> 
>  * FAF is the main consumer of uReports. It performs some analysis on
>    them (e.g. resolving addresses to source code locations, or grouping
>    reports likely caused by the same bug), and provides a web interface
>    with statistics. The instance for Fedora is available at [3]
> 
>  * satyr is a library (in C with Python bindings) for creating and
>    manipulating uReports. It is used by ABRT to create uReports and by
>    FAF to perform clustering on them. In terms of type of problems, it
>    currently supports crashes of native binaries that produce core dump,
>    uncaught python exceptions, and kernel oopses.

ACK. Is patching whoopsie-daisy to output this format on the roadmap?
I'd love to continue to foster collaboration from Fedora / RH -> Debian / Ubuntu

(doubly so if this is going to integrate with Firehose!)

> Due to the slightly different goals of both projects and substantial
> amount of code already written, it seems unclear whether it would be
> beneficial to directly collaborate. However, it might be interesting to
> find out if we can obtain anything useful by correlating the reports
> from static analyzers and from crashes on users' computers.

It would indeed. I plan on producing Firehose for the Debian archive
once I have the cycles to finish the management code.

> To be more concrete, we were thinking of doing something like this:
>
>  * Run static analysis on a particular package, keep only the issues
>    that would correspond to a crash if it occurred.

Hummmmm. This might be a toughie. Figuring out what may cause a crash
turns out to be hard(tm), but keeping *all* the data would be a snap.

>  * Take the crash reports for that package.
>
>  * For every static analysis result, try to find a crash report with the
>    same source code location.

Interesting. This seems like it could be quite nice, if we keep debug
headers and have the lineno / bt

> Finding such pair would mean that the static analysis issue is not a
> false positive and also the additional information from the static
> analysis (e.g. trace) could be added to the crash report.
> 
> Does it make any sense? Would the results of such analysis be useful?

I'm extremely intrigued.

> Best regards,
> Martin Milata
> 
> [1] https://github.com/abrt/abrt/wiki/ABRT-Project
> [2] https://github.com/abrt/faf/wiki/uReport
> [3] https://retrace.fedoraproject.org/faf/summary/
> _______________________________________________
> firehose-devel mailing list
> firehose-devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/firehose-devel

Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte <paultag at debian.org>
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `-     http://people.debian.org/~paultag
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.fedoraproject.org/pipermail/firehose-devel/attachments/20131001/98bd11d5/attachment.sig>