6 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, call centre, continuous integration, Debian,, Firefox, Grace Hopper, index card, Isaac Newton, natural language processing, p-value, performance metric, revision control, six sigma, software as a service, software patent, the scientific method, Therac-25, Valgrind, web application

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. The original version only supports Linux on some specific hardware platforms (x86, amd64, ppc32/64), but there exist unofficial ports to other systems. Valgrind emulates an environment similar to the one the program is supposed to run in. Since it also emulates a CPU, the execution is significantly slower (in the worst case, even up to 50 times slower).

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. Now, we execute the following command: valgrind -tool=callgrind ./foobar test1 This generates an output file, where the “pid” is a number.

., 2.6.1 and 2.6.2) also go through rigorous testing with a no new feature policy. 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. Memory leaks can be very detrimental to applications, as they can effectively create a denial-of-service (DoS) issue.


pages: 1,025 words: 150,187

ZeroMQ by Pieter Hintjens


anti-pattern, carbon footprint, cloud computing, Debian, distributed revision control, domain-specific language, factory automation, fault tolerance, fear of failure, finite state, Internet of things, iterative process, 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 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. 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.

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... Multithreading with ØMQ ØMQ is perhaps the nicest way ever to write multithreaded (MT) applications. Whereas ØMQ sockets require some readjustment if you are used to traditional sockets, ØMQ multithreading will take everything you know about writing MT applications, throw it into a heap in the garden, pour gasoline over it, and set it alight. It’s a rare book that deserves burning, but most books on concurrent programming do.

I built it piece by piece, and got each piece working properly before going onto the next one. 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,201 words: 233,519

Coders at Work by Peter Seibel


Ada Lovelace, bioinformatics, cloud computing, Conway's Game of Life, domain-specific language, fault tolerance, Fermat's Last Theorem, Firefox, George Gilder, glass ceiling, HyperCard, information retrieval, loose coupling, Menlo Park, Metcalfe's law, premature optimization, publish or perish, random walk, revision control, Richard Stallman, rolodex, Saturday Night Live, side project, slashdot, speech recognition, 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?” and you get the full stack.

I'm not that great at it, but I can look around and kind of figure things out generally. 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.” Then maybe in the process of refactoring, I have to think about the code more, and then it becomes obvious.

Like the C++ hype, the whole “design patterns will save us.” 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: 555 words: 119,733

Autotools by John Calcote


Albert Einstein, card file, Debian, delayed gratification,, place-making, Richard Feynman, Richard Feynman, Valgrind

Modern Windows operating systems are based on the Common Object File Format (COFF) system. 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 [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. Thus, this argument is not conclusive. As an aside, Windows operating systems simply disallow the delete operation on open files.

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/ /bin/df ... Unfortunately, free-floating symbols can also lead to problems. For instance, two libraries can provide the same symbol name, and the dynamic loader can inadvertently bind an executable to a symbol from the wrong library.


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,, failed state, Firefox, GnuPG, Google Chrome, Jono Bacon, NP-complete, QWERTY keyboard, RFC: Request For Comment, Richard Stallman, Skype, SpamAssassin, Valgrind, web application, x509 certificate, zero day, Zimmermann PGP

This additional protection is not, however, impregnable, and if you think that this file has been compromised, it is best to disable that key on the computers in which it has been installed (by removing it from the authorized_keys files) and replacing it with a newly generated key. 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. → 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. He also did not clearly identify himself as the maintainer of the corresponding Debian package.


pages: 496 words: 174,084

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


business intelligence, business process, cellular automata, cloud computing, complexity theory, conceptual framework, continuous integration, data acquisition, domain-specific language, Douglas Hofstadter, Fellow of the Royal Society, finite state, Firefox, follow your passion, Frank Gehry, general-purpose programming language, HyperCard, information retrieval, iterative process, John von Neumann, linear programming, loose coupling, Mars Rover, millennium bug, NP-complete, Paul Graham, performance metric, QWERTY keyboard, RAND corporation, randomized controlled trial, Renaissance Technologies, Silicon Valley, slashdot, software as a service, software patent, sorting algorithm, Steve Jobs, traveling salesman, Turing complete, type inference, Valgrind, Von Neumann architecture, web application

You should learn debugging as you learn to program. How do you test and debug your code? Luiz: I try mainly to construct and test it piece by piece. 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. Luiz: I agree. I stick to comments that say something that the code does not make obvious.