BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Pentabarf//Schedule 0.3//EN CALSCALE:GREGORIAN METHOD:PUBLISH X-WR-CALDESC;VALUE=TEXT:Valgrind devroom X-WR-CALNAME;VALUE=TEXT:Valgrind devroom X-WR-TIMEZONE;VALUE=TEXT:Europe/Brussels BEGIN:VEVENT METHOD:PUBLISH UID:4849@FOSDEM17@fosdem.org TZID:Europe-Brussels DTSTART:20170204T103000 DTEND:20170204T113000 SUMMARY:A dozen years of Memcheck DESCRIPTION:
Memcheck is probably the most heavily used tool in the Valgrind suite,checking for invalid addresses, undefined values and memory leaks. Inthis talk I'll look back at the history of the tool, then I'll lookforwards at some of the challenges it faces as the hardware andsoftware ecosystem continue to evolve around it. I'll talk a bitabout some of the effects of Memcheck on the C++ ecosystem and how itfits into the big picture of making your big C++ app crash-free andreliable.
This talk is aimed at Valgrind (Memcheck!) users and developers. Itshould be accessible to C/C++/Fortran developers who have used thetool or are thinking of doing so.
CLASS:PUBLIC STATUS:CONFIRMED CATEGORIES:Valgrind URL:https:/fosdem.org/2017/schedule/2017/schedule/event/valgrind_memcheck/ LOCATION:UD2.119 (Moved from AW1.124) ATTENDEE;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL;CN="Julian Seward":invalid:nomail END:VEVENT BEGIN:VEVENT METHOD:PUBLISH UID:4907@FOSDEM17@fosdem.org TZID:Europe-Brussels DTSTART:20170204T113000 DTEND:20170204T123000 SUMMARY:sparcv9 DESCRIPTION:SPARC is an instruction set architecture (ISA) originally developed by Sun Microsystems since 1980's.Today's largest enterprise servers run on sparc, leveraging several terabytes of memoryand several hundreds of CPUs.This talk will briefly introduce key concepts of sparcv9 ISA and the big picture where supportof a new architecture fits into Valgrind architecture. Some interesting problems during the portwill be discussed together with solutions and still-to-be-solved issues. Finally a live demo willconclude the talk.The talk assumes basic knowledge of Valgrind, interaction among Valgrind subsystems, basic assemblyand VEX IR notation. It is targeted to all interested in sparcv9 ISA and running Valgrind on sparc.
CLASS:PUBLIC STATUS:CONFIRMED CATEGORIES:Valgrind URL:https:/fosdem.org/2017/schedule/2017/schedule/event/valgrind_sparcv9/ LOCATION:UD2.119 (Moved from AW1.124) ATTENDEE;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL;CN="Ivo Raisr":invalid:nomail ATTENDEE;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL;CN="Tomáš Jedlička":invalid:nomail END:VEVENT BEGIN:VEVENT METHOD:PUBLISH UID:5635@FOSDEM17@fosdem.org TZID:Europe-Brussels DTSTART:20170204T123000 DTEND:20170204T133000 SUMMARY:Valgrind, the anti-Alzheimer pill for your memory problems DESCRIPTION:Valgrind and its different tools are providing a rich set of functionalityto track memory problems such as dangling pointers, memory leaks,race conditions, etc.
In this talk, we will describe some old and new features that help tounderstand what happens in your application.Among others, we will give a demo and/or discuss:
how to use valgrind with your application specific memory pool
how to (interactively) ask Valgrind to describe a piece of memory
some heuristics used by Valgrind to reduce the number of'possibly lost' leaks with C++ code
...
We will discuss more in detail the concept of execution trees,which will be available in the next Valgrind release.An execution tree associates stack traces of your program with some data.Execution trees allow Memcheck and Helgrind to providea memory profile of your application. We will show how such an executiontree memory profile can be visualised using tools such asMassif visualiser or kcachegrind.
CLASS:PUBLIC STATUS:CONFIRMED CATEGORIES:Valgrind URL:https:/fosdem.org/2017/schedule/2017/schedule/event/valgrind_features/ LOCATION:UD2.119 (Moved from AW1.124) ATTENDEE;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL;CN="Philippe Waroquiers":invalid:nomail END:VEVENT BEGIN:VEVENT METHOD:PUBLISH UID:5597@FOSDEM17@fosdem.org TZID:Europe-Brussels DTSTART:20170204T133000 DTEND:20170204T143000 SUMMARY:fortification vs memcheck DESCRIPTION:gcc/glibc support fortification of some functions by defining FORTIFYSOURCE. This inserts some compile and runtime buffer overflow checks for selected glibc functions. These checks have no or very little runtime overhead and work on the object level (the compiler provides/proofs the size of the object buffer size). valgrind memcheck provides similar memory buffer overflow checks. These checks don't need any compiler help (you won't have to rebuild your code). But they have a much higher runtime overhead. They also work on a different level. valgrind memcheck doesn't know anything about the objects the user is manipulation but has knowledge of all memory blocks allocated. Lets explore how these different mechanisms work and how we can make them work better together.
CLASS:PUBLIC STATUS:CONFIRMED CATEGORIES:Valgrind URL:https:/fosdem.org/2017/schedule/2017/schedule/event/valgrind_fortification/ LOCATION:UD2.119 (Moved from AW1.124) ATTENDEE;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL;CN="Mark Wielaard":invalid:nomail END:VEVENT BEGIN:VEVENT METHOD:PUBLISH UID:5636@FOSDEM17@fosdem.org TZID:Europe-Brussels DTSTART:20170204T143000 DTEND:20170204T153000 SUMMARY:Successful and not (yet?) successful optimisations in Valgrind DESCRIPTION:Making Valgrind faster is a never ending challenge.In this talk, we will describe 2 optimisations in Valgrind.
A first optimisation is a speedup of Helgrind (a race detection tool). A verysimple observation has led to an optimisation in the way helgrind capturesstack traces for its 'full recording' of where a piece of memory wasmodified. This optimisation gives a typical speed up of 25%. We will describethe issues encountered during the implementation and discuss the reasonswhy this optimisation is not (yet?) committed in the Valgrind sources.
The second optimisation is the implementationof the execution tree concept : this generalises the wayMassif (a heap profiler) records the memory usage of a program.We will show how a (maybe counter-intuitive) representation of a treeusing a hash table of flat stack traces has doubled the speed ofMassif for some workloads.
This talk is aimed at Valgrind developers and any application developerinterested in data structures and algorithm optimisations.
CLASS:PUBLIC STATUS:CONFIRMED CATEGORIES:Valgrind URL:https:/fosdem.org/2017/schedule/2017/schedule/event/valgrind_optimizations/ LOCATION:UD2.119 (Moved from AW1.124) ATTENDEE;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL;CN="Philippe Waroquiers":invalid:nomail END:VEVENT BEGIN:VEVENT METHOD:PUBLISH UID:4850@FOSDEM17@fosdem.org TZID:Europe-Brussels DTSTART:20170204T153000 DTEND:20170204T163000 SUMMARY:VEX DESCRIPTION:VEX is the JIT at the core of Valgrind. It unpicks blocks of machinecode, hands them off to the tool for instrumentation, recompiles theresult, and links the instrumented version into the running image.By using a target independent intermediate representation, it insulatestools from the complexity of the underlying instruction sets.
Back in 2003, when the framework was designed, I never dreamt that itwould end up supporting X86, ARM, POWER, MIPS, S390 and TILEGX in both32- and 64-bit variants. From that perspective VEX has been amazinglysuccessful. But the framework is now showing its age. Recentinstruction set features (transactional memory,LoadLinked/StoreConditional, wide vectors) have proven difficult toimplement. It supports precise memory exceptions only poorly. Andperhaps worst, its simplistic compilation pipeline causes it togenerate code that is uncompetitive compared to other frameworks,particularly DynamoRIO and PIN.
In this talk I'll outline VEX's structure, then talk about theseproblems and what can be done about them. And I'd be particularlyinterested to hear opinions on how much effort, and for which problemareas, should be invested in upgrading it.
For the audience, some background in compiler internals and assemblycode programming would be helpful, but is not essential.
CLASS:PUBLIC STATUS:CONFIRMED CATEGORIES:Valgrind URL:https:/fosdem.org/2017/schedule/2017/schedule/event/valgrind_vex_future/ LOCATION:UD2.119 (Moved from AW1.124) ATTENDEE;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL;CN="Julian Seward":invalid:nomail END:VEVENT BEGIN:VEVENT METHOD:PUBLISH UID:5512@FOSDEM17@fosdem.org TZID:Europe-Brussels DTSTART:20170204T163000 DTEND:20170204T173000 SUMMARY:Binary analysis with angr DESCRIPTION:The angr binary analysis platform (http://angr.io) uses libVEX as the base of its analysis engine. In this talk, we discuss the things about VEX that make it attractive for static analysis and symbolic execution, its pitfalls, and ways that it can be improved, including the changes we have made in our fork of libVEX.
CLASS:PUBLIC STATUS:CONFIRMED CATEGORIES:Valgrind URL:https:/fosdem.org/2017/schedule/2017/schedule/event/valgrind_angr/ LOCATION:UD2.119 (Moved from AW1.124) ATTENDEE;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL;CN="Andrew Dutcher":invalid:nomail END:VEVENT BEGIN:VEVENT METHOD:PUBLISH UID:5658@FOSDEM17@fosdem.org TZID:Europe-Brussels DTSTART:20170204T173000 DTEND:20170204T190000 SUMMARY:Valgrind BoF and Hackaton DESCRIPTION:Come and hack on Valgrind together. Open discussion about small (or big) ideas to improve or change Valgrind.
Valgrind developers and users are encouraged to participate either by submitting ideas/suggestions or by joining the discussion. And of course by kindly (or bitterly) complain about bugs you find important that are still Not YET solved for that many years!?@!!!
Afterwards we will sit together and try to fix or implement some of the things discussed.
CLASS:PUBLIC STATUS:CONFIRMED CATEGORIES:Valgrind URL:https:/fosdem.org/2017/schedule/2017/schedule/event/valgrind_hackaton/ LOCATION:UD2.119 (Moved from AW1.124) ATTENDEE;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL;CN="Mark Wielaard":invalid:nomail END:VEVENT END:VCALENDAR