check the right return value for mmap

[mangod9]

FIxes: #77477. mmap returns MAP_FAILED rather than NULL on failures.

[ghost]

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

Issue Details

---

FIxes: #77477. mmap returns MAP_FAILED rather than NULL on failures.

Author:	mangod9
Assignees:	mangod9
Labels:	area-GC-coreclr
Milestone:	-

[mangod9]

the failures are all helix timeouts. But the musl arm outerloop failure is fixed after this change.

[stephentoub]

We have some other usage of mmap, e.g. as part of MemoryMappedFiles. Do we need to fix anything there?

[mangod9]

We have some other usage of mmap, e.g. as part of MemoryMappedFiles. Do we need to fix anything there?

I can take a look, but assuming its been that way for a while? This particular code was recently added to coreclr (was only included within standalone GC previously), hence we are noticing this issue now.

[mangod9]

mmap return value is handled correctly here:

runtime/src/libraries/Common/src/Interop/Unix/System.Native/Interop.MMap.cs

Line 30 in 264d739

// NOTE: Shim returns null pointer on failure, not non-null MAP_FAILED sentinel.

[janvorli]

LGTM. Thank you!

[stephentoub]

mmap return value is handled correctly here:

Is it? SystemNative_MMap is just coercing MMAP_FAILED into NULL:

runtime/src/native/libs/System.Native/pal_io.c

Lines 948 to 951 in a4e98d4

	if (ret==MAP_FAILED)
	{
	returnNULL;
	}

But my understanding from this PR is that mmap returning NULL is actually a success case, not failure, and SystemNative_MMap is conflating the two such that

runtime/src/libraries/System.IO.MemoryMappedFiles/src/System/IO/MemoryMappedFiles/MemoryMappedView.Unix.cs

Lines 114 to 117 in 264d739

	if(addr==IntPtr.Zero)// note that shim uses null pointer, not non-null MAP_FAILED sentinel
	{
	throwInterop.GetExceptionForIoErrno(Interop.Sys.GetLastErrorInfo());
	}

then treats both as failure.

Do we know in what situations null might be returned as a success case?

[jkotas]

We know in what situations null might be returned as a success case?

When you map a page at address 0 (some Unix versions allow that). CoreCLR does not support that configuration.

[stephentoub]

When you map a page at address 0

Ok, thanks.

CoreCLR does not support that configuration.

Does mono?

[janvorli]

Actually, mmap is not allowed to return NULL by spec unless MAP_FIXED is passed to it.

When MAP_FIXED is not set, the implementation uses addr in an implementation-defined manner to arrive at pa. The pa so chosen shall be an area of the address space that the implementation deems suitable for a mapping of len bytes to the file. All implementations interpret an addr value of 0 as granting the implementation complete freedom in selecting pa, subject to constraints described below. A non-zero value of addr is taken to be a suggestion of a process address near which the mapping should be placed. When the implementation selects a value for pa, it never places a mapping at address 0, nor does it replace any extant mapping.

[stephentoub]

Actually, mmap is not allowed to return NULL by spec unless MAP_FIXED is passed to it.

Perfect. Thanks.

[mangod9]

FIxes: #77477. mmap returns MAP_FAILED rather than NULL on failures.

[ghost]

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

Issue Details

---

FIxes: #77477. mmap returns MAP_FAILED rather than NULL on failures.

Author:	mangod9
Assignees:	mangod9
Labels:	area-GC-coreclr
Milestone:	-

[mangod9]

the failures are all helix timeouts. But the musl arm outerloop failure is fixed after this change.

[stephentoub]

We have some other usage of mmap, e.g. as part of MemoryMappedFiles. Do we need to fix anything there?

[mangod9]

We have some other usage of mmap, e.g. as part of MemoryMappedFiles. Do we need to fix anything there?

I can take a look, but assuming its been that way for a while? This particular code was recently added to coreclr (was only included within standalone GC previously), hence we are noticing this issue now.

[mangod9]

mmap return value is handled correctly here:

runtime/src/libraries/Common/src/Interop/Unix/System.Native/Interop.MMap.cs

Line 30 in 264d739

// NOTE: Shim returns null pointer on failure, not non-null MAP_FAILED sentinel.

[janvorli]

LGTM. Thank you!

[stephentoub]

mmap return value is handled correctly here:

Is it? SystemNative_MMap is just coercing MMAP_FAILED into NULL:

runtime/src/native/libs/System.Native/pal_io.c

Lines 948 to 951 in a4e98d4

	if (ret==MAP_FAILED)
	{
	returnNULL;
	}

But my understanding from this PR is that mmap returning NULL is actually a success case, not failure, and SystemNative_MMap is conflating the two such that

runtime/src/libraries/System.IO.MemoryMappedFiles/src/System/IO/MemoryMappedFiles/MemoryMappedView.Unix.cs

Lines 114 to 117 in 264d739

	if(addr==IntPtr.Zero)// note that shim uses null pointer, not non-null MAP_FAILED sentinel
	{
	throwInterop.GetExceptionForIoErrno(Interop.Sys.GetLastErrorInfo());
	}

then treats both as failure.

Do we know in what situations null might be returned as a success case?

[jkotas]

We know in what situations null might be returned as a success case?

When you map a page at address 0 (some Unix versions allow that). CoreCLR does not support that configuration.

[stephentoub]

When you map a page at address 0

Ok, thanks.

CoreCLR does not support that configuration.

Does mono?

[janvorli]

Actually, mmap is not allowed to return NULL by spec unless MAP_FIXED is passed to it.

When MAP_FIXED is not set, the implementation uses addr in an implementation-defined manner to arrive at pa. The pa so chosen shall be an area of the address space that the implementation deems suitable for a mapping of len bytes to the file. All implementations interpret an addr value of 0 as granting the implementation complete freedom in selecting pa, subject to constraints described below. A non-zero value of addr is taken to be a suggestion of a process address near which the mapping should be placed. When the implementation selects a value for pa, it never places a mapping at address 0, nor does it replace any extant mapping.

[stephentoub]

Actually, mmap is not allowed to return NULL by spec unless MAP_FIXED is passed to it.

Perfect. Thanks.

[mangod9]

FIxes: #77477. mmap returns MAP_FAILED rather than NULL on failures.

[ghost]

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

Issue Details

---

FIxes: #77477. mmap returns MAP_FAILED rather than NULL on failures.

Author:	mangod9
Assignees:	mangod9
Labels:	area-GC-coreclr
Milestone:	-

[mangod9]

the failures are all helix timeouts. But the musl arm outerloop failure is fixed after this change.

[stephentoub]

We have some other usage of mmap, e.g. as part of MemoryMappedFiles. Do we need to fix anything there?

[mangod9]

We have some other usage of mmap, e.g. as part of MemoryMappedFiles. Do we need to fix anything there?

I can take a look, but assuming its been that way for a while? This particular code was recently added to coreclr (was only included within standalone GC previously), hence we are noticing this issue now.

[mangod9]

mmap return value is handled correctly here:

runtime/src/libraries/Common/src/Interop/Unix/System.Native/Interop.MMap.cs

Line 30 in 264d739

// NOTE: Shim returns null pointer on failure, not non-null MAP_FAILED sentinel.

[janvorli]

LGTM. Thank you!

[stephentoub]

mmap return value is handled correctly here:

Is it? SystemNative_MMap is just coercing MMAP_FAILED into NULL:

runtime/src/native/libs/System.Native/pal_io.c

Lines 948 to 951 in a4e98d4

	if (ret==MAP_FAILED)
	{
	returnNULL;
	}

But my understanding from this PR is that mmap returning NULL is actually a success case, not failure, and SystemNative_MMap is conflating the two such that

runtime/src/libraries/System.IO.MemoryMappedFiles/src/System/IO/MemoryMappedFiles/MemoryMappedView.Unix.cs

Lines 114 to 117 in 264d739

	if(addr==IntPtr.Zero)// note that shim uses null pointer, not non-null MAP_FAILED sentinel
	{
	throwInterop.GetExceptionForIoErrno(Interop.Sys.GetLastErrorInfo());
	}

then treats both as failure.

Do we know in what situations null might be returned as a success case?

[jkotas]

We know in what situations null might be returned as a success case?

When you map a page at address 0 (some Unix versions allow that). CoreCLR does not support that configuration.

[stephentoub]

When you map a page at address 0

Ok, thanks.

CoreCLR does not support that configuration.

Does mono?

[janvorli]

Actually, mmap is not allowed to return NULL by spec unless MAP_FIXED is passed to it.

When MAP_FIXED is not set, the implementation uses addr in an implementation-defined manner to arrive at pa. The pa so chosen shall be an area of the address space that the implementation deems suitable for a mapping of len bytes to the file. All implementations interpret an addr value of 0 as granting the implementation complete freedom in selecting pa, subject to constraints described below. A non-zero value of addr is taken to be a suggestion of a process address near which the mapping should be placed. When the implementation selects a value for pa, it never places a mapping at address 0, nor does it replace any extant mapping.

[stephentoub]

Actually, mmap is not allowed to return NULL by spec unless MAP_FIXED is passed to it.

Perfect. Thanks.

[mangod9]

FIxes: #77477. mmap returns MAP_FAILED rather than NULL on failures.

[ghost]

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

Issue Details

---

FIxes: #77477. mmap returns MAP_FAILED rather than NULL on failures.

Author:	mangod9
Assignees:	mangod9
Labels:	area-GC-coreclr
Milestone:	-

[mangod9]

the failures are all helix timeouts. But the musl arm outerloop failure is fixed after this change.

[stephentoub]

We have some other usage of mmap, e.g. as part of MemoryMappedFiles. Do we need to fix anything there?

[mangod9]

We have some other usage of mmap, e.g. as part of MemoryMappedFiles. Do we need to fix anything there?

I can take a look, but assuming its been that way for a while? This particular code was recently added to coreclr (was only included within standalone GC previously), hence we are noticing this issue now.

[mangod9]

mmap return value is handled correctly here:

runtime/src/libraries/Common/src/Interop/Unix/System.Native/Interop.MMap.cs

Line 30 in 264d739

// NOTE: Shim returns null pointer on failure, not non-null MAP_FAILED sentinel.

[janvorli]

LGTM. Thank you!

[stephentoub]

mmap return value is handled correctly here:

Is it? SystemNative_MMap is just coercing MMAP_FAILED into NULL:

runtime/src/native/libs/System.Native/pal_io.c

Lines 948 to 951 in a4e98d4

	if (ret==MAP_FAILED)
	{
	returnNULL;
	}

But my understanding from this PR is that mmap returning NULL is actually a success case, not failure, and SystemNative_MMap is conflating the two such that

runtime/src/libraries/System.IO.MemoryMappedFiles/src/System/IO/MemoryMappedFiles/MemoryMappedView.Unix.cs

Lines 114 to 117 in 264d739

	if(addr==IntPtr.Zero)// note that shim uses null pointer, not non-null MAP_FAILED sentinel
	{
	throwInterop.GetExceptionForIoErrno(Interop.Sys.GetLastErrorInfo());
	}

then treats both as failure.

Do we know in what situations null might be returned as a success case?

[jkotas]

We know in what situations null might be returned as a success case?

When you map a page at address 0 (some Unix versions allow that). CoreCLR does not support that configuration.

[stephentoub]

When you map a page at address 0

Ok, thanks.

CoreCLR does not support that configuration.

Does mono?

[janvorli]

Actually, mmap is not allowed to return NULL by spec unless MAP_FIXED is passed to it.

When MAP_FIXED is not set, the implementation uses addr in an implementation-defined manner to arrive at pa. The pa so chosen shall be an area of the address space that the implementation deems suitable for a mapping of len bytes to the file. All implementations interpret an addr value of 0 as granting the implementation complete freedom in selecting pa, subject to constraints described below. A non-zero value of addr is taken to be a suggestion of a process address near which the mapping should be placed. When the implementation selects a value for pa, it never places a mapping at address 0, nor does it replace any extant mapping.

[stephentoub]

Actually, mmap is not allowed to return NULL by spec unless MAP_FIXED is passed to it.

Perfect. Thanks.

[mangod9]

FIxes: #77477. mmap returns MAP_FAILED rather than NULL on failures.

[ghost]

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

Issue Details

---

FIxes: #77477. mmap returns MAP_FAILED rather than NULL on failures.

Author:	mangod9
Assignees:	mangod9
Labels:	area-GC-coreclr
Milestone:	-

[mangod9]

the failures are all helix timeouts. But the musl arm outerloop failure is fixed after this change.

[stephentoub]

We have some other usage of mmap, e.g. as part of MemoryMappedFiles. Do we need to fix anything there?

[mangod9]

We have some other usage of mmap, e.g. as part of MemoryMappedFiles. Do we need to fix anything there?

I can take a look, but assuming its been that way for a while? This particular code was recently added to coreclr (was only included within standalone GC previously), hence we are noticing this issue now.

[mangod9]

mmap return value is handled correctly here:

runtime/src/libraries/Common/src/Interop/Unix/System.Native/Interop.MMap.cs

Line 30 in 264d739

// NOTE: Shim returns null pointer on failure, not non-null MAP_FAILED sentinel.

[janvorli]

LGTM. Thank you!

[stephentoub]

mmap return value is handled correctly here:

Is it? SystemNative_MMap is just coercing MMAP_FAILED into NULL:

runtime/src/native/libs/System.Native/pal_io.c

Lines 948 to 951 in a4e98d4

	if (ret==MAP_FAILED)
	{
	returnNULL;
	}

But my understanding from this PR is that mmap returning NULL is actually a success case, not failure, and SystemNative_MMap is conflating the two such that

runtime/src/libraries/System.IO.MemoryMappedFiles/src/System/IO/MemoryMappedFiles/MemoryMappedView.Unix.cs

Lines 114 to 117 in 264d739

	if(addr==IntPtr.Zero)// note that shim uses null pointer, not non-null MAP_FAILED sentinel
	{
	throwInterop.GetExceptionForIoErrno(Interop.Sys.GetLastErrorInfo());
	}

then treats both as failure.

Do we know in what situations null might be returned as a success case?

[jkotas]

We know in what situations null might be returned as a success case?

When you map a page at address 0 (some Unix versions allow that). CoreCLR does not support that configuration.

[stephentoub]

When you map a page at address 0

Ok, thanks.

CoreCLR does not support that configuration.

Does mono?

[janvorli]

Actually, mmap is not allowed to return NULL by spec unless MAP_FIXED is passed to it.

When MAP_FIXED is not set, the implementation uses addr in an implementation-defined manner to arrive at pa. The pa so chosen shall be an area of the address space that the implementation deems suitable for a mapping of len bytes to the file. All implementations interpret an addr value of 0 as granting the implementation complete freedom in selecting pa, subject to constraints described below. A non-zero value of addr is taken to be a suggestion of a process address near which the mapping should be placed. When the implementation selects a value for pa, it never places a mapping at address 0, nor does it replace any extant mapping.

[stephentoub]

Actually, mmap is not allowed to return NULL by spec unless MAP_FIXED is passed to it.

Perfect. Thanks.

[mangod9]

FIxes: #77477. mmap returns MAP_FAILED rather than NULL on failures.

[ghost]

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

Issue Details

---

FIxes: #77477. mmap returns MAP_FAILED rather than NULL on failures.

Author:	mangod9
Assignees:	mangod9
Labels:	area-GC-coreclr
Milestone:	-

[mangod9]

the failures are all helix timeouts. But the musl arm outerloop failure is fixed after this change.

[stephentoub]

We have some other usage of mmap, e.g. as part of MemoryMappedFiles. Do we need to fix anything there?

[mangod9]

We have some other usage of mmap, e.g. as part of MemoryMappedFiles. Do we need to fix anything there?

I can take a look, but assuming its been that way for a while? This particular code was recently added to coreclr (was only included within standalone GC previously), hence we are noticing this issue now.

[mangod9]

mmap return value is handled correctly here:

runtime/src/libraries/Common/src/Interop/Unix/System.Native/Interop.MMap.cs

Line 30 in 264d739

// NOTE: Shim returns null pointer on failure, not non-null MAP_FAILED sentinel.

[janvorli]

LGTM. Thank you!

[stephentoub]

mmap return value is handled correctly here:

Is it? SystemNative_MMap is just coercing MMAP_FAILED into NULL:

runtime/src/native/libs/System.Native/pal_io.c

Lines 948 to 951 in a4e98d4

	if (ret==MAP_FAILED)
	{
	returnNULL;
	}

But my understanding from this PR is that mmap returning NULL is actually a success case, not failure, and SystemNative_MMap is conflating the two such that

runtime/src/libraries/System.IO.MemoryMappedFiles/src/System/IO/MemoryMappedFiles/MemoryMappedView.Unix.cs

Lines 114 to 117 in 264d739

	if(addr==IntPtr.Zero)// note that shim uses null pointer, not non-null MAP_FAILED sentinel
	{
	throwInterop.GetExceptionForIoErrno(Interop.Sys.GetLastErrorInfo());
	}

then treats both as failure.

Do we know in what situations null might be returned as a success case?

[jkotas]

We know in what situations null might be returned as a success case?

When you map a page at address 0 (some Unix versions allow that). CoreCLR does not support that configuration.

[stephentoub]

When you map a page at address 0

Ok, thanks.

CoreCLR does not support that configuration.

Does mono?

[janvorli]

Actually, mmap is not allowed to return NULL by spec unless MAP_FIXED is passed to it.

When MAP_FIXED is not set, the implementation uses addr in an implementation-defined manner to arrive at pa. The pa so chosen shall be an area of the address space that the implementation deems suitable for a mapping of len bytes to the file. All implementations interpret an addr value of 0 as granting the implementation complete freedom in selecting pa, subject to constraints described below. A non-zero value of addr is taken to be a suggestion of a process address near which the mapping should be placed. When the implementation selects a value for pa, it never places a mapping at address 0, nor does it replace any extant mapping.

[stephentoub]

Actually, mmap is not allowed to return NULL by spec unless MAP_FIXED is passed to it.

Perfect. Thanks.

[mangod9]

FIxes: #77477. mmap returns MAP_FAILED rather than NULL on failures.

[ghost]

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

Issue Details

---

FIxes: #77477. mmap returns MAP_FAILED rather than NULL on failures.

Author:	mangod9
Assignees:	mangod9
Labels:	area-GC-coreclr
Milestone:	-

[mangod9]

the failures are all helix timeouts. But the musl arm outerloop failure is fixed after this change.

[stephentoub]

We have some other usage of mmap, e.g. as part of MemoryMappedFiles. Do we need to fix anything there?

[mangod9]

We have some other usage of mmap, e.g. as part of MemoryMappedFiles. Do we need to fix anything there?

I can take a look, but assuming its been that way for a while? This particular code was recently added to coreclr (was only included within standalone GC previously), hence we are noticing this issue now.

[mangod9]

mmap return value is handled correctly here:

runtime/src/libraries/Common/src/Interop/Unix/System.Native/Interop.MMap.cs

Line 30 in 264d739

// NOTE: Shim returns null pointer on failure, not non-null MAP_FAILED sentinel.

[janvorli]

LGTM. Thank you!

[stephentoub]

mmap return value is handled correctly here:

Is it? SystemNative_MMap is just coercing MMAP_FAILED into NULL:

runtime/src/native/libs/System.Native/pal_io.c

Lines 948 to 951 in a4e98d4

	if (ret==MAP_FAILED)
	{
	returnNULL;
	}

But my understanding from this PR is that mmap returning NULL is actually a success case, not failure, and SystemNative_MMap is conflating the two such that

runtime/src/libraries/System.IO.MemoryMappedFiles/src/System/IO/MemoryMappedFiles/MemoryMappedView.Unix.cs

Lines 114 to 117 in 264d739

	if(addr==IntPtr.Zero)// note that shim uses null pointer, not non-null MAP_FAILED sentinel
	{
	throwInterop.GetExceptionForIoErrno(Interop.Sys.GetLastErrorInfo());
	}

then treats both as failure.

Do we know in what situations null might be returned as a success case?

[jkotas]

We know in what situations null might be returned as a success case?

When you map a page at address 0 (some Unix versions allow that). CoreCLR does not support that configuration.

[stephentoub]

When you map a page at address 0

Ok, thanks.

CoreCLR does not support that configuration.

Does mono?

[janvorli]

Actually, mmap is not allowed to return NULL by spec unless MAP_FIXED is passed to it.

When MAP_FIXED is not set, the implementation uses addr in an implementation-defined manner to arrive at pa. The pa so chosen shall be an area of the address space that the implementation deems suitable for a mapping of len bytes to the file. All implementations interpret an addr value of 0 as granting the implementation complete freedom in selecting pa, subject to constraints described below. A non-zero value of addr is taken to be a suggestion of a process address near which the mapping should be placed. When the implementation selects a value for pa, it never places a mapping at address 0, nor does it replace any extant mapping.

[stephentoub]

Actually, mmap is not allowed to return NULL by spec unless MAP_FIXED is passed to it.

Perfect. Thanks.

[mangod9]

FIxes: #77477. mmap returns MAP_FAILED rather than NULL on failures.

[ghost]

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

Issue Details

---

FIxes: #77477. mmap returns MAP_FAILED rather than NULL on failures.

Author:	mangod9
Assignees:	mangod9
Labels:	area-GC-coreclr
Milestone:	-

[mangod9]

the failures are all helix timeouts. But the musl arm outerloop failure is fixed after this change.

[stephentoub]

We have some other usage of mmap, e.g. as part of MemoryMappedFiles. Do we need to fix anything there?

[mangod9]

We have some other usage of mmap, e.g. as part of MemoryMappedFiles. Do we need to fix anything there?

I can take a look, but assuming its been that way for a while? This particular code was recently added to coreclr (was only included within standalone GC previously), hence we are noticing this issue now.

[mangod9]

mmap return value is handled correctly here:

runtime/src/libraries/Common/src/Interop/Unix/System.Native/Interop.MMap.cs

Line 30 in 264d739

// NOTE: Shim returns null pointer on failure, not non-null MAP_FAILED sentinel.

[janvorli]

LGTM. Thank you!

[stephentoub]

mmap return value is handled correctly here:

Is it? SystemNative_MMap is just coercing MMAP_FAILED into NULL:

runtime/src/native/libs/System.Native/pal_io.c

Lines 948 to 951 in a4e98d4

	if (ret==MAP_FAILED)
	{
	returnNULL;
	}

But my understanding from this PR is that mmap returning NULL is actually a success case, not failure, and SystemNative_MMap is conflating the two such that

runtime/src/libraries/System.IO.MemoryMappedFiles/src/System/IO/MemoryMappedFiles/MemoryMappedView.Unix.cs

Lines 114 to 117 in 264d739

	if(addr==IntPtr.Zero)// note that shim uses null pointer, not non-null MAP_FAILED sentinel
	{
	throwInterop.GetExceptionForIoErrno(Interop.Sys.GetLastErrorInfo());
	}

then treats both as failure.

Do we know in what situations null might be returned as a success case?

[jkotas]

We know in what situations null might be returned as a success case?

When you map a page at address 0 (some Unix versions allow that). CoreCLR does not support that configuration.

[stephentoub]

When you map a page at address 0

Ok, thanks.

CoreCLR does not support that configuration.

Does mono?

[janvorli]

Actually, mmap is not allowed to return NULL by spec unless MAP_FIXED is passed to it.

When MAP_FIXED is not set, the implementation uses addr in an implementation-defined manner to arrive at pa. The pa so chosen shall be an area of the address space that the implementation deems suitable for a mapping of len bytes to the file. All implementations interpret an addr value of 0 as granting the implementation complete freedom in selecting pa, subject to constraints described below. A non-zero value of addr is taken to be a suggestion of a process address near which the mapping should be placed. When the implementation selects a value for pa, it never places a mapping at address 0, nor does it replace any extant mapping.

[stephentoub]

Actually, mmap is not allowed to return NULL by spec unless MAP_FIXED is passed to it.

Perfect. Thanks.