[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