DOCSLIB.ORG

DOUBLETAKE: Fast and Precise Error Detection Via Evidence-Based Dynamic Analysis

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
DOUBLETAKE: Fast and Precise Error Detection Via Evidence-Based Dynamic Analysis 2016 IEEE/ACM 38th IEEE International Conference on Software Engineering DOUBLETAKE: Fast and Precise Error Detection via Evidence-Based Dynamic Analysis Tongping Liu ∗ Charlie Curtsinger ∗ Emery D. Berger Dept. of Computer Science Dept. of Computer Science College of Information and University of Texas Grinnell College Computer Sciences at San Antonio 1116 8th Ave. University of Massachusetts San Antonio, TX 78249 Grinnell, IA 50112 Amherst [email protected] [email protected] Amherst, MA 01003 [email protected] ABSTRACT Categories and Subject Descriptors Programs written in unsafe languages like C and C++ often suffer D.2.5 [Software Engineering]: Testing and Debugging–Debugging from errors like buffer overflows, dangling pointers, and memory Aids, Monitors, Tracing; D.2.4 [Software Engineering]: Soft- leaks. Dynamic analysis tools like Valgrind can detect these er- ware/Program Verification–Reliability rors, but their overhead—primarily due to the cost of instrumenting every memory read and write—makes them too heavyweight for use in deployed applications and makes testing with them painfully Keywords slow. The result is that much deployed software remains suscepti- Dynamic Analysis, Software Quality, Testing, Debugging, Leak ble to these bugs, which are notoriously difficult to track down. Detection, Buffer Overflow Detection, Use-After-Free Detection This paper presents evidence-based dynamic analysis, an ap- proach that enables these analyses while imposing minimal over- 1. INTRODUCTION head (under 5%), making it practical for the first time to perform these analyses in deployed settings. The key insight of evidence- Dynamic analysis tools are widely used to find bugs in appli- based dynamic analysis is that for a class of errors, it is possible to cations. They are popular among programmers because of their ensure that evidence that they happened at some point in the past precision—for many analyses, they report no false positives—and remains for later detection. Evidence-based dynamic analysis al- can pinpoint the exact location of errors, down to the individual lows execution to proceed at nearly full speed until the end of an line of code. Perhaps the most prominent and widely used dynamic epoch (e.g., a heavyweight system call). It then examines program analysis tool for C/C++ binaries is Valgrind [28]. Valgrind’s most state to check for evidence that an error occurred at some time dur- popular use case, via its default tool, MemCheck, can find a wide ing that epoch. If so, it rolls back execution and re-executes the range of memory errors, including buffer overflows, use-after-free code with instrumentation activated to pinpoint the error. errors, and memory leaks. We present DOUBLETAKE, a prototype evidence-based dynamic Unfortunately, these dynamic analysis tools often impose sig- analysis framework. DOUBLETAKE is practical and easy to de- nificant performance overhead that precludes their use outside of ploy, requiring neither custom hardware, compiler, nor operating testing scenarios. An extreme example is the widely-used tool Val- system support. We demonstrate DOUBLETAKE’s generality and grind. Across the SPEC CPU2006 benchmark suite, Valgrind de- × efficiency by building dynamic analyses that find buffer overflows, grades performance by almost 17 on average (geometric mean); × × memory use-after-free errors, and memory leaks. Our evaluation its overhead ranges from 4.5 and 42.8 , making it often too slow shows that DOUBLETAKE is efficient, imposing under 5% over- to use even for testing (see Table 5). head on average, making it the fastest such system to date. It is While faster dynamic analysis frameworks exist for finding par- also precise: DOUBLETAKE pinpoints the location of these errors ticular errors (leveraging compiler support to reduce overhead), to the exact line and memory addresses where they occur, providing they sacrifice precision while continuing to impose substantial over- valuable debugging information to programmers. head that would impede their use in deployed settings. The current state-of-the-art, Google’s AddressSanitizer, detects buffer overflows and use-after-free errors, but slows applications by around 30% [38]. AddressSanitizer also identifies memory leaks but only at the end * This work was initiated and partially conducted while Liu and Curtsinger of program execution, which is not necessarily useful for servers or were PhD students at the University of Massachusetts Amherst. other long-lived applications. Because of their overhead, this class of dynamic analysis tools Permission to make digital or hard copies of all or part of this work for personal or can generally only be used during testing. However, they are lim- classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation ited by definition to the executions that are tested prior to deploy- on the first page. Copyrights for components of this work owned by others than the ment. Even exhaustive testing regimes will inevitably fail to un- author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or cover these errors, which are notoriously difficult to debug. republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. This paper presents an approach called evidence-based dynamic ICSE ’16, May 14 - 22, 2016, Austin, TX, USA analysis that is based on the following key insight: it is often possi- ble to discover evidence that an error occurred or plant markers that © 2016 Copyright held by the owner/author(s). Publication rights licensed to ACM. ISBN 978-1-4503-3900-1/16/05. $15.00 ensure that such evidence exists. By combining evidence place- DOI: http://dx.doi.org/10.1145/2884781.2884784 ment with checkpointing and infrequent checking, we can run app- 911 plications at nearly full speed in the common case (no errors). If we find an error, we can use the checkpoint to roll back and re- execute the program with instrumentation activated to pinpoint the exact cause of the error. Certain errors, including the ones we describe here, naturally ex- hibit a monotonicity property: when an error occurs, evidence that it happened tends to remain or even grow so that it can be discov- ered at a later point during execution. When this evidence is not naturally occurring or not naturally monotonic, it can be forced to exhibit this property by planting what we call tripwires to ensure later detection. A canonical example of such a tripwire is a ran- dom canary value placed in unallocated space between heap ob- jects [11]. A corrupted canary is incontrovertible evidence that a Figure 1: Overview of DOUBLETAKE in action: execution is buffer overflow occurred at some time in the past. divided into epochs at the boundary of irrevocable system calls. This paper presents a prototype evidence-based dynamic analy- Each epoch begins by taking a snapshot of program state. Exe- sis framework called DOUBLETAKE that locates such errors with cution runs at nearly full-speed during epochs. Evidence-based extremely low overhead and no false positives. DOUBLETAKE analysis takes place once an epoch ends, replaying execution checkpoints program state and performs most of its error analyses from the previous snapshot until it pinpoints the exact location only at epoch boundaries (what we call irrevocable system calls) or where the error is introduced. Relatively-long epochs amortize when segfaults occur; these occur relatively infrequently, amortiz- the cost of snapshots and analysis, keeping overhead low. ing DOUBLETAKE’s overhead. If DOUBLETAKE finds evidence of an error at an epoch bound- ary or after a segmentation violation, it re-executes the application Outline from the most recent checkpoint. During re-execution, DOUBLE- This paper first provides an overview of the basic operation of TAKE enables instrumentation to let it precisely locate the source DOUBLETAKE in Section 2. Section 3 details the dynamic anal- of the error. For example, for buffer overflows, DOUBLETAKE sets yses we have built using DOUBLETAKE. Section 4 describes key hardware watchpoints on the tripwire memory locations that were implementation details. Section 5 evaluates DOUBLETAKE’s effec- found to be corrupted. During re-execution, DOUBLETAKE pin- tiveness, performance, and memory overhead, and compares these points exactly the point where the buffer overflow occurred. to the state of the art. Section 6 describes how users can add new We have implemented DOUBLETAKE as a drop-in library that analyses to DOUBLETAKE, and discusses limitations of evidence- can be linked directly with the application, without the need to based analysis and the detectors implemented to date. Section 7 modify code or even recompile the program. DOUBLETAKE works describes key related work and Section 8 concludes. without the need for custom hardware, compiler, or OS support. Using DOUBLETAKE as a framework, we have built three dif- 2. OVERVIEW ferent analyses that attack three of the most salient problems for DOUBLETAKE is an efficient dynamic analysis framework for a unsafe code: a buffer overflow detector (as described above), a class of errors that exhibit or can be forced to exhibit a monotonic- use-after-free detector, and a memory leak detector. These anal- ity property: evidence of the error is persistent and can be gathered yses can all run concurrently. By virtue of being evidence-based, after-the-fact. With DOUBLETAKE, program execution is divided they have a zero false positive rate, precisely pinpoint the error lo- into epochs, during which execution proceeds at full speed (Fig- cation, and operate with extremely low overhead: for example, with ure 1). At the beginning of an epoch, DOUBLETAKE checkpoints DOUBLETAKE, buffer overflow analysis alone operates with virtu- program state. Epochs end only when the application issues an irre- ally no overhead. When all three of these analyses are enabled, vocable system call (e.g., a socket read); most system calls are not DOUBLETAKE’s average overhead is under 5%.
Load more

Recommended publications
  • Ben Livshits 1 Basic Instrumentation
    Runtime monitoring CO444H Ben Livshits 1 Basic Instrumentation • Insert additional code into the program • This code is designed to record important events as they occur at runtime • Some examples • A particular function is being hit or a statement is being hit • This leads to function-level or line-level coverage • Each allocation to measure overall memory allocation 2 Levels of Instrumentation • Native code • Instrument machine code • Tools like LLVM are often used for rewriting • Bytecode • Common for languages such as Java and C# • A variety of tools are available for each bytecode format • JoeQ is in this category as well, although it’s a lot more general • Source code • Common for languages like JavaScript • Often the easiest option – parse the code and add more statements 3 Runtime Code Monitoring •Three major examples of monitoring • Purify/Valgrind • Detecting data races • Detecting memory leaks 4 5 Memory Error Detection Purify • C and C++ are not type-safe • The type system and the runtime fail to enforce type safety • What are some of the examples? • Possible to read and write outside of your intended data structures • Write beyond loop bounds • Or object bounds • Or overwrite the code pointer, etc. 6 Track Each Byte of Memory • Three states for every byte of tracker memory • Unallocated: cannot be read or written • Allocated but not initialized: cannot be read • Allocated and initialized: all operations are allowed 7 Instrumentation for Purify • Check the state of each byte at every access • Binary instrumentation: • Add
    [Show full text]
  • Memory Leak Or Dangling Pointer
    Modern C++ for Computer Vision and Image Processing Igor Bogoslavskyi Outline Using pointers Pointers are polymorphic Pointer “this” Using const with pointers Stack and Heap Memory leaks and dangling pointers Memory leak Dangling pointer RAII 2 Using pointers in real world Using pointers for classes Pointers can point to objects of custom classes: 1 std::vector<int> vector_int; 2 std::vector<int >* vec_ptr = &vector_int; 3 MyClass obj; 4 MyClass* obj_ptr = &obj; Call object functions from pointer with -> 1 MyClass obj; 2 obj.MyFunc(); 3 MyClass* obj_ptr = &obj; 4 obj_ptr->MyFunc(); obj->Func() (*obj).Func() ↔ 4 Pointers are polymorphic Pointers are just like references, but have additional useful properties: Can be reassigned Can point to ‘‘nothing’’ (nullptr) Can be stored in a vector or an array Use pointers for polymorphism 1 Derived derived; 2 Base* ptr = &derived; Example: for implementing strategy store a pointer to the strategy interface and initialize it with nullptr and check if it is set before calling its methods 5 1 #include <iostream > 2 #include <vector > 3 using std::cout; 4 struct AbstractShape { 5 virtual void Print() const = 0; 6 }; 7 struct Square : public AbstractShape { 8 void Print() const override { cout << "Square\n";} 9 }; 10 struct Triangle : public AbstractShape { 11 void Print() const override { cout << "Triangle\n";} 12 }; 13 int main() { 14 std::vector<AbstractShape*> shapes; 15 Square square; 16 Triangle triangle; 17 shapes.push_back(&square); 18 shapes.push_back(&triangle); 19 for (const auto* shape : shapes) { shape->Print(); } 20 return 0; 21 } 6 this pointer Every object of a class or a struct holds a pointer to itself This pointer is called this Allows the objects to: Return a reference to themselves: return *this; Create copies of themselves within a function Explicitly show that a member belongs to the current object: this->x(); 7 Using const with pointers Pointers can point to a const variable: 1 // Cannot change value , can reassign pointer.
    [Show full text]
  • Effective and Efficient Memory Protection Using Dynamic Tainting
    1 Effective and Efficient Memory Protection Using Dynamic Tainting Ioannis Doudalis, Student Member, IEEE, James Clause, Member, IEEE, Guru Venkataramani, Member, IEEE, Milos Prvulovic, Senior Member, IEEE, and Alessandro Orso, Member, IEEE, ! Abstract—Programs written in languages allowing direct access to pointer p or a pointer derived from p and 2) if the access memory through pointers often contain memory-related faults, which occurs during the interval when p is valid, (i.e. between the cause non-deterministic failures and security vulnerabilities. We present allocation and deallocation of m). All other accesses to m are a new dynamic tainting technique to detect illegal memory accesses. illegal memory accesses (IMAs), where a pointer is used to When memory is allocated, at runtime, we taint both the memory and the corresponding pointer using the same taint mark. Taint marks access memory outside the bounds of the memory area with are then propagated and checked every time a memory address m which it was originally associated, or outside the time period is accessed through a pointer p; if the associated taint marks differ, during which the pointer is valid. an illegal access is reported. To allow always-on checking using a IMAs are especially relevant for several reasons. First, they low-overhead, hardware-assisted implementation, we make several key are caused by typical programming errors, such as array-out- technical decisions. We use a configurable, low number of reusable taint of-bounds accesses and stale pointer dereferences, and are thus marks instead of a unique mark for each allocated area of memory, reducing the performance overhead without losing the ability to target widespread and common.
    [Show full text]
  • Tutorial on Debugging, Memory Leaks and Profiling
    High Performance Computing for Science and Engineering I Tutorial on debugging, memory leaks and profiling Michalis Chatzimanolakis Computational Science & Engineering Laboratory OUTLINE - Approaches to debug your code •Using assertions •Using a debugger •Memory sanitation •Using a profiler Assertions in C++ An assertion is a logical statement that will cause your code to abort execution, if it is false. Example: Assertions can affect performance, Assertions perform checks that make sure that as they are essentially ‘if’ statements. some conditions are met. However, it is good practice to add assertions in a code. A simple compilation flag can ignore all assertions, so it is generally a good idea to use them. It is useful to combine assertions with the std functions isinf and isnan They can also be used with screen output. Compiler warnings Compiler warnings are compilation flags that you can (should) add to your Makefiles. Enabling warnings makes the compiler check for several issues in your source file, such as: • Forgetting to initialize a variable • Not using a declared variable • Using a function before declaring it • Having screen/file output with incorrect format (for example, treating doubles as integers) Generally, you should add warnings and try to fix all of them, before proceeding with further debugging your code. Note that different compilers may produce different warnings. The most common compiler warning flags are listed below: -Wall : enables several construction/declaration warnings -Wextra : more warnings than Wall including warnings for unused variables -Werror: will treat all warnings as errors -Wpedantic: warnings related to the use of non standard C++ extensions Using a debugger What is a debugger? A debugger is a program.
    [Show full text]
  • Memory Vulnerability Diagnosis for Binary Program
    ITM Web of Conferences 7 03004 , (2016) DOI: 10.1051/itmconf/20160703004 ITA 2016 Memory Vulnerability Diagnosis for Binary Program Feng-Yi TANG, Chao FENG and Chao-Jing TANG College of Electronic Science and Engineering National University of Defense Technology Changsha, China Abstract. Vulnerability diagnosis is important for program security analysis. It is a further step to understand the vulnerability after it is detected, as well as a preparatory step for vulnerability repair or exploitation. This paper mainly analyses the inner theories of major memory vulnerabilities and the threats of them. And then suggests some methods to diagnose several types of memory vulnerabilities for the binary programs, which is a difficult task due to the lack of source code. The diagnosis methods target at buffer overflow, use after free (UAF) and format string vulnerabilities. We carried out some tests on the Linux platform to validate the effectiveness of the diagnosis methods. It is proved that the methods can judge the type of the vulnerability given a binary program. 1 Introduction (or both) the memory area. These headers can contain some information like size, used or not, and etc. Memory vulnerabilities are difficult to detect and diagnose Therefore, we can monitor the allocator so as to especially for those do not crash the program. Due to its determine the base address and the size of the allocation importance, vulnerability diagnosis problem has been areas. Then, check all STORE and LOAD accesses in intensively studied. Researchers have proposed different memory to see which one is outside the allocated area. techniques to diagnose memory vulnerabilities.
    [Show full text]
  • A Statistical Approach for Identifying Memory Leaks in Cloud Applications
    A STATISTICAL APPROACH FOR IDENTIFYING MEMORY LEAKS IN CLOUD APPLICATIONS Vladimir Sorˇ and Satish Narayana Srirama Institute of Computer Science, University of Tartu, J. Liivi 2, Tartu, Estonia Keywords: Troubleshooting, JavaTM Virtual Machine, Byte code instrumentation, Cloud computing, Tools. Abstract: This position paper describes the attempt to automate the statistical approach for memory leak detection in JavaTM applications. Proposed system extends the basic statistical memory leak detection method with further intelligence to pinpoint the source of the memory leak in the source code. As the method adds only small overhead in runtime it is designed to be used in production systems and will help detecting memory leaks in production environments without constraint to the source of the leak. Architecture of the proposed approach is intended to use in cloud applications. 1 INTRODUCTION in production under very specific circumstances (of- ten hardly specifiable) can be very hard to find and fix Memory leaks can be a major problem in distributed in development and test environments. applications, depleting their performance, even if they This is the area we think we can improve by de- run on platforms with automatic memory manage- veloping the solution that uses efficient statistical al- ment like Java Virtual Machine. Finding memory gorithm to detect memory leaks in advance, imposes leaks is coveredby many researches and there are sev- low overhead in production system and would help eral tools and methodologies to find memory leaks. tracking down the source of the leak. The rest of the However, these tools are incorporated in profilers and paper is organized as follows.
    [Show full text]
  • Using Cyclic Memory Allocation to Eliminate Memory Leaks
    Using Cyclic Memory Allocation to Eliminate Memory Leaks Huu Hai NGUYEN1 and Martin RINARD2 1Singapore-MIT Alliance, National University of Singapore 2CSAIL, Massachusetts Institute of Technology Abstract— We present and evaluate a new memory man- I. INTRODUCTION agement technique for eliminating memory leaks in programs with dynamic memory allocation. This technique observes the A program that uses explicit allocation and deallocation has execution of the program on a sequence of training inputs to a memory leak when it fails to free objects that it will no longer find m-bounded allocation sites, which have the property that at access in the future. A program that uses garbage collection any time during the execution of the program, the program only has a memory leak when it retains references to objects that accesses the last m objects allocated at that site. The technique it will no longer access in the future. Memory leaks are an then transforms the program to use cyclic memory allocation at that site: it preallocates a buffer containing m objects of the issue since they can cause the program to consume increasing type allocated at that site, with each allocation returning the amounts of memory as it runs. Eventually the program may next object in the buffer. At the end of the buffer the allocations exhaust the available memory and fail. Memory leaks may wrap back around to the first object. Cyclic allocation eliminates therefore be especially problematic for server programs that any memory leak at the allocation site — the total amount of must execute for long (and in principle unbounded) periods of memory required to hold all of the objects ever allocated at the site is simply m times the object size.
    [Show full text]
  • Jamaicavm 8.1 — User Manual
    JamaicaVM 8.1 — User Manual Java Technology for Critical Embedded Systems aicas GmbH 2 JamaicaVM 8.1 — User Manual: Java Technology for Critical Embedded Systems JamaicaVM 8.1, Release 1. Published May 31, 2017. c 2001–2017 aicas GmbH, Karlsruhe. All rights reserved. No licenses, expressed or implied, are granted with respect to any of the technology described in this publication. aicas GmbH retains all intellectual property rights associated with the technology described in this publication. This publication is intended to assist application developers to develop applications only for the Jamaica Virtual Machine. Every effort has been made to ensure that the information in this publication is accurate. aicas GmbH is not responsible for printing or clerical errors. Although the information herein is provided with good faith, the supplier gives neither warranty nor guarantee that the information is correct or that the results described are obtainable under end-user conditions. aicas GmbH phone +49 721 663 968-0 Emmy-Noether-Straße 9 fax +49 721 663 968-99 76131 Karlsruhe email [email protected] Germany web http://www.aicas.com aicas incorporated phone +1 203 359 5705 6 Landmark Square, Suite 400 Stamford CT 06901 email [email protected] USA web http://www.aicas.com aicas GmbH phone +33 1 4997 1762 9 Allee de l’Arche fax +33 1 4997 1700 92671 Paris La Defense email [email protected] France web http://www.aicas.com This product includes software developed by IAIK of Graz University of Technology. This software is based in part on the work of the Independent JPEG Group.
    [Show full text]
  • Efficient High Frequency Checkpointing for Recovery and Debugging Vogt, D
    VU Research Portal Efficient High Frequency Checkpointing for Recovery and Debugging Vogt, D. 2019 document version Publisher's PDF, also known as Version of record Link to publication in VU Research Portal citation for published version (APA) Vogt, D. (2019). Efficient High Frequency Checkpointing for Recovery and Debugging. General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal ? Take down policy If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim. E-mail address: [email protected] Download date: 30. Sep. 2021 Efficient High Frequency Checkpointing for Recovery and Debugging Ph.D. Thesis Dirk Vogt Vrije Universiteit Amsterdam, 2019 This research was funded by the European Research Council under the ERC Advanced Grant 227874. Copyright © 2019 by Dirk Vogt ISBN 978-94-028-1388-3 Printed by Ipskamp Printing BV VRIJE UNIVERSITEIT Efficient High Frequency Checkpointing for Recovery and Debugging ACADEMISCH PROEFSCHRIFT ter verkrijging van de graad Doctor aan de Vrije Universiteit Amsterdam, op gezag van de rector magnificus prof.dr.
    [Show full text]
  • Xilinx XAPP1137 Linux Operating System Software Debugging
    Application Note: Embedded Processing Linux Operating System Software R Debugging Techniques with Xilinx Embedded Development Platforms XAPP1137 (v1.0) June 9, 2009 Author: Brian Hill Abstract This application note discusses Linux Operating System debugging techniques. Debugging boot issues, kernel panics, software and hardware debuggers, driver <-> application interaction, and various other tools are discussed. Included Included with this application note is one reference system built for the Xilinx ML507 Rev A Systems board. The reference system is available in the following ZIP file available at: https://secure.xilinx.com/webreg/clickthrough.do?cid=125262 Introduction This application note discusses Linux Operating System debugging techniques. Software applications and drivers are included to present debugging material. General Topics The application note discusses debugging Linux boot issues, and the use of various Linux debugging facilities such as strace. Included Software buggy_core The buggy_core application is used to demonstrate techniques for debugging application crashes. The use of gdb, gdbserver, and coredump analysis are discussed. buggy_memleak The buggy_memleak application allocates memory with malloc() and never frees it. This application is used to discuss memory leak detection and debugging techniques with the mtrace facility and the Linux /proc filesystem. buggy_drv A kernel driver ‘buggy_drv’ is provided as an example of debugging kernel bugs. buggy_allstrings The buggy_allstrings application operates with the buggy_drv driver. buggy_choosestring The buggy_choosestring application operates with the buggy_drv driver. Intended This application note is best suited to users who are comfortable configuring, building, and Audience booting Linux on a Xilinx embedded platform. © 2009 Xilinx, Inc. All rights reserved. XILINX, the Xilinx logo, and other designated brands included herein are trademarks of Xilinx, Inc.
    [Show full text]
  • Boundschecker Free Download
    Boundschecker free download click here to download I give Micro Focus and/or Micro Focus partners permission to contact me regarding Micro Focus products and services. View our Privacy Policy. Download here. IMO It might be a better idea to write custom memory manager (the one that supports new/delete/malloc/free wrappers). Make a new/delete. Our website provides a free download of Micro Focus DevPartner for Visual C++ BoundsChecker Suite Our antivirus check shows. Download Boundschecker - best software for Windows. Deleaker Add-in for Visual C++: Deleaker is a useful add-in for Visual Studio that helps. boundschecker Windows 10 downloads - Free boundschecker download for Windows 10 - Windows 10 Download - Free Windows 10 Download. DevPartner® Visual C++ BoundsChecker Suite; Visual COBOL® for Visual Download the zip file that contains the HeapAgent free trial. Breaking the bounds of BoundsChecker: Micro Focus DevPartner® for Visual C++ / BoundsChecker Suite extends the DevPartner BoundsChecker capabilities. NET and native support DevPartner VC++ BoundsChecker Suite - Geared for C/C++ Development Micro Focus Testing Solutions - ASQ for. You can also download this document in Microsoft Word for Windows version / format . On every call to allocate or free memory, HeapAgent validates the. BoundsChecker is a memory checking and API call validation tool used for C++ software From Wikipedia, the free encyclopedia. BoundsChecker is an indispensable tool for Windows programming. It finds errors that no one else can find (including tons in Microsoft's code!!). Its main focus is. Bounds checker Free Download,Bounds checker Software Collection Download. The transition from BoundsChecker tools to the Intel Inspector XE is straightforward.
    [Show full text]
  • Dxperience V2008 Vol 1 All Devexpress ASP.NET, Winforms, WPF and Productivity Tools in One Package
    /issue 66/us edition best selling publisher awards see page 58 .upThe latest dateproducts available at www.componentsource.com Experience the DevExpress Difference • ASP.NET, WinForms & WPF Components • IDE Productivity Tools • Business Application Frameworks In one integrated package • XtraReports Suite • XtraReports for ASP.NET • XtraGrid Suite • XtraCharts for ASP.NET • XtraEditors Suite • ASPxGridView • XtraCharts Suite • ASPxEditors • XtraPivotGrid Suite • ASPxPivotGrid • XtraBars Suite • ASPxperience • XtraScheduler Suite • ASPxTreeList • XtraLayout Control • ASPxSpellChecker • XtraNavBar • ASPxHTML Editor • XtraPrinting Library • CodeRush • XtraSpellChecker • Refactor! Pro • XtraVerticalGrid • eXpressPersistent Objects • XtraTreeList • eXpressApp Framework DXperience v2008 vol 1 All DevExpress ASP.NET, WinForms, WPF and Productivity Tools in one package Learn more at: www.componentsource.com/devexpress US Headquarters European Headquarters Asia / Pacific Headquarters ComponentSource ComponentSource ComponentSource 650 Claremore Prof Way 30 Greyfriars Road 3F Kojimachi Square Bldg www.componentsource.com Suite 100 Reading 3-3 Kojimachi Chiyoda-ku Woodstock Berkshire Tokyo GA 30188-5188 RG1 1PE Japan Sales Hotline: USA United Kingdom 102-0083 Tel: (770) 250 6100 Tel: +44 118 958 1111 Tel: +81-3-3237-0281 Fax: (770) 250 6199 Fax: +44 118 958 9999 Fax: +81-3-3237-0282 (888) 850-9911 /n software /n software Red Carpet Subscription 2008 Write communications, security and e-business applications. • Includes components for FTP, IMAP, SNMP, SSL, SSH, S/MIME, Digital Certificates, Credit Card Processing and e-business (EDI) transactions • Free updates, upgrades, tech support and new releases for a year NEW RELEASE IP*Works! Internet Communications Secure Components Includes IP*Works! which is a ATOM, REST, MX, DNS, RSS, NNTP, /n software Red Carpet comprehensive framework for SMPP, POP, Rexec, Rshell, SMTP, Subscription includes secure Internet development.
    [Show full text]