Michael Prokop: Error handling: ENOSPC
Hopefully fuzz testing is well known nowadays, right? But did you check how smart your software can handle ENOSPC - the ‘No space left on device’ error?
I like stress testing software (to be honest: no, not really). Yesterday I debugged a problem regarding zsh history writing on ENOSPC. Usually I use the grml Linux live-cd for stress testing (often running inside Qemu, Virtbox, VMware,…) like in:
dd if=/dev/zero of=/tmp/home.lo count=1000 losetup /dev/loop1 /tmp/home.lo mkfs.ext3 /dev/loop1 mount /dev/loop1 /home mkdir /home/grml chown grml: /home/grmlNow after restarting the shell session of user grml I can play with ‘No space left on device’ situations. (Notice: I adjust the count=… according to what type of application I want to test.) Too many applications don’t really cope with the ENOSPC situation. Firefox for example is very funny, depending on the situation it either just segfaults when trying to start up, or decides to not start up at all and just exits with ‘1′. See the relevant strace output:
mkdir("/home", 0700) = -1 EEXIST (File exists)
access("/home", F_OK) = 0
mkdir("/home/grml", 0700) = -1 EEXIST (File exists)
access("/home/grml", F_OK) = 0
mkdir("/home/grml/.mozilla", 0700) = -1 ENOSPC (No space left on device)
access("/home/grml/.mozilla", F_OK) = -1 ENOENT (No such file or directory)
exit_group(1) = ?
Opera also just exits when already running and receiving an ENOSPC - I encountered data loss (for example the transfer history got lost) more than once. Very "funny" to see how applications like dillo, joe, wireshark,… behave in the ENOSPC situation. Not.
Oh, your application handles ENOSPC just fine? Then continue testing with read-only filesystem, using NFS, removing files randomly,…

