Closed naricc closed 3 years ago
Yes, this is expected, for a huge StackOverflow with 66 thousand lines you'll get slowness like that. Doubt we can do anything about it.
Incidentally, I've seen a stackoverflow in Cecil before, and it has to do with a cycle in assembly resolution. See related: https://github.com/KirillOsenkov/MetadataTools/issues/4
@KirillOsenkov I don't suppose you have any tips for debugging a cycle in assembly resolution? I realized it was a cycle, but I can't figure out what assemblies are involved/how to fix it.
Sometimes assemblies will reference each other. If you have a custom resolver I'd keep a HashSet around of the assemblies being visited, and for each new assembly first check if it's already in the HashSet before trying to resolve it. Read the file I linked to for details (you'll need a custom resolver). There might be a Cecil bug around it too, I can't remember.
Of course place a breakpoint in the custom resolver and see which assemblies it gets stuck on, maybe log each assembly as you're visiting it, then inspect the log (printf-debugging).
Read the issue and the code I linked to in more detail, maybe you'll have some insights. Good luck! If you get really stuck, ping me internally and I can help take a look or maybe connect you to Jb Evain, the author of Cecil.
I figured it out. I guess we can close this one, unless you think there is some way to solve it.
There is probably a linker issue here to make these types of problems easier to diagnose.
The log viewer can become unusably slow on some not especially big logs. I think this has something to do with large stack traces being in the binlog, but I am not exactly sure where it goes wrong.
Here is an example binlog that produces the problem: https://microsoft-my.sharepoint.com/:u:/p/naricc/Eauc8Kph1P9Mp79fOfQDiYEBKw1sX-k8X4hQH6PiraUJ5Q?e=mwRELS