Open koliyo opened 2 months ago
With hylo code, I mean the hylo compiler code, skipping the extra layer of async indirection. If I take the content of the buildProgram
function and put it directly in the main
function, I no longer get the crash.
I am very curious to the cause of this bug, and I think it is worth investigating as it could potentially be some "hidden" problem in the hylo compiler that might turn up at some other time(?). It is very possible it is some misconfiguration on my part, but the code for reproducing the bug is very minimal. It is just the main
branch of the hylo repo, with the changeset linked above (https://github.com/hylo-lang/hylo/commit/c60d2dd2e8c8f4f74c9fdc68820e9554f7634267). It is just an additional executable declared in the Package.swift
, and the short main entry point shown above.
As a start it would be interesting to hear if anyone else can reproduce the bug. As I said, on my machine it happens 100% of the time.
Sounds like the spooky bug we had with parallel type checking. See here https://github.com/hylo-lang/hylo/issues/1162
Ah interesting! Yeah that makes sense, blowing the stack, and the dispatch threads having a smaller stack to work with.
In my Hylo-LSP prototype I have an async main entrypoint and I noticed that I am now getting memory corruption (SIGBUS) when running the type checker in hylo.
I managed to make a minimal application that demonstrates the problem. It is 100% reproducible on my machine. Here is the code:
https://github.com/hylo-lang/hylo/commit/c60d2dd2e8c8f4f74c9fdc68820e9554f7634267
Specifically the main entrypoint, which looks like this:
When running this, I get a crash during type checking:
Note that I only get the crash with the two step async dispatch pattern in
MyApp
.If I place the hylo code directly in the async main function the code completes without crashing.