kdev-valgrind : technical documentation · 2013. 12. 19. · kdev-valgrind : technical...

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


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


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


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:


Figure 1: Diagram sequence of the interactions between the user, KDevelop, KDevValgrind andValgrind.


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>

[...]


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: 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: 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


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


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


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


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


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


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


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.


4 Diagrams

4.1 Use case diagram

4.1.1 Management plugin

Figure 9: Use case diagram representative of the plugin management.


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.


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.


kdev-valgrind : technical documentation · 2013. 12. 19. · kdev-valgrind : technical...

Documents