schulmar/templar

Visualization tool for Templight C++ template debugger traces

templar's Issues

gvLayout() failed

I compiled in 5.8.0 succeed, but failed with "gvLayout() failed" in executing. Do you have any advice how to debug this?

Global Statistics

Hi,

As discussed in issue #6, I think it would be great to get some total statistics.

For starter, simply the total number of instantiations. Ideally, this number would be updated by the filters. This could also probably be done for each node type (template instantiation, memoization, deduced...).

The total duration could also be interesting. This would be the sum of the durations of all templates of first level in the graph.

Another thing that would be great but maybe harder to get is the number of instantiations of each template. For instance, the number of times std::forward has been instantiated.

What do you think ?

Checking matching begin / end entries

This is kind of an issue with both templar and templight. I recently tried to load a very large templight profile with templar. The attempt failed on a seg-fault because there seems to be a mismatching of begin and end entries in the templight trace file.

The templar file-reading code makes the assumption that every time TraceReader::endEntry() is called, the "end" entry is the end of the "begin" entry that is currently on top of the stack childVectorStack. This is certainly a reasonable assumption, but it seems that there are rare cases where there might be an "end" entry with no matching "begin" entry or vice versa. In those cases, that whole code breaks down, of course (and ends up with a seg-fault or just a corrupt graph).

I'm not exactly sure where this mismatch is coming from. It could be coming from a bug in templight, or it could be coming from a specific set of circumstances that make Clang call templight in a mismatching way (i.e., the problem is in Clang, not templight).

Either way, I can try to fix it, but I cannot guarantee that such things will never occur. So, I'm thinking that it would be best to have a correction mechanism in the traces. If there was a way to verify that a given "end" entry matches a given "begin" entry (like an id number or some other common information), than there would at least be a way to repair / recover / ignore mismatching entries and limiting the damage to only those few entries. What do you think?

Mutliline tooltip for the table

Hi,

In the trace I'm working with some names are insanely long (thousand of chars I guess). The tooltip in the table is quite practical for most names, but once the name is long the tooltip is larger than my two screens together. It would be great if the tooltip were multiline with some word wrapping.

Thanks

Missing include of QHeaderView in mainwindow.cpp on Qt5

gui/mainwindow.cpp needs to #include <QHeaderView.h> to compile with Qt5.

segfault on fibonacci trace from metashell

Using the feature/templight2 Templar executable on trace file produced by metashell's
template_metashell causes a segfault:

evansl@lje-OptiPlex-9020:~/prog_dev/metashell$ make templight
templight_metashell -Xtemplight -profiler -Xtemplight -ignore-system -c -std=c++11 fib.cpp
evansl@lje-OptiPlex-9020:~/prog_dev/metashell$ pushd
~/dwnlds/templar/Templar ~/prog_dev/metashell
evansl@lje-OptiPlex-9020:~/dwnlds/templar/Templar$ ./Templar
QObject::connect: No such slot QTableView::sortByColumn(int,)
QObject::connect: No such slot QGraph::follow()
TraceReader::build( "/home/evansl/prog_dev/metashell/fib.o.trace.pbf" )
Segmentation fault (core dumped)
evansl@lje-OptiPlex-9020:~/dwnlds/templar/Templar$ git branch
* feature/templight2
  feature/templight2_mp_fork
  master
evansl@lje-OptiPlex-9020:~/dwnlds/templar/Templar$ 

After debug build, examined the core dump with gdb. The 1st several lines in bt were:

evansl@lje-OptiPlex-9020:~/dwnlds/templar/build$ gdb Templar core
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from Templar...done.
[New LWP 11459]
[New LWP 11468]
[New LWP 11461]
[New LWP 11462]
[New LWP 11467]
[New LWP 11471]
[New LWP 11460]
[New LWP 11464]
[New LWP 11469]
[New LWP 11470]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./Templar'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000000000046b7ea in QString::~QString (this=0xffffffffffffff88, __in_chrg=<optimized out>)
    at /usr/include/x86_64-linux-gnu/qt5/QtCore/qstring.h:1053
1053	inline QString::~QString() { if (!d->ref.deref()) Data::deallocate(d); }
[Current thread is 1 (Thread 0x7fca3c4a2740 (LWP 11459))]
(gdb) bt
#0  0x000000000046b7ea in QString::~QString (this=0xffffffffffffff88, __in_chrg=<optimized out>)
    at /usr/include/x86_64-linux-gnu/qt5/QtCore/qstring.h:1053
#1  0x000000000049c21e in std::pair<QString, QColor>::~pair (this=0xffffffffffffff88, __in_chrg=<optimized out>)
    at /usr/include/c++/5/bits/stl_pair.h:96
#2  0x000000000049c4b1 in std::_Destroy<std::pair<QString, QColor> > (__pointer=0xffffffffffffff88)
    at /usr/include/c++/5/bits/stl_construct.h:93
#3  0x000000000049c3a1 in std::_Destroy_aux<false>::__destroy<std::pair<QString, QColor>*> (
    __first=0xffffffffffffff88, __last=0x0) at /usr/include/c++/5/bits/stl_construct.h:103
#4  0x000000000049c1d6 in std::_Destroy<std::pair<QString, QColor>*> (__first=0xffffffffffffff88, __last=0x0)
    at /usr/include/c++/5/bits/stl_construct.h:126
#5  0x000000000049bdb9 in std::_Destroy<std::pair<QString, QColor>*, std::pair<QString, QColor> > (
    __first=0xffffffffffffff88, __last=0x0) at /usr/include/c++/5/bits/stl_construct.h:151
#6  0x000000000049befc in std::vector<std::pair<QString, QColor>, std::allocator<std::pair<QString, QColor> > >::_M_erase_at_end (this=0x20a55a8, __pos=0xffffffffffffff88) at /usr/include/c++/5/bits/stl_vector.h:1438
#7  0x000000000049c105 in std::vector<std::pair<QString, QColor>, std::allocator<std::pair<QString, QColor> > >::_M_erase (this=0x20a55a8, __first=<error reading variable: Cannot access memory at address 0xffffffffffffff88>, 
    __last=<error reading variable: Cannot access memory at address 0x0>)
    at /usr/include/c++/5/bits/vector.tcc:160
#8  0x000000000049bcce in std::vector<std::pair<QString, QColor>, std::allocator<std::pair<QString, QColor> > >::erase (this=0x20a55a8, __first=<error reading variable: Cannot access memory at address 0xffffffffffffff88>, 
    __last=<error reading variable: Cannot access memory at address 0x0>)
    at /usr/include/c++/5/bits/stl_vector.h:1177
#9  0x000000000049b5f1 in Templar::EditorHandler::rewind (this=0x20a5590, count=6)
    at /home/evansl/dwnlds/templar/Templar/templateeventhandlers/editorhandler.cpp:73
#10 0x000000000047ad4a in Templar::DebugManager::rewind (this=0x208abc0)
    at /home/evansl/dwnlds/templar/Templar/gui/debugmanager.cpp:172
#11 0x00000000004a688e in Templar::DebugManager::qt_static_metacall (_o=0x208abc0, 
    _c=QMetaObject::InvokeMetaMethod, _id=3, _a=0x7ffdd03a0eb0)
    at /home/evansl/dwnlds/templar/build/moc_debugmanager.cpp:88
#12 0x00007fca3adb4d2a in QMetaObject::activate(QObject*, int, int, void**) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#13 0x00007fca3bd9b412 in QAction::triggered(bool) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#14 0x00007fca3bd9d898 in QAction::activate(QAction::ActionEvent) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#15 0x00007fca3bea35a0 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
---Type <return> to continue, or q <return> to quit---

The dump occurred when I pressed the rewind button (the one with the icon
that resembles 2 left arrows).

When editorhandler.cpp was changed as follows:

 void EditorHandler::rewind(unsigned int count)
 {
-    undoList.erase(undoList.end() - count + 1, undoList.end());
+    std::size_t list_size=undoList.size();
+    std::size_t undo=(list_size<count)?list_size:count;
+    undoList.erase(undoList.end() - undo, undoList.end());
     undoEvent();
 }

The program ran without a segfault; however, the [rewind] and [fast forward]
buttons made no change in the graphic in the top righthand corner of the
Templar window.

HTH.

-regards,
Larry

cannot build

I've downloaded the repo as described here:

https://baptiste-wicht.com/posts/2016/02/use-templight-and-templar-to-debug-cpp-templates.html

I've also tried building as described in the README.md for both the feature/templight2 and
the feature/templight2_mp_fork branches. None build with the commands described in the
REAMDE.md files. For example, the last one produced:

evansl@lje-OptiPlex-9020:~/dwnlds/templar/Templar$ git checkout feature/templight2_mp_fork
Branch feature/templight2_mp_fork set up to track remote branch feature/templight2_mp_fork from origin.
Switched to a new branch 'feature/templight2_mp_fork'
evansl@lje-OptiPlex-9020:~/dwnlds/templar/Templar$ cmake CMakeLists.txt make
CMake Error: The source directory "/home/evansl/dwnlds/templar/Templar/make" does not exist.
Specify --help for usage, or press the help button on the CMake GUI.
evansl@lje-OptiPlex-9020:~/dwnlds/templar/Templar$ cmake CMakeLists.txt
-- Configured for build-type: Release
-- Configured compiler options for Linux system with GNU toolset.
Using Qt5
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE  
-- Found Protobuf: /usr/lib/x86_64-linux-gnu/libprotobuf.so  
Generating protocol buffer classes from .proto files.
-- Configuring done
-- Generating done
-- Build files have been written to: /home/evansl/dwnlds/templar/Templar
evansl@lje-OptiPlex-9020:~/dwnlds/templar/Templar$ make
[  1%] Generating qrc_resources.cpp
make[2]: *** No rule to make target 'PROTOBUF_PROTOC_EXECUTABLE-NOTFOUND', needed by 'templight_messages.pb.cc'.  Stop.
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/Templar.dir/all' failed
make[1]: *** [CMakeFiles/Templar.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2
evansl@lje-OptiPlex-9020:~/dwnlds/templar/Templar$ 

Seg-faults after clearing the graph scene

I was just trying to run templar a bit and got several seg-faults and other memory issues. I fixed a couple of them in the pull request that I just put up. But there are still several that I can't fix myself (without knowing how things are supposed to work).

The latest one I got triggers the following valgrind log entry:

==23753== Invalid read of size 4
==23753==    at 0x48AA20: QNode::getId() const (qgraph.h:137)
==23753==    by 0x4897F4: QGraph::colorizeUpToNode(int) (qgraph.cpp:452)
==23753==    by 0x47CD16: Templar::GraphHandler::handleEvent(Templar::TraceEntry const&) (graphhandler.cpp:30)
==23753==    by 0x4820FC: Templar::DebugManager::next() (debugmanager.cpp:61)
==23753==    by 0x4A9459: Templar::DebugManager::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_debugmanager.cxx:53)
==23753==    by 0x5C7B879: QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (in /usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.6)
==23753==    by 0x4FFAA61: QAction::triggered(bool) (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.6)
==23753==    by 0x4FFC432: QAction::activate(QAction::ActionEvent) (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.6)
==23753==    by 0x53B3B01: ??? (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.6)
==23753==    by 0x53B3C2B: QAbstractButton::mouseReleaseEvent(QMouseEvent*) (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.6)
==23753==    by 0x546AA49: QToolButton::mouseReleaseEvent(QMouseEvent*) (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.6)
==23753==    by 0x5050509: QWidget::event(QEvent*) (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.6)
==23753==  Address 0x20277430 is 64 bytes inside a block of size 80 free'd
==23753==    at 0x4C2C2BC: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23753==    by 0x4AA191: QNode::~QNode() (qgraph.h:122)
==23753==    by 0x55CE225: QGraphicsScene::clear() (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.6)
==23753==    by 0x47CD7C: Templar::GraphHandler::reset(Templar::TraceEntry const&) (graphhandler.cpp:54)
==23753==    by 0x48225E: Templar::DebugManager::reset() (debugmanager.cpp:81)
==23753==    by 0x46A1BB: MainWindow::reset() (mainwindow.cpp:270)
==23753==    by 0x46AFB4: MainWindow::openTrace(QString const&) (mainwindow.cpp:373)
==23753==    by 0x46AD06: MainWindow::on_actionOpen_trace_triggered() (mainwindow.cpp:350)
==23753==    by 0x4A8DE8: MainWindow::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_mainwindow.cxx:81)
==23753==    by 0x4A8F6B: MainWindow::qt_metacall(QMetaObject::Call, int, void**) (moc_mainwindow.cxx:127)
==23753==    by 0x5C7BA77: QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (in /usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.6)
==23753==    by 0x4FFAA61: QAction::triggered(bool) (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.6)

Which pretty much speaks for itself when you look at the corresponding source locations. When the GraphHandler calls the "theGraph->getScene()->clear();" during its "reset" callback, it causes all the QNode objects to be deleted and then, the next time the QGraph gets colored via a call to "colorizeUpToNode" it accesses freed memory.

I believe that the fix would be to call "theGraph->clearGraph()" before (or instead of) the call to clear the scene. I think that clearGraph should include the clearing of the scene. Thus, having:

void QGraph::clearGraph()
{
    nodeList.clear();
    QList<QGraphicsItem*> items(scene->items());
    while (!items.isEmpty())
        delete items.takeFirst();
    scene->clear();
}

and

void GraphHandler::reset(const TraceEntry &/*entry*/)
{
    undoStack.clear();
    nodeColor.clear();
    theGraph->clearGraph();
}

That just looks cleaner to me.

Unresponsive application

Hi,

I'm trying to use this application to visualize the results from templight, but without success so far.

I have used templight and generated a whole bunch of pbf files. I converted one of them into an xml with the templight-tools and then loaded it in Templar. The loading seemed to work but as soon as I try one of the buttons, the application hangs at 100% CPU and it has been hanging for several minutes. Am I doing something ?

Are my files simply too big ?

Is there another way to visualize the templight results ? I cannot install KCacheGrind and I haven't seen anything of direct value in the text output.

Thanks

Shortcut for Go to parent

Hi,

Just a small request that would greatly improve quality of life: When you navigate large graphs, it is sometimes quite hard to find the go to parent node. It would be great if there was a button in the button bar to go to the parent directly.

Thanks