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

Segfault in datetime.time.strftime("%z") #49273

Closed
eswald mannequin opened this issue Jan 21, 2009 · 10 comments
Closed

Segfault in datetime.time.strftime("%z") #49273

eswald mannequin opened this issue Jan 21, 2009 · 10 comments
Assignees
@abalkin
Labels
stdlib Python modules in the Lib dir type-crash A hard crash of the interpreter, possibly with a core dump

Comments

@eswald
Copy link
Mannequin

eswald mannequin commented Jan 21, 2009

BPO 5023
Nosy @abalkin, @mephinet
Files
  • zone_failure.py: Minimal reproduction script
    		•

    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 = 'https://github.com/abalkin'
closed_at = <Date 2012-09-07.03:58:36.149>
created_at = <Date 2009-01-21.16:44:44.519>
labels = ['library', 'type-crash']
title = 'Segfault in datetime.time.strftime("%z")'
updated_at = <Date 2012-09-07.03:58:36.148>
user = 'https://bugs.python.org/eswald'

    bugs.python.org fields:

    activity = <Date 2012-09-07.03:58:36.148>
actor = 'belopolsky'
assignee = 'belopolsky'
closed = True
closed_date = <Date 2012-09-07.03:58:36.149>
closer = 'belopolsky'
components = ['Library (Lib)']
creation = <Date 2009-01-21.16:44:44.519>
creator = 'eswald'
dependencies = []
files = ['12825']
hgrepos = []
issue_num = 5023
keywords = []
message_count = 10.0
messages = ['80332', '80392', '80698', '93140', '106812', '106823', '106830', '108044', '109274', '163446']
nosy_count = 4.0
nosy_names = ['nnorwitz', 'belopolsky', 'mephinet', 'eswald']
pr_nums = []
priority = 'normal'
resolution = 'works for me'
stage = 'test needed'
status = 'closed'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue5023'
versions = ['Python 2.6', 'Python 2.7']
    @eswald
    Copy link
    Mannequin Author

    eswald mannequin commented Jan 21, 2009

    Execution of "make test" for Python 2.6.1 halts with a segmentation
    fault on line 2198 of Python-2.6.1/Lib/test/test_datetime.py; also
    occurs using the attached script, narrowing it down to the %z sequence
    in the format argument to datetime.time.strftime(), but only when the
    time object has a non-None tzinfo. The segfault disappears when I
    comment out line 1133 of Python-2.6.1/Modules/datetimemodule.c:

    PyOS_snprintf(buf, buflen, "%c%02d%s%02d", sign, hours, sep, minutes);

    Compiled with GCC 3.4.3 with Smashing Stack Protector on LFS 5.1.1
    (Linux 2.6.11.12 and glibc 2.3.5 with ssp patches). Using BASECFLAGS=-
    fno-stack-protector has no effect on the segfault. All other Python
    tests pass. HAVE_SNPRINTF has been defined to 1 in pyconfig.h by the
    config script.

    I have not yet compiled gdb, but I can if requested.

    @eswald eswald mannequin added stdlib Python modules in the Lib dir type-crash A hard crash of the interpreter, possibly with a core dump labels Jan 21, 2009
    @eswald
    Copy link
    Mannequin Author

    eswald mannequin commented Jan 22, 2009

    Update: Undefining HAVE_SNPRINTF does not correct the problem.

    @nnorwitz
    Copy link
    Mannequin

    nnorwitz mannequin commented Jan 28, 2009

    Can you debug this problem any further? What is the C call stack? Does
    the problem occur if you build in debug mode (./configure
    --with-pydebug)? Does the problem occur with a different compiler (if
    you have access to another one on the same box)?

    @mephinet
    Copy link
    Mannequin

    mephinet mannequin commented Sep 25, 2009

    I can reproduce this problem with Gentoo Hardened and
    gcc version 3.4.6 (Gentoo Hardened 3.4.6-r2 p1.6, ssp-3.4.6-1.0, pie-8.7.10)

    when gdb-ing through the datetimemodule.c, and displaying the "tuple"
    variable in time_strftime, I can see that the pointer gets modified by
    the wrap_strftime call, resulting in Py_DECREF causing the segfault:
    before wrap_strftime:
    (gdb) x tuple
    0xa8938f2c: 0x00000001
    after wrap_strftime:
    (gdb) x tuple
    0x938f2c: Cannot access memory at address 0x938f2c
    thus executing
    Py_DECREF(tuple)
    results in the segfault.

    @abalkin abalkin self-assigned this May 25, 2010
    @mephinet
    Copy link
    Mannequin

    mephinet mannequin commented May 31, 2010

    @belopolsky: unittest exists,
    /usr/lib/python2.6/test/test_datetime.py
    as mentioned by the OP, this unittest reproduces
    the issue.

    @abalkin
    Copy link
    Member

    abalkin commented Jun 1, 2010

    Philipp,

    Why do you think you see the same problem as Eric?

    Can you set a trace on &tuple and see when it gets modified?

    Do you see the crash with zone_failure.py, test_datetime.py or both?

    @mephinet
    Copy link
    Mannequin

    mephinet mannequin commented Jun 1, 2010

    Unfortunately, I'm no longer able to reproduce this issue as I upgraded to gcc 4.3 sometime within the last nine months...
    With 4.3, I don't see this segfault any longer.

    @abalkin
    Copy link
    Member

    abalkin commented Jun 17, 2010

    Since this does not seem to be reproducible anymore, I am going to close this soon.

    @eswald
    Copy link
    Mannequin Author

    eswald mannequin commented Jul 4, 2010

    Reproduced again in version 2.7rc2; I had thought that it went away, but it turns out that --with-pydebug hides the problem.

    Compiling GDB now.

    @abalkin
    Copy link
    Member

    abalkin commented Jun 22, 2012

    Since no one is able to reproduce this crash, I am going to close this issue.

    @abalkin abalkin closed this as completed Sep 7, 2012
    @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

    @abalkin abalkin

    Labels
    stdlib Python modules in the Lib dir 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
    1 participant
    @abalkin