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
internal error in regular expression engine #62198
Comments
On Linux Ubuntu 13.04, i686: $ uname -a
Linux arando 3.5.0-26-generic #42-Ubuntu SMP Fri Mar 8 23:20:06 UTC 2013 i686 i686 i686 GNU/Linux $ python
Python 2.7.5 (default, May 17 2013, 18:43:24)
[GCC 4.7.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> re.compile('(.*)\.[0-9]*\.[0-9]*$', re.I|re.S).findall('3.0.0')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
RuntimeError: internal error in regular expression engine This is a 2.7.5 regression, 2.7.4 worked fine. |
27162465316f |
Also, note this particular case only reproduces on 32 bit. |
I'm able to confirm Benjamin's notes. The regexp works on 64bit Linux but fails with a 32bit build: $ CFLAGS="-m32" LDFLAGS="-m32" ./configure
$ make -j10
$ ./python -c "import re; print(re.compile('(.*)\.[0-9]*\.[0-9]*$', re.I|re.S).findall('3.0.0'))"
Traceback (most recent call last):
File "<string>", line 1, in <module>
RuntimeError: internal error in regular expression engine |
Here are some simpler examples of the bug: re.compile('.*yz', re.S).findall('xyz') Unfortunately I find it difficult to see what's happening when single-stepping through the code because of the macros. :-( |
Here is a patch which should fix this bug. I still have to look for similar bugs and write tests. |
Thank you Matthew for simpler examples. They helped and I'll use them in the tests. |
Perhaps it would be safer to revert the original commit in bugfix branches, and just commit the better patch in default? |
what's the status on this one? Can the proposed patch be applied until the decision whether to backout the original change, or not? |
I'm working on tests. No need to rush. |
There is now a need to rush. I'm hoping to cut the release in about two days, so we can have Python 3.4a1 on time. Can we resolve this in the next day or two? Sorry for the short notice. |
Can I downgrade this to "deferred blocker"? That means we still need to deal with it before the release, but we don't have to hold up Python 3.4a1 for it. |
I'm downgrading this to "deferred blocker". I'm sure we'll get it fixed for Python 3.4 final, but in the meantime there's no sense in holding up Python 3.4a1 for it. |
New changeset 86b8b035529b by Serhiy Storchaka in branch '3.3': New changeset 36702442ffe0 by Serhiy Storchaka in branch 'default': New changeset e5e425fd1e4f by Serhiy Storchaka in branch '2.7': |
Sorry for the delay. I have committed a simple patch which fixes this bug. But I don't close the issue still because there are other related issues. |
This appears to have turned the buildbots red. |
This broke the test suite on all the 32-bit Linux buildbots. Sample output is here: There's no obvious fix, and I want to cut 3.4a1 right about now, so I'm going to tag the version in trunk just before this checkin. |
See bpo-18647. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: