Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#2584 closed bug (fixed)

File corruption

Reported by: andreasf Owned by: bonefish
Priority: critical Milestone: R1/alpha1
Component: System/Kernel Version: R1/pre-alpha1
Keywords: Cc: grzegorz.dabrowski@…, rgollent@…
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description

At hrev26856 and hrev26863 I get file corruption when extracting, configuring and make'ing libiconv-1.12.tar. The (first) affected file is lib/cp862.h, which is either truncated or contains garbage at slightly varying offsets. This does not happen back at hrev26820 for the same tar archive.

Attachments (1)

rw_test.cpp (2.2 KB) - added by anevilyak 11 years ago.
Test driver

Download all attachments as: .zip

Change History (7)

comment:1 Changed 11 years ago by kaliber

Cc: grzegorz.dabrowski@… added

Changed 11 years ago by anevilyak

Attachment: rw_test.cpp added

Test driver

comment:2 Changed 11 years ago by anevilyak

Cc: rgollent@… added
Component: - GeneralSystem/Kernel
Milestone: R1R1/alpha1
Priority: normalcritical

I've been trying to find a way to duplicate this one consistently but thus far I haven't succeeded. A subset of the files from an svn checkout seem to wind up with garbage data towards the end, but the attached test driver for instance does not manage to trigger the problem, even with several hundred concurrent threads. Does svn use the normal stdio calls to write files or is it perhaps using some other syscall that might have fancier semantics that are triggering the bug?

comment:3 Changed 11 years ago by bonefish

Owner: changed from axeld to bonefish
Status: newassigned

I can reproduce the problem with the libiconv archive. Even better the file is already corrupted directly after untaring. Will look into it later tonight.

comment:4 Changed 11 years ago by bonefish

Resolution: fixed
Status: assignedclosed

Fixed in hrev26910.

comment:5 in reply to:  2 Changed 11 years ago by bonefish

Replying to anevilyak:

I've been trying to find a way to duplicate this one consistently but thus far I haven't succeeded. A subset of the files from an svn checkout seem to wind up with garbage data towards the end, but the attached test driver for instance does not manage to trigger the problem, even with several hundred concurrent threads. Does svn use the normal stdio calls to write files or is it perhaps using some other syscall that might have fancier semantics that are triggering the bug?

No, this really hadn't anything to do with multi-threading. AFAIK svn uses only the standard I/O operations. If your problem with the svn files still persists, please open a new ticket.

comment:6 Changed 11 years ago by anevilyak

Confirmed fixed, managed a full svn checkout and build in the same session (via ssh no less) with hrev26911 and all completed successfully.

Note: See TracTickets for help on using tickets.