7

I have a Python and C application on Linux that's supposed to properly handle IO errors whilst reading files from disk. The bulk of the application is written in Python, with a C extension that does the IO. It's within this extension that the IO errors are detected.

There are two cases that the errors appear to occur for me.

  1. A file is missing.
  2. A file appears larger on disk (using stat) than can be read using fread.

I can test and handle case number 1 rather easily. However, I'd also like to write a unit test for case 2. However, I have no idea how to trigger a "fake" IO error for the test. Is this even possible? Is there a better approach to testing this kind of error?

Tom
  • 18,685
  • 15
  • 71
  • 81
  • 3
    Side note: Simulating a file disappearing after successfully opening (e. g. it was on a memory stick now removed) might make another interesting case. – chux - Reinstate Monica Jan 09 '14 at 23:58
  • Case 2 isn't going to give you an IO error, it's just going to return fewer bytes than you expected. [`fread`](http://pubs.opengroup.org/onlinepubs/007904975/functions/fread.html) will return the number of elements read (and the same is true with most other functions, both in C/POSIX and in Python). And if you call `ferror()` and `feof()` to check why you got fewer results than expected, you'll get zero and nonzero, respectively. So, are you trying to test an actual I/O error, or your case 2? – abarnert Jan 10 '14 at 00:02
  • @abarnert I'm referring to the errno value, which is (EIO == 5) in that case. Is this not technically an IO error? – Tom Jan 10 '14 at 01:00
  • @chux That crossed my mind, although I'm not yet sure how I'll test that either. This probably means I have to refactor my code. :-/ – Tom Jan 10 '14 at 01:03
  • 2
    The errno value from what? Are you calling `fread`, then `ferror` is telling you there's an error, and then `errno` is set to EIO? If so, that doesn't mean the file is shorter than expected, this means something else (like a physical read error) has happened. If the file is just shorter than expected, that's not an error, and `ferror` must tell you so. (And if there happens to be some old error lying around in `errno`, it's irrelevant.) Unless there's a serious bug in linux or glibc, which I doubt. – abarnert Jan 10 '14 at 01:11
  • The Internets are giving me conflicting information about whether `fread` sets errno. Some sources say it does, other say it's not required but may depend on the implementation. I guess I *should* be using ferror anyway. – Tom Jan 10 '14 at 01:25
  • But yes, the underlying problem is definitely a physical read error (bad sector on disk, I suppose.) – Tom Jan 10 '14 at 01:29
  • What exactly is your Python & C application doing? If it is so critical (e.g. life-critical embedded software) are you sure that Python is the best choice??? – Basile Starynkevitch Jan 10 '14 at 06:23
  • No, it's definitely not doing anything critical. The reason it has to handle this kind of IO error is because it reads a huge amount of data. (At this kind of scale, in fact, it's just an inevitability that some files can't be read, due to disk issues.) – Tom Jan 10 '14 at 15:39

4 Answers4

6

errno(3) is set to EIO only for 

   EIO    Input/output error (POSIX.1)

also, according to read(2) for:

   EIO    I/O error.  This will happen for example when the process is
          in a background process group, tries to read from its
          controlling terminal, and either it is ignoring or blocking
          SIGTTIN or its process group is orphaned.  It may also occur
          when there is a low-level I/O error while reading from a 
          disk or tape.

and according to write(2) for:

   EIO    A low-level I/O error occurred while modifying the inode.

So simulating that particular error code could be difficult; notice that there are other syscalls for I/O, notably writev(2) and (indirectly) mmap(2), but read(2) and write(2) are the most common ones.

Notice also that file systems and the Linux kernel (e.g. its VFS layer) are caching data. You could get EIO much later or never. See sync(2) and fsync(2)

However, generally, most software does not handle EIO specially w.r.t. other error codes; you probably are testing enough by getting another error code, like e.g. 

  EDQUOT The user's quota of disk blocks on the filesystem containing
          the file referred to by fd has been exhausted.

So you'll probably test enough by limiting disk quotas (see quotactl(2), setquota(8) etc...) and file space (see setrlimit(2) with RLIMIT_FSIZE, prlimit(1), ulimit builtin of bash(1) etc...)

If you really want to fake specifically EIO you could physically damage a device (or perhaps just unplug an USB disk at the wrong moment) or write your own Filesystem in User Space (FUSE) simulating it. I don't think it is worth the effort (because when something gets EIO the entire computer becomes very quickly unusable, and the user will notice that anyway.... and because most software handle all error codes likewise -except for EINTR)

In the C part of your code you may want to use strerror(3) (with syslog(3) perhaps) and/or perror(3). I am not sure it is worth the effort to handle EIO very differently of most other errors.

NB: many critical domains have standards defining how errors should be handled and code should be developed and tested, e.g. ISO26262 in automotive or DO-178B in avionics. Follow the standards of your domain.

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
2

As far as I understand the matter, classics of TDD warn us against writing mocks/stubs for 3rd-party interfaces (including standard library), see e.g. here. The major issue is that there is usually a gap between the application code and generic-purpose 3rd-party library which is hard to tie with mock-objects. Also, that prevents you from using tests to derive the design issues.

(Even though in your case the C library is not exactly 3rd party, unit-testing means that you test the entities in isolation).

The idea is that instead you write an adaptor class that encapsulates all the low-level logic and exposes an interface close to what your application needs (and, for example, raises more meaningful exceptions, like FileIsTooBig). Then you write mock-objects in terms of your domain. As for testing the adaptor itself, it's tested with few simple system tests.

bereal
  • 32,519
  • 6
  • 58
  • 104
  • That makes sense. I'm accepting this answer because it helps me understand how I should approach the problem from a software architecture standpoint. – Tom Jan 10 '14 at 15:42
1

Use fusepy.

fusepy is a python layer on top of FUSE, which allows file systems to be implemented in the Linux user space. fusepy is a Python module that provides a simple interface to FUSE and MacFUSE. It's just one file and is implemented using ctypes. With fusepy, you can modify the behavior of the write function implementation and throw an EIO if you want to. I'd use the memory.py example as a base.

Sebastian Wagner
  • 2,308
  • 2
  • 25
  • 32
1

libfiu (as mentioned in the "How can I simulate a failed disk during testing?" answer) is a structured approach to using interposing to perform fault injection of POSIX calls and would be ideal for use in test suites.

A more general list of techniques (such as using a FUSE filesystem) are mentioned in the list of Linux disk fault injection mechanisms answer to the "Special File that causes I/O error" question.

Anon
  • 6,306
  • 2
  • 38
  • 56