pkg/report: add a ReportToGuiltyFile method

We cannot unfortunately just substitute Report and invoke Symbolize(),
because in this case a non-emtpy reportPrefixLen may lead to `panic:
runtime error: slice bounds out`.

Create a special external method in the pkg/report package.

2 files changed, 19 insertions, 2 deletions

diff --git a/pkg/report/linux.go b/pkg/report/linux.go
index b0650339e..0e2d8e1a4 100644
--- a/pkg/report/linux.go
+++ b/pkg/report/linux.go
@@ -691,8 +691,11 @@ func (ctx *linux) decompileOpcodes(text []byte, report *Report) []byte {
 }
 
 func (ctx *linux) extractGuiltyFile(rep *Report) string {
-	report := rep.Report[rep.reportPrefixLen:]
-	if strings.HasPrefix(rep.Title, "INFO: rcu detected stall") {
+	return ctx.extractGuiltyFileRaw(rep.Title, rep.Report[rep.reportPrefixLen:])
+}
+
+func (ctx *linux) extractGuiltyFileRaw(title string, report []byte) string {
+	if strings.HasPrefix(title, "INFO: rcu detected stall") {
 		// Special case for rcu stalls.
 		// There are too many frames that we want to skip before actual guilty frames,
 		// we would need to ignore too many files and that would be fragile.
diff --git a/pkg/report/report.go b/pkg/report/report.go
index 7dd9714b3..77244fcd9 100644
--- a/pkg/report/report.go
+++ b/pkg/report/report.go
@@ -259,6 +259,20 @@ func (reporter *Reporter) isInteresting(rep *Report) bool {
 	return false
 }
 
+// There are cases when we need to extract a guilty file, but have no ability to do it the
+// proper way -- parse and symbolize the raw console output log. One of such cases is
+// the syz-fillreports tool, which only has access to the already symbolized logs.
+// ReportToGuiltyFile does its best to extract the data.
+func (reporter *Reporter) ReportToGuiltyFile(title string, report []byte) string {
+	ii, ok := reporter.impl.(interface {
+		extractGuiltyFileRaw(title string, report []byte) string
+	})
+	if !ok {
+		return ""
+	}
+	return ii.extractGuiltyFileRaw(title, report)
+}
+
 func extractReportType(rep *Report) Type {
 	// Type/frame extraction logic should be integrated with oops types.
 	// But for now we do this more ad-hoc analysis here to at least isolate