Feature #7624
closed
Visualize multiple threads in error traces
Added by Evgeny Novikov over 7 years ago.
Updated over 7 years ago.
Description
Recently we discussed a more common but in addition more user-friendly representation of error traces. It assumes that error traces include execution from multiple threads, i.e. edges have an additional attribute holding a corresponding thread identifier.
Visualization of error trace parts for corresponding threads should be done like in the attached picture but any more impressive means are welcome. The main ideas are:
- Show what thread is executed using narrow bars between line numbers and source code. The maximum width of bars correspond to the maximum number of threads.
- Start all threads with zero offset non depending on current real offset for corresponding edges.
- Additionally separate all threads from each other with horizontal lines.
- Allow to quickly hide/show continuous parts of threads (not everything from a given thread) - this isn't shown on the picture.
- Show popups with thread identifiers on hovering corresponding bars - I am not sure that this will be very valuable but who knows.
Please, do not pay much attention to other "nice" things like "..." here.
Files
I attached an example of an error trace with almost real threads from Pavel. So this issue can be implemented without waiting for #7622. Nevertheless they should be tested together as well.
- Due date set to 10/25/2016
- % Done changed from 0 to 90
Implemented in commit 0794d17 of "better-unsafes-and-marks" branch.
Show what thread is executed using narrow bars between line numbers and source code. The maximum width of bars correspond to the maximum number of threads.[/quote]
I put narrow bars before line numbers - it looks better.
Additionally separate all threads from each other with horizontal lines.
Simple approach with css "border" failed. So now I don't know how to do it. And I don't think it will be usefull - colors are bright and visually users can understand when thread is changed.
Allow to quickly hide/show continuous parts of threads (not everything from a given thread) - this isn't shown on the picture.
It is already can be hidden/shown by hiding/showing body of "ldv_thread_create" finction.
Show popups with thread identifiers on hovering corresponding bars - I am not sure that this will be very valuable but who knows.
Popups is not good idea for error trace - it is already overloaded by other features. I supposed to put description of wich thread identifier has each color, but I didn't find place for it.
Okay, let's assume that mentioned questions are answered quite well and maybe think more about this later.
But I encountered an important issue with visualization. For instance, for attached error trace "unsafelinux:drivers:clk2 report files.tar.gz" the initial offset for the second thread isn't 0.
Evgeny Novikov wrote:
Okay, let's assume that mentioned questions are answered quite well and maybe think more about this later.
But I encountered an important issue with visualization. For instance, for attached error trace "unsafelinux:drivers:clk2 report files.tar.gz" the initial offset for the second thread isn't 0.
Can you explain about offsets? As I understood from picture each new thread's offset is (previous offset + 1).
Vladimir Gratinskiy wrote:
Evgeny Novikov wrote:
Okay, let's assume that mentioned questions are answered quite well and maybe think more about this later.
But I encountered an important issue with visualization. For instance, for attached error trace "unsafelinux:drivers:clk2 report files.tar.gz" the initial offset for the second thread isn't 0.
Can you explain about offsets? As I understood from picture each new thread's offset is (previous offset + 1).
Maybe this is about offsets for bars while I am speaking about offsets for source code. And these offsets should always start from 0 for each new started thread (this is actually the most valuable feature introduced by threads visualization). But if a thread will be interrupted by another one then its offset should be remained the same after interruption as it was before interruption.
- Due date changed from 10/25/2016 to 11/16/2016
- Status changed from New to Resolved
- % Done changed from 90 to 100
Implemented in branch 'better-unsafes-and-marks'.
- Status changed from Resolved to Closed
Also available in: Atom
PDF