Ticket #2584 (closed bug: fixed)

Opened 3 weeks ago

Last modified 3 weeks ago

File corruption

Reported by: andreasf Owned by: bonefish
Priority: critical Milestone: R1/alpha1
Component: System/Kernel Version: R1 development
Cc: grzegorz.dabrowski@…, rgollent@… Blocked By:
Platform: x86 Blocking:

Description

At r26856 and r26863 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 r26820 for the same tar archive.

Attachments

rw_test.cpp (2.2 kB) - added by anevilyak 3 weeks ago.
Test driver

Change History

  Changed 3 weeks ago by kaliber

  • cc grzegorz.dabrowski@… added

Changed 3 weeks ago by anevilyak

Test driver

follow-up: ↓ 5   Changed 3 weeks ago by anevilyak

  • cc rgollent@… added
  • priority changed from normal to critical
  • component changed from - General to System/Kernel
  • milestone changed from R1 to R1/alpha1

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?

  Changed 3 weeks ago by bonefish

  • owner changed from axeld to bonefish
  • status changed from new to 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.

  Changed 3 weeks ago by bonefish

  • status changed from assigned to closed
  • resolution set to fixed

Fixed in r26910.

in reply to: ↑ 2   Changed 3 weeks 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.

  Changed 3 weeks ago by anevilyak

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

Note: See TracTickets for help on using tickets.