Valgrind

8 results back to index


pages: 351 words: 123,876

Beautiful Testing: Leading Professionals Reveal How They Improve Software (Theory in Practice) by Adam Goucher, Tim Riley

Albert Einstein, barriers to entry, Black Swan, business logic, call centre, continuous integration, Debian, Donald Knuth, en.wikipedia.org, Firefox, Grace Hopper, index card, Isaac Newton, natural language processing, off-by-one error, p-value, performance metric, revision control, six sigma, software as a service, software patent, SQL injection, the scientific method, Therac-25, Valgrind, web application

Fortunately enough, there exist advanced memory-debugging tools that can save a lot of time, significantly improving the developer’s life. A dynamic code analysis with these tools is often more optimal and easier than the static approach, especially when the problem is reproducible. The ClamAV project most often makes use of Valgrind, Electric Fence and DUMA, and Mudflap. Valgrind Valgrind is both powerful and easy to use. Its major advantage is that the application you want to test doesn’t need to be modified at all, and Valgrind works directly with binaries, meaning that your program can be written in any language (also interpreted ones!). It’s not only a memory debugger; in fact, it’s a complete suite that also provides tools for cache and heap profiling or detection of synchronization problems.

Only bug fixes are allowed in micro releases.§ Dynamic Analysis Valgrind is a dynamic analysis‖ tool. This means that it analyzes an application while the application runs. The memcheck tool that is part of Valgrind detects memory leaks and errors, including invalid memory reads and writes. Using dynamic analysis is very powerful because it can find issues that are otherwise hard to detect. For example, a memory access might happen only once in a million times and doesn’t always cause a noticeable problem. Such an issue can be detected with little effort when using Valgrind. Python has used dynamic analysis tools for over 10 years, to minimize the amount of memory leaked.

However, in order to generate a reliable caller–callee function graph, we should be using dynamic binary analysis (DBA) and instrumentation tools. One of the widely used open source DBA tools is Valgrind. There is a Valgrind extension that is of particular interest to us: Callgrind. Callgrind generates a reliable and comprehensive call graph from a debug or optimized build of an executable. Make sure that you have set up the Valgrind environment on the test box properly before you execute the Callgrind extension. Callgrind generates an output file in the form of a text document. With the help of the KCachegrind tool, the Callgrind output can be converted into a visual display.* Example 1 Let us say that your program is called “foobar” and you have 20 test cases in your test base.


pages: 1,025 words: 150,187

ZeroMQ by Pieter Hintjens

AGPL, anti-pattern, behavioural economics, carbon footprint, cloud computing, Debian, distributed revision control, domain-specific language, eat what you kill, Eben Moglen, exponential backoff, factory automation, fail fast, fault tolerance, fear of failure, finite state, Internet of things, iterative process, no silver bullet, power law, premature optimization, profit motive, pull request, revision control, RFC: Request For Comment, Richard Stallman, Skype, smart transportation, software patent, Steve Jobs, Valgrind, WebSocket

If you use a language that handles this automatically for you, congratulations. If you program in C or C++ or any other language where you’re responsible for memory management, here’s a short tutorial on using valgrind, which, among other things, will report on any leaks your programs have: To install valgrind, such as on Ubuntu or Debian, issue: sudo apt-get install valgrind By default, ØMQ will cause valgrind to complain a lot. To remove these warnings, create a file called valgrind.supp that contains this: { <socketcall_sendto> Memcheck:Param socketcall.sendto(msg) fun:send ... } { <socketcall_sendto> Memcheck:Param socketcall.send(msg) fun:send ... } Fix your applications to exit cleanly after Ctrl-C.

To remove these warnings, create a file called valgrind.supp that contains this: { <socketcall_sendto> Memcheck:Param socketcall.sendto(msg) fun:send ... } { <socketcall_sendto> Memcheck:Param socketcall.send(msg) fun:send ... } Fix your applications to exit cleanly after Ctrl-C. For any application that exits by itself, that’s not needed, but for long-running applications, this is essential. Otherwise, valgrind will complain about all currently allocated memory. Build your application with -DDEBUG, if it’s not your default setting. That ensures valgrind can tell you exactly where memory is being leaked. Finally, run valgrind as follows (all on one line) valgrind --tool=memcheck --leak-check=full --suppressions=valgrind.supp someprog After fixing any errors it reports, you should get the pleasant message: ==30536== ERROR SUMMARY: 0 errors from 0 contexts...

Because there are four or five main socket flows, that meant quite a lot of debugging and testing. I debugged just by dumping messages to the console. Don’t use classic debuggers to step through ØMQ applications; you need to see the message flows to make any sense of what is going on. For testing, I always try to use valgrind, which catches memory leaks and invalid memory accesses. In C, this is a major concern, as you can’t delegate to a garbage collector. Using proper and consistent abstractions like kvmsg and CZMQ helps enormously. The Clustered Hashmap Protocol While the Model Six server is pretty much a mashup of the previous model plus the Binary Star pattern, the client is quite a lot more complex.


pages: 1,380 words: 190,710

Building Secure and Reliable Systems: Best Practices for Designing, Implementing, and Maintaining Systems by Heather Adkins, Betsy Beyer, Paul Blankinship, Ana Oprea, Piotr Lewandowski, Adam Stubblefield

air gap, anti-pattern, barriers to entry, bash_history, behavioural economics, business continuity plan, business logic, business process, Cass Sunstein, cloud computing, cognitive load, continuous integration, correlation does not imply causation, create, read, update, delete, cryptocurrency, cyber-physical system, database schema, Debian, defense in depth, DevOps, Edward Snowden, end-to-end encryption, exponential backoff, fault tolerance, fear of failure, general-purpose programming language, Google Chrome, if you see hoof prints, think horses—not zebras, information security, Internet of things, Kubernetes, load shedding, margin call, microservices, MITM: man-in-the-middle, NSO Group, nudge theory, operational security, performance metric, pull request, ransomware, reproducible builds, revision control, Richard Thaler, risk tolerance, self-driving car, single source of truth, Skype, slashdot, software as a service, source of truth, SQL injection, Stuxnet, the long tail, Turing test, undersea cable, uranium enrichment, Valgrind, web application, Y2K, zero day

This section presents some solutions for C++ and Go. C++: Valgrind or Google Sanitizers C++ allows for low-level memory management. As we mentioned earlier, memory management errors are a leading cause of security issues, and can result in the following failure scenarios: Reading unallocated memory (before new or after delete) Reading outside of the allocated memory (buffer overflow attack scenario) Reading uninitialized memory Memory leaks when a system loses the address of allocated memory or doesn’t deallocate unused memory early Valgrind is a popular framework that allows developers to catch those sorts of errors, even if unit tests don’t catch them.

As we mentioned earlier, memory management errors are a leading cause of security issues, and can result in the following failure scenarios: Reading unallocated memory (before new or after delete) Reading outside of the allocated memory (buffer overflow attack scenario) Reading uninitialized memory Memory leaks when a system loses the address of allocated memory or doesn’t deallocate unused memory early Valgrind is a popular framework that allows developers to catch those sorts of errors, even if unit tests don’t catch them. Valgrind has the benefit of providing a virtual machine that interprets a user’s binary, so users don’t need to recompile their code to use it. The Valgrind tool Helgrind can additionally detect common synchronization errors such as these: Misuses of the POSIX pthreads API (e.g., unlocking a not-locked mutex, or a mutex held by another thread) Potential deadlocks arising from lock ordering problems Data races caused by accessing memory without adequate locking or synchronization Alternatively, the Google Sanitizers suite offers various components that can detect all the same issues that Valgrind’s Callgrind (a cache and branch prediction profiler) can detect: AddressSanitizer (ASan) detects memory errors (buffer overflows, use after free, incorrect initialization order).

-Mental Models breaking down complexity, Breaking Down Complexity centralized responsibility for security/reliability requirements, Centralized Responsibility for Security and Reliability Requirements complex data flows, Understanding Complex Data Flows-Understanding Complex Data Flows complexity versus, Complexity Versus Understandability designing understandable systems, Designing Understandable Systems-Conclusion Google CA implementation, Complexity Versus Understandability identities, Identities-Example: Identity model for the Google production system interface specifications, Understandable Interface Specifications-Pay attention to idempotent operations mental models and, Mental Models security boundaries, Security Boundaries-TCBs and understandability software design, Software Design-Example: Secure cryptographic APIs and the Tink crypto framework system architecture, System Architecture-TCBs and understandability system invariants and, System Invariants-Analyzing Invariants unit testing, Unit Testing-How Unit Testing Affects Codeeffect on code, How Unit Testing Affects Code-How Unit Testing Affects Code when to write unit tests, When to Write Unit Tests writing effective unit tests, Writing Effective Unit Tests universal two-factor (U2F) hardware security tokens, Example: Strong second-factor authentication using FIDO security keys Unix, small functional APIs and, Small Functional APIs-Small Functional APIs unmanaged complexity, understandability versus, Complexity Versus Understandability unzipping, Deny lists Upvote, Increase Productivity and Usability URLs, Understanding Complex Data Flows usabilityfocus on, Increase Productivity and Usability increasing, Increase Productivity and Usability-Increase Productivity and Usability user experience, failures' effect on, User experience user productivity, least privilege and, Impact on User Productivity V Valgrind, Evolution, C++: Valgrind or Google Sanitizers validation, continuous (see continuous validation) velocity, initial versus sustained, Initial Velocity Versus Sustained Velocity-Initial Velocity Versus Sustained Velocity verifiable builds, Verifiable Builds-Unauthenticated inputsarchitectures, Verifiable build architectures implementation, Implementing verifiable builds-Unauthenticated inputs unauthenticated inputs, Unauthenticated inputs untrusted inputs, Untrusted inputs Verizon, Invisibility version advancement, Limit Your Dependencies on External Notions of Time virtual LANs (VLANs), Controlling the Blast Radius vulnerability researchers, as attackers, Vulnerability Researchers Vulnerability Reward Programs (bug bounties), Vulnerability Researchers, Background and Team Evolution, External Researchers-External Researchers vulnerability scanning teams, Special Teams: Blue and Red Teams W wall-clock time, limiting dependencies on, Limit Your Dependencies on External Notions of Time-Limit Your Dependencies on External Notions of Time WannaCry Ransomware, Attacker Motivations, Compromise web application firewall (WAF), Conclusion web applications, Google-internal framework, Example: Microservices and the Google Web Application Framework web origin, defined, Security boundaries and threat models WebKit, Background and Team Evolution "Wheel of Misfortune", Collaborative Debugging: A Way to Teach Wilkes, Maurice, From Debugging to Investigation writing code, Writing Code-Conclusionavoiding multilevel nesting, Avoid Multilevel Nesting choice of tools for, Choose the Right Tools-Use strong typing and static type checking common security vulnerabilities, Common Security Vulnerabilities-Preventing XSS: SafeHtml eliminating YAGNI smells, Eliminate YAGNI Smells frameworks to enforce security and reliability, Frameworks to Enforce Security and Reliability-Example code snippets lessons for framework evaluation/construction, Lessons for Evaluating and Building Frameworks-Legacy conversions memory-safe languages for, Use memory-safe languages refactoring, Refactoring repaying technical debt, Repay Technical Debt rollout strategy, Rollout Strategy sanitizing code, Sanitize Your Code security and reliability by default, Security and Reliability by Default-Go: Race Detector simple, safe, reliable libraries for common tasks, Simple, Safe, Reliable Libraries for Common Tasks simplicity's importance to, Simplicity Leads to Secure and Reliable Code-Refactoring static type checking for, Use strong typing and static type checking strong typing for, Use strong typing and static type checking, Use Strong Types-Use Strong Types understandability, Software Design-Example: Secure cryptographic APIs and the Tink crypto framework Wycheproof, How Unit Testing Affects Code X XSS (cross-site scripting), Preventing XSS: SafeHtml Y YAGNI ("You Aren't Gonna Need It"), Eliminate YAGNI Smells Yahoo!


pages: 555 words: 119,733

Autotools by John Calcote

Albert Einstein, card file, Debian, delayed gratification, Dennis Ritchie, don't repeat yourself, en.wikipedia.org, Everything should be made as simple as possible, Free Software Foundation, place-making, Richard Feynman, seminal paper, Valgrind

COFF is also used by other operating systems, such as IBM's AIX. Many Unix (and all Linux) systems today are based on the Executable and Linking Format (ELF) system, which promotes the use of soft references, which don't need to be fully resolved until the program is executed. [82] For more information on the Valgrind tool suite, see the Valgrind Developers' website at http://valgrind.org/. [83] Unix-like (POSIX) systems will retain deleted files for which outstanding file handles exist within running processes. From the filesystem user's perspective, the file appears to be gone, but the file remains intact until the last file handle is closed.

This variable has been set to a path referring to a library that presumably contains a heap manager that's compatible with the C malloc interface. This technique can be used to debug problems in your programs. By preloading your own heap manager, you can capture memory allocations in a logfile—in order to debug memory block overruns, for instance. This sort of technique is used by such widely known debugging aids as the valgrind package.[82] In the following example, the LD_PRELOAD environment variable is set on the same command line used to execute the df program. This shell code causes only the df child process environment to contain the LD_PRELOAD variable, set to the specified value: $ LD_PRELOAD=$HOME/lib/libmymalloc.so /bin/df ...


pages: 1,201 words: 233,519

Coders at Work by Peter Seibel

Ada Lovelace, Bill Atkinson, bioinformatics, Bletchley Park, Charles Babbage, cloud computing, Compatible Time-Sharing System, Conway's Game of Life, Dennis Ritchie, domain-specific language, don't repeat yourself, Donald Knuth, fallacies of distributed computing, fault tolerance, Fermat's Last Theorem, Firefox, Free Software Foundation, functional programming, George Gilder, glass ceiling, Guido van Rossum, history of Unix, HyperCard, industrial research laboratory, information retrieval, Ken Thompson, L Peter Deutsch, Larry Wall, loose coupling, Marc Andreessen, Menlo Park, Metcalfe's law, Multics, no silver bullet, Perl 6, premature optimization, publish or perish, random walk, revision control, Richard Stallman, rolodex, Ruby on Rails, Saturday Night Live, side project, slashdot, speech recognition, systems thinking, the scientific method, Therac-25, Turing complete, Turing machine, Turing test, type inference, Valgrind, web application

You try to figure out by monitoring execution and the state of memory and try to bound the extent of the bug and control flow and data that can be addressed. If it's a wild pointer store then you're kinda screwed and you have to really start looking at harder-to-use tools, which have only come to the fore recently, thanks to those gigahertz processors, like Valgrind and Purify. Instrumenting and having a checked model of the entire memory hierarchy is big. Robert O'Callahan, our big brain in New Zealand, did his own debugger based on the Valgrind framework, which efficiently logs every instruction so he can re-create the entire program state at any point. It's not just a time-traveling debugger. It's a full database so you see a data structure and there's a field with a scrogged value and you can say, “Who wrote to that last?”

If I have to go in there, I generally can find my way out. I love strace. Strace, I don't think I could live without. If I don't know what some program is doing, or what my program is doing, I run it under strace and see exactly what's happening. If I could only have one tool, it would probably be that. All the Valgrind tools, Callgrind and all that, those are good. But a lot of times lately, if there's something weird going on, I'm like, “OK, that function is too big; let's break that up into smaller parts and unit-test each one of them separately to figure out where my assumptions are wrong, rather than just sticking in random printlns.”

Though maybe they were reacting to the conservatism of the Unix C world of the '80s. But at some point we have to have better languages. And the reason is to have proof assistants or proof systems, to have some kind of automatic verification of some claims you're making in your code. You won't get all of them, right? And the dynamic tools like Valgrind and its race detectors, that's great too. There's no silver bullet, as Brooks said, but there are better languages and we should migrate to them as we can. Seibel: To what extent should programming languages be designed to prevent programmers from making mistakes? Eich: So a blue-collar language like Java shouldn't have a crazy generic system because blue-collar people can't figure out what the hell the syntax means with covariant, contravariant type constraints.


pages: 678 words: 159,840

The Debian Administrator's Handbook, Debian Wheezy From Discovery to Mastery by Raphaal Hertzog, Roland Mas

bash_history, Debian, distributed generation, do-ocracy, en.wikipedia.org, end-to-end encryption, failed state, Firefox, Free Software Foundation, GnuPG, Google Chrome, Jono Bacon, MITM: man-in-the-middle, Neal Stephenson, NP-complete, precautionary principle, QWERTY keyboard, RFC: Request For Comment, Richard Stallman, Skype, SpamAssassin, SQL injection, Valgrind, web application, zero day, Zimmermann PGP

CULTURE OpenSSL flaw in Debian Etch The OpenSSL library, as initially provided in Debian Etch, had a serious problem in its random number generator (RNG). Indeed, the Debian maintainer had made a change so that applications using it would no longer generate warnings when analyzed by memory testing tools like valgrind. Unfortunately, this change also meant that the RNG was employing only one source of entropy corresponding to the process number (PID) whose 32,000 possible values do not offer enough randomness. → http://www.debian.org/security/2008/dsa-1571 Specifically, whenever OpenSSL was used to generate a key, it always produced a key within a known set of hundreds of thousands of keys (32,000 multiplied by a small number of key lengths).

Additionally, the ssh-vulnkey command allows identification of possibly compromised keys in the system. A more thorough analysis of this incident brings to light that it is the result of multiple (small) problems, both at the OpenSSL project, as well as with the Debian package maintainer. A widely used library like OpenSSL should — without modifications — not generate warnings when tested by valgrind. Furthermore, the code (especially the parts as sensitive as the RNG) should be better commented to prevent such errors. The Debian maintainer, for his part, wanting to validate his modifications with the OpenSSL developers, simply explained his modifications without providing them the corresponding patch to review.


pages: 612 words: 187,431

The Art of UNIX Programming by Eric S. Raymond

A Pattern Language, Albert Einstein, Apple Newton, barriers to entry, bioinformatics, Boeing 747, Clayton Christensen, combinatorial explosion, commoditize, Compatible Time-Sharing System, correlation coefficient, David Brooks, Debian, Dennis Ritchie, domain-specific language, don't repeat yourself, Donald Knuth, end-to-end encryption, Everything should be made as simple as possible, facts on the ground, finite state, Free Software Foundation, general-purpose programming language, George Santayana, history of Unix, Innovator's Dilemma, job automation, Ken Thompson, Larry Wall, level 1 cache, machine readable, macro virus, Multics, MVC pattern, Neal Stephenson, no silver bullet, OSI model, pattern recognition, Paul Graham, peer-to-peer, premature optimization, pre–internet, publish or perish, revision control, RFC: Request For Comment, Richard Stallman, Robert Metcalfe, Steven Levy, the Cathedral and the Bazaar, transaction costs, Turing complete, Valgrind, wage slave, web application

Specifically, compile your software on a true 64-bit machine. Underlying datatypes can change on 64-bit machines, and you will often find new problems there. Find a Unix vendor's system and run the lint utility over your software. Run tools that look for memory leaks and other runtime errors; Electric Fence and Valgrind are two good ones available in open source. For Python projects, the PyChecker program can be a useful check. It often catches nontrivial errors. If you're writing Perl, check your code with perl -c (and maybe -T, if applicable). Use perl -w and 'use strict' religiously. (See the Perl documentation for further discussion.)


pages: 496 words: 174,084

Masterminds of Programming: Conversations With the Creators of Major Programming Languages by Federico Biancuzzi, Shane Warden

Benevolent Dictator For Life (BDFL), business intelligence, business logic, business process, cellular automata, cloud computing, cognitive load, commoditize, complexity theory, conceptual framework, continuous integration, data acquisition, Dennis Ritchie, domain-specific language, Douglas Hofstadter, Fellow of the Royal Society, finite state, Firefox, follow your passion, Frank Gehry, functional programming, general-purpose programming language, Guido van Rossum, higher-order functions, history of Unix, HyperCard, industrial research laboratory, information retrieval, information security, iterative process, Ivan Sutherland, John von Neumann, Ken Thompson, Larry Ellison, Larry Wall, linear programming, loose coupling, machine readable, machine translation, Mars Rover, millennium bug, Multics, NP-complete, Paul Graham, performance metric, Perl 6, QWERTY keyboard, RAND corporation, randomized controlled trial, Renaissance Technologies, Ruby on Rails, Sapir-Whorf hypothesis, seminal paper, Silicon Valley, slashdot, software as a service, software patent, sorting algorithm, SQL injection, Steve Jobs, traveling salesman, Turing complete, type inference, Valgrind, Von Neumann architecture, web application

I rarely use a debugger. When I do, it’s for C code, never for Lua code. For Lua, a few well-placed print statements usually work just fine. Roberto: I follow a similar approach. When I use a debugger, frequently it’s only to do a where to find where the code is crashing. For C code, a tool like Valgrind or Purify is essential. What is the role of comments in the source code? Roberto: Very small. I usually consider that if something needs comments, it is not well written. For me, a comment is almost a note like “I should try to rewrite this code later.” I think clear code is much more readable than commented code.