[ltt-dev] Crash in lttv-0.12.12

[Gregory Haskins]

Mathieu Desnoyers wrote:
> And here is the offending code :
>
> eventhooks.c :
>
> int before_execmode_hook_trap(void *hook_data, void *call_data)
>
>
>   if (tfc->tf->name != LTT_CHANNEL_KERNEL)
>     return 0;
>   minfo = marker_get_info_from_id(tfc->tf->mdata, e->event_id);
>   g_assert(minfo != NULL);
>   if (minfo->name == LTT_EVENT_TRAP_ENTRY
>       || minfo->name == LTT_EVENT_PAGE_FAULT_ENTRY
>       || minfo->name == LTT_EVENT_PAGE_FAULT_NOSEM_ENTRY) {
>     trap = ltt_event_get_long_unsigned(e, lttv_trace_get_hook_field(th, 0));
>   } else if (minfo->name == LTT_EVENT_TRAP_EXIT
>              || minfo->name == LTT_EVENT_PAGE_FAULT_EXIT
>              || minfo->name == LTT_EVENT_PAGE_FAULT_NOSEM_EXIT) {
>     trap = ts->cpu_states[cpu].last_trap;
>   } else
>     return 0;
>
>   guint trace_num = ts->parent.index;
>
>   /* Well, the process_out existed : we must get it in the process hash
>    * or add it, and draw its items.
>    */
>    /* Add process to process list (if not present) */
>   guint pl_height = 0;
>   HashedResourceData *hashed_process_data = NULL;
>   ProcessList *process_list = resourceview_data->process_list;
>
>   hashed_process_data = resourcelist_obtain_trap(resourceview_data, trace_num, trap);
>
> we end up calling resourcelist_obtain_trap() with a trap id of -1.
>
> I bet the trace first has a trap exit event, without any prior trap
> entry. Therefore, the last_trap is probably set to -1, which is used as
> trap id.
>
> I fixed it in LTTV 0.12.14. It seems to work fine for me now.
>
> I also took care of fixing the irq and softirq code, which has the same
> problem.
>   

Thanks Mathieu!

I will update the binary in my build-service.

On that topic, I've been meaning to drop a line that Ive been
maintaining the RPMs for the userspace components there.  I currently
only have opensuse supported, but the build service technically supports
quite a few distros.  I just need to sort out a bug in the spec file
that is causing other distros like Fedora to fail (patches welcome!).

But long story short: keep me updated when a new release comes out and I
will update the RPMs.

-Greg



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 266 bytes
Desc: OpenPGP digital signature
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20090515/f315b647/attachment-0003.pgp>