IRQ tables, trap tables and softirq tables can grow. The copy mechanism for
these is not correct when saving/restoring state, because it uses always the
name table size (which grows) to copy the saved/restored state snapshots.
We should change the g_new allocations for g_arrays, and use the array length as
boundary for the copy rather than the name table len.
TODO / FIXME !
I currently increased the initial irq name table size to 512 to deal correctly
with ARM. This is a dumb temporary fix.
Chris Smowton [Fri, 27 Nov 2009 17:18:31 +0000 (12:18 -0500)]
wakeup wait for cpu display
Here's a slightly more constructive patch: this one adds support in
LTTV's generic state monitoring code and its control flow visualiser to
note when a process is woken by another process using the
sched_try_wakeup event.
Previously the woken process would continue to register its old state
until such time as it got scheduled; here the process transitions to
WAIT_CPU state (like preempted processes, indicating it is ready to run
but not currently scheduled). Ordinarily we see this state exist very
briefly, in between the device driver IRQ (typically) clearing it to run
and the scheduler invocation after irq_exit, but on a heavily loaded
system we might see a large stripe of dark yellow indicating the process
is ready but cannot yet be allocated a core.
The new code in controlflow/eventhooks.c is essentially a copy of the
second half of before_schedchange -- it would be nice to factor these
two and before_execmode, all of which basically identify a process,
create state objects if necessary, and draw his line up to a certain
time.
Chris Smowton [Wed, 18 Nov 2009 17:49:12 +0000 (12:49 -0500)]
LTTV trace control bug fix
Chris Smowton <cs448@cam.ac.uk>:
...whenever I tried
to start a trace using the GUI, it would freeze consuming 100% CPU after
I clicked "start". Turned out this was because in tracecontrol.c's
start_clicked callback, you poll(2) on an FD and use a switch()
statement to handle its return.
Unfortunately, poll(2) doesn't work that way -- it returns a *mask* of
bits, not a single value. Here poll was returning POLLIN | POLLHUP to
indicate there's data ready and the FD has been closed by the other
side, and since this != POLLIN and != POLLHUP, the poll loop spins
forever.
Attached is a patch to be applied to tracecontrol.c which fixes it to
check for set-bits instead. It's still strictly broken, as the read(fd,
buf, 256) call might not fully drain the child's output, but it's a step
in the right direction and means I can at least use the trace-control
thing.
Benjamin Poirier [Mon, 19 Oct 2009 19:33:03 +0000 (15:33 -0400)]
Fix use after free of "filter/expression" attribute
As evidenced by Valgrind:
Invalid read of size 4
at 0x402E248: process_traceset (batchAnalysis.c:103)
by 0x80558E5: lttv_hooks_call (hook.c:272)
by 0x8053596: main (main.c:219)
Address 0x4cea1b8 is 88 bytes inside a block of size 256 free'd
at 0x4024D47: realloc (vg_replace_malloc.c:476)
[...]
by 0x402E204: process_traceset (batchAnalysis.c:97)
by 0x80558E5: lttv_hooks_call (hook.c:272)
by 0x8053596: main (main.c:219)
Signed-off-by: Benjamin Poirier <benjamin.poirier@polymtl.ca>
Benjamin Poirier [Mon, 19 Oct 2009 19:33:02 +0000 (15:33 -0400)]
Move "active" code out of debug statements
Certain g_assert() statements contained expressions that modify the rest of
the program state (eg. modifying variables). As stated in the GLib reference,
g_assert() is a macro that can be compiled out. This would change the behavior
of an otherwise correct lttv.
Signed-off-by: Benjamin Poirier <benjamin.poirier@polymtl.ca>
Actually, looking back at state.c, I noticed there was a major problem
with name table resizing:
the top level pointers were copied from the name table structure to the
trace context, so when the tables were resized, the trace context was
not updated and still refered to the old tables. This is why we could
not free the old tables upon resizing.
Benjamin Poirier [Fri, 25 Sep 2009 19:44:07 +0000 (15:44 -0400)]
runlttv: Add options to specify LTTV options
It is possible, from .runlttvrc:
* to modify the list of modules loaded in text mode or in graphical mode while
still honoring the mode specified in the runlttv command line
* to change the default mode while still honoring the mode specified in the
runlttv command line
from the command line or .runlttvrc:
* force the mode
* specify traces
* specify options that go before (eg. -v) or after (eg. -h) the list of
modules
Signed-off-by: Benjamin Poirier <benjamin.poirier@polymtl.ca>
Benjamin Poirier [Wed, 12 Aug 2009 13:18:43 +0000 (09:18 -0400)]
lttv: Change "dbg" option in runlttv
Change the "dbg" option to "gdb" for more homogeneity: `valgrind` and `strace`
are specified by the tool name, not by its function. This allows adding an
option for another debugger.
Signed-off-by: Benjamin Poirier <benjamin.poirier@polymtl.ca>
Benjamin Poirier [Wed, 12 Aug 2009 13:18:22 +0000 (09:18 -0400)]
lttv: Extra arguments in runlttv
Here's an alternate take on specifying extra arguments for LTTV in the runlttv
script. They are specified on the command line after the optionnal "helper"
program name. This is more in line with the way commands like `xargs` take
extra arguments for the executable they invoke.
Signed-off-by: Benjamin Poirier <benjamin.poirier@polymtl.ca>
Benjamin Poirier [Mon, 10 Aug 2009 20:38:20 +0000 (16:38 -0400)]
lttv: Fix configure arguments
Remove the unused maintainer mode switch.
Fix argument processing for static link mode. Note that it has little effect
on the actual build process since the modules are still dlopen()'ned.
Signed-off-by: Benjamin Poirier <benjamin.poirier@polymtl.ca>
Benjamin Poirier [Mon, 10 Aug 2009 20:38:06 +0000 (16:38 -0400)]
lttv: Clean up library handling in the build system
Take advantage of some more autoconf macros
Use LDADD instead of modifying LIBS through automake
Do not link each loadable module against lttvwindow ("Warning: Linking the
shared library [...] against the loadable module liblttvwindow.so is not
portable!")
Signed-off-by: Benjamin Poirier <benjamin.poirier@polymtl.ca>