[release/9.0-preview1] Revert "Update HP libunwind to v1.8.0" #97679
Conversation
This reverts commit 5bb5840.
ghost
assigned 
|
Tagging subscribers to this area: @dotnet/area-system-reflection-metadata Issue DetailsThis reverts commit 5bb5840. Most debugging and dump collection scenarios are broken on Unix platforms due to a null pointer read during remote unwinding introduced in libunwind/libunwind#524. The long term fix is in the works in libunwind/libunwind#714, revert this for preview 1 for now. cc: @am11
|
hoyosjs
added
Servicing-consider
|
Tagging subscribers to this area: @dotnet/area-meta Issue DetailsThis reverts commit 5bb5840. Most debugging and dump collection scenarios are broken on Unix platforms due to a null pointer read during remote unwinding introduced in libunwind/libunwind#524. The long term fix is in the works in libunwind/libunwind#714, revert this for preview 1 for now. cc: @am11
|
|
@am11 I have found that there is also some race condition in the new libunwind that manifests itself with my new EH enabled on arm64. The older libunwind works fine. The issue occurs when multiple threads are trying to unwind from the same function at the same time. The unw_step sometimes returns 0 in PC and nonsense in SP. When I added a call to it again right after that on a copy of the original context, it passes. I suspect the caching in libunwind is somehow involved in this. The baseservices/exceptions/regressions/V1/SEH/VJ/ExternalException test crashes within 50..100 iterations with the libunwind 1.8.0 and can pass thousands of iterations with the older one. |
|
However, it seems that the new libunwind has also fixed some issues with unwinding that I have started observing in my testing of the new EH stuff after locally reverting the change, so it seems that in main, we should keep it and I'll need to figure out what's causing the race now. It seems that the caching is actually not the culprit there as even when I disable the caching in libunwind, the problem still happens. |
jeffschwMSFT
added
Servicing-approved
|
Merge when ready. |
|
Hard to track the mono crash, it's a reflection crash. |
|
Should it be reverted from Main as well? It causes problems for VMR repo: dotnet/source-build#4007 (comment) |
|
@EgorBo, as @janvorli mentioned, I think we should fix the problem rather than reverting it. Some distos have already upgraded to libunwind v1.8 (and others will soon), so it won't help the source-build if we revert it, because:
In short, lets apply this upstream patch: https://github.com/libunwind/libunwind/pull/714.patch in source-build for the time being until that PR is merged, then we will apply it in runtime repo. |
This reverts commit 5bb5840.
Most debugging and dump collection scenarios are broken on Unix platforms due to a null pointer read during remote unwinding introduced in libunwind/libunwind#524. The long term fix is in the works in libunwind/libunwind#714, revert this for preview 1 for now.
cc: @am11