#377 segmentation fault on replace

release
closed-fixed
Program (402)
5
2004-07-15
2004-07-08
No

This appeared in both 5.3 and 5.4 releases.
I just installed your RPM for 5.4 and the problem still
occurs:
when researching for replacement something like
a(.|\n)*b
with "keep dialog" and "regular expression" set, nedit
ends in seg fault when I try to find the pattern.

The file I am editing is a big html file (attached).

My system : redhat linux 9.0

Discussion

  • Eddy De Greef

    Eddy De Greef - 2004-07-08

    Logged In: YES
    user_id=73597

    Please check the "Check to Upload and Attach a File" box
    when you attach a file. Nothing is attached right now.

     
  • Eddy De Greef

    Eddy De Greef - 2004-07-08

    Logged In: YES
    user_id=73597

    The file is no longer necessary. It's easy to reproduce it
    on any file of relative large size.
    It's a stack overflow problem in the recursive
    implementation of regular expression searches. This problem
    must have existed since the introduction of regular
    expressions in NEdit. It is rather hard to fix, but I'll see
    what I can do.

     
  • Eddy De Greef

    Eddy De Greef - 2004-07-08
    • assigned_to: nobody --> edg
     
  • Nathan Gray

    Nathan Gray - 2004-07-14

    Logged In: YES
    user_id=121553

    Eddy, I know this is an older bug but it would be nice to at least prevent
    the segfault in 5.5, even if the fix is not fantastic. Would a simple
    recursion counter/limit be a viable workaround for the time being?

    By the way, I can't reproduce this on OS X, but maybe I didn't try a big
    enough file. How big does the file have to be?

     
  • Eddy De Greef

    Eddy De Greef - 2004-07-14

    Logged In: YES
    user_id=73597

    I have attached a patch with a "simple" recursion counter
    check. It already requires 60 (!) changes to regularExp.c,
    if I didn't miss anything. That's why I am a bit reluctant
    to commit it now.

    The main problem with such a solution is that you can never
    be sure that the limit is safe on all platforms. At work, I
    got a crash after about 80 000 recursive calls, while at
    home it crashed already after 40 000 calls. Both are
    relatively recent Linux systems. It's dependent on the
    compiler, on the process stack size limit (which the user
    can freely choose), possibly on the expression, and probably
    on some other platform parameters.

    Another problem is the fact that with the current regex API
    it is only possible to write some error message to stderr,
    so the user may not even see the message. But that's only a
    minor issue compared to the crash (and we can still extend
    the API later on).

    I've now set the limit to 10 000 calls, which I expect to be
    relatively safe, but it should be tested on more platforms.

    To reproduce it with the simplest pattern, (.|\n)*, you need
    a file whose length is at least one fourth of recursion
    limit on your platform (which is in the order of 1/100 of
    the maximum process stack size). Eg: max stack size of 8 MB
    -> recursion limit = +/- 80000 -> file size = +/- 20000 bytes.

    A better solution would be to avoid the recursion
    completely, but that means a major rewrite of the matching
    engine. I don't even know that we ever want to do that,
    because a recursive implementation is conceptually much
    simpler. Since the problem is very rare, a recursion counter
    is probably a good compromise.

    So, what shall I do? Commit it now?

     
  • Eddy De Greef

    Eddy De Greef - 2004-07-15
    • status: open --> closed-fixed
     
  • Eddy De Greef

    Eddy De Greef - 2004-07-15

    Logged In: YES
    user_id=73597

    A less-intrusive version of the patch is in CVS. I've
    tripple-checked it and it looks safe.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks