Vitek Karas

The only failure is linux_musl arm64 libraries test run timing out which is happening other PRs as well.

The trace log is for a single-file self-contained app - so the runtime is statically linked to the host (so there's no CoreCLR .dylib anywhere). @VSadov has been looking at...

@rcdailey it was more a generic recommendation - we often get issue reports which are using a somewhat stale versions, so just trying to make sure that this is not...

@rcdailey were you able to try this on a more recent SDK?

I don't think that the same problem. This problem (wrong custom debug info) has been in Cecil since forever it seems.

Sample test for this in Cecil tests is here: https://github.com/vitek-karas/cecil/commit/1d9104abf53dc233e66a25648dc5e6c1d6004c80

No I haven't fixed it - mono/linker had a bug on top of this one.. and fixing that meant it didn't need Cecil fix.

Not really - That said I can see couple of places in the `ResolveInstructionOffset` which could lead to the exception as there are not enough checks. For example if there...

As per @ltrzesniewski comment - you need to ask for deterministic behavior. But if you still get different outputs after that I would be very interested (as it would break...

I think this is because we don't allow loading "components" as self-contained. Is that right @jkoritzinsky ?