Bug #9759

Memory erasure test fails on Debian sid

Added by intrigeri 2015-07-19 03:21:19 . Updated 2015-08-11 10:46:57 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Test suite
Target version:
Tails_1.5
Start date:
2015-07-19
Due date:
% Done:

100%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

I find many patterns in the guest's memory always fails. I’ve debugged it a bit, and looking at the memory dump the pattern is in there, but still grep -c always returns 1. Presumably some binary/text file detection or line ending handling has changed. Adding --text to the grep command-line fixes this problem for me:

--- a/features/step_definitions/erase_memory.rb
+++ b/features/step_definitions/erase_memory.rb
@@ -64,7 +64,7 @@ def pattern_coverage_in_guest_ram
   FileUtils.touch(dump)
   FileUtils.chmod(0666, dump)
   @vm.domain.core_dump(dump)
-  patterns = IO.popen(['grep', '-c', 'wipe_didnt_work', dump]).gets.to_i
+  patterns = IO.popen(['grep', '--text', '-c', 'wipe_didnt_work', dump]).gets.to_i
   File.delete dump
   # Pattern is 16 bytes long
   patterns_b = patterns*16

(untested on Jessie)

Subtasks

History

#1 Updated by anonym 2015-07-21 05:41:05

intrigeri wrote:
> […] grep -c always returns 1. Presumably some binary/text file detection or line ending handling has changed.

Yup. I’d guess that in binary mode, grep now do not treat newlines as anything special. The concept of lines doesn’t make sens in binary mode, only in text mode.

#2 Updated by anonym 2015-07-21 05:42:13

Applied in changeset commit:070c7b6213597bff6742f601fcc0709e4e2193b2.

#3 Updated by anonym 2015-07-21 05:42:14

  • Status changed from In Progress to Fix committed
  • % Done changed from 50 to 100

Applied in changeset commit:c05158a75a7cbd8ea0a879251796f30fccade1fd.

#4 Updated by anonym 2015-07-21 05:42:57

  • Assignee deleted (anonym)
  • QA Check changed from Ready for QA to Pass

Still works well on Debian Jessie. Merged!

#5 Updated by BitingBird 2015-08-11 10:46:57

  • Status changed from Fix committed to Resolved