Fsharp: IncrementalBuild object has already been disposed!

[vasily-kirichenko]

---------------------------
Assertion Failed: Abort=Quit, Retry=Debug, Ignore=Continue
---------------------------
IncrementalBuild object has already been disposed!



   at Microsoft.FSharp.Compiler.IncrementalBuilder.assertNotDisposed()

   at Microsoft.FSharp.Compiler.IncrementalBuilder.StampFileNameTask[a,b](TimeStampCache cache, a _ctok, range _m, String filename, b _isLastCompiland)

   at <StartupCode$FSharp-LanguageService-Compiler>[email protected](TimeStampCache cache, CompilationThreadToken _ctok, Tuple`3 tupledArg)

   at [email protected](DateTime acc, Int32 slot)

   at [email protected](TState s, FSharpList`1 xs)

   at Microsoft.FSharp.Compiler.IncrementalBuilder.GetLogicalTimeStampForProject(TimeStampCache cache, CompilationThreadToken ctok)

   at Microsoft.FSharp.Compiler.SourceCodeServices.BackgroundCompiler.TryGetLogicalTimeStampForProject(TimeStampCache cache, CompilationThreadToken ctok, FSharpProjectOptions options)

   at <StartupCode$FSharp-LanguageService-Compiler>.$[e-mail]-FSharp-Compiler-CompileOps-IProjectReference-TryGetLogicalTimeStamp(TimeStampCache , CompilationThreadToken )

   at Microsoft.FSharp.Compiler.CompileOps.TimeStampCache.GetProjectReferenceTimeStamp(IProjectReference pr, CompilationThreadToken ctok)

   at <StartupCode$FSharp-LanguageService-Compiler>[email protected](TimeStampCache cache, CompilationThreadToken ctok)

   at [email protected](T acc, Int32 slot)

   at [email protected](TState s, FSharpList`1 xs)

   at [e-mail](FSharpOption`1 optSlot, VectorBuildRule ve, T acc)

   at [e-mail](FSharpOption`1 optSlot, VectorBuildRule ve, T acc)

   at [email protected](Unit unitVar)

   at Microsoft.FSh[e-mail](CancellationToken ct)

   at Microsoft.FS[e-mail](CancellationToken ct)

   at Microsoft.FSharp.Compiler.AbstractIL.Internal.Library.CancellableModule.runWithoutCancellation[a](Cancellable`1 comp)

   at <StartupCode$FSharp-LanguageService-Compiler>[email protected](CompilationThreadToken ctok)

   at <StartupCode$FSharp-LanguageService-Compiler>[email protected](FSharpOption`1 _arg2)

   at [email protected](a a)

   at <StartupCode$FSharp-Core>[email protected](FSharpFunc`2 action)

   at Microsoft.FSharp.Control.Trampoline.ExecuteAction(FSharpFunc`2 firstAction)

   at Microsoft.FSharp.Control.TrampolineHolder.Protect(FSharpFunc`2 firstAction)

   at <StartupCode$FSharp-Core>[email protected](Object state, Boolean timedOut)

   at System.Threading._ThreadPoolWaitOrTimerCallback.WaitOrTimerCallback_Context(Object state, Boolean timedOut)

   at System.Threading._ThreadPoolWaitOrTimerCallback.WaitOrTimerCallback_Context_t(Object state)

   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)

   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)

   at System.Threading._ThreadPoolWaitOrTimerCallback.PerformWaitOrTimerCallback(Object state, Boolean timedOut)


---------------------------
Abort   Retry   Ignore   
---------------------------

[vasily-kirichenko]

It pops up endlessly, VS is unusable.

[dsyme]

I'll review the last PR for Cancellable. Do you have any details on the solution you're loading?

[dsyme]

@vasily-kirichenko I've reviewed the changes and I don't see the mistake yet https://github.com/Microsoft/visualfsharp/pull/2460/files.

This call should have incremented the usage count. I don't think there's a mistake in the cancellable implementation of tryFinally or bind, so I presume the problem is elsewhere - something else decrementing the usage count more than once.

Is it a reliable repro? Was the above the callstack of the first assert?

thanks

[dsyme]

Ugh I'm stumped.

Some things we could do

• Put an assert in getOrCreateBuilder that checks that if we get it from the incrementalBuildersCache then the thing is not already disposed (there should never be disposed entries accessible from that store). But that won't do anything more than shift the assert one step earlier (I presume

• Put some tracing data in IncrementaBuilder that records the history of callstacks that have done increment/decrement operations. In debug mode we could store the last 50-100 callstacks in each builder.

If this is happening all the time (reliable repro) then surely there was a basic mistake in the last PR of mine. If it's happening only very occasionally then it was probably something much more subtle, perhaps a pre-existing problem, and we may need to use the second technique above to find the problem.

[KevinRansom]

@dsyme it is not hard to repro. But I think the exception happened before on debug builds. I will go back a day or two, and try it out. We just have a different stacktrace now.

[dsyme]

@KevinRansom Thanks. We need to get to the bottom of it as with type providers it's quite a severe problem (otherwise the problem is pretty harmless). Perhaps we should start running some VS tests in the debug CI build.

I think @vasily-kirichenko may have been regularly using debug builds

[KevinRansom]

@dsyme looking at it :-)

[KevinRansom]

I was correct, Huh!!! how often is that the case ?

:-)
Here without the cancellable callstack.

[KevinRansom]

And this is the stacktrace with the cancellable on the callstack: Note the ErrorLogger+InternalError for both.

[dsyme]

@KevinRansom That's a different throw/assert - it's in TcImports (one of only a handful of disposable objects in the compiler) rather than IncrementalBuilder. But it may be related still. What's the repro to get those stacktraces? thanks

[KevinRansom]

easy install the debug .vsix. Open visualfsharp sln and open a .fs file, click about a bit and it will go bang.

[dsyme]

easy install the debug .vsix. Open visualfsharp sln and open a .fs file, click about a bit and it will go bang.

@KevinRansom Is this problem gone after #2479 ? Thanks.

@vasily-kirichenko Please let me know if the "IncrementalBuild object has already been disposed!" problem recurs (which I think is different to the problem reported by @KevinRansom though there may be similar underlying causes)

[vasily-kirichenko]

@dsyme I've not seen "already been disposed" so far, but a new one popped up - "FSharp.Core was not delayed" (not precisely this text).

[dsyme]

@dsyme I've not seen "already been disposed" so far, but a new one popped up - "FSharp.Core was not delayed" (not precisely this text).

If you could capture any possible information when that happens that would be great

[cartermp]

@vasily-kirichenko Are you still seeing this?

[vasily-kirichenko]

No.

[cartermp]

😄