classification
Title: Segfault in datetime.time.strftime("%z")
Type: crash Stage: test needed
Components: Library (Lib) Versions: Python 2.7, Python 2.6
process
Status: closed Resolution: works for me
Dependencies: Superseder:
Assigned To: belopolsky Nosy List: belopolsky, eswald, mephinet, nnorwitz
Priority: normal Keywords:

Created on 2009-01-21 16:44 by eswald, last changed 2012-09-07 03:58 by belopolsky. This issue is now closed.

Files
File name Uploaded Description Edit
zone_failure.py eswald, 2009-01-21 16:44 Minimal reproduction script
Messages (10)
msg80332 - (view) Author: Eric Wald (eswald) Date: 2009-01-21 16:44
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.
msg80392 - (view) Author: Eric Wald (eswald) Date: 2009-01-22 23:38
Update: Undefining HAVE_SNPRINTF does not correct the problem.
msg80698 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2009-01-28 07:29
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)?
msg93140 - (view) Author: Philipp Gortan (mephinet) Date: 2009-09-25 20:55
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.
msg106812 - (view) Author: Philipp Gortan (mephinet) Date: 2010-05-31 21:29
@belopolsky: unittest exists, 
/usr/lib/python2.6/test/test_datetime.py
as mentioned by the OP, this unittest reproduces
the issue.
msg106823 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-06-01 03:19
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?
msg106830 - (view) Author: Philipp Gortan (mephinet) Date: 2010-06-01 08:02
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.
msg108044 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-06-17 18:42
Since this does not seem to be reproducible anymore, I am going to close this soon.
msg109274 - (view) Author: Eric Wald (eswald) Date: 2010-07-04 23:49
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.
msg163446 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2012-06-22 17:50
Since no one is able to reproduce this crash, I am going to close this issue.
History
Date User Action Args
2012-09-07 03:58:36belopolskysetstatus: pending -> closed
2012-06-22 17:50:05belopolskysetstatus: open -> pending

messages: + msg163446
2010-07-04 23:49:47eswaldsetstatus: pending -> open

messages: + msg109274
versions: + Python 2.7
2010-06-17 18:42:20belopolskysetstatus: open -> pending
resolution: works for me
messages: + msg108044
2010-06-01 08:02:55mephinetsetmessages: + msg106830
2010-06-01 03:19:21belopolskysetmessages: + msg106823
2010-05-31 21:29:10mephinetsetmessages: + msg106812
2010-05-31 19:29:10belopolskysetstage: test needed
2010-05-25 23:49:55belopolskysetassignee: belopolsky

nosy: + belopolsky
2009-09-25 20:55:45mephinetsetnosy: + mephinet
messages: + msg93140
2009-01-28 07:29:50nnorwitzsetnosy: + nnorwitz
messages: + msg80698
2009-01-22 23:38:32eswaldsetmessages: + msg80392
2009-01-21 16:44:44eswaldcreate