[SATYR PATCH 0/5] Short text backtraces a.k.a. optimized thread generators
Jakub Filak
jfilak at redhat.com
Mon May 27 11:34:09 UTC 2013
On Monday 27 of May 2013 13:15:47 Martin Milata wrote:
> On Mon, May 27, 2013 at 04:52:47 -0400, Jakub Filak wrote:
> > Thank you for the patch set! I will take a look at it. At first glance it
> > looks good to me except sr_core_*_to_short_text functions. They are all
> > same :( Any request for change in formatting will cost much effort.
>
> You're right - I'll try to factor the common code out in the next
> iteration.
>
> > Please, give me a short example how should I use this functions in
> > libreport/reporter-bugzilla>
> > The current implementation is the following[1]:
> > struct sr_gdb_stacktrace *backtrace =
> > sr_gdb_stacktrace_parse((const char **)&content, &location);
> >
> > if (!backtrace)
> > {
> >
> > log(_("Can't parse backtrace"));
> > return 0;
> >
> > }
> >
> > /* Get optimized thread stack trace for 10 top most frames */
> > struct sr_gdb_thread *thread =
> > sr_gdb_stacktrace_get_optimized_thread(backtrace, 10);
> >
> > sr_gdb_stacktrace_free(backtrace);
> >
> > if (!thread)
> > {
> >
> > log(_("Can't find crash thread"));
> > return 0;
> >
> > }
> >
> > /* Cannot be NULL, it dies on memory error */
> > struct sr_strbuf *bt = sr_strbuf_new();
> >
> > sr_gdb_thread_append_to_str(thread, bt, true);
> >
> > sr_gdb_thread_free(thread);
> >
> > truncated = sr_strbuf_free_nobuf(bt);
> >
> > And I hope it won't be necessary to add a big switch and case for each
> > supported backtrace type :) (IMHO reporter-bugzilla should not be aware
> > of crash types)
>
> Well, that's actually the case. I wanted to stay consistent with the
> current interface where there are distinct structures and functions for
> distinct problem types. And this switch needs to be somewhere anyway,
> because satyr needs to know which parser to use to parse the stacktrace.
>
> TBH I don't know how to design an interface that would make it possible
> to operate on the problem data regardless of its type (keeping
> type-specific operations possible too). Suggestions are welcome.
>
> That said, I can implement the _to_short_text function to work with
> struct sr_report instead of individual stacktrace types. That would
> accomplish hiding the problem type specific logic. Not sure if it's the
> right approach though.
>
> Martin
My suggestion:
struct sr_stacktrace *backtrace = sr_stacktrace_parse(
dd_load_text(dd, FILENAME_TYPE),
dd_load_text(dd, FILENAME_BACKTRACE),
location);
if (!backtrace)
return 0;
/* Get optimized thread stack trace for 10 top most frames */
truncated = sr_stacktrace_to_short_text (backtrace, 10);
sr_stacktrace_free(backtrace);
Jakub
More information about the Crash-catcher
mailing list