[Bug 5516] New: hglib doesn't reset the command server after an unexpected prompt

mercurial-bugs at mercurial-scm.org mercurial-bugs at mercurial-scm.org
Tue Mar 28 05:36:26 EDT 2017


            Bug ID: 5516
           Summary: hglib doesn't reset the command server after an
                    unexpected prompt
           Product: Mercurial
           Version: 4.1.1
          Hardware: PC
                OS: Windows
            Status: UNCONFIRMED
          Severity: bug
          Priority: urgent
         Component: hglib
          Assignee: bugzilla at mercurial-scm.org
          Reporter: gabor.stefanik at nng.com
                CC: mercurial-devel at mercurial-scm.org

When hglib encounters an unexpected prompt from the command server, it raises a
ResponseError exception. However, it fails to reset/resynchronize with the
command server. As a result, if you catch that exception, and try to run
another command, it will behave in unpredictable ways, up to and including a
hard lockup that doesn't even respond to Ctrl+C.

As an example, load the following in-process hook:
from mercurial import util

def hook(ui, repo, *args, **kwargs):
        repo.ui.promptchoice("dummy $$ &OK", 0)
    except util.Abort:

    return False

as a "pre-pull" hook. Then, execute the following code:

client = hglib.open('.')
except hglib.error.ResponseError:
newtip = client.log(revrange='tip')

On my machine, this locks up in client.log inside a read(), and the command
server process itself leaks several gigabytes of memory. The only way out is to
manually kill the command server in Task Manager. It appears that hglib never
resets the command server to a "command waiting" state, and so the log command
is actually interpreted as a response to the prompt.

We should either reset the command server before raising the exception, or flag
the client as dead and deny further commands on it.

You are receiving this mail because:
You are on the CC list for the bug.

More information about the Mercurial-devel mailing list