Debugging StackOverflowException finds me in FSharp.Core.ni.dll and only disassembly, no user code

[abelbraaksma]

When my code hits a StackOverflowException and I try to debug it, instead of seeing a stack-trace of user-code or .NET library code (Framework Source Stepping is enabled), I find myself in an assembly window with a large list of stack points in the Call Stack window, with none of the entries leading to user code:

Oh, and it took VS about 10 minutes to build up the breakpoint and show the disassembly, until that time it froze. I run a debug build (see also settings below). With a "normal" SO, it is almost immediate.

Repro steps

When I try to repro this with a non-tailrecursive function in the same project, I just get into the normal debugging experience with the compiler pointing at the proper location.

Expected behavior

Should get a debugging experience where the debugger knows the correct location. Should not see FSharp.Core.ni.dll in the the call stack.

Related information

I am seeing this with a project that still has FSharp.Core 4.0.0.1 linked. However I doubt that lies at the root of this.

I'm not sure this is a bug, I'm merely curious what kind of code could hit this. Perhaps inlined recursive code (I don't think that's even possible, I would get a "is not bound to an optimization environment" error) or normal recursive code that uses inlines? But when I try to repro an SO with that, the debugger usually points me at the nearest call-site that isn't inlined.

Is this "expected behavior"? If so, perhaps we can improve the experience here? Should the debugger link to the *.ni.dll files? In my opinion, it shouldn't.

[dsyme]

Whatever it is I don't think it's a bug in F# specifically.

[abelbraaksma]

@dsyme, I don't know. The screenshot is not familiar I take it? Is it possible that somehow the F# debugger links to the binary cache of the *.ni.dll files? Sounds to me that such calls ought to be redirected to the .NET assemblies, especially when in debug build, right?

[abelbraaksma]

I just thought that perhaps symbols weren't loaded (there were some errors that PDB's could not be found). Now, on the breakpoint, it does show something (it's in _NtWaitForSingleObject@12). And the top of the stack shows:

I'm unsure what the phrase "Frames below may be incorrect and/or missing, native debugger attempting to walk managed call stack" attempts to explain. I do know that the FSharp.Core.dll symbols have been loaded, so the fact that it cannot find the symbols for FSharp.Core.ni.dll suggests to me that there isn't an exact match. Which in turn begs the question: how can I have a different version than the supported versions?

After emptying the symbol cache, forcing a reload of the symbols upon start of debugging, I clearly saw it downloading symbols for FSharp.Core.dll. Also, I have the proper bindingRedirect (afaik), but still it can't find symbols.

Finally, not the whole stack is shown. At the bottom it ends with the same lines as in the first screenshot. This may be by design (it already takes ages to load this stack), but this way I never get to the part that is in user code, causing the SO.

[dsyme]

@dsyme, I don't know. The screenshot is not familiar I take it? Is it possible that somehow the F# debugger links to the binary cache of the *.ni.dll files? Sounds to me that such calls ought to be redirected to the .NET assemblies, especially when in debug build, right?

There is no "F# debugger" - it's just the VS/.NET debugger using F#-generated symbols. The *.ni.dll are the native images produced by NGEN. Anyway, stack overflow is a tricky case for the debugger and AFAIK "things can go wrong".

It could be that FSharp.Core symbols aren't being uploaded correctly, but I don't think that would have anything to do with stack overflow.

[abelbraaksma]

@dsyme, Indeed, these are the native images, but they don't get the symbols for some odd reason. I wasn't aware that there wasn't an "F# debugger", but it makes sense. I've tried a different approach to find the culprit, I just ran a profiler and investigate the hot path. It looks like this, and then thousands more nested:

Then it didn't take too long to find what created this. I had a Seq.foldWhile implementation like as follows:

module Seq =
    /// Folds while predicate is true, returns state when predicate is false, or end of sequence is reached
    let foldWhile<'T,'State> predicate folder (state:'State) (source : seq<'T>)  =
        use e = source.GetEnumerator()
        let f = OptimizedClosures.FSharpFunc<_,_,_>.Adapt(folder)
        let mutable state = state
        while e.MoveNext() && predicate state  do
            state <- f.Invoke(state, e.Current)
        state

I don't understand why this causes the compiler to "get lost", but the stack-steps are very small and the stack got very deep (why, I don't know, that's a matter of debugging my code).

What is surprising, however, is that creating a "small repro" doesn't succeed:

    // no stackoverflow
    [1 .. 5000000]
    |> Seq.foldWhile (fun x -> x < 5000000) (fun x y -> x + y) 0
    |> printfn "%A"

The sequence in question is only 5000 items long. My not-so-educated guess is that I run into a non-tailrecursive situation while debugging, but the same exception also occurs when in Release mode. However, I don't see anything in the code above that wouldn't make it tail-recursive (in fact, it isn't recursive at all).

I'm aware that now this starts to be become more like a question that would be suited more for the SO site than here. Still, I'm quite surprised about the StackOverflowException and even more so since I cannot yet repro it.

[dsyme]

I don't understand why this causes the compiler to "get lost", but the stack-steps are very small and the stack got very deep (why, I don't know, that's a matter of debugging my code).

I'm curious, what sequence were you folding over?

[dsyme]

I'll close this, though I'm curious what went wrong with the foldWhile above

[abelbraaksma]

@dsyme I've done more research, removed some inlined code to see better traces, and it now looks like it's overflowing on Seq.length, from a sequence created with Seq.append. I've read some reports that it wasn't always safe to use that. I'm gong to try to make a repro.

Rewriting the foldWhile with only library functions gave no discernable effect. Making sure that particular loop was only 1 deep neither, which led me to Seq.append, which caused the stacktrace dumped above.

Question is whether it's a known possibilities to run into StackOverflowException with only using library functions on sequences

[abelbraaksma]

@dsyme, thanks for taking the time to look into this, as it turns out, I had some code lurking around that was waiting to blow things up. It was difficult to diagnose because I didn't have a stacktrace, but the good news is any of my hasty assumptions turned out wrong:

• Seq.foldWhile turns out to be sound, it didn't raise the SOE
• Seq.length or any other Core library function, while it triggered the exception, wasn't at fault either
• Indirectly, Seq.append was, but only because of a bad function

I'm curious, what sequence were you folding over?

In the code above, the sequences were flat (just normal seq sequences or lists), but I had a Result.unwindSeq which task it was to return Fail if any of the items were failing. The definition was as follows:

/// Takes a sequence of Results and returns a Result of a sequence. 
/// If one item in the sequence is Fail, then the function returns the first Fail it finds, rest is not evaluated.
/// TODO: rewrite without Seq.append, or at least test this performance..., replace where possible with unwindList, it's probably faster
let unwindSeq (sourceSeq: #seq<Result<_, _>>) =
    sourceSeq
    |> Seq.fold (fun state res -> 
        match state with
        | Fail e -> Fail e
        | Success innerResult ->
            match res with
            | Success suc -> 
                (Seq.singleton suc) 
                |> Seq.append innerResult
                |> Success
            | Fail e -> Fail e) (Success Seq.empty)

My own comment there said "rest is not evaluated.", but that's not true as this uses Seq.fold. Either way, the really bad thing here is obviously Seq.singleton x |> Seq.append current.

While I still don't see how this ends up recursive, it is clearly bad code, because of the expensive concat operation in the heart of the loop.

I have no good solution for unwinding a sequence of Results into a Result of a seq without iterating over the sequence itself, but lifting the fold and preventing the forced iteration fixed the SOE from firing.

[abelbraaksma]

Here's a short version of the above using F# 4.1's Result type:

module Result =
    let unwindSeq (sourceSeq: #seq<Result<_, _>>) =
        sourceSeq
        |> Seq.fold (fun state res -> 
            match state with
            | Error e -> Error e
            | Ok innerResult ->
                match res with
                | Ok suc -> 
                    (Seq.singleton suc) 
                    |> Seq.append innerResult
                    |> Ok
                | Error e -> Error e) (Ok Seq.empty)

I don't think this should raise a StackOverflowException, though it is badly performing code, as mentioned in the previous post. To blow it up, this suffices:

Seq.init 1000000 Result.Ok
|> Result.unwindSeq
|> printfn "%A" 

[abelbraaksma]

I went from lib bug, to my bug, back to lib bug... Sorry for the confusion, I'll report again on a clean thread.

Now that we know better what's going on, I'll close this thread (I assume you would agree, @dsyme) and I started a new one in #5139 with a simple repro, in case it is indeed considered a bug in FSharp.Core, as was suggested on StackOverflow.com.