System.NullReferenceException in new `task` CE in F# 6

[sasmithjr]

In some cases where a let precedes a let! in the new task CE, an NRE is thrown. I'm not sure of the specifics for why it happens sometimes and not others, but I've got an example than can quickly be run through FSI.

dotnet --version: 6.0.100
OS: macOS 11.6.1

Repro steps

After using dotnet fsi, copy/paste the following code block into FSI to see the issue:

let z0 () =
    task {
        let w = [| 1 |] |> Array.map (fun w -> w + 1) |> Array.head
        let! x = task { return 3 }
        let finalResult = w + x + 3
        return finalResult
    }

// Throws an NRE
z0 () |> Async.AwaitTask |> Async.RunSynchronously;;

If you swap the let w... and let! x... lines, it works:

let z1 () =
    task {
        let! x = task { return 3 }
        let w = [| 1 |] |> Array.map (fun w -> w + 1) |> Array.head
        let finalResult = w + x + 3
        return finalResult
    }

// Works
z1 () |> Async.AwaitTask |> Async.RunSynchronously;;

Or a simple replacement of Array.map and Array.head works:

let increment = Array.map (fun w -> w + 1)
let head = Array.head

let z2 () =
    task {
        let w = [| 1 |] |> increment |> head
        let! x = task { return 3 }
        let finalResult = w + x + 3
        return finalResult
    }

// Works
z2 () |> Async.AwaitTask |> Async.RunSynchronously;;

Adding a second let also works:

let z3 () =
    task {
        let w0 = [| 1 |] |> Array.map (fun w -> w + 1)
        let w1 = w0 |> Array.head
        let! x = task { return 3 }
        let finalResult = w1 + x + 3
        return finalResult
    }

//Works
z3 () |> Async.AwaitTask |> Async.RunSynchronously;;

Actual behavior

System.NullReferenceException: Object reference not set to an instance of an object. at FSI_0003.z0@13.MoveNext()

Expected behavior

I'd expect the z0() call to eventually evaluate to 8 instead of throwing an exception.

Known workarounds

The problem occurs when

1. You are in a task { ... }, and
2. You are in a binding let v = ... where the v becomes a state variable of the task state machine, because it is used after an asynchronous point
3. The right-hand-side of a binding uses either a while or try or for or a construct such as Array.map that is inlined to produce one of these

In short, the most common cause appears to be the use of the inlined Array.map inside task { ... }. For this case, you can either rewrite your code to avoid the use of Array.map, e.g. using Array.mapi, or define and use a non-inlined Array.map as follows:

module Array =
    let map f x = FSharp.Collections.Array.map f x
    
let f arr =
    task {
        let w = arr |> Array.map (fun w -> w + 1) |> Array.head // This uses the new non-inlined Array.map
        do!  System.Threading.Tasks.Task.Yield()
        return w + 3
    }

(f [| 1 |]).Result

Alternatively using Array.mapi:

let f arr =
    task {
        let w = arr |> Array.mapi (fun _ w -> w + 1) |> Array.head 
        do!  System.Threading.Tasks.Task.Yield()
        return w + 3
    }

(f [| 1 |]).Result

Other workarounds are shown above

[NinoFloris]

@sasmithjr Thanks for opening this issue, I can repro it.

@dsyme in a normal project this repro causes an AccessViolationException which usually points to invalid IL, the dynamic case seems to suffer from the same underlying issue though just manifesting as an NRE instead.

An interplay of resumable code and calls to a function with InlineIfLambda arguments before the first yield seems to be the trigger (moving it after a resumption point indeed avoids the issue).

[dsyme]

Thank you for the bug report, we will prioritise a fix for this.

An interplay of resumable code and calls to a function with InlineIfLambda arguments before the first yield seems to be the trigger (moving it after a resumption point indeed avoids the issue).

It could also be the presence of an inlined loop implied by Array.map. Do you happen to have other failing examples for InlineIfLambda?

[forki]

we see similar things. Sometimes NRE and sometime System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

[forki]

It could also be the presence of an inlined loop implied by Array.map

all issues that I saw today were with Array.map somewhere in that code

[dsyme]

The fix is in. I wrote up some workarounds that can be used systematically until dev 17.1 and its associated update to .NET SDK and FCS are out

[cmeeren]

Happy to hear this is fixed! Anyone know when it'll be out - days, weeks, months? I have some (non-critical) work that depends on this (through Giraffe).

[dsyme]

Happy to hear this is fixed! Anyone know when it'll be out - days, weeks, months? I have some (non-critical) work that depends on this (through Giraffe).

I'd imagine it's in preview within weeks, though @KevinRansom and @brettfo may know for sure