mirror of
https://github.com/xoofx/markdig.git
synced 2026-02-12 13:54:45 +00:00
BitVector128 not copying consistently #351
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @craigwi on GitHub (Mar 16, 2020).
Here's an odd one. I have a .NET Framework 4.6.2 test program using markdig 0.18.3 and it worked fine. I have a UWP app (target 18362) using the same version of markdig and it fails to recognize auto links and other things.
I have traced at least one problem down to line 79 of CharacterMap.cs:
this.isOpeningCharacter = isOpeningCharacter;In the .NET program, this line copies all 4 uint values of the vector. In the UWP version, only the first uint is copied. That is, the x86 code generated for the copy is different.
BitVector128 was introduced in 0.18.2. I have reverted to 0.18.1 and the problem has disappeared.
@xoofx commented on GitHub (Mar 17, 2020):
cc: @KrisVandermotten
@KrisVandermotten commented on GitHub (Mar 18, 2020):
That seems to be a bug in UWP. I would suggest that first, you make sure you are using the latest version (of Visual Studio, UWP and .NET Native). If updating to the latest version does not solve the problem, report it to Microsoft.
Reporting this to Microsoft is important, as it is highly likely that MarkDig is not the only software impacted by the bug.
In the mean time, I will try to create a workaround as soon as possible. Manually copying the four uint values should do the trick (I hope).
@craigwi commented on GitHub (Mar 18, 2020):
Reporting to Microsoft makes sense. I'll need to create a small repo case first.
@MihaZupan commented on GitHub (Mar 18, 2020):
I can reproduce this when ingesting the NuGet package, but not if targetting a locally-built master.
@craigwi commented on GitHub (Mar 18, 2020):
Hi @MihaZupan, I have an inside track at Microsoft. If you are willing to share the repo, I will get it to the right team to investigate.
@MihaZupan commented on GitHub (Mar 18, 2020):
Testing this a bit more, this only reproduces if I target the NuGet Markdig and deploying the UWP app in Debug.
Deploying in Release / ingesting a locally built Debug/Release master, I can't reproduce this.
Attaching a repro - fresh UWP app, targeting the NuGet package and code that will display True/False on the window if the parsing worked.
Test.zip
@craigwi commented on GitHub (Mar 18, 2020):
I can confirm this repro: fails on Debug, succeeds on Release. Thanks! I will pass this on within Microsoft.
@KrisVandermotten commented on GitHub (Mar 30, 2020):
@craigwi Any news from Microsoft?
@MihaZupan commented on GitHub (Mar 31, 2020):
Nothing yet
@craigwi commented on GitHub (Mar 31, 2020):
I have responses now from some of the .NET team; will report back when I hear more.
@craigwi commented on GitHub (Apr 7, 2020):
I am in contact with a dev in .NET who owns UWP. The issue appears limited to Debug, x86 builds -- which happens to be what I use for my everyday debugging. x64 builds that I have tried are fine. I haven't tried ARM.
@MihaZupan, can you confirm that x64 works for you?
@MihaZupan commented on GitHub (Apr 7, 2020):
Yes, I can confirm it only reproducing in x86 mode.
I tested it with different UWP package versions and can reproduce it with
6.2.8(March 2019) and newer.It does not seem to affect
6.1.12and older.@craigwi commented on GitHub (Apr 7, 2020):
Yes, and I too discovered the fact that it appears to be a regression after 6.1.2.
@KrisVandermotten commented on GitHub (Apr 27, 2020):
Does this reproduce with version 0.20.0? If not, should we close this?
(I'd still like to know what happens to the bug in UWP though.)
@craigwi commented on GitHub (Apr 30, 2020):
Based on the test provided by @MihaZupan, the bug does not show up using 0.20.0 on x64 or x86 , debug or release. So assuming that was the only case hitting the bug in unsafe struct copy, then we are good to go.
@MihaZupan commented on GitHub (Apr 30, 2020):
In that case I think we can close the issue here. We can update the info on this issue if/when we get more info about it from UWP's side.