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

 
 

bug #46193: Discussion of system crash behaviours

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

Add a New Comment Rich Markup
   

Thu 16 Jan 2020 09:58:25 PM UTC, comment #3: 

I added some information to the section "Interrupting or Killing make" discussing ways to write recipes to defend against these types of extreme errors.

Paul D. Smith <psmith>
Group administrator
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:
   
   
Comment:
   

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 psmith (Posted a comment)
  • -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)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-01-16 psmith StatusNone Fixed
        Assigned toNone psmith
        Open/ClosedOpen Closed
        Fixed ReleaseNone 4.3
    2015-10-18 egmont Carbon-Copy- Added egmont

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code