bugmake - Bugs: bug #46193, Discussion of system crash...


bug #46193: Discussion of system crash behaviours

Submitted by:  Yanyan Jiang <jiangyy>
Submitted on:  Tue 13 Oct 2015 02:25:56 AM UTC  
Severity:  3 - Normal Item Group:  Documentation
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Open
Component Version:  None Operating System:  Any
Fixed Release:  None Triage Status:  None

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


Sun 18 Oct 2015 05:30:18 PM UTC, comment #2:

Please see also bug 46242: make can leave behind out of date files even if nothing crashes.

Egmont Koblinger <egmont>
Tue 13 Oct 2015 10:28:57 PM UTC, comment #1:

Fail-stops aren't limited to crashes. Ctrl-Z and network splits sometimes stop make from removing a half-written target. At this shop, we aim to write rules that only write into temporary files, renaming them to the desired name once writing has completed successfully. This also saves us from persistent breakage when multiple builds accidentally contend. Perhaps someone has a write-up linked to from http://make.mad-scientist.net/#resources of how to do this without duplication.

Martin Dorey <mdorey>
Tue 13 Oct 2015 02:25:56 AM UTC, original submission:

I am currently working on the file system reliability issues. I have a disk driver that is able to simulate crash disk sites after injected power failures (inspired by two OSDI'14 papers about crash sites, and they found interesting bugs in many production systems like database). This disk is compatible with the Linux block driver semantics (refer to https://www.kernel.org/doc/Documentation/block/writeback_cache_control.txt), and may create many crash sites that pending blocks are partially flushed into the disk.

Our tool finds that a typical compiler (e.g., gcc) may suffer the issue of crash inconsistency. Specifically, there is a chance that for the binary output file (e.g., a .o file):

1. its timestamp is updated and gmake considers this file is up-to-date.
2. its actual data is not persisted to the disk.

On an ext4 filesystem (default setting) of a typical Linux distribution, we observed that there is a chance of leaving a 0-byte output file whose timestamp is updated. In more relaxed settings (e.g., old-time filesystems), a system crash would leave partially corrupted file in the filesystem with timestamp updated (e.g., several blocks are missing but with a correct header).

Note that this is NOT a defect for gcc or gmake as they have nothing to do with the crash semantics. However, if the user continues the incremental build after system crash, the entire thing would proceed, gmake will consider the generated .o file is up-to-date and proceed into the next stages, finally leading to incorrect outputs.

Though it is not a software defect, and is expected to be very rarely in practice. Neverthless, gmake is supposed to be general and to run on any platform. I am wondering if we should make users aware of this phenomenon (e.g., adding a small section in the document to discuss this issue).

Yanyan Jiang <jiangyy>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by egmont (Posted a comment)
  • -email is unavailable- added by egmont
  • -email is unavailable- added by mdorey (Posted a comment)
  • -email is unavailable- added by jiangyy (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-10-18 egmont Carbon-Copy- => Added egmont

    Back to the top

    Powered by Savane 3.4