Skip to content
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

RuntimeWarning: tp_compare didn't return -1 or -2 #45068

Closed
fabioz mannequin opened this issue Jun 8, 2007 · 6 comments
Closed

RuntimeWarning: tp_compare didn't return -1 or -2 #45068

fabioz mannequin opened this issue Jun 8, 2007 · 6 comments
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs)

Comments

@fabioz
Copy link
Mannequin

fabioz mannequin commented Jun 8, 2007

BPO 1733757
Nosy @birkenfeld, @amauryfa, @fabioz
Files
  • case4.py: Code (when run prints error)
  • 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 2008-04-03.23:10:09.308>
    created_at = <Date 2007-06-08.18:58:19.000>
    labels = ['interpreter-core']
    title = "RuntimeWarning: tp_compare didn't return -1 or -2"
    updated_at = <Date 2008-04-03.23:10:09.190>
    user = 'https://github.com/fabioz'

    bugs.python.org fields:

    activity = <Date 2008-04-03.23:10:09.190>
    actor = 'amaury.forgeotdarc'
    assignee = 'none'
    closed = True
    closed_date = <Date 2008-04-03.23:10:09.308>
    closer = 'amaury.forgeotdarc'
    components = ['Interpreter Core']
    creation = <Date 2007-06-08.18:58:19.000>
    creator = 'fabioz'
    dependencies = []
    files = ['2391']
    hgrepos = []
    issue_num = 1733757
    keywords = []
    message_count = 6.0
    messages = ['32286', '32287', '32288', '64858', '64867', '64908']
    nosy_count = 5.0
    nosy_names = ['georg.brandl', 'amaury.forgeotdarc', 'aspineux', 'fabioz', 'peaker']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = None
    status = 'closed'
    superseder = None
    type = None
    url = 'https://bugs.python.org/issue1733757'
    versions = ['Python 2.5']

    @fabioz
    Copy link
    Mannequin Author

    fabioz mannequin commented Jun 8, 2007

    The code attached is giving the error below

    D:\bin\Python251\Lib\threading.py:697: RuntimeWarning: tp_compare didn't return -1 or -2 for exception
    return _active[_get_ident()]
    Exception exceptions.SystemError: 'error return without exception set' in <generator object at 0x00B07E68> ignored
    Ok, I have no clues why there could be an error here...

    @fabioz fabioz mannequin added the interpreter-core (Objects, Python, Grammar, and Parser dirs) label Jun 8, 2007
    @peaker
    Copy link
    Mannequin

    peaker mannequin commented Jun 9, 2007

    Bug bpo-1733973 is related.

    What is happening in this bug, is that tokenize.tokenize is using generate_tokens to generate the tokens. Since tokeneater() fails while the iteration is occuring, the exception is raised and it unwinds the tokenize() call. This garbage collects the generate_tokens generator -- which throws a GeneratorExit into the generator.

    This time, sysmodule.c's trace_trampoline is the one assuming it can overwrite PyErr_*.

    Maybe the correct way of fixing the bug is saving+clearing/restoring PyErr_* in ceval.c:call_trace, rather than in each trace/profile handler.

    The upside is that they all seem to assume that they can overwrite PyErr_* and this will fix them all.
    The downside is that the PyErr_* that's been set in the frame will not be accessible to the trace function. This can be fixed by storing it in some global.

    Basically, the fix is to call PyErr_Fetch before the trace/profile func, and PyErr_Restore after it. The problem is that the trace/profile func is a function ptr in the PyThreadState that's used by more than Python's ceval.c. It seems to be liberally used by pyexpat and others. This means that this function pointer should always point at the wrapper function rather than the given function, which means storing more information in the thread state, and then extracting it from the thread state again.

    This got more complicated and intricate than I intended, and the whole thing has a wrong feel to it - as it seems to me that all calls to the trace/profile func should be in one centralized place, and that place should be wrapped.

    I hope someone else will implement the fix or at least comment on this. If anyone is not clear on what the fix is, please post questions (and if this bug system has mailing notifications) and I'll further explain.

    @birkenfeld
    Copy link
    Member

    Note that there is already a call_trace_protected in ceval.c which saves/restores the exception,
    it just doesn't seem to be called in this instance.

    @aspineux
    Copy link
    Mannequin

    aspineux mannequin commented Apr 2, 2008

    This has chnaged with python-2.5.2.
    runing python openpkg under linux centos-5.1,
    the test case case4.py don't give any error message anymore, but
    still block like with 2.5.1:
    # strace -p 937
    Process 937 attached - interrupt to quit
    futex(0x9b9cc78, FUTEX_WAIT, 0, NULL

    Hope this help

    @aspineux aspineux mannequin changed the title RuntimeWarning: tp_compare didn't return -1 or -2 RuntimeWarning: tp_compare didn't return -1 or -2 Apr 2, 2008
    @amauryfa
    Copy link
    Member

    amauryfa commented Apr 2, 2008

    The "funny" errors around trace & exceptions have been corrected with
    bpo-1265.

    The remaining problem is a livelock: when the interpreter exits,
    threading.Thread.__delete is called, and this calls
    "_active_limbo_lock.acquire".

    But the sys.settrace is still enabled... and threading.currentThread()
    can also call "_active_limbo_lock.acquire" when the main thread cannot
    be found...

    A solution could be to clear sys.settrace when closing the interpreter.

    @amauryfa
    Copy link
    Member

    amauryfa commented Apr 3, 2008

    The deadlock was resolved by r62136.
    I think I was lucky this time. I was close to disable sys.settrace
    before interpreter shutdown. But is would disallow debugging inside the
    finalization procedures.

    @amauryfa amauryfa closed this as completed Apr 3, 2008
    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    interpreter-core (Objects, Python, Grammar, and Parser dirs)
    Projects
    None yet
    Development

    No branches or pull requests

    2 participants