Buckets:
mxz/PresentBench-bucket / education /CSAPP-Lectures_2015Fall /Lecture19 /generation_task /judge_prompt.json
| { | |
| "material_dependent_checklist_1": [ | |
| "\n**Title & Context**\n\n**Identification of Core Topic & Source**\n* Does the material clearly identify the subject as **Garbage Collection** and **Memory-Related Bugs** within the context of C programming?\n* Are the Instructors/Authors (Randal E. Bryant and David R. O'Hallaron) and the course context (Computer Systems: A Programmer's Perspective) acknowledged?\n Note: Check only for presence.\n", | |
| "\n**Coverage of Key Sections**\n* Does the content explicitly cover the two main sub-topics from the text:\n * Section 9.10: Garbage Collection (specifically Mark&Sweep).\n * Section 9.11: Common Memory-Related Bugs in C Programs.\n", | |
| "\n**Garbage Collection Fundamentals**\n\n**Definitions and History**\n* Is a **Garbage Collector** defined as a dynamic storage allocator that automatically frees allocated blocks no longer needed?\n* Is the historical context of **John McCarthy** and **Lisp (1960s)** mentioned as the origin of these systems?\n", | |
| "\n**The Memory Reachability Graph**\n* Does the content describe memory as a **directed reachability graph**?\n* Are the node types explicitly defined:\n * **Root Nodes:** Registers, stack variables, global variables.\n * **Heap Nodes:** Allocated blocks in the heap.\n* Is the distinction between **Reachable** (path exists from root) and **Unreachable** (garbage) clearly stated?\n\n", | |
| "\n**The Mark&Sweep Algorithm**\n\n**Algorithm Phases**\n* Are the two distinct phases explained?\n * **Mark Phase:** Marking all reachable and allocated descendants of root nodes.\n * **Sweep Phase:** Scanning the heap to free unmarked allocated blocks.\n Note: If the explanation merges these into one step, it is incomplete.\n", | |
| "\n**Implementation Logic**\n* Is the pseudo-code or logic flow provided for the specific helper functions?\n * `isPtr(ptr p)`: Determining if p points to an allocated block.\n * `blockMarked(ptr b)` and `markBlock(ptr b)`.\n * `blockAllocated(ptr b)`.\n * `length(ptr b)` and `nextBlock(ptr b)`.\n", | |
| "\n**Conservative Garbage Collection in C**\n\n**The C Language Challenge**\n* Does the content explain *why* C requires a **Conservative Garbage Collector**?\n * Lack of type tagging (scalars can masquerade as pointers).\n * Difficulty in determining if a pointer points to a payload.\n", | |
| "\n**Implementation Strategy**\n* Is the solution for tracking allocated blocks described? specifically the use of a **balanced binary tree** with left/right pointers in block headers.\n* Is the definition of \"Conservative\" explicit? (Correctly identifies all reachable blocks, but may incorrectly identify some garbage as reachable).\n", | |
| "\n**Common Memory-Related Bugs (Part 1)**\n\n**Dereferencing Bad Pointers**\n* Is the **scanf bug** used as the primary example? (Passing the contents of `val` instead of `&val`, leading to memory overwrite).\n* Is the concept of \"holes\" in the virtual address space (causing segmentation exceptions) addressed?\n", | |
| "\n**Reading Uninitialized Memory**\n* Does the content debunk the assumption that heap memory is initialized to zero?\n* Is the distinction made between `.bss` segments (zeroed by loader) and heap memory (not zeroed by `malloc`)?\n* Is the `matvec` example referenced where `y[i]` accumulates garbage values?\n", | |
| "\n**Common Memory-Related Bugs (Part 2)**\n\n**Buffer Overflows & Sizing Errors**\n* Is the **Stack Buffer Overflow** illustrated using `gets` (unsafe) vs. `fgets` (safe)?\n* Is the \"Pointer vs. Object Size\" error explained? Specifically, using `sizeof(int)` instead of `sizeof(int*)` when allocating an array of pointers.\n", | |
| "\n**Off-by-One & Arithmetic Errors**\n* Is the off-by-one loop error (`i <= n` instead of `i < n`) shown to overwrite the boundary tag or next block?\n* Is the **Pointer Arithmetic** misunderstanding explained? (e.g., manually adding `sizeof(int)` to a pointer, which incorrectly scales the addition).\n", | |
| "\n**Lifecycle & Operator Errors**\n\n**Precedence and Associativity**\n* Is the `*size--` vs. `(*size)--` bug analyzed? (Decrementing the pointer itself vs. the value it points to).\n* Is the danger of referencing **nonexistent variables** (returning a pointer to a local stack variable) explained?\n", | |
| "\n**Freeing & Leaks**\n* Is the error of referencing data in **freed heap blocks** covered?\n* Is **Memory Leak** defined explicitly as forgetting to free allocated blocks, leading to heap exhaustion?\n" | |
| ], | |
| "material_dependent_checklist_2": [ | |
| "\n**Garbage Collection Mechanics**\n\n* **Graph Interpretation:** Does the visual representation of the heap correctly show that arrows denote **memory references**, not free list pointers?\n * *Detail Check:* Ensure the \"Root\" points to a heap node, which points to others, establishing reachability.\n", | |
| "\n* **Sweep Logic Accuracy:** Does the text clarify that the sweep function acts on **unmarked** allocated blocks?\n * *Detail Check:* The logic must correspond to: If allocated & unmarked -> free. If marked -> unmark (for next cycle).\n", | |
| "\n* **Conservative Definition:** Is the trade-off accurately described? The collector must guarantee that *no reachable node is reclaimed* (correctness), accepting that *some garbage may not be freed* (unnecessary fragmentation).\n", | |
| "\n**Pointer Identification in C**\n\n* **isPtr Functionality:** Is the difficulty of `isPtr` accurately attributed to C's lack of type information?\n * *Detail Check:* Verify the explanation that an integer value in the payload could happen to correspond to a valid address, forcing the collector to treat it as a pointer.\n", | |
| "\n* **Balanced Tree Invariant:** If the balanced tree approach is mentioned, is the invariant correct?\n * *Detail Check:* All blocks in the left subtree are at smaller addresses; all in the right are at larger addresses.\n\n", | |
| "\n**Dereferencing & Initialization Bugs**\n\n* **Scanf Behavior:** Is the description of the `scanf` bug accurate?\n * *Detail Check:* It must state that `scanf` interprets the *value* of the integer as an address, writing to that arbitrary location.\n", | |
| "\n* **Malloc vs. Calloc:** Is the distinction accurate regarding initialization?\n * *Detail Check:* The content must confirm that `malloc` returns uninitialized memory, whereas `calloc` (or explicit zeroing) is required to avoid the uninitialized read bug.\n", | |
| "\n**Sizing & Arithmetic Logic**\n\n* **Sizeof Accuracy:** When discussing the array of pointers bug, does the text specify the environment context (e.g., Core i7) where `sizeof(int*)` > `sizeof(int)`?\n * *Detail Check:* The code creates an array of *ints* instead of *pointers*, leading to writing past the end of the array on 64-bit systems.\n", | |
| "\n* **Pointer Arithmetic Scaling:** Is the explanation of the `p += sizeof(int)` bug mathematically correct?\n * *Detail Check:* It should explain that because `p` is an `int*`, adding `sizeof(int)` (e.g., 4) actually increments the address by $4 \times 4 = 16$ bytes, scanning every fourth integer.\n", | |
| "\n**Operator Precedence & Stack Discipline**\n\n* **Unary Operator Precedence:** Is the explanation for `*size--` correct?\n * *Detail Check:* The `--` and `*` operators have the same precedence and associate right-to-left, so the pointer is decremented, then dereferenced (or logically, the pointer is changed).\n", | |
| "\n* **Stack Validity:** Is the reasoning for the \"Nonexistent Variable\" bug accurate?\n * *Detail Check:* The pointer `p` remains a valid address, but the *stack frame* it points to is invalid/popped and will be overwritten by subsequent function calls.\n", | |
| "\n**Memory Leak Characteristics**\n\n* **Silent Failure:** Are memory leaks described correctly as \"slow, silent killers\"?\n * *Detail Check:* The text should note that the error doesn't cause an immediate crash but consumes heap space over time, critical for daemons/servers.\n" | |
| ] | |
| } | |
Xet Storage Details
- Size:
- 8.01 kB
- Xet hash:
- 06550916e608c41113f66e5ebe73522bde4f697633626229b4fa20ad78ecc91c
·
Xet efficiently stores files, intelligently splitting them into unique chunks and accelerating uploads and downloads. More info.