Skip to content

SR-4993: Read zero length files on Linux #1166

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 29, 2017

Conversation

spevans
Copy link
Contributor

@spevans spevans commented Aug 10, 2017

  • Some files (eg in /proc) report a filesize of zero and need to
    be read into a buffer instead of using mmap().


func test_contentsOfZeroFile() {
#if os(Linux)
let contents = NSData(contentsOfFile: "/proc/self/cmdline")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's possible that the /proc/ filesystem isn't mounted in some situations, so I would guard this with a check to see if /proc/self/cmdline exists and silently abort if it doesn't - because it's possible someone will run this with a minimal container where procfs isn't present.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, I will wrap something around it

@alblue
Copy link
Contributor

alblue commented Aug 10, 2017

@swift-ci please test

@spevans
Copy link
Contributor Author

spevans commented Aug 10, 2017

Rebased, as I was printing the contents of /proc/self/maps to the logs. I added a check for /proc/self before using it.

let maps = try String(contentsOfFile: "/proc/self/maps", encoding: .utf8)
XCTAssertTrue(maps.characters.count > 0)
} catch {
XCTFail()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be worth having a failure reason here inside the XCTFail?

var amt = 0

repeat {
data = realloc(data, bytesRead + blockSize)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may return NULL, in which case the unwrap subsequently will fail. Is there any reason why we can't use a single byte array for reading and then have an NSMutableData to append the bytes into? That would solve the realloc calls.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was duplicating the usage of malloc() in the readBytesFromFileWithExtendedAttributes function above. Generally the pattern in Foundation seems to be not checking the return value of malloc()/realloc() and letting it eventually abort on a NULL deref. The same is true if bytesRead exceeds Int.max

@alblue
Copy link
Contributor

alblue commented Aug 10, 2017

@swift-ci please test

@spevans
Copy link
Contributor Author

spevans commented Aug 11, 2017

@alblue could you give this another test please, I think ci missed the last one

@ianpartridge
Copy link
Contributor

@swift-ci please test

1 similar comment
@ianpartridge
Copy link
Contributor

@swift-ci please test

@ianpartridge
Copy link
Contributor

It seems a shame to wrap all this in #if os(Linux). There are other operating systems which use a procfs and might find this code useful in future. Is there anything we can do about that?

@spevans
Copy link
Contributor Author

spevans commented Aug 15, 2017

Its not a problem to remove them, although I will leave them in the test case for now, I dont think macOS has any files that can be used for tests.

- Some files (eg in /proc) report a filesize of zero and need to
  be read into a buffer instead of using mmap().

- Check that '/proc/self' exists before using it for tests.
@spevans
Copy link
Contributor Author

spevans commented Aug 15, 2017

I removed the #if os(Linux) and also squashed & rebased to master. Tested OK in xcode9 with swift-DEVELOPMENT-SNAPSHOT-2017-08-14

@ianpartridge
Copy link
Contributor

What do you think @alblue?

@spevans
Copy link
Contributor Author

spevans commented Aug 17, 2017

@parkera Any thoughts on this PR?

@parkera
Copy link
Contributor

parkera commented Aug 18, 2017

We've been having a discussion about this on the team, trying to decide if it's non-portable behavior or not. In the end we decided that if you're accessing /proc then you're already platform-specific.

@parkera parkera self-requested a review August 18, 2017 17:23
@spevans
Copy link
Contributor Author

spevans commented Aug 23, 2017

@parkera Is this ok to merge now?

@spevans
Copy link
Contributor Author

spevans commented Aug 28, 2017

@swift-ci please test

@parkera
Copy link
Contributor

parkera commented Aug 28, 2017

Yup, we can merge when ready.

@spevans
Copy link
Contributor Author

spevans commented Aug 28, 2017

@parkera Could you test and merge please, my swift-ci access isnt currently working

@ianpartridge
Copy link
Contributor

@swift-ci please test and merge

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants