Closed nosami closed 6 years ago
@nosami Which compiler is being used to compile FCS in this case? It could be we need to use an updated one
@dsyme: fsharp/fsharp 4.1.33
@dsyme I have the same problem on Mono 5.4.1.6 on macOS.
@auduchinok - I don't know if patching Mono is an option for you, but this patch works around the issue https://gist.github.com/lambdageek/1e5f8904daa2493093b825b32144d472#file-0001-Print-some-info-if-we-are-asked-to-look-up-a-method--patch
So that reference to https://github.com/mono/mono/issues/8655 - it means we can't compile our Xamarin projects; this is more severe than just "don't debug the compiler." I'm trying the mdb workaround from the other bug.
I don't remember the details very well but it had to do with getting a different number of rows between the method table in a .dll and the MethodDebugInformation table in the PPDB. Specifically if you have
type ISomeInterface =
abstract member SomeProperty: string with get
you'll get a row for it in the .dll method table but no row in the PPDB MethodDebugInformation table.
Here's what I wrote in Slack in january (I'm afraid I no longer understand what I meant):
that code in ilwrite.fs seems right - we want get_SomeProperty to generate an entry in the PPDB MethodDebugInformation table since it generates an entry in the Method table in the assembly. "MethodDebugInformation table is either empty (missing) or has exactly as many rows as MethodDef table" (https://github.com/dotnet/corefx/blob/master/src/System.Reflection.Metadata/specs/PortablePdb-Metadata.md#methoddebuginformation-table-0x31).
(I think this about this code) https://github.com/Microsoft/visualfsharp/blob/7aa7cd3734dcf5e9ff9a29cd2f5814be301f308b/src/absil/ilwrite.fs#L2526-L2536
@nosami Do you recall if we tried generating a ppdb using an F# running on top of .NET Core and then consuming the ppdb by debugging using Mono. That would help narrow down whether the problem is in fsharp itself or in some library that comes with the runtime.
@lambdageek No, I haven't tried that. I've been assuming the whole time that the issue was in the compiler.
I see. I don't know the fsharp code well enough to tell what's in the compiler and what's in some library - I wasn't sure if we still needed to track down the misbehaving component.
I believe this is a bug in the fsharp compiler. And I need to look at this.
@nosami, Can you provide the .dll and .portable pdb that demonstrates the issue. Also, let me know which version of the compiler you were using? Was it a mono compiler or one from MS?
If it was mono, could you point me to the repo, and let me know which commit, the mono compiler was built from.
Thanks
If the mono compiler comes from here: https://github.com/mono/linux-packaging-fsharp
Then it is about 5 months out of date, and doesn't include this portable pdb fix from @brettfo:
Which I believe could even have fixed the problem you are seeing.
I was using the Mono F# compiler built from fsharp/fsharp from here which doesn't contain @brettfo's fix.
The latest tag (4.1.34) doesn't contain the fix either, the repo looks to be very outdated.
I'll try cherry-picking the fix in and see if it makes things work. Thanks!
My pleasure.
I built fsharp/fsharp from master which is currently 18 days old and contains the fix from @brettfo.
I compiled VSMac with portable pdb symbols and hit the same error.
2018-07-24 10:44:21.469 mono64[65799:2091868] error: * Assertion at metadata.c:1117, condition `idx < t->rows' not met
Stacktrace:
at <unknown> <0xffffffff>
at MonoDevelop.FSharp.signatureHelp.isFSharp (Microsoft.FSharp.Compiler.SourceCodeServices.FSharpMemberOrFunctionOrValue) [0x00047] in /Users/jason/src/monodevelop/main/external/fsharpbinding/MonoDevelop.FSharpBinding/TypeSignatureHelp.fs:103
at MonoDevelop.FSharp.signatureHelp.getFunctionInformation (Microsoft.FSharp.Compiler.SourceCodeServices.FSharpSymbolUse) [0x00058] in /Users/jason/src/monodevelop/main/external/fsharpbinding/MonoDevelop.FSharpBinding/TypeSignatureHelp.fs:118
at MonoDevelop.FSharp.signatureHelp/funs@146.Invoke (Microsoft.FSharp.Compiler.SourceCodeServices.FSharpSymbolUse) [0x00000] in /Users/jason/src/monodevelop/main/external/fsharpbinding/MonoDevelop.FSharpBinding/TypeSignatureHelp.fs:146
at Microsoft.FSharp.Primitives.Basics.List.chooseToFreshConsTail<a_REF, b_REF> (Microsoft.FSharp.Collections.FSharpList`1<a_REF>,Microsoft.FSharp.Core.FSharpFunc`2<b_REF, Microsoft.FSharp.Core.FSharpOption`1<a_REF>>,Microsoft.FSharp.Collections.FSharpList`1<b_REF>) [0x0001a] in <5a7203e1904cf4daa7450383e103725a>:0
at Microsoft.FSharp.Primitives.Basics.List.choose<T_REF, TResult_REF> (Microsoft.FSharp.Core.FSharpFunc`2<T_REF, Microsoft.FSharp.Core.FSharpOption`1<TResult_REF>>,Microsoft.FSharp.Collections.FSharpList`1<T_REF>) [0x0003d] in <5a7203e1904cf4daa7450383e103725a>:0
Mono is crashing as soon as this line is hit (but only when debugging with ppdb) https://github.com/mono/monodevelop/blob/master/main/external/fsharpbinding/MonoDevelop.FSharpBinding/TypeSignatureHelp.fs#L103
I've attached a zip file containing the assembly being debugged and the pdb file that was generated. FSharpBinding.zip
I ran:
nuget install mdv -Version 1.0.0-beta1-62016-01 -Source https://dotnet.
myget.org/F/metadata-tools/api/v3/index.json
mono mdv.1.0.0-beta1-62016-01/tools/mdv.exe FSharpBinding.dll > dll.txt
mono mdv.1.0.0-beta1-62016-01/tools/mdv.exe FSharpBinding.pdb > pdb.txt
then compared the number of rows in the Method (0x06, 0x1C)
table in dll.txt vs MethodDebugInformation (index: 0x31, size: 15472)
from pdb.txt
There are 0xf1f rows in the Method
table, but only 0xf1c rows in MethodDebugInformation
.
@nosami what version of Mono are you running? Do you have a full stack trace? - it should have spit out a bit more info about what it was looking for, but maybe it went down a different codepath...
@lambdageek I'm not sure which version of Mono it was (I switch versions frequently), but it didn't have your recent patch to print out the debug information. Let me get a newer version and try the same thing again.
I also tried to make a smaller repro that used the same code (some FCS code that inspected the same FSharpMemberFunctionOrValue that made VSMac crash) - but I couldn't make it fail.
Using Mono 5.17.0.446 from today.
2018-07-26 08:46:49.890 mono64[19410:5799176] error: Method idx 3869 is greater than number of rows (3867) in PPDB MethodDebugInformation table, for method MonoDevelop.FSharp.Seq:tryHead<a_REF> in '/Users/jason/src/monodevelop/main/build/AddIns/FSharpBinding/FSharpBinding.pdb'. Likely a malformed PDB file.
Stacktrace:
at <unknown> <0xffffffff>
at MonoDevelop.FSharp.signatureHelp.isFSharp (Microsoft.FSharp.Compiler.SourceCodeServices.FSharpMemberOrFunctionOrValue) [0x00047] in /Users/jason/src/monodevelop/main/external/fsharpbinding/MonoDevelop.FSharpBinding/TypeSignatureHelp.fs:103
at MonoDevelop.FSharp.signatureHelp.getFunctionInformation (Microsoft.FSharp.Compiler.SourceCodeServices.FSharpSymbolUse) [0x00058] in /Users/jason/src/monodevelop/main/external/fsharpbinding/MonoDevelop.FSharpBinding/TypeSignatureHelp.fs:118
at MonoDevelop.FSharp.signatureHelp/funs@146.Invoke (Microsoft.FSharp.Compiler.SourceCodeServices.FSharpSymbolUse) [0x00000] in /Users/jason/src/monodevelop/main/external/fsharpbinding/MonoDevelop.FSharpBinding/TypeSignatureHelp.fs:146
at Microsoft.FSharp.Primitives.Basics.List.chooseToFreshConsTail<a_REF, b_REF> (Microsoft.FSharp.Collections.FSharpList`1<a_REF>,Microsoft.FSharp.Core.FSharpFunc`2<b_REF, Microsoft.FSharp.Core.FSharpOption`1<a_REF>>,Microsoft.FSharp.Collections.FSharpList`1<b_REF>) [0x0001a] in <5a7203e1904cf4daa7450383e103725a>:0
at Microsoft.FSharp.Primitives.Basics.List.choose<T_REF, TResult_REF> (Microsoft.FSharp.Core.FSharpFunc`2<T_REF, Microsoft.FSharp.Core.FSharpOption`1<TResult_REF>>,Microsoft.FSharp.Collections.FSharpList`1<T_REF>) [0x0003d] in <5a7203e1904cf4daa7450383e103725a>:0
at Microsoft.FSharp.Collections.ListModule.Choose<T_REF, TResult_REF> (Microsoft.FSharp.Core.FSharpFunc`2<T_REF, Microsoft.FSharp.Core.FSharpOption`1<TResult_REF>>,Microsoft.FSharp.Collections.FSharpList`1<T_REF>) [0x00002] in <5a7203e1904cf4daa7450383e103725a>:0
at MonoDevelop.FSharp.signatureHelp/displaySignatures@136.Invoke (System.Tuple`2<MonoDevelop.FSharp.ParseAndCheckResults, MonoDevelop.FSharp.FSharpParsedDocument>) [0x0009f] in /Users/jason/src/monodevelop/main/external/fsharpbinding/MonoDevelop.FSharpBinding/TypeSignatureHelp.fs:144
at Microsoft.FSharp.Core.OptionModule.Iterate<T_REF> (Microsoft.FSharp.Core.FSharpFunc`2<T_REF, Microsoft.FSharp.Core.Unit>,Microsoft.FSharp.Core.FSharpOption`1<T_REF>) [0x0000c] in <5a7203e1904cf4daa7450383e103725a>:0
at MonoDevelop.FSharp.signatureHelp.displaySignatures (MonoDevelop.Ide.Editor.DocumentContext,MonoDevelop.Ide.Editor.TextEditor,bool) [0x00063] in /Users/jason/src/monodevelop/main/external/fsharpbinding/MonoDevelop.FSharpBinding/TypeSignatureHelp.fs:136
at <StartupCode$FSharpBinding>.$TypeSignatureHelp/displaySignatures@211-9<a_REF>.Invoke (a_REF) [0x00002] in /Users/jason/src/monodevelop/main/external/fsharpbinding/MonoDevelop.FSharpBinding/TypeSignatureHelp.fs:211
at Microsoft.FSharp.Control.CommonExtensions/SubscribeToObservable@1741<T_REF>.System-IObserver`1-OnNext (T_REF) [0x00007] in <5a7203e1904cf4daa7450383e103725a>:0
at System.Reactive.SafeObserver`1<TSource_REF>.OnNext (TSource_REF) [0x00009] in <ea9763e1f97043e39575e99208fac035>:0
at System.Reactive.Linq.ObservableImpl.Throttle`1/_<TSource_REF>.Propagate (System.Reactive.Concurrency.IScheduler,ulong) [0x00030] in <375ab67d885b4efaa5ac288551dbbef1>:0
at System.Reactive.Concurrency.DefaultScheduler/<>c__DisplayClass6_0`1<ulong>.<Schedule>b__0 (object) [0x00025] in <ea9763e1f97043e39575e99208fac035>:0
at System.Reactive.Concurrency.DefaultConcurrencyAbstractionLayer/Timer.Tick (object) [0x00007] in <ea9763e1f97043e39575e99208fac035>:0
at System.Threading.Timer/Scheduler.TimerCB (object) [0x00007] in /Users/builder/jenkins/workspace/build-package-osx-mono/master/external/bockbuild/builds/mono-x64/mcs/class/corlib/System.Threading/Timer.cs:405
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem () [0x00015] in /Users/builder/jenkins/workspace/build-package-osx-mono/master/external/bockbuild/builds/mono-x64/mcs/class/referencesource/mscorlib/system/threading/threadpool.cs:1281
at System.Threading.ThreadPoolWorkQueue.Dispatch () [0x00074] in /Users/builder/jenkins/workspace/build-package-osx-mono/master/external/bockbuild/builds/mono-x64/mcs/class/referencesource/mscorlib/system/threading/threadpool.cs:858
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback () [0x00000] in /Users/builder/jenkins/workspace/build-package-osx-mono/master/external/bockbuild/builds/mono-x64/mcs/class/referencesource/mscorlib/system/threading/threadpool.cs:1213
at (wrapper runtime-invoke) <Module>.runtime_invoke_bool (object,intptr,intptr,intptr) [0x0001f] in <5606a5d5605d4bbe91fc983091c9c83d>:0
2018-07-26 08:46:49.891 mono64[19410:5799176] Memory around native instruction pointer (0x7fff63c7db6e):
This is the function that is complaining about (I didn't realise that VSMac had it's own version of Seq.tryHead)
module Seq =
let tryHead items =
if Seq.isEmpty items then None else Some (Seq.head items)
There doesn't seem to be anything wrong with the method debug information for this particular function. The issue seems to be that this is the last function to end up in the assembly (the first in the source code).
open Microsoft.FSharp.Compiler.SourceCodeServices
module Seq =
let tryHead items =
if Seq.isEmpty items then None else Some (Seq.head items)
let checker = FSharpChecker.Create()
let parseAndTypeCheckSingleFile (file, input) =
// Get context representing a stand-alone (script) file
let projOptions, errors =
checker.GetProjectOptionsFromScript(file, input)
|> Async.RunSynchronously
let parseFileResults, checkFileResults =
checker.ParseAndCheckFileInProject(file, 0, input, projOptions)
|> Async.RunSynchronously
// Wait until type checking succeeds (or 100 attempts)
match checkFileResults with
| FSharpCheckFileAnswer.Succeeded(res) -> parseFileResults, res
| res -> failwithf "Parsing did not finish... (%A)" res
let typeDefinitionSafe (t:FSharpType) =
match t.HasTypeDefinition with
| true -> Some t.TypeDefinition
| false -> None
let isFSharp (mfv: FSharpMemberOrFunctionOrValue) =
let baseType =
match mfv.IsOverrideOrExplicitInterfaceImplementation, mfv.IsExplicitInterfaceImplementation with
| true, false ->
mfv.DeclaringEntity
|> Option.bind(fun ent -> ent.BaseType)
|> Option.bind typeDefinitionSafe
| true, true ->
mfv.ImplementedAbstractSignatures
|> Seq.tryHead
|> Option.map(fun s -> s.DeclaringType)
|> Option.bind typeDefinitionSafe
| _ -> mfv.DeclaringEntity
baseType
|> Option.map(fun ent -> ent.IsFSharp)
|> Option.defaultValue true
[<EntryPoint>]
let main argv =
// Create an interactive checker instance
let input2 =
"""
module ImplementingInterfaces =
/// This is a type that implements IDisposable.
type ReadFile() =
let file = new System.IO.StreamReader("readme.txt")
member this.ReadLine() = file.ReadLine()
// This is the implementation of IDisposable members.
interface System.IDisposable with
member this.Dispose() = file.Close()
"""
let parseFileResults, checkFileResults =
parseAndTypeCheckSingleFile("test.fsx", input2)
let partialAssemblySignature = checkFileResults.PartialAssemblySignature
let moduleEntity = partialAssemblySignature.Entities.[0].NestedEntities.[0].NestedEntities.[0]
let dispose = moduleEntity.MembersFunctionsAndValues.[1]
let e =
dispose.ImplementedAbstractSignatures
|> Seq.tryHead
|> Option.map(fun s -> s.DeclaringType)
|> Option.bind typeDefinitionSafe
let isfs = isFSharp dispose
printfn "%b" isfs
0 // return an integer exit code
This is my attempt at a repro which I would have expected to fail in the same way as VSMac, but doesn't :(
If it's any use, I'm experiencing a similar looking issue (not sure whether or not it's actually related). I'm using C# to write an Expecto test suite that calls various other things, and here's a full VSfM log with a stack trace (with some names censored):
Loaded assembly: /Users/jwostenberg/Code/Mobile/Apps/ViewModelTests/bin/Debug/ViewModelTests.exe
Loaded assembly: /Users/jwostenberg/Code/Mobile/Apps/ViewModelTests/bin/Debug/Xamarin.Forms.Core.UnitTests.dll [External]
Loaded assembly: /Users/jwostenberg/Code/Mobile/Apps/ViewModelTests/bin/Debug/netstandard.dll [External]
Loaded assembly: /Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/gac/System/4.0.0.0__b77a5c561934e089/System.dll [External]
Loaded assembly: /Users/jwostenberg/Code/Mobile/Apps/ViewModelTests/bin/Debug/Xamarin.Forms.Core.dll [External]
Loaded assembly: /Users/jwostenberg/Code/Mobile/Apps/ViewModelTests/bin/Debug/AlgoCP.dll
Loaded assembly: /Users/jwostenberg/Code/Mobile/Apps/ViewModelTests/bin/Debug/*****.dll
Loaded assembly: /Users/jwostenberg/Code/Mobile/Apps/ViewModelTests/bin/Debug/*****.dll
Loaded assembly: /Users/jwostenberg/Code/Mobile/Apps/ViewModelTests/bin/Debug/*****.dll
Loaded assembly: /Users/jwostenberg/Code/Mobile/Apps/ViewModelTests/bin/Debug/Stateless.dll [External]
Loaded assembly: /Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/gac/System.Xml/4.0.0.0__b77a5c561934e089/System.Xml.dll [External]
Loaded assembly: /Users/jwostenberg/Code/Mobile/Apps/ViewModelTests/bin/Debug/FSharp.Core.dll [External]
Loaded assembly: /Users/jwostenberg/Code/Mobile/Apps/ViewModelTests/bin/Debug/Expecto.dll [External]
Loaded assembly: /Users/jwostenberg/Code/Mobile/Apps/ViewModelTests/bin/Debug/Xamarin.Forms.Xaml.UnitTests.dll [External]
Loaded assembly: /Users/jwostenberg/Code/Mobile/Apps/ViewModelTests/bin/Debug/SQLCipher.dll
Loaded assembly: /Users/jwostenberg/Code/Mobile/Apps/ViewModelTests/bin/Debug/Xamarin.Forms.Xaml.dll [External]
Loaded assembly: /Users/jwostenberg/Code/Mobile/Apps/ViewModelTests/bin/Debug/System.Runtime.dll [External]
Loaded assembly: /Users/jwostenberg/Code/Mobile/Apps/ViewModelTests/bin/Debug/Xamarin.Forms.Platform.dll [External]
Loaded assembly: /Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/gac/System.Core/4.0.0.0__b77a5c561934e089/System.Core.dll [External]
Loaded assembly: /Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/gac/System.Configuration/4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll [External]
Loaded assembly: /Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/gac/Mono.Security/4.0.0.0__0738eb9f132ed756/Mono.Security.dll [External]
App.App()
Loaded assembly: /Users/jwostenberg/Code/Mobile/Apps/ViewModelTests/bin/Debug/System.Reflection.dll [External]
Loaded assembly: /Users/jwostenberg/Code/Mobile/Apps/ViewModelTests/bin/Debug/System.Xml.ReaderWriter.dll [External]
Loaded assembly: /Users/jwostenberg/Code/Mobile/Apps/ViewModelTests/bin/Debug/System.ComponentModel.dll [External]
Loaded assembly: /Users/jwostenberg/Code/Mobile/Apps/ViewModelTests/bin/Debug/System.Resources.ResourceManager.dll [External]
Loaded assembly: /Users/jwostenberg/Code/Mobile/Apps/ViewModelTests/bin/Debug/Plugin.Fingerprint.Abstractions.dll [External]
Loaded assembly: /Users/jwostenberg/Code/Mobile/Apps/ViewModelTests/bin/Debug/System.ObjectModel.dll [External]
Loaded assembly: /Users/jwostenberg/Code/Mobile/Apps/ViewModelTests/bin/Debug/CrashlyticsKit.dll [External]
Loaded assembly: /Users/jwostenberg/Code/Mobile/Apps/ViewModelTests/bin/Debug/FabricSdk.dll [External]
Version is "TestVersion"/"TestBuild"
Build "3d54f97" at 4783381
UsernamePasswordEntryView.UsernamePasswordEntryView()
*** No such file: UI/Login/Assets/UserIcon_Input.png
*** No such file: UI/Login/Assets/UserIcon_NoInput.png
*** No such file: UI/Login/Assets/UserIcon_Failure.png
*** No such file: UI/Login/Assets/PasswordIcon_OnInput.png
*** No such file: UI/Login/Assets/PasswordIcon_NoInput.png
*** No such file: UI/Login/Assets/PasswordIcon_Failure.png
Confirm.Confirm() in thread 1
Loaded assembly: /Users/jwostenberg/Code/Mobile/Apps/ViewModelTests/bin/Debug/System.ValueTuple.dll [External]
Thread started: #2
*** No such file: UI/Login/Assets/Logon_Background.png
Loaded assembly: /Users/jwostenberg/Code/Mobile/Apps/ViewModelTests/bin/Debug/SQLite.Net.dll [External]
Loaded assembly: /Users/jwostenberg/Code/Mobile/Apps/ViewModelTests/bin/Debug/System.Collections.dll [External]
Loaded assembly: /Users/jwostenberg/Code/Mobile/Apps/ViewModelTests/bin/Debug/Argu.dll [External]
Loaded assembly: /Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/gac/System.Numerics/4.0.0.0__b77a5c561934e089/System.Numerics.dll [External]
Loaded assembly: /Users/jwostenberg/Code/Mobile/Apps/ViewModelTests/bin/Debug/en/FSharp.Core.resources.dll [External]
* Assertion at metadata.c:1117, condition `idx < t->rows' not met
Stacktrace:
at <unknown> <0xffffffff>
at (wrapper managed-to-native) object.__icall_wrapper_mono_generic_class_init (intptr) <0x00012>
at Expecto.ANSIOutputWriter.get_buffer () [0x00000] in <5b48938b21908b47a74503838b93485b>:0
at Expecto.ANSIOutputWriter.textToOutput (Microsoft.FSharp.Collections.FSharpList`1<System.Tuple`2<string, System.ConsoleColor>>) [0x00000] in C:\Users\Ant\src\expecto\Expecto\Progress.fs:0
at Expecto.ANSIOutputWriter.TextToOutput (object,Microsoft.FSharp.Collections.FSharpList`1<System.Tuple`2<string, System.ConsoleColor>>) [0x00000] in C:\Users\Ant\src\expecto\Expecto\Progress.fs:189
at Expecto.Tests/runTestsWithCancel@1697-1.Invoke (object,Microsoft.FSharp.Collections.FSharpList`1<System.Tuple`2<string, System.ConsoleColor>>) [0x00000] in C:\Users\Ant\src\expecto\Expecto\Expecto.fs:1697
at Microsoft.FSharp.Core.OptimizedClosures/Invoke@2810<T2_REF, TResult_REF, T1_REF>.Invoke (T2_REF) [0x0000f] in <5b4c6262904cf4daa745038362624c5b>:0
at Expecto.Logging.LiterateConsoleTarget.writeColourisedThenNewLine (Expecto.Logging.Message) [0x00000] in C:\Users\Ant\src\expecto\Expecto\Logging.fs:855
at <StartupCode$Expecto>.$Logging/Expecto-Logging-Logger-logWithAck@876.Invoke (Microsoft.FSharp.Core.Unit) [0x00000] in C:\Users\Ant\src\expecto\Expecto\Logging.fs:876
at Microsoft.FSharp.Control.AsyncPrimitives.CallThenInvoke<T_REF, TResult_REF> (Microsoft.FSharp.Control.AsyncActivation`1<T_REF>,TResult_REF,Microsoft.FSharp.Core.FSharpFunc`2<TResult_REF, Microsoft.FSharp.Control.FSharpAsync`1<T_REF>>) [0x00007] in <5b4c6262904cf4daa745038362624c5b>:0
at <StartupCode$FSharp-Core>.$Async/Delay@1095<T_REF>.Invoke (Microsoft.FSharp.Control.AsyncActivation`1<T_REF>) [0x0002c] in <5b4c6262904cf4daa745038362624c5b>:0
at Microsoft.FSharp.Control.AsyncPrimitives.Invoke<T_REF> (Microsoft.FSharp.Control.FSharpAsync`1<T_REF>,Microsoft.FSharp.Control.AsyncActivation`1<T_REF>) [0x00065] in <5b4c6262904cf4daa745038362624c5b>:0
at Microsoft.FSharp.Control.AsyncPrimitives.Bind<int, Microsoft.FSharp.Core.Unit> (Microsoft.FSharp.Control.AsyncActivation`1<int>,Microsoft.FSharp.Control.FSharpAsync`1<Microsoft.FSharp.Core.Unit>,Microsoft.FSharp.Core.FSharpFunc`2<Microsoft.FSharp.Core.Unit, Microsoft.FSharp.Control.FSharpAsync`1<int>>) [0x00046] in <5b4c6262904cf4daa745038362624c5b>:0
at Microsoft.FSharp.Control.AsyncPrimitives.Invoke<int> (Microsoft.FSharp.Control.FSharpAsync`1<int>,Microsoft.FSharp.Control.AsyncActivation`1<int>) [0x00065] in <5b4c6262904cf4daa745038362624c5b>:0
at Microsoft.FSharp.Control.AsyncPrimitives/RunSynchronouslyInCurrentThread@901<int>.Invoke (Microsoft.FSharp.Core.Unit) [0x0004f] in <5b4c6262904cf4daa745038362624c5b>:0
at Microsoft.FSharp.Control.Trampoline.Execute (Microsoft.FSharp.Core.FSharpFunc`2<Microsoft.FSharp.Core.Unit, Microsoft.FSharp.Control.AsyncReturn>) [0x00023] in <5b4c6262904cf4daa745038362624c5b>:0
at Microsoft.FSharp.Control.TrampolineHolder.ExecuteWithTrampoline (Microsoft.FSharp.Core.FSharpFunc`2<Microsoft.FSharp.Core.Unit, Microsoft.FSharp.Control.AsyncReturn>) [0x00038] in <5b4c6262904cf4daa745038362624c5b>:0
at Microsoft.FSharp.Control.AsyncPrimitives.RunSynchronouslyInCurrentThread<int> (System.Threading.CancellationToken,Microsoft.FSharp.Control.FSharpAsync`1<int>) [0x00016] in <5b4c6262904cf4daa745038362624c5b>:0
at Microsoft.FSharp.Control.AsyncPrimitives.RunSynchronously<int> (System.Threading.CancellationToken,Microsoft.FSharp.Control.FSharpAsync`1<int>,Microsoft.FSharp.Core.FSharpOption`1<int>) [0x00015] in <5b4c6262904cf4daa745038362624c5b>:0
at Microsoft.FSharp.Control.FSharpAsync.RunSynchronously<int> (Microsoft.FSharp.Control.FSharpAsync`1<int>,Microsoft.FSharp.Core.FSharpOption`1<int>,Microsoft.FSharp.Core.FSharpOption`1<System.Threading.CancellationToken>) [0x0006e] in <5b4c6262904cf4daa745038362624c5b>:0
at Expecto.Tests.runTestsWithArgsAndCancel (System.Threading.CancellationToken,Expecto.Impl/ExpectoConfig,string[],Expecto.Test) [0x00157] in C:\Users\Ant\src\expecto\Expecto\Expecto.fs:1742
at Expecto.Tests.runTestsInAssemblyWithCancel (System.Threading.CancellationToken,Expecto.Impl/ExpectoConfig,string[]) [0x0009b] in C:\Users\Ant\src\expecto\Expecto\Expecto.fs:1759
at Expecto.CSharp.Runner.RunTestsInAssembly (Expecto.Impl/ExpectoConfig,string[]) [0x00000] in C:\Users\Ant\src\expecto\Expecto\CSharp.fs:50
at ViewModelTests.TestSuite.Main (string[]) [0x00039] in /Users/jwostenberg/Code/Mobile/Apps/ViewModelTests/Program.cs:56
at (wrapper runtime-invoke) <Module>.runtime_invoke_void_object (object,intptr,intptr,intptr) [0x00051] in <e8d6c30b5c7c4c2fa00efd416cad8f7f>:0
Native stacktrace:
0 mono32 0x00192949 mono_handle_native_crash + 233
1 mono32 0x002230c9 sigabrt_signal_handler + 153
2 libsystem_platform.dylib 0xa758c02b _sigtramp + 43
3 ??? 0xffffffff 0x0 + 4294967295
4 libsystem_c.dylib 0xa732d956 abort + 133
5 mono32 0x00391be3 mono_log_write_logfile + 355
6 mono32 0x0038cbc1 structured_log_adapter + 33
7 mono32 0x003a99d0 monoeg_g_logv + 80
8 mono32 0x003a9afa monoeg_assertion_message + 26
9 mono32 0x002a861d mono_metadata_decode_row + 301
10 mono32 0x00267122 mono_ppdb_get_seq_points + 194
11 mono32 0x000eda87 mono_method_to_ir + 1031
12 mono32 0x000d94c8 mini_method_compile + 4088
13 mono32 0x000dd06a mono_jit_compile_method_inner + 810
14 mono32 0x000e0787 mono_jit_compile_method_with_opt + 1655
15 mono32 0x000e4bd1 mono_jit_runtime_invoke + 481
16 mono32 0x002d110a do_runtime_invoke + 74
17 mono32 0x002cd0b4 mono_runtime_class_init_full + 1044
18 mono32 0x001410b9 mono_generic_class_init + 25
19 ??? 0x007a5b3e 0x0 + 8018750
20 ??? 0x031ef3dc 0x0 + 52360156
21 ??? 0x031ef2ac 0x0 + 52359852
22 ??? 0x031ef1f0 0x0 + 52359664
23 ??? 0x031ef138 0x0 + 52359480
24 ??? 0x031b7e53 0x0 + 52133459
25 ??? 0x031cf9f3 0x0 + 52230643
26 ??? 0x031ccd28 0x0 + 52219176
27 ??? 0x031cca9f 0x0 + 52218527
28 ??? 0x031cc9b8 0x0 + 52218296
29 ??? 0x031cc846 0x0 + 52217926
30 ??? 0x031cc39c 0x0 + 52216732
31 ??? 0x031cc02a 0x0 + 52215850
32 ??? 0x031c7a53 0x0 + 52197971
33 ??? 0x031c7369 0x0 + 52196201
34 ??? 0x031c7048 0x0 + 52195400
35 ??? 0x031c63a8 0x0 + 52192168
36 ??? 0x031c6044 0x0 + 52191300
37 ??? 0x031c52e0 0x0 + 52187872
38 ??? 0x030756bc 0x0 + 50812604
39 ??? 0x030667a8 0x0 + 50751400
40 ??? 0x03066344 0x0 + 50750276
41 ??? 0x00799d78 0x0 + 7970168
42 ??? 0x00799ecf 0x0 + 7970511
43 mono32 0x000e4d14 mono_jit_runtime_invoke + 804
44 mono32 0x002d110a do_runtime_invoke + 74
45 mono32 0x002d45b4 do_exec_main_checked + 132
46 mono32 0x002d33f5 mono_runtime_run_main_checked + 69
47 mono32 0x00152eaa mono_jit_exec + 314
48 mono32 0x001562da mono_main + 12106
49 mono32 0x000d353a main + 266
50 mono32 0x000d3425 start + 53
Debug info from gdb:
(lldb) command source -s 0 '/tmp/mono-gdb-commands.DCX6bv'
Executing commands in '/tmp/mono-gdb-commands.DCX6bv'.
(lldb) process attach --pid 41597
Process 41597 stopped
* thread #1, name = 'tid_303', queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
frame #0: 0xa73df6a6 libsystem_kernel.dylib`__wait4 + 10
libsystem_kernel.dylib`__wait4:
-> 0xa73df6a6 <+10>: jae 0xa73df6b6 ; <+26>
0xa73df6a8 <+12>: calll 0xa73df6ad ; <+17>
0xa73df6ad <+17>: popl %edx
0xa73df6ae <+18>: movl 0x246997f(%edx), %edx
Target 0: (mono32) stopped.
Executable module set to "/Library/Frameworks/Mono.framework/Versions/5.10.1/bin/mono32".
Architecture set to: i386-apple-macosx.
(lldb) thread list
Process 41597 stopped
* thread #1: tid = 0x2d374c, 0xa73df6a6 libsystem_kernel.dylib`__wait4 + 10, name = 'tid_303', queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
thread #2: tid = 0x2d3754, 0xa73ded4e libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'SGen worker'
thread #3: tid = 0x2d3759, 0xa73d543e libsystem_kernel.dylib`semaphore_wait_trap + 10, name = 'Finalizer'
thread #4: tid = 0x2d375a, 0xa73defc6 libsystem_kernel.dylib`__recvfrom + 10, name = 'Debugger agent'
thread #5: tid = 0x2d3761, 0xa73df716 libsystem_kernel.dylib`__workq_kernreturn + 10
thread #6: tid = 0x2d3762, 0xa73df716 libsystem_kernel.dylib`__workq_kernreturn + 10
thread #7: tid = 0x2d3766, 0xa73ded4e libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'Timer-Scheduler'
(lldb) thread backtrace all
* thread #1, name = 'tid_303', queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
* frame #0: 0xa73df6a6 libsystem_kernel.dylib`__wait4 + 10
frame #1: 0xa734ace2 libsystem_c.dylib`waitpid$UNIX2003 + 32
frame #2: 0x00192a1e mono32`mono_handle_native_crash(signal=<unavailable>, ctx=<unavailable>, info=0xbff2df9c) at mini-exceptions.c:2830 [opt]
frame #3: 0x002230c9 mono32`sigabrt_signal_handler(_dummy=6, _info=<unavailable>, context=0xbff2dfdc) at mini-posix.c:208 [opt]
thread #2, name = 'SGen worker'
frame #0: 0xa73ded4e libsystem_kernel.dylib`__psynch_cvwait + 10
frame #1: 0xa759543c libsystem_pthread.dylib`_pthread_cond_wait + 658
frame #2: 0xa759708c libsystem_pthread.dylib`pthread_cond_wait$UNIX2003 + 51
frame #3: 0x00388d71 mono32`thread_func [inlined] mono_os_cond_wait(mutex=0x0047892c) at mono-os-mutex.h:173 [opt]
frame #4: 0x00388d5c mono32`thread_func at sgen-thread-pool.c:165 [opt]
frame #5: 0x00388d4c mono32`thread_func(data=<unavailable>) at sgen-thread-pool.c:196 [opt]
frame #6: 0xa75944d5 libsystem_pthread.dylib`_pthread_body + 347
frame #7: 0xa759437a libsystem_pthread.dylib`_pthread_start + 357
frame #8: 0xa7593a56 libsystem_pthread.dylib`thread_start + 34
thread #3, name = 'Finalizer'
frame #0: 0xa73d543e libsystem_kernel.dylib`semaphore_wait_trap + 10
frame #1: 0x00337d74 mono32`finalizer_thread [inlined] mono_os_sem_wait(flags=MONO_SEM_FLAGS_ALERTABLE) at mono-os-semaphore.h:90 [opt]
frame #2: 0x00337d66 mono32`finalizer_thread at mono-coop-semaphore.h:43 [opt]
frame #3: 0x00337d55 mono32`finalizer_thread(unused=0x00000000) at gc.c:852 [opt]
frame #4: 0x002f3c49 mono32`start_wrapper [inlined] start_wrapper_internal at threads.c:1004 [opt]
frame #5: 0x002f3b94 mono32`start_wrapper(data=<unavailable>) at threads.c:1064 [opt]
frame #6: 0xa75944d5 libsystem_pthread.dylib`_pthread_body + 347
frame #7: 0xa759437a libsystem_pthread.dylib`_pthread_start + 357
frame #8: 0xa7593a56 libsystem_pthread.dylib`thread_start + 34
thread #4, name = 'Debugger agent'
frame #0: 0xa73defc6 libsystem_kernel.dylib`__recvfrom + 10
frame #1: 0xa734aec0 libsystem_c.dylib`recv$UNIX2003 + 30
frame #2: 0x001cb749 mono32`socket_transport_recv(buf=<unavailable>, len=11) at debugger-agent.c:1152 [opt]
frame #3: 0x001b71b4 mono32`debugger_thread [inlined] transport_recv(len=11) at debugger-agent.c:1558 [opt]
frame #4: 0x001b71a2 mono32`debugger_thread(arg=0x00000000) at debugger-agent.c:10517 [opt]
frame #5: 0x002f3c49 mono32`start_wrapper [inlined] start_wrapper_internal at threads.c:1004 [opt]
frame #6: 0x002f3b94 mono32`start_wrapper(data=<unavailable>) at threads.c:1064 [opt]
frame #7: 0xa75944d5 libsystem_pthread.dylib`_pthread_body + 347
frame #8: 0xa759437a libsystem_pthread.dylib`_pthread_start + 357
frame #9: 0xa7593a56 libsystem_pthread.dylib`thread_start + 34
thread #5
frame #0: 0xa73df716 libsystem_kernel.dylib`__workq_kernreturn + 10
frame #1: 0xa7593e64 libsystem_pthread.dylib`_pthread_wqthread + 1035
frame #2: 0xa7593a32 libsystem_pthread.dylib`start_wqthread + 34
thread #6
frame #0: 0xa73df716 libsystem_kernel.dylib`__workq_kernreturn + 10
frame #1: 0xa7594059 libsystem_pthread.dylib`_pthread_wqthread + 1536
frame #2: 0xa7593a32 libsystem_pthread.dylib`start_wqthread + 34
thread #7, name = 'Timer-Scheduler'
frame #0: 0xa73ded4e libsystem_kernel.dylib`__psynch_cvwait + 10
frame #1: 0xa7595486 libsystem_pthread.dylib`_pthread_cond_wait + 732
frame #2: 0xa75967cf libsystem_pthread.dylib`pthread_cond_timedwait_relative_np + 27
frame #3: 0x00395642 mono32`mono_os_cond_timedwait(cond=0x7b07f2f4, mutex=<unavailable>, timeout_ms=2997) at mono-os-mutex.c:44 [opt]
frame #4: 0x00314b41 mono32`mono_w32handle_timedwait_signal_handle at mono-coop-mutex.h:102 [opt]
frame #5: 0x00314b1e mono32`mono_w32handle_timedwait_signal_handle [inlined] mono_w32handle_timedwait_signal_naked(poll=0, alerted=<unavailable>) at w32handle.c:652 [opt]
frame #6: 0x00314b1e mono32`mono_w32handle_timedwait_signal_handle(handle_data=<unavailable>, timeout=<unavailable>, poll=0, alerted=<unavailable>) at w32handle.c:767 [opt]
frame #7: 0x00314a05 mono32`mono_w32handle_wait_one(handle=0x7b07f2b8, timeout=<unavailable>, alertable=<unavailable>) at w32handle.c:885 [opt]
frame #8: 0x00314ca2 mono32`mono_w32handle_wait_multiple(handles=0xb09e4a28, nhandles=<unavailable>, waitall=<unavailable>, timeout=<unavailable>, alertable=<unavailable>) at w32handle.c:923 [opt]
frame #9: 0x002ee665 mono32`ves_icall_System_Threading_WaitHandle_Wait_internal(handles=<unavailable>, numhandles=<unavailable>, waitall=<unavailable>, timeout=-1, error=<unavailable>) at threads.c:1931 [opt]
frame #10: 0x0302a1fc
frame #11: 0x03029b68
frame #12: 0x030299a4
frame #13: 0x03029448
frame #14: 0x030293a8
frame #15: 0x030292a4
frame #16: 0x0301fc71
frame #17: 0x0301dfbf
frame #18: 0x0301d618
frame #19: 0x0301d1a4
frame #20: 0x0301cc04
frame #21: 0x0301ca44
frame #22: 0x02e874b5
frame #23: 0x000e4d14 mono32`mono_jit_runtime_invoke(method=0x00000000, obj=0x00901888, params=0xb09e4f4c, exc=<unavailable>, error=<unavailable>) at mini-runtime.c:2806 [opt]
frame #24: 0x002d110a mono32`do_runtime_invoke(method=<unavailable>, obj=<unavailable>, params=<unavailable>, exc=<unavailable>, error=<unavailable>) at object.c:2887 [opt]
frame #25: 0x002d2b4d mono32`mono_runtime_delegate_try_invoke [inlined] mono_runtime_try_invoke(method=<unavailable>, params=<unavailable>, exc=<unavailable>, error=<unavailable>) at object.c:2994 [opt]
frame #26: 0x002d2b43 mono32`mono_runtime_delegate_try_invoke(delegate=<unavailable>, params=0x00000000, exc=<unavailable>, error=<unavailable>) at object.c:4023 [opt]
frame #27: 0x002d2b7f mono32`mono_runtime_delegate_invoke_checked(delegate=0x00901888, params=0xb09e4f4c, error=0xb09e4f18) at object.c:4044 [opt]
frame #28: 0x002f3c6f mono32`start_wrapper at threads.c:1012 [opt]
frame #29: 0x002f3b94 mono32`start_wrapper(data=<unavailable>) at threads.c:1064 [opt]
frame #30: 0xa75944d5 libsystem_pthread.dylib`_pthread_body + 347
frame #31: 0xa759437a libsystem_pthread.dylib`_pthread_start + 357
frame #32: 0xa7593a56 libsystem_pthread.dylib`thread_start + 34
(lldb) detach
=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
(lldb) quit
I looked into the relevant Expecto code, and (what I'm pretty sure is) the offending line seems to be creating a StringBuilder: Progress.fs#L128
I'm running on VSfM (7.5.4 build 3) + Mono 5.10.1.57, and my project references Expecto 8.1.1 + FSharp.Core 4.5.
I can't include the project here since it of course has intellectual property, but I'm working on creating a reproducible project with the same crash. Just an information dump for now (probably not super useful, but hey, you never know)
EDIT: I can no longer get this crash to happen, even in the original solution. :/ I guess I just needed to do a classic clean-and-restore-and-rebuild everything in sight.
@nosami This seems consistent with what we saw back in January - there are methods that are missing from the middle of the MethodDebugInformation table, but the error gets triggered by an innocent method that happens to have an index that's greater than the number of rows in the MethodDebugInformation.
What we saw before was that abstract methods in interfaces don't seem to get a row - maybe throw a couple of those into your smaller example?
@jwosty Yes, that's the same issue. You can probably work around it by deleting the .pdb
files from the output folder belonging to one or more of your F# assemblies (nobody has ever reported this issue for C#)
An alternative is to switch to generating .mdb
files. The Mono F# targets have a failsafe in case of this eventuality :)
<FscDebugType>full</FscDebugType>
<FscDebugFileExt>.mdb</FscDebugFileExt>
What we saw before was that abstract methods in interfaces don't seem to get a row - maybe throw a couple of those into your smaller example?
@lambdageek I tried this once before, but I'll give it another shot.
@nosami Ok, I'll keep this in mind next time it happens, thanks.
The weird thing, though, is that there are no F# projects in this particular product (thus the F# compiler is never being invoked in my environment); we're just referencing Expecto via Nuget... I wonder how this happens in my situation.
EDIT: I didn't realize that pdb's make it in from Nuget libraries. I assume the problem is actually present in Expecto.pdb
, not anything I'm compiling (since it's C#)
Also, I've locked FSharp.Core at 4.3.4 in case #5369 has anything to do with it -- the upshot is that there's real compatibility issues between the currently released F# compiler, and FSharp.Core 4.5.1.
EDIT: I didn't realize that pdb's make it in from Nuget libraries. I assume the problem is actually present in Expecto.pdb, not anything I'm compiling (since it's C#)
This is almost certainly why
What we saw before was that abstract methods in interfaces don't seem to get a row - maybe throw a couple of those into your smaller example?
@lambdageek I tried these cases and both worked (I think the abstract method debug information has been fixed since we looked into it)
//[<AbstractClass>]
//type Animal () =
// abstract Name : string
//type Dog (name) =
// inherit Animal()
// override dog.Name = name
//let pluto = Dog("Pluto")
//let name = pluto.Name
type Animal =
abstract member Name : string
type Dog (name : string) =
interface Animal with
member this.Name : string = name
let pluto = new Dog("Pluto")
let name = (pluto :> Animal).Name
Ah well... I wish MethodDebugInformation had just a little bit more info so it would be possible to cross-check with the method table π
Maybe at https://github.com/Microsoft/visualfsharp/blob/8705df068323bedc4140f34c4f90ccb89e6b4133/src/absil/ilwritepdb.fs#L405 instead of ignoring the result, it's possible to do a check that the resulting MethodDebugInformationHandle
is good (there are not a lot of public methods on it - I guess it's possible to call ToDefinitionHandle()
and get a MethodDefinitionHandle
and maybe compare with the method definition handle from the method itself?). Maybe it would be possible to detect if the ppdb construction is about to go bad...
I wish MethodDebugInformation had just a little bit more info so it would be possible to cross-check with the method table
Yeah... I was trying to see if there was an easy way to cross-reference between the files produced by mdv
, doesn't look like it.
I just happened to chance upon this comment by @jbevain
from this bug report
The Mono Linker rewrites the PDB file emitted by the compiler to account for all the unneeded code that is removed.
It was failing here
System.NullReferenceException: Object reference not set to an instance of an object
at Mono.Cecil.MetadataBuilder.AddLocalConstants (Mono.Cecil.Cil.ScopeDebugInformation scope) [0x00011] in <02bda330e3df4b0a951856a277c73d92>:0
This was the workaround https://github.com/jbevain/cecil/commit/22b36c3dc5dcc0ddba38164904a1b3daf02151e2
It looks as if Local Constants are never added to the PDB table
Could this be the cause of the problem here?
OK. I worked out which 3 methods don't have corresponding entries in the pdb file
[<DllImport("Advapi32.dll", CharSet = CharSet.Unicode, BestFitMapping = false)>]
extern uint32 RegOpenKeyExW(UIntPtr _hKey, string _lpSubKey, uint32 _ulOptions, int _samDesired, UIntPtr & _phkResult);
[<DllImport("Advapi32.dll", CharSet = CharSet.Unicode, BestFitMapping = false)>]
extern uint32 RegQueryValueExW(UIntPtr _hKey, string _lpValueName, uint32 _lpReserved, uint32 & _lpType, IntPtr _lpData, int & _lpchData);
[<DllImport("Advapi32.dll")>]
extern uint32 RegCloseKey(UIntPtr _hKey)
trying to debug this very small program results in the same crash!
<DebugType>portable</DebugType>
open System
open System.Runtime.InteropServices
[<DllImport("Advapi32.dll")>]
extern uint32 RegCloseKey(UIntPtr _hKey)
[<EntryPoint>]
let main argv =
printfn "%A" argv
0 // return an integer exit code
Side note, the Cecil/constant issue is probably not directly related. The Cecil crash was because of the way fsc
encoded the fact that a method debug information had no constant, which was atypical but valid.
@jbevain: Thanks!
I figured it out - there is no MethodDebugInformation for externs
Expecto has externs here - https://github.com/haf/expecto/blob/642f9bb9de4ae9ffb87586c7fb7bdee0122affd1/Expecto/Progress.fs#L152
which explains why debugging crashes with Expecto references.
17:45 $ cat Program.fs
open System
open System.Runtime.InteropServices
[<DllImport("Advapi32.dll")>]
extern uint32 RegCloseKey(UIntPtr _hKey)
[<EntryPoint>]
let main argv =
printfn "%A" argv
0 // return an integer exit code
β ~/Projects/debugextens/debugextens [master L|β2β 2β¦4]
17:47 $ fsharpc Program.fs --debug:portable --test:DumpDebugInfo
Microsoft (R) F# Compiler version 4.1
Copyright (c) Microsoft Corporation. All Rights Reserved.
β ~/Projects/debugextens/debugextens [master L|β2β 2β¦4]
17:47 $ cat Pro
Program.exe Program.exe.debuginfo Program.fs Program.pdb
β ~/Projects/debugextens/debugextens [master L|β2β 2β¦4]
17:47 $ cat Program.exe.debuginfo
ENTRYPOINT
true
DOCUMENTS
[0] /Users/jason/Projects/debugextens/debugextens/Program.fs
Type: <null>
Language: <null>
Vendor: <null>
METHODS
main
Params: []
Range: Some "[0,8:5] - [0,9:6]"
Points:
- Doc: 0 Offset:0 [8:5]-[8-17]
- Doc: 0 Offset:29 [9:5]-[9-6]
Scopes:
- [0-31]
It definitely looks like a bug in fsharpc
, there are 2 rows in the Method
table and only one row in the MethodDebugInformation
table, and the ppdb spec specifies those should match.
Bad symbol information in portable pdb.
Repro steps
Provide the steps required to reproduce the problem
Build FCS with portable pdb
Debug code which uses FSharpChecker.Create()
Expected behavior
Should be able to step through code.
Actual behavior
Mono runtime halts with
Known workarounds
Don't debug the compiler / delete pdb / build with mdb / patch mono to ignore bad ppdb