Navigation Menu

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

Jump to bottom

sys.call_tracing segfaults #47911

Closed
devdanzin mannequin opened this issue Aug 24, 2008 · 6 comments
Closed

sys.call_tracing segfaults #47911

devdanzin mannequin opened this issue Aug 24, 2008 · 6 comments
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) release-blocker type-crash A hard crash of the interpreter, possibly with a core dump

Comments

@devdanzin
Copy link
Mannequin

devdanzin mannequin commented Aug 24, 2008

BPO 3661
Nosy @warsaw, @tiran, @devdanzin, @benjaminp
Files
  • fix_call_tracing_segfault.patch
    		•

    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-10-17.01:30:08.366>
created_at = <Date 2008-08-24.19:29:04.699>
labels = ['interpreter-core', 'type-crash', 'release-blocker']
title = 'sys.call_tracing segfaults'
updated_at = <Date 2008-10-17.01:30:08.365>
user = 'https://github.com/devdanzin'

    bugs.python.org fields:

    activity = <Date 2008-10-17.01:30:08.365>
actor = 'barry'
assignee = 'none'
closed = True
closed_date = <Date 2008-10-17.01:30:08.366>
closer = 'barry'
components = ['Interpreter Core']
creation = <Date 2008-08-24.19:29:04.699>
creator = 'ajaksu2'
dependencies = []
files = ['11702']
hgrepos = []
issue_num = 3661
keywords = ['patch', 'needs review']
message_count = 6.0
messages = ['71853', '71856', '71857', '72458', '74320', '74887']
nosy_count = 4.0
nosy_names = ['barry', 'christian.heimes', 'ajaksu2', 'benjamin.peterson']
pr_nums = []
priority = 'release blocker'
resolution = 'accepted'
stage = None
status = 'closed'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue3661'
versions = ['Python 3.0']
    @devdanzin
    Copy link
    Mannequin Author

    devdanzin mannequin commented Aug 24, 2008

    The following code causes a segfault for me:

    import sys; sys.call_tracing(type,2)

    Running on:
    Python 3.0b3+ (py3k:66015, Aug 24 2008, 16:21:19)
    [GCC 4.1.3 2007092 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2

    gdb output:
    [New Thread -1210857280 (LWP 8823)]
    python: Objects/typeobject.c:1854: type_new: Assertion `args != ((void
    *)0) && ((((((PyObject*)(args))->ob_type))->tp_flags & ((1L<<26))) !=
    0)' failed.

    Program received signal SIGABRT, Aborted.
    [Switching to Thread -1210857280 (LWP 8823)]
    0xffffe410 in __kernel_vsyscall ()
    (gdb) backtrace
    #0 0xffffe410 in __kernel_vsyscall ()
    #1 0xb7d67875 in raise () from /lib/tls/i686/cmov/libc.so.6
    #2 0xb7d69201 in abort () from /lib/tls/i686/cmov/libc.so.6
    #3 0xb7d60b6e in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
    #4 0x0806e802 in type_new (metatype=0x81ba120, args=0x81fbda8,
    kwds=0x0) at Objects/typeobject.c:1854
    #5 0x0806bd0e in type_call (type=0x81ba120, args=0x81fbda8, kwds=0x0)
    at Objects/typeobject.c:636
    #6 0x08118ec5 in PyObject_Call (func=0x81ba120, arg=0x81fbda8, kw=0x0)
    at Objects/abstract.c:2181
    #7 0x080b2ac5 in _PyEval_CallTracing (func=0x81ba120, args=0x81fbda8)
    at Python/ceval.c:3109
    #8 0x080e7830 in sys_call_tracing (self=0xb7f073b4, args=0xb7a53bcc) at
    Python/sysmodule.c:771
    #9 0x081626b1 in PyCFunction_Call (func=0xb7f081bc, arg=0xb7a53bcc,
    kw=0x0) at Objects/methodobject.c:81
    #10 0x080b378f in call_function (pp_stack=0xbf9b6b84, oparg=2) at
    Python/ceval.c:3403
    #11 0x080ae8d2 in PyEval_EvalFrameEx (f=0x829bb14, throwflag=0) at
    Python/ceval.c:2205
    #12 0x080b1c24 in PyEval_EvalCodeEx (co=0xb7a9b9e8, globals=0xb7f0b5d4,
    locals=0xb7f0b5d4, args=0x0, argcount=0, kws=0x0,
    kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at
    Python/ceval.c:2840
    #13 0x080a69cb in PyEval_EvalCode (co=0xb7a9b9e8, globals=0xb7f0b5d4,
    locals=0xb7f0b5d4) at Python/ceval.c:519
    #14 0x080df64b in run_mod (mod=0x82a2aa0, filename=0x819e3be "<string>",
    globals=0xb7f0b5d4, locals=0xb7f0b5d4,
    flags=0xbf9b6f60, arena=0x82b1060) at Python/pythonrun.c:1560
    #15 0x080df393 in PyRun_StringFlags (str=0x8203fd8 "import sys;
    sys.call_tracing(type,2)\n", start=257, globals=0xb7f0b5d4,
    locals=0xb7f0b5d4, flags=0xbf9b6f60) at Python/pythonrun.c:1494
    #16 0x080ddd37 in PyRun_SimpleStringFlags (command=0x8203fd8 "import
    sys; sys.call_tracing(type,2)\n", flags=0xbf9b6f60)
    at Python/pythonrun.c:1073
    #17 0x080ef5ca in Py_Main (argc=2, argv=0xb7ede028) at Modules/main.c:533
    #18 0x0805a689 in main (argc=2, argv=0xbf9b80b4) at ./Modules/python.c:57

    @devdanzin devdanzin mannequin added interpreter-core (Objects, Python, Grammar, and Parser dirs) type-crash A hard crash of the interpreter, possibly with a core dump labels Aug 24, 2008
    @tiran
    Copy link
    Member

    tiran commented Aug 24, 2008

    The function call fails much earlier in debug builds. sys_call_tracing()
    doesn't check the type of the second argument. It must be a tuple
    because it's directly passed to the PyObject_Call() API.

    Suggestion: Add an explicit type check for PyTupleType the
    sys_call_tracing() function

    Check 2.6, too

    @benjaminp
    Copy link
    Contributor

    Not applicable in 2.6:

    Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: type() takes 1 or 3 arguments

    @warsaw
    Copy link
    Member

    warsaw commented Sep 4, 2008

    This bug should be fixed for rc2, but it doesn't need to block rc1.

    @benjaminp
    Copy link
    Contributor

    Attaching patch.

    @warsaw
    Copy link
    Member

    warsaw commented Oct 17, 2008

    r66949

    @warsaw warsaw closed this as completed Oct 17, 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
    Assignees
    No one assigned
    Labels
    interpreter-core (Objects, Python, Grammar, and Parser dirs) release-blocker type-crash A hard crash of the interpreter, possibly with a core dump
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    3 participants
    @warsaw @benjaminp @tiran