WikiLabs - Schimbări recente [ro]

CID aplicatii 12 : Exercitii cu circuite secventiale

Mihai.antonescu — Thu, 21 May 2026 10:14:09 GMT

Exercitii

Fișier:Subiect fifo din 2 stive.pdf

Mihai.antonescu — Thu, 21 May 2026 10:13:46 GMT

Mihai.antonescu a încărcat Fișier:Subiect fifo din 2 stive.pdf

Pagină nouă

SDPT Lab 9

Rhobincu — Mon, 18 May 2026 15:38:13 GMT

Tasks

SDPT Lab 10

Rhobincu — Mon, 18 May 2026 13:50:45 GMT

SDPT Lab 10

Rhobincu — Mon, 18 May 2026 13:48:36 GMT

Pagină nouă: = Week 10 Lab Activity: Documentation as Code with Doxygen = == Objective == Generate API documentation for your Oven Controller with Doxygen and publish it automatically to GitL...

Pagină nouă

= Week 10 Lab Activity: Documentation as Code with Doxygen =

== Objective ==

Generate API documentation for your Oven Controller with Doxygen and publish it automatically to GitLab Pages. This lab is deliberately short --- once the documentation pipeline works, the rest of the session is yours for capstone work.

== Background ==

Doxygen parses your source code and your specially-formatted comments and produces a cross-referenced HTML website. It is configured by a single file, the '''Doxyfile''', generated with <code>doxygen -g</code>. Because Doxygen reads source directly, it needs no compiled binary and no CMake involvement --- the documentation job is completely independent of your build.

GitLab Pages serves a static website straight from a CI job. On this course's instance, <code>gitlab.cs.pub.ro</code>, the Pages wildcard domain is <code>pages.upb.ro</code>. With unique domains enabled (the default), your published site receives an unpredictable URL of the form <code>https://<project>-<6-char-id>.pages.upb.ro/</code>. You read the exact URL from '''Deploy > Pages''' in the GitLab UI after the first successful deployment --- you cannot know it in advance.

The modern GitLab Pages CI syntax marks a job as a Pages job using a <code>pages:</code> property, and names the directory to publish using <code>publish:</code> inside it. The job itself can have any name. See the Week 10 lecture slide "CI Integration: Publishing to GitLab Pages" for the shape of this job.

For Doxygen comment syntax, see the lecture's before/after Oven Controller slides. Reference material: the Doxygen manual at https://www.doxygen.nl/manual/, and the special-command list at https://www.doxygen.nl/manual/commands.html.

== Tasks ==

Work on a feature branch opened from a tracked Issue. Open a Merge Request when you are ready to integrate.

# '''Generate the Doxyfile.''' Run <code>doxygen -g</code> in your project root. This creates a file named <code>Doxyfile</code> containing every Doxygen setting with its default value and an explanatory comment. Commit it as-is in its own commit, so your later configuration changes are visible as a clean diff.

# '''Configure the Doxyfile.''' Edit at least the following settings: <code>PROJECT_NAME</code> and <code>PROJECT_NUMBER</code>; <code>INPUT</code> (point it at your source and header directories and your <code>README.md</code>); <code>RECURSIVE = YES</code>; <code>EXTRACT_ALL = YES</code>; <code>GENERATE_HTML = YES</code>; <code>GENERATE_LATEX = NO</code>; <code>HAVE_DOT = YES</code> (enables the Graphviz class and call diagrams); and <code>USE_MDFILE_AS_MAINPAGE</code> (set to your <code>README.md</code> so it becomes the documentation landing page). Leave <code>OUTPUT_DIRECTORY</code> empty and <code>HTML_OUTPUT</code> at its default <code>html</code>, so the generated site lands in <code>./html</code>.

# '''Document the Oven Controller's public API.''' Add Doxygen comments to the main class and its public methods. Each public function should have a <code>\brief</code>, plus <code>\param</code> and <code>\return</code> where they apply. Write genuine contracts --- units, valid ranges, error behavior --- not restatements of the function name. The lecture's before/after example sets the standard. ''This task is verified through your published documentation site, not submitted as a file.''

# '''Build and check locally.''' Run <code>doxygen Doxyfile</code>. Open <code>html/index.html</code> in a browser and confirm that your classes, your comments, and (if Graphviz is installed locally) the diagrams all appear as expected. Fix anything that looks wrong before moving on.

# '''Add the documentation job to CI.''' Edit <code>.gitlab-ci.yml</code>:
## Add a new <code>docs</code> stage as the last stage.
## Add a job (suggested name <code>create-pages</code>) in that stage. It should use a stock Debian or Ubuntu image, install <code>doxygen</code> and <code>graphviz</code> in a <code>before_script</code>, run <code>doxygen Doxyfile</code> in its <code>script</code>, and publish the <code>html</code> directory using the <code>pages:</code> property.
## Restrict the job to the default branch with a <code>rules:</code> entry, so the documentation deploys only from released code.

# '''Publish and verify.''' Push your branch and open the Merge Request. Note that because the job is restricted to the default branch, it will '''not''' run on your feature-branch pipeline --- this is expected. Once the MR is merged, the pipeline on the default branch runs the <code>create-pages</code> job. Then open '''Deploy > Pages''', find your site's live URL, open it, and confirm the documentation is served correctly. Paste that URL into your Merge Request description.

== Deliverables ==

Submit exactly two files:

# <code>Doxyfile</code> --- your configured Doxygen configuration file.
# <code>.gitlab-ci.yml</code> --- including the new <code>docs</code> stage and the <code>create-pages</code> job.

In addition, your Merge Request description must contain the live GitLab Pages URL from Task 6. The quality of your Doxygen comments (Task 3) is assessed by visiting that URL.

== Stretch tasks (optional) ==

Pick at most one. Neither earns extra points; both make your capstone documentation noticeably better.

* '''Turn documentation into a real gate.''' Set <code>EXTRACT_ALL = NO</code>, <code>WARN_IF_UNDOCUMENTED = YES</code>, and <code>WARN_AS_ERROR = YES</code> in your Doxyfile. Now Doxygen exits with an error --- failing the pipeline --- whenever a public entity has no documentation. Then document everything until the job passes. This is how documentation becomes a true quality gate rather than a suggestion.

* '''Add a hand-written architecture page.''' Create <code>docs/architecture.md</code> describing how the Oven Controller's pieces fit together. Add it to the Doxyfile's <code>INPUT</code>. It will appear as a first-class page in your documentation site, alongside the auto-extracted API reference.

== Common pitfalls ==

* '''The published site is 404 or shows the wrong content.''' The directory named in <code>publish:</code> must exactly match where Doxygen actually wrote the HTML. With the default <code>HTML_OUTPUT = html</code> and an empty <code>OUTPUT_DIRECTORY</code>, that directory is <code>html</code>. If you changed either setting, update <code>publish:</code> to match.

* '''The docs job never runs.''' If you restricted it to the default branch, it will not appear on feature-branch or Merge Request pipelines --- only after the merge. This is correct behavior. Verify the <code>doxygen</code> command itself locally (Task 4) so you are confident before merging.

* '''The <code>pages:</code> keyword causes a YAML or pipeline error.''' The Pages CI syntax has changed across GitLab versions. The <code>pages:</code> property with <code>publish:</code> inside it is the current form. If your instance rejects it, check the GitLab version of <code>gitlab.cs.pub.ro</code> and consult its documentation for the exact accepted syntax.

* '''No diagrams in the output.''' <code>HAVE_DOT = YES</code> requires the Graphviz <code>dot</code> tool to be installed. Make sure your CI <code>before_script</code> installs <code>graphviz</code>, not only <code>doxygen</code>.

* '''Doxygen reports warnings about undocumented members.''' With <code>EXTRACT_ALL = YES</code> this is harmless --- the site still builds. It only fails the job if you also set <code>WARN_AS_ERROR = YES</code> (see the stretch task).

* '''I cannot find my Pages URL.''' It is under '''Deploy > Pages''' in the GitLab project sidebar, and only appears after the <code>create-pages</code> job has succeeded at least once on the default branch.

== Looking ahead ==

Next week is the last: '''Capstone Synthesis'''. Your CI pipeline is now complete --- build, test, lint, sanitize, and docs. We step back, look at the whole system you have built, cover a few industry topics, and reserve lab time for capstone polish and a dry run of your project presentation.

Software Development Process and Testing

Rhobincu — Mon, 18 May 2026 13:48:30 GMT

SDPT Lab 9

Rhobincu — Mon, 11 May 2026 13:41:55 GMT

Deliverables

SDPT Lab 9

Rhobincu — Mon, 11 May 2026 13:33:13 GMT

Pagină nouă: = Week 9 Lab Activity: Dynamic Analysis with Sanitizers and Valgrind = == Objective == Extend your Oven Controller's CI pipeline with a fourth quality gate: a <code>sanitize</cod...

Pagină nouă

= Week 9 Lab Activity: Dynamic Analysis with Sanitizers and Valgrind =

== Objective ==

Extend your Oven Controller's CI pipeline with a fourth quality gate: a <code>sanitize</code> stage that builds the project under AddressSanitizer and UndefinedBehaviorSanitizer and runs your full test suite against the instrumented binary. By the end of this lab, your pipeline catches a fourth class of bug --- runtime memory errors and undefined behavior --- automatically on every push.

== Background ==

You will add a new CMake build type called <code>Sanitize</code> that compiles with <code>-fsanitize=address,undefined</code> alongside <code>-O1 -g -fno-omit-frame-pointer</code>. The <code>-O1</code> keeps the optimizer light enough that sanitizer reports stay readable; <code>-g</code> embeds debug information so backtraces have line numbers; <code>-fno-omit-frame-pointer</code> ensures those backtraces are actually complete on x86_64.

The sanitizers report errors by printing to stderr and exiting with a nonzero status. This means your existing GoogleTest tests do not need any modification: if a test triggers a sanitizer error, the test binary aborts, ctest reports failure, the CI job fails, and the MR is blocked. The pipeline plumbing from Week 6 carries this work for you for free.

In addition to the sanitizer build, you will run Valgrind manually once against the same codebase. The two tools are complementary: ASan is fast and runs in CI; Valgrind is slow but sometimes catches things ASan misses (notably uninitialized reads, which require MemorySanitizer to catch with sanitizers --- and you saw in the lecture why MSan is impractical).

You will also reuse <code>gcovr</code> from Week 4. Dynamic analysis can only find bugs on code paths your tests actually execute, so coverage is part of the deliverable.

The point of this lab is not to introduce new tools you have never seen --- you have met all four (ASan/UBSan/Valgrind/gcovr) in lectures. The point is to wire them together into your existing pipeline and prove the wiring works by deliberately breaking things.

Documentation pointers: <code>man valgrind</code>, the AddressSanitizer wiki at https://github.com/google/sanitizers/wiki/AddressSanitizer, the UBSan documentation at https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html, and your existing gcovr docs.

== Tasks ==

Work on a feature branch opened from a tracked Issue. Open a Merge Request when you are ready to integrate.

# '''Extend the Docker build environment.''' Update your <code>Dockerfile</code> to install <code>valgrind</code> alongside the tools already present. Rebuild and verify with <code>valgrind --version</code>. The sanitizers themselves ship with the compiler, so no separate package is needed --- but confirm by running <code>echo "int main(){}" | g++ -fsanitize=address -x c++ - -o /dev/null</code> inside the container; if that succeeds, ASan is available.

# '''Add the Sanitize build type to CMake.''' In your <code>CMakeLists.txt</code>, add logic that, when <code>CMAKE_BUILD_TYPE</code> equals <code>Sanitize</code>, sets compile and link options for <code>-fsanitize=address,undefined</code> plus <code>-O1 -g -fno-omit-frame-pointer</code>. Make sure both compile ''and'' link options include the sanitizer flag --- if you forget the link side, you will get cryptic linker errors about missing <code>__asan_*</code> symbols. Test locally: <code>cmake -B build-san -DCMAKE_BUILD_TYPE=Sanitize</code>, then build, then run a test binary directly to confirm it produces output that mentions ASan.

# '''Run your existing tests under the sanitizers and clean up.''' Run <code>ctest --test-dir build-san --output-on-failure</code>. If any tests fail due to sanitizer reports, fix the underlying bugs in the Oven Controller code (do '''not''' suppress them). Typical findings in EE-trained codebases: forgotten <code>delete[]</code>, signed overflow in temperature math, reading from a member variable that was never initialized in a constructor. Each fix should be its own small commit with a message describing what the sanitizer reported.

# '''Add a sanitize stage to GitLab CI.''' Edit <code>.gitlab-ci.yml</code> to add a new <code>sanitize</code> stage after <code>test</code>. The job should: configure a <code>Sanitize</code> build, compile it, and run <code>ctest</code> against it. Use your existing Docker image. The job must fail the pipeline on any sanitizer error.

# '''Trigger ASan on purpose.''' On your feature branch, introduce a deliberate '''heap-buffer-overflow''' bug somewhere in the production code. Push, watch the <code>sanitize</code> stage fail, capture the ASan report (the job-log permalink in the MR description is sufficient), then revert. Your goal is to see the full ASan diagnostic --- the line with the offending access, the line of the allocation, and the "stack-buffer-overflow" or "heap-buffer-overflow" classification.

# '''Trigger UBSan on purpose.''' Repeat with a deliberate '''signed integer overflow''' or '''null pointer dereference'''. The UBSan report looks different from ASan's --- a one-line "runtime error" message at the trigger point. Capture, revert.

# '''Trigger LeakSanitizer on purpose.''' Repeat with a deliberate memory leak (allocate something on the heap, do not free it). LeakSan reports at program exit, not at the leak site. Capture, revert.

# '''Run Valgrind once, manually.''' Build your project in a normal Debug configuration (no sanitizers --- they conflict with Valgrind's instrumentation). From inside your Docker container, run <code>valgrind --leak-check=full --show-leakkinds=all --track-origins=yes ./your_test_binary</code>. Save the full output. If Valgrind reports any errors that ASan did not, fix them. Add a paragraph to your MR description noting which tool caught what, or that the two agreed completely.

# '''Re-check coverage.''' Recall from Week 4: <code>gcovr -r .. --html-details</code> against a coverage-instrumented build. Generate a current coverage report. Compare against your Week 4 baseline. If coverage dropped, write enough additional tests to bring it back. Coverage gaps are places where sanitizer findings are silently impossible, so this is part of the dynamic-analysis story even if the tool is the same one you used in Week 4.

# '''Document the cost.''' Compare the wall-clock time of your full pipeline before and after this lab. The <code>sanitize</code> stage adds work; document by how much in your MR description. As in Week 7, "the sanitize stage adds 6 minutes and we caught two real bugs" is a more honest finding than rounding to "negligible".

# '''Review and merge.''' Open the MR. The reviewer should check: the Sanitize build type works locally and in CI, that the three deliberate-bug pipeline runs are visible, that the Valgrind output is referenced in the MR, that coverage has not regressed.

== Stretch tasks (optional, if you finish early) ==

Pick at most one. None earn extra points; all teach you something useful.

* '''Add a second sanitizer build.''' Some teams maintain two CI jobs: one with ASan+UBSan, one with ThreadSanitizer. Add a TSan job that builds with <code>-fsanitize=thread</code> and runs the tests. Even on single-threaded code this is harmless, and it sets you up for the day you add concurrency.

* '''Valgrind in CI.''' Add a manual-trigger CI job (using GitLab's <code>when: manual</code>) that runs Valgrind on your test binary. It is too slow to run on every push, but a one-click button for the weekly deep audit is valuable.

* '''Coverage threshold gate.''' Use <code>gcovr --fail-under-line N</code> to fail the pipeline if line coverage drops below a threshold you choose (e.g. 80%). Now coverage is also an automatic quality gate, not just a number.

* '''Sanitizer-specific environment variables.''' Read the docs for <code>ASAN_OPTIONS</code> and <code>UBSAN_OPTIONS</code>. Add <code>halt_on_error=1</code> and <code>abort_on_error=1</code> to your CI environment, which makes the first error a hard stop instead of letting the program limp on. Useful for getting clearer reports.

== Deliverables ==

For this lab to be marked complete, your <code>main</code> branch must contain:

# A <code>Dockerfile</code> that installs <code>valgrind</code> in addition to the previous week's tooling.
# A <code>CMakeLists.txt</code> with a working <code>Sanitize</code> build type.
# A <code>.gitlab-ci.yml</code> with a <code>sanitize</code> stage running after the <code>test</code> stage.
# A merged Merge Request whose linked Issue (or MR description) contains:
## References to '''three''' failed pipeline runs from Tasks 5, 6, and 7 (one each for ASan, UBSan, and LeakSan), with the relevant snippet of each sanitizer's report quoted briefly.
## The Valgrind output from Task 8, or a permalink to it (a job artifact or a gist).
## A note comparing Valgrind's findings with the sanitizers' findings (Task 8).
## The coverage comparison from Task 9 (before/after, plus what you did about it).
## The pipeline cost comparison from Task 10.

== Common pitfalls ==

* '''Linker errors mentioning <code>__asan_*</code> or <code>__ubsan_*</code> symbols.''' You set the sanitizer flag for compilation but forgot to also pass it at the link step. In CMake, both <code>add_compile_options</code> and <code>add_link_options</code> need <code>-fsanitize=...</code>.

* '''Sanitizers and Valgrind conflict.''' You cannot run a sanitizer-built binary under Valgrind. They both rely on intercepting memory accesses and the interception clashes. Build a separate Debug binary (no sanitizers) when you want to run Valgrind.

* '''ASan reports look truncated or have <code>??</code> in the backtrace.''' Almost always means missing <code>-g</code> or missing <code>-fno-omit-frame-pointer</code>. Without frame pointers, the unwinder on x86_64 falls back to imperfect heuristics.

* '''The pipeline passes locally but ASan errors only appear in CI.''' Check that your container image is using a recent enough compiler. GCC's ASan got significantly better between 8.x and 11.x; UBSan added several checks in the same span. The Debian Bookworm <code>g++</code> (12.x) is fine.

* '''Tests pass under the sanitizers locally, but a teammate's machine shows different errors.''' ASan and UBSan are deterministic for a given binary, but slight platform differences (libc version, glibc malloc settings) can occasionally surface bugs that are real but only fire on one machine. The CI container is the source of truth.

* '''Valgrind reports complaints in the standard library.''' Usually you can ignore these unless they reference your own code. Use <code>--suppressions=/usr/share/valgrind/default.supp</code> (most distributions ship a default suppression file) to filter out the well-known libc and libstdc++ noise.

* '''ASan says "AddressSanitizer: DEADLYSIGNAL" with no obvious cause.''' Your program received a fatal signal (often SIGSEGV) inside ASan's own instrumentation. This usually means very serious memory corruption or stack overflow. Use <code>ASAN_OPTIONS=abort_on_error=1</code> to get a core dump and a clearer backtrace.

* '''Some sanitizer findings disappear at <code>-O2</code> or <code>-O3</code>.''' That is expected --- the optimizer can eliminate the offending construct entirely. Keep your sanitizer build at <code>-O1</code>: optimized enough to be realistic, unoptimized enough to keep reports trustworthy.

== Looking ahead ==

Next week: '''Documentation as Code'''. You will add a Doxygen build to your CMake, publish the generated HTML docs as a GitLab Pages artifact, and turn your scattered code comments into navigable API documentation. Bring a piece of your capstone code that is poorly documented and you want to improve.

Software Development Process and Testing

Rhobincu — Mon, 11 May 2026 13:33:07 GMT

← Versiunea anterioară		Versiunea de la data 21 mai 2026 10:14
Linia 70:		Linia 70:

	[https://wiki.dcae.pub.ro/images/0/0c/Lucrarea2_Subiect_pentru_wiki.pdf Media_dintre_cel_mai_mic_si_cel_mai_mare_numar]		[https://wiki.dcae.pub.ro/images/0/0c/Lucrarea2_Subiect_pentru_wiki.pdf Media_dintre_cel_mai_mic_si_cel_mai_mare_numar]
		+
		+
		+
		+	===Exercitiul 9: Fifo facut din 2 stive===
		+
		+	[https://wiki.dcae.pub.ro/images/2/2f/Subiect_fifo_din_2_stive.pdf Fifo_facut_din_2_stive]

@@ Linia 7: / Linia 7: @@
 == Background ==
-Doxygen parses your source code and your specially-formatted comments and produces a cross-referenced HTML website. It is configured by a single file, the '''Doxyfile''', generated with <code>doxygen -g</code>. Because Doxygen reads source directly, it needs no compiled binary and no CMake involvement --- the documentation job is completely independent of your build.
+Doxygen parses your source code and your specially-formatted comments and produces a cross-referenced HTML website. It is configured by a single file, the '''Doxyfile''', generated with <code>doxygen -g</code>. Because Doxygen reads source directly, it needs no compiled binary --- the documentation job does not depend on your <code>build</code> stage at all, and in this lab it runs <code>doxygen Doxyfile</code> directly without involving CMake. (You ''can'' add a <code>docs</code> target to <code>CMakeLists.txt</code> that wraps the same command, as the lecture notes, but this lab does not require it.)
 GitLab Pages serves a static website straight from a CI job. On this course's instance, <code>gitlab.cs.pub.ro</code>, the Pages wildcard domain is <code>pages.upb.ro</code>. With unique domains enabled (the default), your published site receives an unpredictable URL of the form <code>https://&lt;project&gt;-&lt;6-char-id&gt;.pages.upb.ro/</code>. You read the exact URL from '''Deploy &gt; Pages''' in the GitLab UI after the first successful deployment --- you cannot know it in advance.

@@ Linia 7: / Linia 7: @@
 * [[SDPT Lab 7]]
 * [[SDPT Lab 8]]
 * [[SDPT Lab 9]]

← Versiunea anterioară		Versiunea de la data 11 mai 2026 13:33
Linia 7:		Linia 7:
	* [[SDPT Lab 7]]		* [[SDPT Lab 7]]
	* [[SDPT Lab 8]]		* [[SDPT Lab 8]]
		+	* [[SDPT Lab 9]]

@@ Linia 24: / Linia 24: @@
 # '''Extend the Docker build environment.''' Update your <code>Dockerfile</code> to install <code>valgrind</code> alongside the tools already present. Rebuild and verify with <code>valgrind --version</code>. The sanitizers themselves ship with the compiler, so no separate package is needed - but confirm by running <code>echo "int main(){}" | g++ -fsanitize=address -x c++ - -o /dev/null</code> inside the container; if that succeeds, ASan is available.
 # '''Add the Sanitize build type to CMake.''' In your <code>CMakeLists.txt</code>, add logic that, when <code>CMAKE_BUILD_TYPE</code> equals <code>Sanitize</code>, sets compile and link options for <code>-fsanitize=address,undefined</code> plus <code>-O1 -g -fno-omit-frame-pointer</code>. Make sure both compile ''and'' link options include the sanitizer flag - if you forget the link side, you will get cryptic linker errors about missing <code>__asan_*</code> symbols. Test locally: <code>cmake -B build-san -DCMAKE_BUILD_TYPE=Sanitize</code>, then build, then run a test binary directly to confirm it produces output that mentions ASan.
 # '''Run your existing tests under the sanitizers and clean up.''' Run <code>ctest --test-dir build-san --output-on-failure</code>. If any tests fail due to sanitizer reports, fix the underlying bugs in the Oven Controller code (do '''not''' suppress them). Typical findings in EE-trained codebases: forgotten <code>delete[]</code>, signed overflow in temperature math, reading from a member variable that was never initialized in a constructor. Each fix should be its own small commit with a message describing what the sanitizer reported.
 # '''Add a sanitize stage to GitLab CI.''' Edit <code>.gitlab-ci.yml</code> to add a new <code>sanitize</code> stage after <code>test</code>. The job should: configure a <code>Sanitize</code> build, compile it, and run <code>ctest</code> against it. Use your existing Docker image. The job must fail the pipeline on any sanitizer error.
 # '''Trigger ASan on purpose.''' On your feature branch, introduce a deliberate '''heap-buffer-overflow''' bug somewhere in the production code. Push, watch the <code>sanitize</code> stage fail, capture the ASan report (the job-log permalink in the MR description is sufficient), then revert. Your goal is to see the full ASan diagnostic - the line with the offending access, the line of the allocation, and the "stack-buffer-overflow" or "heap-buffer-overflow" classification.
 # '''Trigger UBSan on purpose.''' Repeat with a deliberate '''signed integer overflow''' or '''null pointer dereference'''. The UBSan report looks different from ASan's - a one-line "runtime error" message at the trigger point. Capture, revert.
 # '''Trigger LeakSanitizer on purpose.''' Repeat with a deliberate memory leak (allocate something on the heap, do not free it). LeakSan reports at program exit, not at the leak site. Capture, revert.
 # '''Run Valgrind once, manually.''' Build your project in a normal Debug configuration (no sanitizers - they conflict with Valgrind's instrumentation). From inside your Docker container, run <code>valgrind --leak-check=full --show-leakkinds=all --track-origins=yes ./your_test_binary</code>. Save the full output. If Valgrind reports any errors that ASan did not, fix them. Add a paragraph to your MR description noting which tool caught what, or that the two agreed completely.
 # '''Re-check coverage.''' Recall from Week 4: <code>gcovr -r .. --html-details</code> against a coverage-instrumented build. Generate a current coverage report. Compare against your Week 4 baseline. If coverage dropped, write enough additional tests to bring it back. Coverage gaps are places where sanitizer findings are silently impossible, so this is part of the dynamic-analysis story even if the tool is the same one you used in Week 4.
 # '''Document the cost.''' Compare the wall-clock time of your full pipeline before and after this lab. The <code>sanitize</code> stage adds work; document by how much in your MR description. As in Week 7, "the sanitize stage adds 6 minutes and we caught two real bugs" is a more honest finding than rounding to "negligible".
 # '''Review and merge.''' Open the MR. The reviewer should check: the Sanitize build type works locally and in CI, that the three deliberate-bug pipeline runs are visible, that the Valgrind output is referenced in the MR, that coverage has not regressed.

@@ Linia 3: / Linia 3: @@
 == Objective ==
-Extend your Oven Controller's CI pipeline with a fourth quality gate: a <code>sanitize</code> stage that builds the project under AddressSanitizer and UndefinedBehaviorSanitizer and runs your full test suite against the instrumented binary. By the end of this lab, your pipeline catches a fourth class of bug --- runtime memory errors and undefined behavior --- automatically on every push.
+Extend your Oven Controller's CI pipeline with a fourth quality gate: a <code>sanitize</code> stage that builds the project under AddressSanitizer and UndefinedBehaviorSanitizer and runs your full test suite against the instrumented binary. By the end of this lab, your pipeline catches a fourth class of bug - runtime memory errors and undefined behavior - automatically on every push.
 == Background ==
@@ Linia 11: / Linia 11: @@
 The sanitizers report errors by printing to stderr and exiting with a nonzero status. This means your existing GoogleTest tests do not need any modification: if a test triggers a sanitizer error, the test binary aborts, ctest reports failure, the CI job fails, and the MR is blocked. The pipeline plumbing from Week 6 carries this work for you for free.
-In addition to the sanitizer build, you will run Valgrind manually once against the same codebase. The two tools are complementary: ASan is fast and runs in CI; Valgrind is slow but sometimes catches things ASan misses (notably uninitialized reads, which require MemorySanitizer to catch with sanitizers --- and you saw in the lecture why MSan is impractical).
+In addition to the sanitizer build, you will run Valgrind manually once against the same codebase. The two tools are complementary: ASan is fast and runs in CI; Valgrind is slow but sometimes catches things ASan misses (notably uninitialized reads, which require MemorySanitizer to catch with sanitizers - and you saw in the lecture why MSan is impractical).
 You will also reuse <code>gcovr</code> from Week 4. Dynamic analysis can only find bugs on code paths your tests actually execute, so coverage is part of the deliverable.
-The point of this lab is not to introduce new tools you have never seen --- you have met all four (ASan/UBSan/Valgrind/gcovr) in lectures. The point is to wire them together into your existing pipeline and prove the wiring works by deliberately breaking things.
+The point of this lab is not to introduce new tools you have never seen - you have met all four (ASan/UBSan/Valgrind/gcovr) in lectures. The point is to wire them together into your existing pipeline and prove the wiring works by deliberately breaking things.
 Documentation pointers: <code>man valgrind</code>, the AddressSanitizer wiki at https://github.com/google/sanitizers/wiki/AddressSanitizer, the UBSan documentation at https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html, and your existing gcovr docs.
@@ Linia 23: / Linia 23: @@
 Work on a feature branch opened from a tracked Issue. Open a Merge Request when you are ready to integrate.
-# '''Extend the Docker build environment.''' Update your <code>Dockerfile</code> to install <code>valgrind</code> alongside the tools already present. Rebuild and verify with <code>valgrind --version</code>. The sanitizers themselves ship with the compiler, so no separate package is needed --- but confirm by running <code>echo "int main(){}" | g++ -fsanitize=address -x c++ - -o /dev/null</code> inside the container; if that succeeds, ASan is available.
+# '''Extend the Docker build environment.''' Update your <code>Dockerfile</code> to install <code>valgrind</code> alongside the tools already present. Rebuild and verify with <code>valgrind --version</code>. The sanitizers themselves ship with the compiler, so no separate package is needed - but confirm by running <code>echo "int main(){}" | g++ -fsanitize=address -x c++ - -o /dev/null</code> inside the container; if that succeeds, ASan is available.
-# '''Add the Sanitize build type to CMake.''' In your <code>CMakeLists.txt</code>, add logic that, when <code>CMAKE_BUILD_TYPE</code> equals <code>Sanitize</code>, sets compile and link options for <code>-fsanitize=address,undefined</code> plus <code>-O1 -g -fno-omit-frame-pointer</code>. Make sure both compile ''and'' link options include the sanitizer flag --- if you forget the link side, you will get cryptic linker errors about missing <code>__asan_*</code> symbols. Test locally: <code>cmake -B build-san -DCMAKE_BUILD_TYPE=Sanitize</code>, then build, then run a test binary directly to confirm it produces output that mentions ASan.
+# '''Add the Sanitize build type to CMake.''' In your <code>CMakeLists.txt</code>, add logic that, when <code>CMAKE_BUILD_TYPE</code> equals <code>Sanitize</code>, sets compile and link options for <code>-fsanitize=address,undefined</code> plus <code>-O1 -g -fno-omit-frame-pointer</code>. Make sure both compile ''and'' link options include the sanitizer flag - if you forget the link side, you will get cryptic linker errors about missing <code>__asan_*</code> symbols. Test locally: <code>cmake -B build-san -DCMAKE_BUILD_TYPE=Sanitize</code>, then build, then run a test binary directly to confirm it produces output that mentions ASan.
 # '''Run your existing tests under the sanitizers and clean up.''' Run <code>ctest --test-dir build-san --output-on-failure</code>. If any tests fail due to sanitizer reports, fix the underlying bugs in the Oven Controller code (do '''not''' suppress them). Typical findings in EE-trained codebases: forgotten <code>delete[]</code>, signed overflow in temperature math, reading from a member variable that was never initialized in a constructor. Each fix should be its own small commit with a message describing what the sanitizer reported.
@@ Linia 31: / Linia 31: @@
 # '''Add a sanitize stage to GitLab CI.''' Edit <code>.gitlab-ci.yml</code> to add a new <code>sanitize</code> stage after <code>test</code>. The job should: configure a <code>Sanitize</code> build, compile it, and run <code>ctest</code> against it. Use your existing Docker image. The job must fail the pipeline on any sanitizer error.
-# '''Trigger ASan on purpose.''' On your feature branch, introduce a deliberate '''heap-buffer-overflow''' bug somewhere in the production code. Push, watch the <code>sanitize</code> stage fail, capture the ASan report (the job-log permalink in the MR description is sufficient), then revert. Your goal is to see the full ASan diagnostic --- the line with the offending access, the line of the allocation, and the "stack-buffer-overflow" or "heap-buffer-overflow" classification.
+# '''Trigger ASan on purpose.''' On your feature branch, introduce a deliberate '''heap-buffer-overflow''' bug somewhere in the production code. Push, watch the <code>sanitize</code> stage fail, capture the ASan report (the job-log permalink in the MR description is sufficient), then revert. Your goal is to see the full ASan diagnostic - the line with the offending access, the line of the allocation, and the "stack-buffer-overflow" or "heap-buffer-overflow" classification.
-# '''Trigger UBSan on purpose.''' Repeat with a deliberate '''signed integer overflow''' or '''null pointer dereference'''. The UBSan report looks different from ASan's --- a one-line "runtime error" message at the trigger point. Capture, revert.
+# '''Trigger UBSan on purpose.''' Repeat with a deliberate '''signed integer overflow''' or '''null pointer dereference'''. The UBSan report looks different from ASan's - a one-line "runtime error" message at the trigger point. Capture, revert.
 # '''Trigger LeakSanitizer on purpose.''' Repeat with a deliberate memory leak (allocate something on the heap, do not free it). LeakSan reports at program exit, not at the leak site. Capture, revert.
-# '''Run Valgrind once, manually.''' Build your project in a normal Debug configuration (no sanitizers --- they conflict with Valgrind's instrumentation). From inside your Docker container, run <code>valgrind --leak-check=full --show-leakkinds=all --track-origins=yes ./your_test_binary</code>. Save the full output. If Valgrind reports any errors that ASan did not, fix them. Add a paragraph to your MR description noting which tool caught what, or that the two agreed completely.
+# '''Run Valgrind once, manually.''' Build your project in a normal Debug configuration (no sanitizers - they conflict with Valgrind's instrumentation). From inside your Docker container, run <code>valgrind --leak-check=full --show-leakkinds=all --track-origins=yes ./your_test_binary</code>. Save the full output. If Valgrind reports any errors that ASan did not, fix them. Add a paragraph to your MR description noting which tool caught what, or that the two agreed completely.
 # '''Re-check coverage.''' Recall from Week 4: <code>gcovr -r .. --html-details</code> against a coverage-instrumented build. Generate a current coverage report. Compare against your Week 4 baseline. If coverage dropped, write enough additional tests to bring it back. Coverage gaps are places where sanitizer findings are silently impossible, so this is part of the dynamic-analysis story even if the tool is the same one you used in Week 4.
@@ Linia 59: / Linia 59: @@
 == Deliverables ==
-For this lab to be marked complete, your <code>main</code> branch must contain:
+For this lab to be considered complete, your <code>main</code> branch must contain:
 # A <code>Dockerfile</code> that installs <code>valgrind</code> in addition to the previous week's tooling.
@@ Linia 70: / Linia 70: @@
 ## The coverage comparison from Task 9 (before/after, plus what you did about it).
 ## The pipeline cost comparison from Task 10.
 == Common pitfalls ==
@@ Linia 87: / Linia 89: @@
 * '''ASan says "AddressSanitizer: DEADLYSIGNAL" with no obvious cause.''' Your program received a fatal signal (often SIGSEGV) inside ASan's own instrumentation. This usually means very serious memory corruption or stack overflow. Use <code>ASAN_OPTIONS=abort_on_error=1</code> to get a core dump and a clearer backtrace.
-* '''Some sanitizer findings disappear at <code>-O2</code> or <code>-O3</code>.''' That is expected --- the optimizer can eliminate the offending construct entirely. Keep your sanitizer build at <code>-O1</code>: optimized enough to be realistic, unoptimized enough to keep reports trustworthy.
+* '''Some sanitizer findings disappear at <code>-O2</code> or <code>-O3</code>.''' That is expected - the optimizer can eliminate the offending construct entirely. Keep your sanitizer build at <code>-O1</code>: optimized enough to be realistic, unoptimized enough to keep reports trustworthy.
 == Looking ahead ==
 Next week: '''Documentation as Code'''. You will add a Doxygen build to your CMake, publish the generated HTML docs as a GitLab Pages artifact, and turn your scattered code comments into navigable API documentation. Bring a piece of your capstone code that is poorly documented and you want to improve.