Bugs item #493183, was opened at 2001-12-13 21:02
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470
Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason R. Mastaler (jasonrm)
Assigned to: Nobody/Anonymous (nobody)
Summary: FreeBSD/Python 2.1.1 Segmentation fault
Initial Comment:
This is Python 2.1.1 on FreeBSD 4.4-RELEASE/i386.
I have a reproducible way to make Python 2.1.1 segfault
here, but I'm
not sure the best way to go about debugging it. I'll
save you the
gory details unless you request them, but basically I
use a Python
program called "tmda-inject" to send my e-mail. It's
core dumping
when fed this one particular message (mess1.txt), but
not others.
Further, Python 1.5.2, 2.0 and 2.2b2 on the same
machine have no such
trouble. It only appears with Python 2.1.1. I can
also reproduce
this problem a complately different machine also
running FreeBSD 4.4
and Python 2.1.1, but not with other operating
systems. The problem
appears to be specifically with FreeBSD and Python
2.1.1.
I've attached the "mess1.txt" e-mail message, and also
python2.1.core.
If you'd like to look at tmda-inject, it's part of my
TMDA package
available at http://sf.net/projects/tmda/. Let me know
if I can do
anything further.
[jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.1
cvs/tmda/dist/bin/tmda-inject
Segmentation fault (core dumped)
[jasonrm@nightshade jasonrm]$ cat mess1.txt | python1.5
cvs/tmda/dist/bin/tmda-inject
[jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.0
cvs/tmda/dist/bin/tmda-inject
[jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.2
cvs/tmda/dist/bin/tmda-inject
[jasonrm@nightshade jasonrm]$ gdb
/usr/local/bin/python2.1 python2.1.core
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it
under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show
warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...(no
debugging symbols found)...
Core was generated by `python2.1'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libutil.so.3...(no
debugging symbols found)...done.
Reading symbols from /usr/lib/libm.so.2...(no debugging
symbols found)...done.
Reading symbols from /usr/lib/libc_r.so.4...(no
debugging symbols found)...done.
Reading symbols from
/usr/local/lib/python2.1/lib-dynload/strop.so...(no
debugging symbols found)...done.
Reading symbols from
/usr/local/lib/python2.1/lib-dynload/time.so...(no
debugging symbols found)...done.
Reading symbols from
/usr/local/lib/python2.1/lib-dynload/binascii.so...(no
debugging symbols found)...done.
Reading symbols from
/usr/local/lib/python2.1/lib-dynload/sha.so...(no
debugging symbols found)...done.
Reading symbols from
/usr/local/lib/python2.1/site-packages/cdbmodule.so...(no
debugging symbols found)...done.
Reading symbols from /usr/libexec/ld-elf.so.1...(no
debugging symbols found)...done.
#0 0x28177e0e in _thread_sys_fsync () from
/usr/lib/libc_r.so.4
(gdb) where
#0 0x28177e0e in _thread_sys_fsync () from
/usr/lib/libc_r.so.4
#1 0x2818ea24 in _thread_autoinit_dummy_decl () from
/usr/lib/libc_r.so.4
#2 0x28179222 in vfprintf () from /usr/lib/libc_r.so.4
#3 0x28169f75 in sprintf () from /usr/lib/libc_r.so.4
#4 0x80934ae in _PyString_FormatLong ()
#5 0x8093d48 in PyString_Format ()
#6 0x807b868 in PyNumber_Remainder ()
#7 0x80556a2 in PyEval_EvalCode ()
#8 0x8058d95 in PyEval_CallObjectWithKeywords ()
#9 0x80574cd in PyEval_EvalCode ()
#10 0x8058d95 in PyEval_CallObjectWithKeywords ()
#11 0x80574cd in PyEval_EvalCode ()
#12 0x8058d95 in PyEval_CallObjectWithKeywords ()
#13 0x80574cd in PyEval_EvalCode ()
#14 0x8058d95 in PyEval_CallObjectWithKeywords ()
#15 0x80574cd in PyEval_EvalCode ()
#16 0x8058d95 in PyEval_CallObjectWithKeywords ()
#17 0x80574cd in PyEval_EvalCode ()
#18 0x8058d95 in PyEval_CallObjectWithKeywords ()
#19 0x80574cd in PyEval_EvalCode ()
#20 0x80548a8 in PyEval_EvalCode ()
#21 0x806d75d in PyRun_FileExFlags ()
#22 0x806d70e in PyRun_FileExFlags ()
#23 0x806d6de in PyRun_FileExFlags ()
#24 0x806cab0 in PyRun_SimpleFileExFlags ()
#25 0x806c5b0 in PyRun_AnyFileExFlags ()
#26 0x8051795 in Py_Main ()
#27 0x80511c2 in main ()
#28 0x8051111 in _start ()
(gdb)
----------------------------------------------------------------------
>Comment By: Jason R. Mastaler (jasonrm)
Date: 2001-12-15 23:49
Message:
Logged In: YES
user_id=85984
The argument to hexlify() is 3 bytes of raw binary.
It's simply an HMAC of '%d' % time.time() stored in binary.
Any suggestions on how to visualize, analyze, or store
this argument? There is something about it that
Python really doesn't like. I even tried to pickle
it, and that too made Python core dump (see attached
backtrace_pickle.txt). Strangely, binascii.hexlify
has no problem handling it.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-15 17:18
Message:
Logged In: YES
user_id=6380
Very strange. You could try setting a breakpoint in
PyString_Format.
But I would first try to boil down the program to a smaller
example. For example, figure out what the argument to
hexlify() is, and see if you get the same crash when you
call hexlify() on its own with that argument.
I find it curious why the core dump is in
_PyString_FormatLong(), since hexlify doesn't pass longs to
the % operator -- it passes a tuple of small ints.
----------------------------------------------------------------------
Comment By: Jason R. Mastaler (jasonrm)
Date: 2001-12-15 16:50
Message:
Logged In: YES
user_id=85984
BTW, if you need access to a FreeBSD machine,
Sourceforge's "Compile Farm" has one available.
ssh to `cf.sourceforge.net'
----------------------------------------------------------------------
Comment By: Jason R. Mastaler (jasonrm)
Date: 2001-12-15 16:47
Message:
Logged In: YES
user_id=85984
Alright, through print statements, I've been able to
pinpoint exactly where the program is failing causing
Python to core dump. It is when the following
function is called:
def hexlify(b):
return "%02x"*len(b) % tuple(map(ord, b))
Ironically, I got this function from you Guido. :-)
(http://groups.google.com/groups?hl=en&selm=3924E204.CE01CA0A%40python.org)
I only have to replace the function body with:
return "foo"
and the program no longer core dumps.
The difficult thing has been trying to reproduce this
problem with a smaller piece of code. I've been
trying for hours and can't do it. As I said in my
original message, I've never had this problem before
this particular message. Even though its contents
look harmless, there is something there that is
triggering this problem. It seems pretty complex to
me.
However, I can run Python from inside gdb and get the
program to crash from there. I changed the program to
open "mess1.txt" directly. Not being experienced with
gdb though, I'm not sure what kind of "digging around"
to do. Could you give me some direction here? I've
attached "backtrace1.txt" as a starting point.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-13 21:25
Message:
Logged In: YES
user_id=6380
Thanks for all the info, but I'm afraid you're going to have
to work harder. We don't have FreeBSD here, so your core
file won't do us any good. Can you use gdb to get a
traceback and do some more digging? (It would be best not to
do this from the core file, but to run the program under gdb
until it crashes -- that way the stacktrace is more reliable
and you can do more digging around.)
Also, it would be really helpful if you could boil this down
to a smaller piece of Python code. Maybe you can put print
statements in your Python program that give you an idea of
which operation is failing.
As it is, the problem is too hard to reproduce to be worth
debugging.
The sample message contains nothing objectionable, so I
think this must be a matter of something the program does
that reads or write a bad pointer, where the value of the
bad pointer depends on what was previously on the stack or
what is in some spot of the heap.
----------------------------------------------------------------------
Comment By: Jason R. Mastaler (jasonrm)
Date: 2001-12-13 21:13
Message:
Logged In: YES
user_id=85984
Oops, the core file was too large to upload (1.5MB).
If you want to see it, you can download it at:
http://www.mastaler.com/tmp/2001-12-13/python2.1.core
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4