`

SSD06 Exercise03 个人解答

阅读更多

Debugging Malloc Lab: Detecting Memory-Related Errors

Introduction

The usual implementation of malloc and free are unforgiving to errors in their callers' code, including cases where the programmer overflows an array, forgets to free memory, or frees a memory block twice. This often does not affect the program immediately, waiting until the corrupted memory is used later (in the case of overwrites) or gradually accumulating allocated but unused blocks. Thus, debugging can be extremely difficult.

In this assignment, you will write a wrapper for the malloc package that will catch errors in the code that calls malloc and free. The skills you will have learned upon the completion of this exercise are pointer arithmetic and a greater understanding of the consequences of subtle memory mistakes.

Logistics

Unzip debugging_malloc.zip into an empty directory. The files contained are as follows:

File(s): Function:
debugmalloc.c Contains the implementation of the three functions you will be writing. This is the one file you will be editing and handing in.
debugmalloc.h Contains the declaration of the functions, as well as the macros that will call them.
driver.c Contains main procedure and the code that will be calling the functions in the malloc package
dmhelper.c , dmhelper.h Contain the helper functions and macros that you will be calling from your code
grader.pl Perl script that runs your code for the various test cases and gives you feedback based on your current code
debugmalloc.vcproj Project file
tailor.h , getopt.c , getopt.h Tools that are used only by the driver program for I/O purposes. You will not need to know what the code in these files do.

Specification

Programs that use this package will call the macros MALLOC and FREE . MALLOC and FREE are used exactly the same way as the malloc() and free() functions in the standard C malloc package. That is, the line

void *ptr = MALLOC(n);

will allocate a payload of at least n bytes, and ptr will point to the front of this block. The line

FREE(ptr);

will cause the payload pointed to by ptr to be deallocated and become available for later use. The macros are defined as follows:

#define MALLOC(s)       MyMalloc(s, __FILE__, __LINE__)
#define FREE(p)         MyFree(p, __FILE__, __LINE__)

The __FILE__ macro resolves to the filename and __LINE__ resolves to the current line number. The debugmalloc.c file contains three functions that you are required to implement, as shown:

void *MyMalloc(size_t size, char *filename, int linenumber);
void MyFree(void *ptr, char *filename, int linenumber);
int  AllocatedSize();

Using the macros above allow MyMalloc and MyFree to be called with the filename and line number of the actual MALLOC and FREE calls, while retaining the same form as the usual malloc package. By default, MyMalloc and MyFree() simply call malloc() and free() , respectively, and return immediately. AllocatedSize() should return the number of bytes currently allocated by the user: the sum of the requested bytes through MALLOC minus the bytes freed using FREE . By default, it simply returns 0 and thus is unimplemented. The definitions are shown below:

void *MyMalloc(size_t size, char *filename, int linenumber) {
    return (malloc(size));
}

void MyFree(void *ptr, char *filename, int linenumber) {
	free(ptr);
}

int AllocatedSize() {
	return 0;
}

Your job is to modify these functions so that they will catch a number of errors that will be described in the next section. There are also two optional functions in the debugmalloc.c file that you can implement:

void PrintAllocatedBlocks();
int HeapCheck();

PrintAllocatedBlocks should print out information about all currently allocated blocks. HeapCheck should check all the blocks for possible memory overwrites.

Implementation Details

To catch the errors, you will allocate a slightly larger amount of space and insert a header and a footer around the "requested payload". MyMalloc() will insert information into this area, and MyFree() will check to see if the information has not changed. The organization of the complete memory block is as shown below:

Header
Checksum ... Fence
Payload Footer
Fence

Note: MyMalloc() returns a pointer to the payload, not the beginning of the whole block. Also, the ptr parameter passed into MyFree(void *ptr) will point to the payload, not the beginning of the block. Information that you might want to store in this extra (header, footer) area include:

  • a "fence" immediately around the requested payload with a known value like 0xCCDEADCC, so that you can check if it has been changed when the block is freed.
  • the size of the block
  • a checksum for the header to ensure that it has not been corrupted (A checksum of a sequence of bits is calculated by counting the number of "1" bits in the stream. For example, the checksum for "1000100010001000" is 4. It is a simple error detection mechanism.)
  • the filename and line number of the MALLOC() call

The errors that can occur are:

  • Error #1: Writing past the beginning of the user's block (through the fence)
  • Error #2: Writing past the end of the user's block (through the fence)
  • Error #3: Corrupting the header information
  • Error #4: Attempting to free an unallocated or already-freed block
  • Error #5: Memory leak detection (user can use ALLOCATEDSIZE to check for leaks at the end of the program)

To report the first four errors, call one of these two functions:

void error(int errorcode, char *filename, int linenumber);
errorcode is the number assigned to the error as stated above. filename and linenumber contain the filename and line number of the line (the free call) in which the error is invoked. For example, call error(2, filename, linenumber) if you come across a situation where the footer fence has been changed.
void errorfl(int errorcode, char *filename_malloc, int linenumber_malloc, char *filename_free, int linenumber_free);
This is the same as the error() , except there are two sets of filenames and line numbers, one for the statement in which the block was malloc'd, and the other for the statement in which the block was free'd (and the error was invoked).

The fact that MyMalloc() and MyFree() are given the filename and line number of the MALLOC() and FREE() call can prove to be very useful when you are reporting errors. The more information you print out, the easier it will be for the programmer to locate the error. Use errorfl() instead of error() whenever possible. errorfl() obviously cannot be used on situations where FREE() is called on an unallocated block, since it was not ever MALLOC 'd.

Note: You will only be reporting errors from MyFree() . None of the errors can be caught in MyMalloc()

In the case of memory leaks, the driver program will call AllocatedSize() , and the grader will look at its return value and possible output. AllocatedSize() should return the number of bytes currently allocated from MALLOC and FREE calls. For example, the code segment:

void *ptr1 = MALLOC(10), *ptr2 = MALLOC(8);
FREE(ptr2);
printf("%d\n", AllocatedSize());

should print out "10". Once you have gotten to the point where you can catch all of the errors, you can go an optional step further and create a global list of allocated blocks. This will allow you to perform analysis of memory leaks and currently allocated memory. You can implement the void PrintAllocatedBlocks() function, which prints out the filename and line number where all currently allocated blocks were MALLOC() 'd. A macro is provided for you to use to print out information about a single block in a readable and gradeable format:

PRINTBLOCK(int size, char *filename, int linenumber)

Also, you can implement the int HeapCheck() function. This should check all of the currently allocated blocks and return -1 if there is an error and 0 if all blocks are valid. In addition, it should print out the information about all of the corrupted blocks, using the macro #define PRINTERROR(int errorcode, char *filename, int linenumber) , with errorcode equal to the error number (according to the list described earlier) the block has gone through. You may find that this global list can also allow you to be more specific in your error messages, as it is otherwise difficult to determine the difference between an overwrite of a non-payload area and an attempted FREE() of an unallocated block.

Evaluation

You are given 7 test cases to work with, plus 1 extra for testing a global list. You can type "debugmalloc -t n " to run the n -th test. You can see the code that is being run in driver.c. If you have Perl installed on your machine, use grader.pl to run all the tests and print out a table of results. There are a total of 100 possible points. Here is a rundown of the test cases and desired output (do not worry about the path of the filename):

Test case #1
Code
char *str = (char *) MALLOC(12);
strcpy(str, "123456789");
FREE(str);
printf("Size: %d\n", AllocatedSize());
PrintAllocatedBlocks();
Error # None
Correct Output
Size: 0
Points worth 10
Details 10 points for not reporting an error and returning 0 in AllocatedSize()
Test case #2
Code
char *str = (char *) MALLOC(8);
strcpy(str, "12345678");
FREE(str);
Error # 2
Correct Output
Error: Ending edge of the payload has been overwritten.
  in block allocated at driver.c, line 26
  and freed at driver.c, line 28
Points worth 15
Details 6 pts for catching error
3 pts for printing the filename/line numbers
6 pts for correct error message
Test case #3
Code
char *str = (char *) MALLOC(2);
strcpy(str, "12");
FREE(str);
Error # 2
Correct Output
Error: Ending edge of the payload has been overwritten.
  in block allocated at driver.c, line 33
  and freed at driver.c, line 35
Points worth 15
Details 6 pts for catching error
3 pts for printing the filename/line numbers
6 pts for correct error message
Test case #4
Code
void *ptr = MALLOC(4), *ptr2 = MALLOC(6);
FREE(ptr);
printf("Size: %d\n", AllocatedSize());
PrintAllocatedBlocks();
Error # None
Correct Output
Size: 6
Currently allocated blocks:
  6 bytes, created at driver.c, line 39
Points worth 15
Details 15 pts for not reporting an error and returning
6 from AllocatedSize
Extra for printing out the extra block
Test case #5
Code
void *ptr = MALLOC(4);
FREE(ptr);
FREE(ptr);
Error # 4
Correct Output
Error: Attempting to free an unallocated block.
  in block freed at driver.c, line 48
Points worth 15
Details 15 pts for catching error
Extra for correct error message
Test case #6
Code
char *ptr = (char *) MALLOC(4);
*((int *) (ptr - 8)) = 8 + (1 << 31);
FREE(ptr);
Error # 1 or 3
Correct Output
Error: Header has been corrupted.
or
Error: Starting edge of the payload has been overwritten.
  in block allocated at driver.c, line 52
  and freed at driver.c, line 54
Points worth 15
Details 9 pts for catching error
6 pts for a correct error message
Test case #7
Code
char ptr[5];
FREE(ptr);
Error # 4
Correct Output
Error: Attempting to free an unallocated block.
  in block freed at driver.c, line 59
Points worth 15
Details 15 pts for recognizing error
Extra for printing correct error message
Test case #8 (Optional)
Code
int i;
int *intptr = (int *) MALLOC(6);
char *str = (char *) MALLOC(12);

for(i = 0; i < 6; i++) {
        intptr[i] = i;
}
if (HeapCheck() == -1) {
        printf("\nCaught Errors\n");
}
Error # None
Correct Output
Error: Ending edge of the payload has been overwritten.
  Invalid block created at driver.c, line 64

Caught Errors
Points worth Extra
Details "Caught Errors" indicates that the HeapCheck() function worked correctly. Extra points possible.

Your instructor may give you extra credit for implementing a global list and the PrintAllocatedBlocks() and HeapCheck() functions.

 

个人感觉比较郁闷,我的电脑没有windows系统。无赖之下,我将project中的部分文件修改了一下,然后在Ubuntu下完全通过了 ,Windows下没有测试

最后发现自己写多了,我写了一个链表来存储所有的错误,不过好像所有的测试都只有一个错误。

  • Exercise03.zip (40.1 KB)
  • 描述: 我的解答 注意整个测试环境是Ubuntu8.04+Gcc+Gdb
  • 下载次数: 157
分享到:
评论
1 楼 qianjigui 2009-02-08  
Feedback for Exercise 3: Debugging Malloc Lab (v2.0)
Total Score: 75/100

    * Debugging malloc
      Score: 75/100

          o Detailed Feedback
            Score: 75/100
            有很多语法错误,程序不能运行.

相关推荐

    SSD06 Exercise05 个人解答

    【标题】"SSD06 Exercise05 个人解答"主要涵盖了两个关键知识点:源码分析和工具使用。在这个练习中,作者分享了他对某个特定编程问题或项目的解答,这通常涉及深入理解代码的运作机制,包括算法、数据结构以及编程...

    SSD04 Exercise03 个人解答

    【标题】"SSD04 Exercise03 个人解答"主要涵盖了两个关键概念:源码分析和工具使用。这可能是某个课程或项目中的一个练习,其中"SSD04"可能代表课程编号或者阶段,而"Exercise03"则指示这是第三次实践任务。解答者...

    SSD06 Exercise04 个人解答

    标题 "SSD06 Exercise04 个人解答" 暗示这可能是一个关于软件开发或编程练习的解答,特别是涉及到性能分析或者优化的环节。描述中的 "NULL" 没有提供额外的信息,但我们可以从标签 "源码" 和 "工具" 中推测,这个...

    SSD06 Exercise01 个人解答

    NULL 博文链接:https://qianjigui.iteye.com/blog/256678

    SSD06 Exercise02 个人解答

    【标题】"SSD06 Exercise02 个人解答"主要涵盖了两个关键概念:源码分析和工具使用。这可能是某个课程或项目练习的一部分,其中作者Qianjigui分享了他在解决特定编程问题或实现某功能时的经验和理解。 在源码分析...

    SSD04 Exercise06 个人解答

    标题“SSD04 Exercise06 个人解答”暗示了一个编程练习或项目,其中涉及到对Microsoft Calendar Control 10.0的使用。这个控制组件通常用于Windows应用程序开发,特别是使用Visual Basic 6 (VB6) 或其他支持ActiveX...

    SSD04 Exercise04 个人解答

    【标题】"SSD04 Exercise04 个人解答"主要涵盖了两个关键知识点:源码理解和工具使用。在这个练习中,作者分享了他们对于特定编程问题的解决方案,可能涉及编程语言的深入理解、代码调试技巧以及如何有效地利用开发...

    SSD04 Exercise05 个人解答

    【标题】"SSD04 Exercise05 个人解答"主要涵盖了两个核心知识点:源码分析和工具使用。在这个练习中,作者分享了他对某个特定编程问题或项目的解答,这通常涉及到深入理解代码的运作机制,包括算法、数据结构以及...

    SSD04 Exercise01 个人解答

    这是我的解答 博文链接:https://qianjigui.iteye.com/blog/248917

    SSD04 Exercise08 个人解答

    【SSD04 Exercise08 个人解答】 在这个学习实践中,我们主要关注的是与源码分析和工具使用相关的知识。这个题目可能源自于一个软件开发或计算机科学的课程,其中"SSD04"可能是课程代码,而"Exercise08"指的是第八个...

    ssd6exercise答案

    【SSD6 Exercise答案解析】 在信息技术领域,SSD6可能是“Software Engineering Studio 6”的简称,这是一门关于软件工程的课程,常见于大学的国际软件学院中。本课程可能涉及软件开发的全过程,包括需求分析、设计...

Global site tag (gtag.js) - Google Analytics