Skip to content
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.

Sign up for GitHub

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

Make tests work on 32-bit #486

Merged
merged 19 commits into from
Aug 16, 2018
Merged

Make tests work on 32-bit #486

Show file tree
Hide file tree
Changes from 13 commits
Commits
Show all changes
19 commits
Select commit Hold shift + click to select a range
149b341
32-bit fix for tests: Replace 0xDEADBEEF w/ 0x1337BEEF
helje5 Jun 12, 2018
6992e1b
Attempt to make ByteBuffer work better on 32-bit
helje5 Jun 12, 2018
dfefac1
Decrease writevLimitBytes on 32-bit
helje5 Jun 12, 2018
4264cf3
Decrease WebSockets max frame size on 32-bit
helje5 Jun 12, 2018
3f0541d
Adjust tests to run on Raspi 32-bit
helje5 Jun 12, 2018
d4c40b0
Fix compile issues introduced in 32-bit port
helje5 Jun 12, 2018
6641f8a
Fix comment of nextPowerOf2ClampedToMax
helje5 Jun 13, 2018
6ab4f11
Invert a #if-else arch conditional
helje5 Jun 13, 2018
abd6238
Use 0xdeadbeef as UInt instead of 0x1337beef
helje5 Jun 13, 2018
d49bee0
Revert one 0xdeadbeef as UInt back into 1337beef
helje5 Jun 13, 2018
b2fe95b
Address PR486 reviews items
helje5 Jul 3, 2018
3246661
Merge branch 'master' into feature/raspi-nio-tests-1
helje5 Jul 3, 2018
1ee4edd
Merge branch 'master' into feature/raspi-nio-tests-1
helje5 Jul 9, 2018
7175fc8
Merge branch 'master' into feature/raspi-nio-tests-1
helje5 Jul 10, 2018
2eb3e6a
Just wraps a comment to 120 columns
helje5 Jul 10, 2018
fb1a6e1
Merge branch 'master' into feature/raspi-nio-tests-1
weissi Aug 4, 2018
19a4199
Merge branch 'master' into feature/raspi-nio-tests-1
weissi Aug 7, 2018
8e8870d
Merge branch 'master' into feature/raspi-nio-tests-1
weissi Aug 14, 2018
91c38d3
Merge branch 'master' into feature/raspi-nio-tests-1
weissi Aug 16, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 8 additions & 2 deletions Sources/NIO/ByteBuffer-int.swift
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -105,21 +105,27 @@ extension FixedWidthInteger {
}

extension UInt32 {
/// Returns the next power of two unless that would overflow in which case UInt32.max is returned.
/// Returns the next power of two unless that would overflow, in which case UInt32.max (on 64-bit systems) or Int32.max (on 32-bit systems) is returned. The returned value is always safe to be cast to Int and passed to malloc on all platforms.
Copy link
Member

Choose a reason for hiding this comment

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

mind breaking that line in two so it's doesn't go over 120 characters ideally?

public func nextPowerOf2ClampedToMax() -> UInt32 {
guard self > 0 else {
return 1
}

var n = self

#if arch(arm) // 32-bit, Raspi/AppleWatch/etc
let max = UInt32(Int32.max)
Copy link
Member

Choose a reason for hiding this comment

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

this is maybe nit-picking but we'd like it to be Int.max (yes, same as Int32.max on 32-bit platforms) because really we'd be okay with it being larger but Swift uses the Int type so maybe it's clearer to users? I'm okay with leaving that too though. @Lukasa

Copy link
Contributor

Choose a reason for hiding this comment

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

Fine with changing this to Int.max

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'm not entirely sure about this. You want UInt32(Int.max)? That would fail on 64-bit platforms? This really only is for the UInt32(Int32.max) case, and it makes sense to be explicit here, no?

Copy link
Member

Choose a reason for hiding this comment

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

yes UInt32(Int.max) would be good. I want it to fail if it's compiled on 64-bits. This thing should only be there for 32-bit platforms

#else
let max = UInt32.max
#endif
Copy link
Contributor

Choose a reason for hiding this comment

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

This change violates the doc comment up above, so we should probably change this.

Incidentally, I assume the reason for this change is that malloc accepts Int on 32-bit platforms, so returning UInt32.max is not a super great plan, so it may be worth changing the doc comment to say something like:

"Returns the next power of two unless that would overflow, in which case UInt32.max (on 64-bit systems) or Int32.max (on 32-bit systems) is returned. The returned value is always safe to be cast to Int and passed to malloc on all platforms."

Copy link
Member

Choose a reason for hiding this comment

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

@helje5 / @Lukasa wait. malloc takes size_t which is unsigned, so it should be CSize == UInt imho. So I don't quite understand this change

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This was probably to support the sysMalloc(Int) issue. Looks like you changed that upstream to sysMalloc(size_t), so it may not be necessary anymore.


n -= 1
n |= n >> 1
n |= n >> 2
n |= n >> 4
n |= n >> 8
n |= n >> 16
if n != .max {
if n != max {
Copy link
Member

Choose a reason for hiding this comment

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

do we actually have a test that on 32-bit systems tests that this returns the right value?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There is no test for this on 64-bit either. /shrug

Copy link
Member

Choose a reason for hiding this comment

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

that's bad, we should definitely have one

n += 1
}

Expand Down
9 changes: 8 additions & 1 deletion Sources/NIO/Socket.swift
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,14 @@ public typealias IOVector = iovec

/// The maximum number of bytes to write per `writev` call.
static var writevLimitBytes: Int {
return Int(Int32.max)
#if arch(arm) // 32-bit, Raspi/AppleWatch/etc
// Note(hh): This is not a _proper_ fix, but necessary because
// other places extend on that. Should be fine in
// practice on 32-bit platforms.
return Int(Int32.max / 4)
Copy link
Contributor

Choose a reason for hiding this comment

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

Hrm, I don't love this. AFAICT this change works around the fact that we have a test that validates what happens if we attempt to write more than writevLimitBytes, which does some unguarded addition on this value.

For the test in ChannelTests.swift, it may be best to change it on 32-bit systems to create the buffer at writevLimitBytes and adjust the expected return values. That's the largest possible allocated buffer on 32-bit NIO anyway.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, there are more NIO issues wrt that. I.e. ByteBuffer uses UInt32 and nextPoW2 to round up the size, which subsequently fails when casting backt to malloc, which wants an Int.
It simply is no good to live on that edge on 32-bit platforms. IMO it is not worthwhile to adjust all of NIO just for the 32-bit edge case. And you don't do similar edge-checks for 64-bit either (but stick to Int32.max ;-) )

Copy link
Contributor

Choose a reason for hiding this comment

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

ByteBuffer uses UInt32 and nextPoW2 to round up the size, which subsequently fails when casting backt to malloc

Doesn't this patch change that?

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 tracked down this specific thing, yes (but stuff kept failing). What I was trying to say is that it probably makes no sense to support that max-addressable-memory edge-case in NIO (generally). If you really want to, I suggest starting out by writing tests that check against Int64.max on 64-bit too. It is not worth it, IMO.

Copy link
Member

Choose a reason for hiding this comment

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

@helje5 I don't understand why Int32.max doesn't work here. It fits into an Int on both 32 and 64 bit platforms.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

            // Note(hh): This is not a _proper_ fix, but necessary because
            //           other places extend on that. Should be fine in
            //           practice on 32-bit platforms.

Well, it is in the comment above it (and in my reply above yours). It is not a proper fix, but it is a lot of work to track down all edge cases (for little gain).

P.S.: Maybe a lot of that went away when you changed sysMalloc(Int) to sysMalloc(size_t).

Copy link
Member

Choose a reason for hiding this comment

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

@helje5 could we re-check this?

Copy link
Member

Choose a reason for hiding this comment

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

@helje5 if you could just re-check that this is still the case. And then just remove the two note(hh) comments with a good explanation why we need (if we need) special casing.

Copy link
Member

Choose a reason for hiding this comment

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

if that's done we can merge I think.

#else
return Int(Int32.max)
#endif
}

/// The maximum number of `IOVector`s to write per `writev` call.
Expand Down
9 changes: 8 additions & 1 deletion Sources/NIOWebSocket/WebSocketFrameEncoder.swift
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,14 @@ import NIO

private let maxOneByteSize = 125
private let maxTwoByteSize = Int(UInt16.max)
private let maxNIOFrameSize = Int(UInt32.max)
#if arch(arm) // 32-bit, Raspi/AppleWatch/etc
// Note(hh): This is not a _proper_ fix, but necessary because
// other places extend on that. Should be fine in
// practice on 32-bit platforms.
private let maxNIOFrameSize = Int(Int32.max / 4)
Copy link
Contributor

Choose a reason for hiding this comment

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

Any reason not to just set this to Int(Int32.max )? So far as I know we don't ever do math on this, so setting it to Int32.max gets the behaviour as close as reasonably possible to the 64-bit behaviour.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Same as above. Probably breaks when it travels to the ByteBuffer, which will use UInt32 and then fail.

Copy link
Member

Choose a reason for hiding this comment

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

we should fully understand this. I think Int32.max should just work

#else
private let maxNIOFrameSize = Int(UInt32.max)
#endif

/// An inbound `ChannelHandler` that serializes structured websocket frames into a byte stream
/// for sending on the network.
Expand Down
47 changes: 31 additions & 16 deletions Tests/NIOTests/ByteBufferTest.swift
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1073,22 +1073,37 @@ class ByteBufferTest: XCTestCase {
}

func testAllocationOfReallyBigByteBuffer() throws {
let alloc = ByteBufferAllocator(hookedMalloc: { testAllocationOfReallyBigByteBuffer_mallocHook($0) },
hookedRealloc: { testAllocationOfReallyBigByteBuffer_reallocHook($0, $1) },
hookedFree: { testAllocationOfReallyBigByteBuffer_freeHook($0) },
hookedMemcpy: { testAllocationOfReallyBigByteBuffer_memcpyHook($0, $1, $2) })

XCTAssertEqual(AllocationExpectationState.begin, testAllocationOfReallyBigByteBuffer_state)
var buf = alloc.buffer(capacity: Int(Int32.max))
XCTAssertEqual(AllocationExpectationState.mallocDone, testAllocationOfReallyBigByteBuffer_state)
XCTAssertGreaterThanOrEqual(buf.capacity, Int(Int32.max))

buf.set(bytes: [1], at: 0)
/* now make it expand (will trigger realloc) */
buf.set(bytes: [1], at: buf.capacity)

XCTAssertEqual(AllocationExpectationState.reallocDone, testAllocationOfReallyBigByteBuffer_state)
XCTAssertEqual(buf.capacity, Int(UInt32.max))
#if arch(arm) // 32-bit, Raspi/AppleWatch/etc
Copy link
Member

Choose a reason for hiding this comment

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

instead of indenting everything, can we just do

#if arch(arm)
// this test fails on 32 bit platforms
return
#endif

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 don't care if you prefer that, but visually an indent makes sense, IMO. Sometimes people do a 4-indent for regular Swift code and indent the # stuff by 2, which I also kinda like.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh, you are saying I should return early, not remove the actual indent. But this will produce a Swift compiler warning wrt unreachable code.

Copy link
Member

Choose a reason for hiding this comment

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

ahh, ok, then leave this as is.

// FIXME: Fails hard on Raspi 32-bit even with Int16.max in `__memcpy_neon`. Figure out how and why.
XCTAssertTrue(false, "testAllocationOfReallyBigByteBuffer fails on 32-bit Raspi")
#else
let alloc = ByteBufferAllocator(hookedMalloc: { testAllocationOfReallyBigByteBuffer_mallocHook($0) },
hookedRealloc: { testAllocationOfReallyBigByteBuffer_reallocHook($0, $1) },
hookedFree: { testAllocationOfReallyBigByteBuffer_freeHook($0) },
hookedMemcpy: { testAllocationOfReallyBigByteBuffer_memcpyHook($0, $1, $2) })

#if arch(arm) // 32-bit, Raspi/AppleWatch/etc
let reallyBigSize = Int(Int16.max) // well, but Int32 is too big (1GB RAM, no swap)
#else
let reallyBigSize = Int(Int32.max)
#endif
XCTAssertEqual(AllocationExpectationState.begin, testAllocationOfReallyBigByteBuffer_state)
var buf = alloc.buffer(capacity: reallyBigSize)
XCTAssertEqual(AllocationExpectationState.mallocDone, testAllocationOfReallyBigByteBuffer_state)
XCTAssertGreaterThanOrEqual(buf.capacity, reallyBigSize)

buf.set(bytes: [1], at: 0)
/* now make it expand (will trigger realloc) */
buf.set(bytes: [1], at: buf.capacity)

XCTAssertEqual(AllocationExpectationState.reallocDone, testAllocationOfReallyBigByteBuffer_state)
#if arch(arm) // 32-bit, Raspi/AppleWatch/etc
// TODO(hh): no idea, but not UInt32.max :-)
XCTAssertGreaterThanOrEqual(buf.capacity, reallyBigSize)
#else
XCTAssertEqual(buf.capacity, Int(UInt32.max))
#endif
#endif
}

func testWritableBytesAccountsForSlicing() throws {
Expand Down
22 changes: 14 additions & 8 deletions Tests/NIOTests/ChannelTests.swift
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -169,9 +169,15 @@ public class ChannelTests: XCTestCase {
for _ in 0..<bufferSize {
buffer.write(staticString: "a")
}

Copy link
Contributor

Choose a reason for hiding this comment

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

Mind removing this whitespace line?


#if arch(arm) // 32-bit, Raspi/AppleWatch/etc
let lotsOfData = Int(Int32.max / 8)
Copy link
Member

Choose a reason for hiding this comment

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

why do we use less data here? Is that documented to be the maximum?

Copy link
Contributor Author

@helje5 helje5 Jul 3, 2018 •
edited
Loading

Choose a reason for hiding this comment

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

Why do you use Int32.max instead of Int64.max on 64-bit? Same reason ;-) (allocating 4GB on 64-bit is usually OK, but a Raspi has only 512MB or maybe 1GB of RAM - and no swap by default either. so lets not overdo this test).

Copy link
Member

Choose a reason for hiding this comment

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

but we're only allocating 2MB here, right? We'll write the same buffer over and over again, this should work. The sizes were chosen so it will exhaust both the number of bytes limit (IIRC 2GB) as well as the number of chunks (1024) you're allowed to give to writev. If we think this isn't worthwhile, then we can lower the number for all platforms. CC @Lukasa

Copy link
Contributor

Choose a reason for hiding this comment

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

@weissi is correct, the purpose of this is to validate that we correctly handle having more data to pass to writev than writev will accept. As @weissi notes, we only actually allocate one buffer, so there is no risk.

Copy link
Contributor Author

@helje5 helje5 Jul 10, 2018 •
edited
Loading

Choose a reason for hiding this comment

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

Oh, I see. You just repeatedly write the 2MB buffer. Maybe the overflow happens because of <=? I guess I need to check this one on a Raspi again.
(I mean, internally it still has to spool up Int32.max of buffers, which won't work out well, right?)

Copy link
Member

Choose a reason for hiding this comment

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

it'd be awesome if you could validate why it fails. There must be something else wrong.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Well, see my () comment:

internally it still has to spool up Int32.max of buffers, which won't work out

#else
let lotsOfData = Int(Int32.max)
#endif
var written = 0
while written <= Int(INT32_MAX) {
while written <= lotsOfData {
clientChannel.write(NIOAny(buffer), promise: nil)
written += bufferSize
}
Expand Down Expand Up @@ -220,7 +226,7 @@ public class ChannelTests: XCTestCase {
var iovecs: [IOVector] = Array(repeating: iovec(), count: Socket.writevLimitIOVectors + 1)
var managed: [Unmanaged<AnyObject>] = Array(repeating: Unmanaged.passUnretained(o), count: Socket.writevLimitIOVectors + 1)
/* put a canary value at the end */
iovecs[iovecs.count - 1] = iovec(iov_base: UnsafeMutableRawPointer(bitPattern: 0xdeadbeef)!, iov_len: 0xdeadbeef)
iovecs[iovecs.count - 1] = iovec(iov_base: UnsafeMutableRawPointer(bitPattern: 0x1337beef)!, iov_len: 0x1337beef)
try iovecs.withUnsafeMutableBufferPointer { iovecs in
try managed.withUnsafeMutableBufferPointer { managed in
let pwm = NIO.PendingStreamWritesManager(iovecs: iovecs, storageRefs: managed)
Expand All @@ -237,8 +243,8 @@ public class ChannelTests: XCTestCase {
}
/* assert that the canary values are still okay, we should definitely have never written those */
XCTAssertEqual(managed.last!.toOpaque(), Unmanaged.passUnretained(o).toOpaque())
XCTAssertEqual(0xdeadbeef, Int(bitPattern: iovecs.last!.iov_base))
XCTAssertEqual(0xdeadbeef, iovecs.last!.iov_len)
XCTAssertEqual(0x1337beef, Int(bitPattern: iovecs.last!.iov_base))
XCTAssertEqual(0x1337beef, iovecs.last!.iov_len)
Copy link
Contributor

Choose a reason for hiding this comment

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

Out of interest why does the old value prevent compilation?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Int(0xdeadbeef) (which the compiler generates for literals) overflows Int32 (which then asserts). The other option which I think I actually used in the original patch is 0xdeadbeef as UInt or sth like that. I don't mind either.

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 better to use that other version, just for consistency with ourselves (we use deadbeef as our marker value elsewhere in the code)

Copy link
Member

@weissi weissi Jun 19, 2018 •
edited
Loading

Choose a reason for hiding this comment

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

I'd propose 0xdedbeef or 0xdadbeef or smth but only if we can't use 0xdeadbeef (which fits fine in a UInt32)

}
}

Expand Down Expand Up @@ -676,8 +682,8 @@ public class ChannelTests: XCTestCase {
/// Test that with a few massive buffers, we don't offer more than we should to `writev` if the individual chunks fit.
func testPendingWritesNoMoreThanWritevLimitIsWritten() throws {
let el = EmbeddedEventLoop()
let alloc = ByteBufferAllocator(hookedMalloc: { _ in UnsafeMutableRawPointer(bitPattern: 0xdeadbeef)! },
hookedRealloc: { _, _ in UnsafeMutableRawPointer(bitPattern: 0xdeadbeef)! },
let alloc = ByteBufferAllocator(hookedMalloc: { _ in UnsafeMutableRawPointer(bitPattern: 0x1337beef)! },
hookedRealloc: { _, _ in UnsafeMutableRawPointer(bitPattern: 0x1337beef)! },
hookedFree: { _ in },
hookedMemcpy: { _, _, _ in })
/* each buffer is half the writev limit */
Expand Down Expand Up @@ -708,8 +714,8 @@ public class ChannelTests: XCTestCase {
/// Test that with a massive buffers (bigger than writev size), we don't offer more than we should to `writev`.
func testPendingWritesNoMoreThanWritevLimitIsWrittenInOneMassiveChunk() throws {
let el = EmbeddedEventLoop()
let alloc = ByteBufferAllocator(hookedMalloc: { _ in UnsafeMutableRawPointer(bitPattern: 0xdeadbeef)! },
hookedRealloc: { _, _ in UnsafeMutableRawPointer(bitPattern: 0xdeadbeef)! },
let alloc = ByteBufferAllocator(hookedMalloc: { _ in UnsafeMutableRawPointer(bitPattern: 0x1337beef)! },
hookedRealloc: { _, _ in UnsafeMutableRawPointer(bitPattern: 0x1337beef)! },
hookedFree: { _ in },
hookedMemcpy: { _, _, _ in })
/* each buffer is half the writev limit */
Expand Down
7 changes: 6 additions & 1 deletion Tests/NIOTests/DatagramChannelTests.swift
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -244,8 +244,13 @@ final class DatagramChannelTests: XCTestCase {
}
let envelope = AddressedEnvelope(remoteAddress: self.secondChannel.localAddress!, data: buffer)

#if arch(arm) // 32-bit, Raspi/AppleWatch/etc
let lotsOfData = Int(Int32.max / 8)
#else
let lotsOfData = Int(Int32.max)
#endif
var written = 0
while written <= Int(INT32_MAX) {
while written <= lotsOfData {
self.firstChannel.write(NIOAny(envelope), promise: myPromise)
overall = EventLoopFuture<Void>.andAll([overall, myPromise.futureResult], eventLoop: self.firstChannel.eventLoop)
written += bufferSize
Expand Down
2 changes: 1 addition & 1 deletion Tests/NIOTests/EmbeddedEventLoopTest.swift
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -110,7 +110,7 @@ public class EmbeddedEventLoopTest: XCTestCase {
var sentinel = 0
let loop = EmbeddedEventLoop()
for index in 1...10 {
_ = loop.scheduleTask(in: .nanoseconds(index)) {
_ = loop.scheduleTask(in: .nanoseconds(TimeAmount.Value(index))) {
sentinel = index
}
}
Expand Down
14 changes: 7 additions & 7 deletions Tests/NIOTests/PendingDatagramWritesManagerTests.swift
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -62,7 +62,7 @@ class PendingDatagramWritesManagerTests: XCTestCase {
var msgs: [MMsgHdr] = Array(repeating: MMsgHdr(), count: Socket.writevLimitIOVectors + 1)
var addresses: [sockaddr_storage] = Array(repeating: sockaddr_storage(), count: Socket.writevLimitIOVectors + 1)
/* put a canary value at the end */
iovecs[iovecs.count - 1] = iovec(iov_base: UnsafeMutableRawPointer(bitPattern: 0xdeadbeef)!, iov_len: 0xdeadbeef)
iovecs[iovecs.count - 1] = iovec(iov_base: UnsafeMutableRawPointer(bitPattern: 0x1337beef)!, iov_len: 0x1337beef)
try iovecs.withUnsafeMutableBufferPointer { iovecs in
try managed.withUnsafeMutableBufferPointer { managed in
try msgs.withUnsafeMutableBufferPointer { msgs in
Expand All @@ -83,8 +83,8 @@ class PendingDatagramWritesManagerTests: XCTestCase {
}
/* assert that the canary values are still okay, we should definitely have never written those */
XCTAssertEqual(managed.last!.toOpaque(), Unmanaged.passUnretained(o).toOpaque())
XCTAssertEqual(0xdeadbeef, Int(bitPattern: iovecs.last!.iov_base))
XCTAssertEqual(0xdeadbeef, iovecs.last!.iov_len)
XCTAssertEqual(0x1337beef, Int(bitPattern: iovecs.last!.iov_base))
XCTAssertEqual(0x1337beef, iovecs.last!.iov_len)
}
}

Expand Down Expand Up @@ -433,8 +433,8 @@ class PendingDatagramWritesManagerTests: XCTestCase {
/// Test that with a few massive buffers, we don't offer more than we should to `writev` if the individual chunks fit.
func testPendingWritesNoMoreThanWritevLimitIsWritten() throws {
let el = EmbeddedEventLoop()
let alloc = ByteBufferAllocator(hookedMalloc: { _ in return UnsafeMutableRawPointer(bitPattern: 0xdeadbeef)! },
hookedRealloc: { _, _ in return UnsafeMutableRawPointer(bitPattern: 0xdeadbeef)! },
let alloc = ByteBufferAllocator(hookedMalloc: { _ in return UnsafeMutableRawPointer(bitPattern: 0xdeadbeef as UInt)! },
hookedRealloc: { _, _ in return UnsafeMutableRawPointer(bitPattern: 0xdeadbeef as UInt)! },
hookedFree: { _ in },
hookedMemcpy: { _, _, _ in })
/* each buffer is half the writev limit */
Expand Down Expand Up @@ -466,8 +466,8 @@ class PendingDatagramWritesManagerTests: XCTestCase {
func testPendingWritesNoMoreThanWritevLimitIsWrittenInOneMassiveChunk() throws {
let el = EmbeddedEventLoop()
let address = try SocketAddress(ipAddress: "127.0.0.1", port: 65535)
let alloc = ByteBufferAllocator(hookedMalloc: { _ in return UnsafeMutableRawPointer(bitPattern: 0xdeadbeef)! },
hookedRealloc: { _, _ in return UnsafeMutableRawPointer(bitPattern: 0xdeadbeef)! },
let alloc = ByteBufferAllocator(hookedMalloc: { _ in return UnsafeMutableRawPointer(bitPattern: 0xdeadbeef as UInt)! },
hookedRealloc: { _, _ in return UnsafeMutableRawPointer(bitPattern: 0xdeadbeef as UInt)! },
hookedFree: { _ in },
hookedMemcpy: { _, _, _ in })
/* each buffer is half the writev limit */
Expand Down
2 changes: 1 addition & 1 deletion Tests/NIOTests/SystemCallWrapperHelpers.swift
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -72,7 +72,7 @@ func runSystemCallWrapperPerformanceTest(testAssertFunction: (@autoclosure () ->
}

let iterations = isDebugMode ? 100_000 : 1_000_000
let pointer = UnsafePointer<UInt8>(bitPattern: 0xdeadbeef)!
let pointer = UnsafePointer<UInt8>(bitPattern: 0x1337beef)!

let directCallTime = try measureRunTime { () -> Int in
/* imitate what the system call wrappers do to have a fair comparison */
Expand Down