-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Get main test-suite running on Windows #773
base: main
Are you sure you want to change the base?
Conversation
get main test-suite running on Windows
The line numbers reported by MDX don't exist and are very large. MDX is probably stuck in a parsing loop. It would be good to shrink the md file to get a minimal test-case that demonstrates the problem and report it at https://github.com/realworldocaml/mdx/issues. Thanks! |
Ok, just for clarification please @talex5 when you say shrink the file?, do you mean probably running a specific test file instead, since the lines captured in the files are non existent? |
I mean that the |
Ok, got it, let me work on that @talex5 |
Hi @talex5 I've reduced the Would you recommend further steps to debug this, or should I proceed to report this as a possible parsing issue with MDX? Thanks for the guidance! |
That's great news! It's much easier to debug a problem in a 10 line file. Can you make it even shorter? Can you still get it to stack overflow if the file doesn't use Eio at all? And then see if you can get the crash by running ocaml-mdx on it manually, outside of Eio. |
Ok. So in essence, aim to isolate the problem without any dependency on Eio right? |
Yes, if possible. Then we know the problem isn't in Eio and must be in MDX. |
Ok, on it, will give feedback soon |
@talex5 I think this suggests that ocaml-MDX may be running into parsing issues, even with a very basic setup. Please let me know if you’d like me to proceed further in a specific way. Thanks again for the guidance! |
That doesn't look like a valid Markdown file, the code block has no closing backticks (i.e. ```). I don't think MDX should stack overflow in such a case, however, it doesn't seem to be blocking this particular piece of work maybe ? |
@patricoferris ooh, I must have missed that closing back ticks, but I'm not sure that's the issue though, but I'll try it however. I did try running a test using various blocks within the markdown file till it got reduced to this as previously stated by @talex5 The stack overflow keeps occurirng on several tests occasions |
Oh wow, just discovered something now. I deleted and reinstalled the Tried lines 1 to 142 so far with no stack overflow How do I proceed from here? Should I keep testing till I get to the end of the line for the markdown file for proper verification? @talex5 @patricoferris |
Ah, yes. Looks like I reported that back in 2023: realworldocaml/mdx#420
I don't see why opam would have any effect on that. Did you perhaps also reinstall Git with a different line-endings setting? e.g. realworldocaml/mdx#294 (comment) Or maybe you're using a different version of MDX. Did you keep a copy of the old installation? Would be good to compare if so. In any case, the tests are still failing in the CI: https://github.com/ocaml-multicore/eio/actions/runs/11529311468/job/32119632533?pr=773#step:6:32 |
No, I didn't keep a copy. Yeah the CI tests still fail because I'm yet to push the changes to this branch. I don't know but I'm really noticing some issues that seem not to be adding up @talex5 dunno if it's a clone problem though. I noticed any markdown file I edit after cloning (by deleting the code and using the code from the parent repo, a simple copy and paste again) runs successfully when tested. But any markdown code on my clone that I run without editing hangs. The difference I noticed between the two files are the backtics at the end of a block. And if this is the case, it would mean rewriting all the tests in my cloned repo before pushing to commit. |
@talex5 @patricoferris Now every other test seem to be failing the CI, and I really don't know what the issue is exactly, tried different approaches already but still fails. Would appreciate some guidance please Thank you |
The CI says |
Hmmm... just checked. Thank you so much for drawing my attention to that So apparently I did, let me edit and re-commit |
ocaml-ci still fails @talex5 @patricoferris , the reason does not seem to be clear to me in the logs either, please kindly look into it |
Seems pretty clear:
This is the problem you're trying to fix. |
Hi @talex5 I’ve worked through several iterations with the test files to isolate the root cause of the stack overflow and test hanging issues:
I think these findings suggest that the issue might be due to a parsing loop or compatibility issue with mdx. I would appreciate any guidance on further isolating the issue. Thank you! |
Based on these failures, should I go ahead and report the issue at https://github.com/realworldocaml/mdx/issues @talex5 @patricoferris |
That's very good! Does the test use anything from Eio? If you can get it to fail just using the OCaml stdlib that would be even better. This avoids any possible confusion about which project (Eio or MDX) is causing the bug. |
Hi @talex5 So as suggested, I tested the trace.md file and other markdown files too both with and without Eio dependencies. Here’s what I found:
Based on these findings, it seems the bug might indeed be related to Eio rather than mdx. |
OK, then could you find out which Eio library causes the problem. e.g. what happens if you just require If it still fails for Keep trying to make the failing and succeeding cases more similar until you find the cause of the difference. |
Issue: #761
This PR modifies the Eio test suite to run on Windows by removing the conditional
enabled_if (<> %{os_type} "Win32"
in tests/dune.After enabling the test suite on Windows, these were some of my observations:
opam install mdx
and worked well when run on Windows locally.dune runtest
led to stack overflow errors in multiple MDX-related files, specifically in fd_passing.md, condition.md, domains.md, buf_reader.md, exn.md, buf_write.md, and others. (See image below)SUGGESTION
I think we can consider increasing the stack size to see if that will completely resolve all failures with the stack overflow ouput
I look forward to your thoughts on this @talex5 @patricoferris