Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Create a separate MetadataReader for the PDB #3313

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
wants to merge 4 commits into from
Closed

Create a separate MetadataReader for the PDB #3313

wants to merge 4 commits into from

Conversation

peterwald
Copy link

@peterwald peterwald commented Jun 2, 2025 •
edited
Loading

Creates a separate MetadataReader for the PDB. This should handle both embedded and non-embedded portable PDBs. Note that it does not support the legacy Windows PDB format.

Any reads of the debug data should use the MetadataReaderProvider created from the PDBs, while the other metadata should be read using the PE MetadataReader.

#3304

@peterwald peterwald mentioned this pull request Jun 2, 2025
Closed
@bradwilson
Copy link
Member

Lack of support for full PDBs is a bummer. We had originally needed to mandate full PDBs for .NET Framework projects because that's what VSTest and/or Test Explorer required, but that requirement is extremely old and perhaps out of date now. So I wonder if we can just move forward with the recommendation of portable PDBs.

Thoughts @Youssef1313 @nohwnd?

@bradwilson
Copy link
Member

(This is fundamentally a question as to whether DiaSession can read portable PDBs for .NET Framework assemblies. My memory says this used to not be supported.)

@Youssef1313
Copy link
Contributor

@bradwilson Generally, Dia is only for full (Windows) PDBs. However, DiaSession in VSTest is named incorrectly (probably for historical reasons?). It supports full (Windows) PDBs, portable PDBs, and embedded PDBs.

https://github.com/microsoft/vstest/blob/107abd3b697cd033c6b037075536fdd089370101/src/Microsoft.TestPlatform.ObjectModel/Navigation/DiaSession.cs#L122-L131

If the PDB file exists, we try to check if it's portable and then determine to use either PortableSymbolReader or FullSymbolReader. If there is no PDB file, then it's probably embedded PDB (embedded PDBs use portable PDB format).

@Youssef1313
Copy link
Contributor

I think the three variants should be supported by xunit (full, portable, and embedded).

@bradwilson
Copy link
Member

I think the three variants should be supported by xunit (full, portable, and embedded)

Well, then, that leaves me with three choices:

  • Always use CecilSourceInformationProvider which appears to be broken for some of @peterwald's projects, presumably due to code age
  • Always use MetadataSourceInformationProvider which will not report source information for full PDBs (since System.Runtime.Metadata does not appear to support full PDBs)
  • Combine the two and fall back to Cecil when there doesn't appear to be source information available via System.Runtime.Metadata

This is quite a mess we have here. 😂

@bradwilson
Copy link
Member

bradwilson commented Jun 4, 2025 •
edited
Loading

Not to mention that I'm seeing hard Mono crashes when trying to use System.Runtime.Metadata:

  * Assertion at assembly.c:1939, condition `is_ok (hook_error)' not met, function:mono_assembly_invoke_load_hook_internal, (null) assembly:/usr/lib/mono/4.5/mscorlib.dll type:TypeLoadException member:(null)
  
  
  =================================================================
  	Native Crash Reporting
  =================================================================
  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.
  =================================================================
  
  =================================================================
  	Native stacktrace:
  =================================================================
  	0x55961e67204b - /usr/bin/mono : 
  	0x55961e6723dd - /usr/bin/mono : 
  	0x55961e61f087 - /usr/bin/mono : 
  	0x55961e6715cc - /usr/bin/mono : 
  	0x7ff9d7c45330 - /lib/x86_64-linux-gnu/libc.so.6 : 
  	0x7ff9d7c9eb2c - /lib/x86_64-linux-gnu/libc.so.6 : pthread_kill
  	0x7ff9d7c4527e - /lib/x86_64-linux-gnu/libc.so.6 : gsignal
  	0x7ff9d7c288ff - /lib/x86_64-linux-gnu/libc.so.6 : abort
  	0x55961e5e13c4 - /usr/bin/mono : 
  	0x55961e8c6135 - /usr/bin/mono : 
  	0x55961e8e35be - /usr/bin/mono : 
  	0x55961e8e3c73 - /usr/bin/mono : monoeg_assertion_message
  	0x55961e759163 - /usr/bin/mono : 
  	0x55961e759ffe - /usr/bin/mono : 
  	0x55961e75c1c3 - /usr/bin/mono : 
  	0x55961e74c145 - /usr/bin/mono : 
  	0x55961e74c23f - /usr/bin/mono : 
  	0x55961e74dee5 - /usr/bin/mono : 
  	0x55961e756731 - /usr/bin/mono : 
  	0x55961e75b46d - /usr/bin/mono : 
  	0x55961e75ce8d - /usr/bin/mono : 
  	0x55961e75dca9 - /usr/bin/mono : mono_assembly_load_reference
  	0x55961e765c8b - /usr/bin/mono : mono_class_from_typeref_checked
  	0x55961e765f65 - /usr/bin/mono : mono_class_get_checked
  	0x55961e7d83cc - /usr/bin/mono : 
  	0x55961e7d8148 - /usr/bin/mono : 
  	0x55961e7d7e7a - /usr/bin/mono : 
  	0x55961e7d8191 - /usr/bin/mono : 
  	0x55961e7687e1 - /usr/bin/mono : 
  	0x55961e76d400 - /usr/bin/mono : 
  	0x55961e76ca63 - /usr/bin/mono : 
  	0x55961e7baeee - /usr/bin/mono : 
  	0x55961e7bb308 - /usr/bin/mono : 
  	0x55961e67d17b - /usr/bin/mono : 
  	0x55961e694413 - /usr/bin/mono : 
  	0x55961e67675f - /usr/bin/mono : 
  	0x55961e678b96 - /usr/bin/mono : 
  	0x55961e5ea1e2 - /usr/bin/mono : 
  	0x55961e6229c6 - /usr/bin/mono : 
  	0x55961e623524 - /usr/bin/mono : 
  	0x4094b393 - Unknown
  
  =================================================================
  	Telemetry Dumper:
  =================================================================
  Pkilling 0x140710955157184x from 0x140710961460928x
  Pkilling 0x140711039071936x from 0x140710961460928x
  Pkilling 0x140710969865920x from 0x140710961460928x
  Pkilling 0x14071096566[342](https://github.com/xunit/xunit/actions/runs/15451697619/job/43495141701#step:8:343)4x from 0x140710961460928x
  Pkilling 0x140710957258432x from 0x140710961460928x
  Pkilling 0x140710967764672x from 0x140710961460928x
  Pkilling 0x140710963562176x from 0x140710961460928x
  Pkilling 0x140710959359680x from 0x140710961460928x
  Pkilling 0x140711050225536x from 0x140710961460928x
  Entering thread summarizer pause from 0x140710961460928x
  Finished thread summarizer pause from 0x140710961460928x.
  Failed to create breadcrumb file (null)/crash_hash_0x180679a1f3
  
  Waiting for dumping threads to resume
  
  =================================================================
  	External Debugger Dump:
  =================================================================
  mono_gdb_render_native_backtraces not supported on this platform, unable to find gdb or lldb
  
  =================================================================
  	Basic Fault Address Reporting
  =================================================================
  Memory around native instruction pointer (0x7ff9d7c9eb2c):0x7ff9d7c9eb1c  05 00 44 89 e2 89 de 89 c7 b8 ea 00 00 00 0f 05  ..D.............
  0x7ff9d7c9eb2c  41 89 c6 41 f7 de 3d 00 f0 ff ff b8 00 00 00 00  A..A..=.........
  0x7ff9d7c9eb3c  44 0f 46 f0 e9 7b ff ff ff 0f 1f 00 4c 89 ef e8  D.F..{......L...
  0x7ff9d7c9eb4c  90 a3 ff ff e9 39 ff ff ff 0f 1f 00 4c 89 ef e8  .....9......L...
  
  =================================================================
  	Managed Stacktrace:
  =================================================================
  	  at <unknown> <0xffffffff>
  	  at Xunit.MetadataSourceInformationProvider:.ctor <0x001d7>
  	  at Xunit.Internal.MetadataSourceInformationProviderHelper:CreateForTesting <0x00083>
  	  at MetadataSourceInformationProviderTests:CanRetrieveSourceInformation <0x00067>
[...]

@Youssef1313
Copy link
Contributor

@tmat is likely best to help.

What I personally would do is to use caller info attributes and avoid reading PDB altogether. It is something I'm planning to explore for MSTest v4 (microsoft/testfx#5500).

@bradwilson
Copy link
Member

What I personally would do is to use caller info attributes and avoid reading PDB altogether. It is something I'm planning to explore for MSTest v4 (microsoft/testfx#5500).

That doesn't work for F#, which is half the reason I introduced the Cecil-based source information provider.

@Youssef1313
Copy link
Contributor

@bradwilson I didn't try myself, but I was under the impression that it should work for F# based on https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/caller-information

@bradwilson
Copy link
Member

Perhaps some of the documentation I was relying on is out of date, but it seemed to suggest that caller information was only available in C# and VB.

@bradwilson
Copy link
Member

@Youssef1313 Seems to be working fine for F#.

image

@peterwald I'm going to close this PR and just push all v3 over to Fact-attribute based discovery. v1 and v2 projects will still use Cecil when appropriate. Since your Cecil-based issues are with v3, they should be solved by the compile-time source information discovery.

@bradwilson
Copy link
Member

Taking a different approach to solve the issue

@bradwilson bradwilson closed this Jun 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@peterwald @bradwilson @Youssef1313