KDev-Valgrind :
Technical Documentation
Damien CoppelAnthony Corbacho
Lionel DucMathieu Lornac
Sebastien RannouLucas Sarie
This document is for developpers who are willing to contribute tothe plugin. It gives an overview of the project, its components and itsvarious interactions. It is also a good start to understand the technicalchoices that were made along the project.
The KDev-Valgrind team - December 9, 2011 1
Description du document
Titre Technical documentationDate December 9, 2011Mail kdevvalgrind [email protected]
In charge Anthony CORBACHOVersion 1.3
Revision chart
Date Section(s) CommentaireMarch 2011 All Creation of the documentApril 2011 4.1.2 Remove some tools from diagramJuly 2011 All UpdateDecember 3, 4, 5 Update
The KDev-Valgrind team - December 9, 2011 2
Contents
1 Summary 4
2 Introduction 42.1 Aim of EIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Aim of KDev-Valgrind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Overall process 43.1 Interactions with KDevelop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1 “kdevvalgrind.so” Librairy . . . . . . . . . . . . . . . . . . . . . . . . . . . 43.1.2 “kdevvalgrind.desktop” file . . . . . . . . . . . . . . . . . . . . . . . . . . . 43.1.3 “kdevvalgrind.rc” file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 KDevelop plugin loading system . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.3 User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.4 Interactions with Valgrind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.5 Valgrind output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5.1 XML format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.5.2 Other format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.6 The plugin structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.6.1 Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.6.2 Config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.6.2.a Configuration classes . . . . . . . . . . . . . . . . . . . . . . 103.6.2.b Launchers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.6.3 Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.6.4 Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.6.5 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.6.6 View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4 Diagrams 164.1 Use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.1 Management plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.1.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.1.3 Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5 Interfaces 185.1 Configuration interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.2 Visualisation interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.3 External tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6 Conclusion 18
The KDev-Valgrind team - December 9, 2011 3
1 Summary
The project KDev-Valgrind aims at implementing a full graphical front-end for Valgrind, and in-tegrating it to the KDevelop IDE, which does not provide any tool of this type right now.
Through this document we will describe the plugin in its current state, highlight the relation-ships between the classes that compose it, identifying which parts are functional and compatiblewith KDevelop 4.x.
Then we will discuss the external interactions, first those with the development environmentKDevelop and then with the Valgrind tool suite.
Finally, a conclusion with justification of technological choices on the project.
2 Introduction
2.1 Aim of EIP
The EIP1 is a two years project where students of the Epitech are working in group of 5 to Nstudents on a project of their own reflexion. The primary goal of the final project of Epitech is toachieve a project as you would in a business context. In addition, it allows students to practicetheir managerial skills.
2.2 Aim of KDev-Valgrind
KDev-Valgrind is a project aiming at create a plugin for the KDevelop environment. This pluginwill integrate the Valgrind’s tools in the IDE2 and facilitate its use. Even if Valgrind is use bymany developpers, there is curently no implementation in this IDE.
The integration is a will of the KDevelop community and obvioulsy, it will be free3.
3 Overall process
3.1 Interactions with KDevelop
3.1.1 “kdevvalgrind.so” Librairy
Once compiled, the plugin is presented as a dynamic library named “kdevvalgrind.so” which willbe located in the folder “/lib/kde4/”
This path may vary according to the user needs.
3.1.2 “kdevvalgrind.desktop” file
This file holds the plugin configuration. Among other things, it contains informations on the textencoding, the plugin’s name and the program description.
This file will be copied to the path “/share/kde4/services/” of the target installation. Therefore,it will be automatically used by KDevelop.
Most of the time, this file doesn’t need any user intervention, but during the developmentprocess and depending on the context (KDevelop version, KDE libraries) the user might have toadapt little things.
1Epitech Innovative Project2Integrated Development Environment3Free as in freedom, not as in beer
The KDev-Valgrind team - December 9, 2011 4
3.1.3 “kdevvalgrind.rc” file
This file describes the menus that will be added by the plugin to the KDevelop IDE.
As for the file “.desktop”, this file will simply be copied to “/share/apps/kdevvalgrind/”.
3.2 KDevelop plugin loading system
During it’s launching process, KDevelop checks all the plugins available thanks to the 3 files pre-viously described and load them.
Therefore, once the plugin is compiled and installed, no user intervention is required to loadthe plugin. A menu in KDevelop, gives the user the opportunity to select the plugins to be loadedduring a particular or every sessions.
3.3 User interface
The user interface uses the QT framework. Every static interface is described in a “.ui” file.Everyconfiguration interface owns its own ui file.
The “uic” program compiles each ui file and transforms it into a header file which will be usedto build the final library.
3.4 Interactions with Valgrind
The user can compile his project inside the IDE. In order to obtain useful infromations, the projecthas to be compiled with specific flags such as “-O0” or “-g3”.
A compilation made with an incorrect set of flags can result in incomplete or misleaded infor-mation. To avoid such problems, our module has to check whether the flags are correct. If the flagset isn’t appropriated, we will warn the user that the informations might be incomplete.
The flags coherence check is ensured by the the ValgrindJob class which will launch the desiredtool.
On the user demand, the plugin will execute the program. A communication between Valgrindand our plugin will then take place. As soon as errors are reported by Valgrind, we will displaythem to the user. A diagram sequence sums up these operations:
The KDev-Valgrind team - December 9, 2011 5
Figure 1: Diagram sequence of the interactions between the user, KDevelop, KDevValgrind andValgrind.
The KDev-Valgrind team - December 9, 2011 6
3.5 Valgrind output
Valgrind’s output can be formated to the XML standard. The output can also be redirected to asocket or a file descriptor.
We will, on the fly, read and interpret this stream to display our interpretation.THe use of the xml outup is only available for the tool “memcheck”, the other create a file that
will be read afterward.
3.5.1 XML format
Valgrind makes the run of the target application around 20 times slower, hence it allows us todisplay intermediate results which can be very usefull in cases of huge applications.
Here is a code sample which contains a memory leak:
int main()
{
int *a = malloc(sizeof(int));
return 0;
}
Once compiled (with the “-g3” flag to have maximum debug information), using memcheck weobtain an xml as follows:
>> gcc -g3 test.c
>> valgrind --tool=memcheck --xml=yes --xml-file=out.xml --leak-check=yes ./a.out
The file out.xml contains information about the memory leaks:
[...]
<error>
<unique>0xd</unique>
<tid>1</tid>
<kind>Leak_DefinitelyLost</kind>
<xwhat>
<text>4 bytes in 1 blocks are definitely lost in loss record 1 of 1</text>
<leakedbytes>4</leakedbytes>
<leakedblocks>1</leakedblocks>
</xwhat>
<stack>
<frame>
<ip>0x4024A18</ip>
<obj>/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so</obj>
<fn>malloc</fn>
</frame>
<frame>
<ip>0x80483B8</ip>
<obj>/home/damien/work/EIP/testValgrind/a.out</obj>
<fn>main</fn>
<dir>/home/damien/work/EIP/testValgrind</dir>
<file>test.c</file>
<line>3</line>
</frame>
</stack>
</error>
[...]
The KDev-Valgrind team - December 9, 2011 7
This file has to be properly parsed in order to display relevant information in KDevelop’s viewand point the errors directly in the code source.
A first version of the parser was created by “Hamish Rodda”. Hamish regrouped in a singleclass named “ValgrindModel”the xml parsing, its rendering, the network connections and the datastorage.
To obtain, simpler, cleaner and more flexible code, we exploded the different elements in sepa-rated class ans rewrote most of this part.
The “ValgrindModel” class now only makes the rendering, ValgrindParser parses the streamand the socket is prepared by another class.
3.5.2 Other format
With the evolution of the plugin, we are now able to manage other valgrind tools (massif, callgrind,cachegrind). Fact is they do not offer XML formatting, so we have to wait for valgrind to finishand then read the file it has produced.
Here is a fragment of a file produced by massif:
[...]
#-----------
snapshot=70
#-----------
time=459887
mem_heap_B=15195
mem_heap_extra_B=277
mem_stacks_B=0
heap_tree=detailed
n3: 15195 (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
n3: 13231 0x8058D10: ??? (in /bin/ls)
n1: 12800 0x804FE54: ??? (in /bin/ls)
n0: 12800 0x408B111: (below main) (libc-start.c:226)
n1: 220 0x804E80B: ??? (in /bin/ls)
n1: 220 0x804ECB4: ??? (in /bin/ls)
n1: 220 0x8050CAA: ??? (in /bin/ls)
n0: 220 0x408B111: (below main) (libc-start.c:226)
n0: 211 in 3 places, all below massif’s threshold (01.00%)
n1: 1720 0x4096727: _nl_intern_locale_data (loadlocale.c:96)
n1: 1720 0x4096247: _nl_find_locale (findlocale.c:107)
n1: 1720 0x4095D92: setlocale (setlocale.c:303)
n1: 1720 0x804F9CD: ??? (in /bin/ls)
n0: 1720 0x408B111: (below main) (libc-start.c:226)
n0: 244 in 10 places, all below massif’s threshold (01.00%)
[...]
and a fragment of file produced by callgrind :
--------------------------------------------------------------------------------
Profile data file ’../../Bureau/EIP/callgrind.out.7311’ (creator: callgrind-3.6.1-Debian)
--------------------------------------------------------------------------------
I1 cache: 32768 B, 64 B, 8-way associative
D1 cache: 32768 B, 64 B, 8-way associative
LL cache: 4194304 B, 64 B, 16-way associative
Timerange: Basic block 0 - 3442607
Trigger: Program termination
The KDev-Valgrind team - December 9, 2011 8
Profiled target: ../taquin/bin/taquin_unix -f ../taquin/bin/board.txt (PID 7311, part 1)
Events recorded: Ir Dr Dw I1mr D1mr D1mw ILmr DLmr DLmw
Events shown: Ir Dr Dw I1mr D1mr D1mw ILmr DLmr DLmw
Event sort order: Ir Dr Dw I1mr D1mr D1mw ILmr DLmr DLmw
Thresholds: 99 0 0 0 0 0 0 0 0
Include dirs:
User annotated:
Auto-annotation: off
--------------------------------------------------------------------------------
Ir Dr Dw I1mr D1mr D1mw ILmr DLmr DLmw
--------------------------------------------------------------------------------
17,851,746 6,702,473 4,945,102 2,547 17,559 5,040 2,155 4,403 4,414 PROGRAM TOTALS
--------------------------------------------------------------------------------
Ir Dr Dw I1mr D1mr D1mw ILmr DLmr DLmw file:function
--------------------------------------------------------------------------------
948,029 240,579 137,765 67 12 3,640 43 2 3,640 /build/buildd/...
[...]
We can see that the format of the two files are quite different ! The separation of the parsersfor each tool allow us to handle this problem.
3.6 The plugin structure
In order to isolate the code, all of our classes are in a namespace “valgrind” that does not appearin the UML diagrams.
3.6.1 Plugin
Plugin is the main plugin class. It inherits from KDEvelop IPlugin and instanciated using a factorypattern. It contains all the elements of the plugin et keep them connectec together.
Plugin also creates and registers the action menus usable by the final user.
Figure 2: Class diagram for Plugin
The KDev-Valgrind team - December 9, 2011 9
3.6.2 Config
We distinguish 2 kinds of classes in Config
3.6.2.a Configuration classes
They contain the configuration GUI of the various tools that offer the plugin. A factory is used toinstantiate the GUI by using the KDevelop mechanisms.
Figure 3: Class diagram for the plugin configuration
The KDev-Valgrind team - December 9, 2011 10
3.6.2.b Launchers
They define the graphical interface used to launch each tool.
This is done through a base class GenericLaunchMode, which inherit four subclasses (Mem-checkLaunchMode, CallgrindLaunchMode, CachegrindLaunchMode, MassifLaunchMode).
Instances of these classes are kept in the class Launcher. During the execution of the plugin,Launcher will instantiate the Job classes with the correct parameters depending of the tool thatthe user wants to use.
Figure 4: Diagramme de classe des lanceurs Valgrind
The KDev-Valgrind team - December 9, 2011 11
3.6.3 Job
An instance of Job (or more precisely one of its implementation) is created each time the userlaunches a specific action.
Job inherits KDevelop::OutputJob in ordet to get the output of valgrind.
Job instantiates a KProcess (class provided by KDE to run a new process) that starts Valgrindwith the specified tool.
The job get the flow from Valgrind and redirect it to the Parser.
Figure 5: Job class diagram, allow to communicate with the Valgrind tools
The KDev-Valgrind team - December 9, 2011 12
3.6.4 Parser
This class get the output of Valgrind with different formats (depending on tool), then processesthe information and redirects it to the Model.
Figure 6: Parser class diagram, used to process the informations
The KDev-Valgrind team - December 9, 2011 13
3.6.5 Model
This class is used to organize the informations that will be displayed in KDevelop.
Figure 7: Model class diagram, used to organize the inforamtions
The KDev-Valgrind team - December 9, 2011 14
3.6.6 View
View displays the information contained in the Model. It also manage the interactions with theuser.
Figure 8: Diagramme de classe de View, permettant l’affichage des donnees.
The KDev-Valgrind team - December 9, 2011 15
4 Diagrams
4.1 Use case diagram
4.1.1 Management plugin
Figure 9: Use case diagram representative of the plugin management.
The KDev-Valgrind team - December 9, 2011 16
4.1.2 Configuration
Figure 10: Use case diagram representative of the plugin configuration.
4.1.3 Utilization
Figure 11: Use case diagram representative of the utilization of the plugin.
The KDev-Valgrind team - December 9, 2011 17
5 Interfaces
5.1 Configuration interfaces
Since we have to implement several tools, it’s interesting to make uniform theirs configurationsboth in terms of technical point of view (make easier the insertion of eventual new tools) and visualpoint of view (all of the tools have to be configured in the same way, that make the utilisationeasily).
We use a facility offered by the API KDevelop: LaunchConfigurationPage, who can create someactivable profiles one by one. Each module defines its own configuration page by inheriting fromthis interface and is encapsulate in a GUI generated by the pre-compiler QT.
The different profiles are saved into the Launcher. Thus, each profiles have theirs own config-uration tab. One main tab is used to define the global configuration (Valgrind executable path,active profile, ...).
5.2 Visualisation interfaces
We have created a dedicated widget for each tool. Each view is specifically design to enlight theerrors raised by the various module Valgrind.
5.3 External tools
External programs with advance visualisation of the data produced by the Valgrind tools exists inthe open source community. These products like Kcachegrind or MassifVisualizer are not designto be integrated in an IDE and their display is way too complex to get a nice integration.
However, their launch can be tedious, first you need to start Valgrind with the right options,then retrieve the generated file and finally open it in the desired software.
We wanted to bring an easy and automatic start of these tools inside the plugin. So it’s possibleto launch Kcachegrind or MassifVisualizer automatically by choosing it in the configuration pages.
6 Conclusion
This document makes the understanding of the interactions between KDev-Valgrind and KDevelopeasier.
The use cases, gives us a global functionning view of the plugin including its interactions withthe user.
It also gives a global overview of the project, which makes the integration of developpers fromthe community easier.
The KDev-Valgrind team - December 9, 2011 18