Thread blocked indefinitely in an STM transaction

[Studywarscat]

[hascard.exe: thread blocked indefinitely in an STM transaction]
I am in windows
This is the error message that I get when I run hascard under powershell.
Why is it so?
It works as administrator .
I am facing an issue with a software called hascard and it depends on this library. The creator asked me to report the issue here and thats why I am here🫤.

[jtdaugherty]

Hi @Studywarscat, sorry to see you're running into a problem.

At the moment I'm afraid this isn't enough information to know for sure that it is a brick issue. It's possible that this is a bug in vty-windows. Can you say more about what was going on when this occurred? Does it happen immediately upon starting hascard?

@ShrykeWindgrace or @chhackett, have you seen anything like this come up in vty-windows? vty, vty-windows, and brick all use STM in various ways but the code in vty and brick have been around much longer so I'm skeptical that there's some issue there.

[Studywarscat]

Yes, it occurs immediately after starting hascard. And the creator told me to specify that I use windows so probably an issue with vty-windows, not sure though ☹️.

[jtdaugherty]

Which terminal are you using?

[Studywarscat]

Powershell in windows terminal

[Studywarscat]

Written in Haskell, UI built with brick and parsing of cards done with megaparsec. Recordings of the terminal were made using terminalizer. The filebrowser widget was mostly copied from the brick filebrowser demo program. Homebrew and Travis configurations were made much easier by the tutorial from Chris Penner.

Extremely sorry. The program is built with brick.

[chhackett]

@jtdaugherty
I did see this error crop up, but only in a branch where I've been testing some changes for mintty terminal support.
But I will try to reproduce this and provide a fix this week.

[jtdaugherty]

Okay, thanks, @chhackett. Keep us posted!

[Macroniop]

Man Same, has this been fixed. I made whole account for this.

[chhackett]

@Macroniop
Are you seeing the error when using hascard? Or some other app?

@Studywarscat
I'm not sure if you are a haskell developer, but on the chance that you are, and you have ghcup, could you run 'ghcup -tui' in powershell? I'm wondering if the same problem occurs with any app that relies on vty-windows or not.

Also do either of you guys see this error if you run your app in a Command Shell?

@jtdaugherty @ShrykeWindgrace
I've tried to reproduce this issue on my own systems and haven't been successful. I am aware of a very recent blog post regarding this exception: https://well-typed.com/blog/2024/01/when-blocked-indefinitely-is-not-indefinite/

After reading that a few times, it occurs to me that perhaps this error is indicating that the input thread is no longer able to produce input. The only way I can see that happening is if an exception is thrown in one of the Windows API calls. Right now the library does not correctly record exceptions on the input thread in the debug log unfortunately. So I'll fix that, and at least we can make that available to the users so they can gather the debug log for analysis.

[ShrykeWindgrace]

I tried running latest release of hascard-0.6.0.1 on my machine (win10, windows terminal-1.18, pwsh-7.4.1), I could not reproduce this problem; maybe something else is at play.

[hreinhardt]

I have the same issue when running ghcup tui. It only occurs in Windows Terminal 1.19, not older versions.

[ShrykeWindgrace]

@hreinhardt That's an important piece of information. I have a preview version of WT (1.20-preview), and it indeed breaks all vty-based apps, no need for brick. Even vty-event-echo is affected.

[chhackett]

Wow, ok. Thank you for the information guys, that really helps! I'll see what I can do, probably tonight.
I also see it now. Hopefully this won't be too difficult to fix.

Edit: It looks like this may actually be a bug in Microsoft Terminal itself. See: microsoft/terminal#16343

I'll see if there is a workaround, but the solution might be to upgrade to Terminal 1.20 which I believe has fixed the issue.

[hreinhardt]

I tested the newest available Terminal release from Github (1.20.10572.0) and it still crashes for me.

[ShrykeWindgrace]

@chhackett I tested latest WT-1.20 yesterday, it crashes native vty-based apps. However, it does not crash linux-built vty-based apps in WSL, at least we have that.

[hreinhardt]

After some debugging, it seems the error originates here: https://github.com/chhackett/vty-windows/blob/main/src/Graphics/Vty/Platform/Windows/WindowsConsoleInput.hsc#L185

Looking at that peek function, I wonder why event has the type DWORD instead of WORD. According to the Microsoft Docs it should be WORD. Or maybe I'm misunderstanding something.

[hasufell]

I don't know how this works, but I'm willing to set a bounty on this ticket with opencollective money from ghcup. Unless someone thinks they can and want to do it in their free time.

I'd like to get this resolved soon and make a new ghcup release containing the fix.

[hreinhardt]

The fix might be as simple as changing DWORD to WORD here: https://github.com/chhackett/vty-windows/blob/f760f631f33989c83730aaf0c0519ef556633355/src/Graphics/Vty/Platform/Windows/WindowsConsoleInput.hsc#L173

I just tested building ghcup with this change and ghcup tui does seem to work fine in Windows Terminal 1.19.

[chhackett]

Thank you @hreinhardt for your investigation on this. I've been unable to make progress in the last few days (weeks actually) due to some unrelated issue my haskell toolchain. (Would love some help with that if anyone has advice!)

But what I can do is make your change on a branch. If someone could test it and give me a thumbs up I'd be willing to publish a new version.

Btw, my unrelated problem is that I can't seem to reliably build .hsc files. Something happens during the hsc2hs stage of compilation, causing the generated .hs files to be invalid. This mostly affects builds of the Win32 library.

I've tried various versions of ghc, going back to 8.10.7, and various versions of Win32 library. Nothing makes a difference.

I've never run into this behavior before and don't really have any ideas how to make progress at the moment.

[chhackett]

Made the change on a branch. @hreinhardt - is this the correct change?
https://github.com/chhackett/vty-windows/pull/17/files

[hreinhardt]

Yes. For consistency it might make sense to also update the five DWORD types in the poke method above, although I don't know if that is actually ever used.

Regarding your hsc2hs problems, what do you mean by "invalid". Are the generated files syntactically invalid Haskell?

[hasufell]

According to the Microsoft Docs it should be WORD. Or maybe I'm misunderstanding something.

Can you link to those docs?

[chhackett]

Big success. I just re-installed my haskell toolchain, and the build problems magically went away. I guess something got corrupted.
I'll verify the change, and get this published today. Sorry for the long wait.

[hreinhardt]

Can you link to those docs?

https://learn.microsoft.com/en-us/windows/console/input-record-str

[chhackett]

Fixed the poke function too...

[hreinhardt]

I've tested the newest pull-request (including the poke-changes) and ghcup tui works fine for me in Windows Terminal 1.18, 1.19 and 1.20.

[chhackett]

OK, I've decided to go ahead and publish. Version 0.2.0.2 is available on hackage.
Thank you for the assistance @hreinhardt.

[jtdaugherty]

Does anyone need anything else before we can consider this resolved?

[hasufell]

I don't see an entry in the changelog: https://hackage.haskell.org/package/vty-windows-0.2.0.2/changelog

That will make it harder for end users to find this.

Additionally, this should be backported to the 0.1 branch.

[jtdaugherty]

this should be backported to the 0.1 branch

@hasufell is there some specific reason you're wanting this? (It doesn't make much difference to me personally, but I don't see backporting of bugfixes that often and judging by the changelog, I don't see a reason why anyone would necessarily need to stick with 0.1 and not upgrade.)

[hasufell]

Yes, the dependency constraints are different and branch 0.1 is effectively broken causing potential churn for end users to upgrade to 0.2 branch.

[jtdaugherty]

Hmm, okay. I don't see any mention of dependency constraint changes in 0.2 that would differ from 0.1. Perhaps they just aren't captured there?

[hasufell]

vty (>=6.0 && <7.0)

vty (>=6.1)

[jtdaugherty]

@hasufell oh, thanks! @chhackett I recommend explicitly mentioning package dependency constraint changes in the changelog as well.

[jtdaugherty]

Thanks, everyone! I'm glad you all were able to figure out what was going on!