Maximum recursion limit exceeded

[markusgritsch]

BPO	561047
Nosy	@smontanaro

^{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:

assignee = None
closed_at = <Date 2002-06-02.13:03:53.000>
created_at = <Date 2002-05-27.12:27:16.000>
labels = ['expert-regex']
title = 'Maximum recursion limit exceeded'
updated_at = <Date 2002-06-02.13:03:53.000>
user = 'https://bugs.python.org/markusgritsch'

bugs.python.org fields:

activity = <Date 2002-06-02.13:03:53.000>
actor = 'skip.montanaro'
assignee = 'effbot'
closed = True
closed_date = None
closer = None
components = ['Regular Expressions']
creation = <Date 2002-05-27.12:27:16.000>
creator = 'markus_gritsch'
dependencies = []
files = []
hgrepos = []
issue_num = 561047
keywords = []
message_count = 3.0
messages = ['10936', '10937', '10938']
nosy_count = 4.0
nosy_names = ['effbot', 'skip.montanaro', 'calvin', 'markus_gritsch']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue561047'
versions = []

[markusgritsch]

Hi!

I think I discovered a limitation of the "new" Regular
Expression engine. I
have put together an example which shows the behavior at

http://stud4.tuwien.ac.at/~e9326522/temporary/re_bug_example.zip
(69kB)

When the script is run with Python 1.5.2 by invoking
psmergeNS.py *.ps

everything is fine and it produces a merged output file
containing both
PostScript files.

When using Python 2.x the following Exception is raised:

  Traceback (most recent call last):
    File "psmergeNS4.py", line 35, in ?
      pages = theRE.findall(contents)
  RuntimeError: maximum recursion limit exceeded

This behavior is the same with the Linux and the Win32
version of Python.

Markus

[calvin]

Logged In: YES
user_id=9205

I had the same problem, but only when using *? matching
several kB text.
It seems the the *? backtracking function is recursive and
cannot handle several thousand characters...

Greetings

[smontanaro]

Logged In: YES
user_id=44345

Saving /F the trouble of closing this, since it's a duplicate of
<http://python.org/sf/493252\> and several others. Read the followups
there for ways to avoid/workaround the problem. If you absolutely can't
modify your regular expression to be less abusive of the stack, you can
always

    import pre as re

and deal with the long match times you'll encounter instead.