Closed voxik closed 10 months ago
Hi @voxik, based on the generated output and the Rakefile
it looks like puma has been using ragel version 6 to generate the code. I would recommend using that.
I'll look into this problem with ragel 7 though. The goal is for ragel 6 code to work properly with ragel 7.
Looking at the parser, ran the test suite (on intel) and nothing stands out as the possible cause. Do you have access to an s390x? I would love to know what percentage of runs fail with ragel-6 vs ragel-7, and when it does fail, what are the values of parser->nread
and len
?
Hi @voxik I still haven't been able to debug this, but I did fix a critical bug on big-endian SPARC and PPC, and was wondering if these problems might now be fixed as well? I noticed the "IBM System/390" is also big-endian.
Unfortunately, Ragel was not updated for some while on Fedora. Any chance to point some specific commit?
Testing on Fedora with ragel-7.0.4-2.fc39.s390x, I can't see any problem. Closing this and thank you very much for looking into this.
I am packaging Puma web server [1] for s390x on Fedora and I use Ragel 7.0.0.12 to regenerate its http parser [2]. However, when running test suite, it frequently (almost always) fails on s390x with this error:
It does not appear the original upstream generated file [3] suffers the same issues. So I wonder, what is the difference between 7.0.0.9 presumably used upstream and the 7.0.0.12. Does the Ragel 7.0.0.12 correctly support s390x, which is big-endian platform. Or is the bug in the parser? There was not change in recent years AFAIK.