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