#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: | ||
| 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)
Change History (7)
comment:1 by , 16 years ago
| Cc: | added |
|---|
by , 16 years ago
| Attachment: | rw_test.cpp added |
|---|
follow-up: 5 comment:2 by , 16 years ago
| Cc: | added |
|---|---|
| Component: | - General → System/Kernel |
| Milestone: | R1 → R1/alpha1 |
| Priority: | normal → critical |
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 by , 16 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
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:5 by , 16 years ago
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 by , 16 years ago
Confirmed fixed, managed a full svn checkout and build in the same session (via ssh no less) with hrev26911 and all completed successfully.
Test driver