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.

Sign up for GitHub

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

Segfault in stringobject.c #48608

Closed
farshad mannequin opened this issue Nov 19, 2008 · 8 comments
Closed

Segfault in stringobject.c #48608

farshad mannequin opened this issue Nov 19, 2008 · 8 comments
Labels
topic-XML type-crash A hard crash of the interpreter, possibly with a core dump

Comments

@farshad
Copy link
Mannequin

farshad mannequin commented Nov 19, 2008

BPO 4358
Nosy @amauryfa, @vstinner
Files
  • backtrace1: GDB Backtrace
  • backtrace2: GDB Backtrace
    		•

    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 2009-03-24.23:37:22.508>
created_at = <Date 2008-11-19.18:34:29.799>
labels = ['expert-XML', 'invalid', 'type-crash']
title = 'Segfault in stringobject.c'
updated_at = <Date 2009-03-24.23:37:22.507>
user = 'https://bugs.python.org/farshad'

    bugs.python.org fields:

    activity = <Date 2009-03-24.23:37:22.507>
actor = 'vstinner'
assignee = 'none'
closed = True
closed_date = <Date 2009-03-24.23:37:22.508>
closer = 'vstinner'
components = ['XML']
creation = <Date 2008-11-19.18:34:29.799>
creator = 'farshad'
dependencies = []
files = ['12063', '12064']
hgrepos = []
issue_num = 4358
keywords = []
message_count = 8.0
messages = ['76066', '76067', '76069', '76078', '76091', '76184', '83720', '84124']
nosy_count = 3.0
nosy_names = ['amaury.forgeotdarc', 'vstinner', 'farshad']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = None
status = 'closed'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue4358'
versions = ['Python 2.5']
    @farshad
    Copy link
    Mannequin Author

    farshad mannequin commented Nov 19, 2008

    I'm encountering random segfaults on multiple machines. By examining
    core dumps, it's all happening in stringobject.c (_PyString_Resize or
    string_join).
    By using pyframev I figured out it's always happening inside
    xmlrpclib.py (/usr/lib/python2.5/xmlrpclib.py (716): dump_struct or
    /usr/lib/python2.5/xmlrpclib.py (627): dumps)

    I'm using Python 2.5.2 on debian in a threaded environment with heavy
    use of xmlrpc.

    @farshad farshad mannequin added the topic-ctypes label Nov 19, 2008
    @farshad farshad mannequin assigned theller Nov 19, 2008
    @farshad farshad mannequin added topic-XML type-crash A hard crash of the interpreter, possibly with a core dump labels Nov 19, 2008
    @farshad
    Copy link
    Mannequin Author

    farshad mannequin commented Nov 19, 2008

    Another Backtrace. I have three other core dumps with exact same
    backtrace on two different machines.

    @theller
    Copy link

    theller commented Nov 19, 2008

    Has nothing to do with ctypes (the package), unassigning.

    @theller theller removed their assignment Nov 19, 2008
    @amauryfa
    Copy link
    Member

    This is difficult: the backtrace only show plain python operations.
    Some hints though:

    One backtrace shows a memory corruption in the obmalloc data. This may come from a
    buffer overrun.

    You initially selected ctypes in "Components", does this mean that your program
    also use ctypes?
    With ctypes it is easy to be caught with a python string converted to a (mutable)
    char* pointer.

    For example, on Windows:
>>> import ctypes
>>> c = ctypes.CDLL('msvcrt')
>>> a = "    "
>>> c.strcpy(a, "X" * 50)
50
>>> a
'XXXX'
... and the crash is not far.

    Another case of corruption in obmalloc is to try to allocate python objects while
    the GIL is not held. This may happen if you wrote a C function that uses the
    Python API, and call this with ctypes.

    In any case, I suggest that you build and a use a debug-enabled version of python
    (configure with --with-pydebug). It catches some errors earlier and sometimes more
    reliably.

    @farshad
    Copy link
    Mannequin Author

    farshad mannequin commented Nov 20, 2008

    No, there isn't any custom made C extension, nor I'm using ctypes. (It
    was a mistake selecting ctypes).
    The application is a web service with postgresql backend, so it heavily
    uses pyexpat and pygresql in a threaded environment.
    I'll recompile python with pydebug and get back with results.

    @vstinner
    Copy link
    Member

    The application is a web service with postgresql backend, so it
    heavily uses pyexpat and pygresql in a threaded environment.

    pyexpat or pygresql is maybe not thread safe. To catch such error, you
    have to use Valgrind. And to use Valgrind, you have to recompile
    Python with the define "Py_USING_MEMORY_DEBUGGER": read
    Misc/valgrind.supp (comments at the top). Then,
    use "valgrind --suppressions=Misc/valgrind.supp <your program>
    <arguments...>". You might also try
    helgrind: "valgrind --tool=helgrind --suppressions=Misc/valgrind.supp
    <your program> <arguments...>".

    Note: remember me to translate this article to english!
    http://www.haypocalc.com/blog/index.php/2008/08/22/160-deboguer-programme-python-avec-gdb

    @vstinner
    Copy link
    Member

    farshad: Is the bug still open? If yes, can you give more
    informations? If you don't answer, I will have to close this issue
    because it's not possible find the bug with so few informations :-/

    @vstinner
    Copy link
    Member

    There are not enough informations to reproduce the issue or understand
    the problem. Since farshad didn't answer since 4 months, I choose to
    close the bug. Reopen the bug if you have new informations!

    @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
    topic-XML 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
    @vstinner @amauryfa @theller