[ python-Bugs-1562092 ] Dedent with Italian keyboard
Bugs item #1562092, was opened at 2006-09-20 13:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562092&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: neclepsio (neclepsio82) Assigned to: Nobody/Anonymous (nobody) Summary: Dedent with Italian keyboard Initial Comment: In IDLE, with an Italian keyboard, it's impossible to dedent the text without using the menu, because the shortcut Ctrl+] cannot be typed. In fact, with an Italian keybaord, the ] is typed with Ctrl+Alt++. While indent can be achieved with Tab, so that's no problem, dedent is only accesible from menu: I suggest you to shortcut it as Shift+Tab too, like many other IDEs. Thank you Ignazio -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562092&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1562171 ] Fails to install on Fedora Core 5
Bugs item #1562171, was opened at 2006-09-20 12:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562171&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Mark Summerfield (mnsummerfield) Assigned to: Nobody/Anonymous (nobody) Summary: Fails to install on Fedora Core 5 Initial Comment: I am using an up-to-date version of Fedora Core 5. : gcc --version gcc (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1) configure I ran ./configure --prefix=/home/mark/opt/python25 and this ran without problems. Makefile I hand edited the Makefile to add -fwrapv to the BASECFLAGS as per the README file since I don't know how to add flags using configure. make make worked fine make test This reported some failures, but nothing that seems significant: ... test_zipfile test_zipfile64 test_zipfile64 skipped -- test requires loads of disk-space bytes and a long time to run test_zipimport test_zlib 281 tests OK. 38 tests skipped: test_aepack test_al test_applesingle test_bsddb test_bsddb185 test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dbm test_gdbm test_gl test_imgfile test_linuxaudiodev test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sqlite test_startfile test_sunaudiodev test_timeout test_urllib2net test_urllibnet test_winreg test_winsound test_zipfile64 3 skips unexpected on linux2: test_dbm test_gdbm test_bsddb make install This failed. ... Compiling /home/mark/opt/python25/lib/python2.5/zipfile.py ... make: *** [libinstall] Error 1 Just in case for some reason a dbm is needed I installed gdbm-devel and retried but the installation still failed in the same place. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562171&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1562193 ] IDLE Hung up after open script by command line...
Bugs item #1562193, was opened at 2006-09-20 13:10
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562193&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Faramir^ (faramir2)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE Hung up after open script by command line...
Initial Comment:
Hello,
I wrote that code in python and saved as prx.py:
--- CUT ---
from BaseHTTPServer import HTTPServer,
BaseHTTPRequestHandler
from time import strftime, gmtime
import urllib2
import thread
from sys import stdout
class RequestHandler(BaseHTTPRequestHandler):
def serve(self):
print "%s %s %s\r\n%s" % (self.command,
self.path,
self.request_version, self.headers)
header={}
header["content-length"]=0
for i in str(self.headers).split("\r\n"):
j=i.split(":", 1)
if len(j)==2:
header[j[0].strip().lower()] =
j[1].strip()
content=self.rfile.read(int(header["content-
length"]))
print content
url="http://faramir2.prv.pl";
u=urllib2.urlopen(url)
for i,j in u.info().items():
print "%s: %s" % (i,j)
self.server_version = "Apache"
self.sys_version = ""
self.send_response(200)
self.send_header("Content-type", "text/html;
charset=ISO-8859-2")
self.send_header("Connectin", "close")
self.end_headers()
def do_POST(self): self.serve()
def do_HEAD(self): self.serve()
def do_GET(self): self.serve()
address = ("", 80)
server = HTTPServer(address, RequestHandler)
thread.start_new_thread(server.serve_forever, () )
--- CUT ---
When I right click on that file and select "Edit with
IDLE" it opens. Then
when I push F5 the script is running. *Python Shell*
is restarting. But
when I try to connect by browser to http://
localhost:80/ IDLE Hung-up. I
don't see that hung ups when I open IDLE from shortcut
and then in IDLE
open file prx.py and run it works normally - good.
IDLE does't hung up.
I don't know why it works like that, but I think that
it's bug..
Python version: 2.5c2
Tk version: 8.4
IDLE version: 1.2c2
OS Version: Microsoft Windows XP Professional with SP2
---
Again:
* Freeze:
>
"C:\Python25\pythonw.exe" "C:\Python25\Lib\idlelib\idle.pyw"
-n -e "prx.py"
// then F5 on IDLE
// when run open Browser and try to open page: http://
localhost:80
// IDLE freezes
* Works ok:
>
"C:\Python25\pythonw.exe" "C:\Python25\Lib\idlelib\idle.pyw"
-e
// open prx.py in IDLE
// press F5 on IDLE
// run Browwser and try to open page: http://
localhost:80
// all works ok
---
regards,
Marek
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562193&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1008295 ] logging.getLevelName returns a number
Bugs item #1008295, was opened at 2004-08-12 21:56 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008295&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Paulo Eduardo Neves (neves) Assigned to: Vinay Sajip (vsajip) Summary: logging.getLevelName returns a number Initial Comment: logging.getLevelName function doc says that it returns the "textual representation of logging level", but if the argument is already the level name, the log level integer is returned. It should return the argument. The problem is that if I add my own levels, and call LoggerInstance.log( levelName, message ), the formatter will save the level number in the log, insted of the desired level name. -- >Comment By: Vinay Sajip (vsajip) Date: 2006-09-20 13:47 Message: Logged In: YES user_id=308438 Yes, that's the way it's supposed to work - the map works both ways, allowing the mapping of names to levels as well as levels to names. This is because both types of mapping are needed in the package, and it makes sense to reuse the dictionary rather than have two separate dictionaries. In your example, you are calling setLevel with a string argument [newLoglevel.upper ()], which is incorrect. I will clarify the setLevel() documentation to point out that the level passed to setLevel() is an integer. -- Comment By: Steve Pole (stevepole) Date: 2006-09-20 04:06 Message: Logged In: YES user_id=455201 I understand this is not a bug, it's by design. It still looks like a bug, though. Please consider the following code: import logging defaultLoglevel = logging.DEBUG newLoglevel = 'WARNING' logging.basicConfig (level = defaultLoglevel, format = '%(message)s') print logging.getLevelName (logging.getLogger ().getEffectiveLevel ()) print logging.getLogger ().getEffectiveLevel () logging.getLogger ().setLevel (newLoglevel.upper ()) print logging.getLevelName (logging.getLogger ().getEffectiveLevel ()) print logging.getLogger ().getEffectiveLevel () Output: DEBUG 10 30 WARNING So the result basically inverts. Is that really the way it is supposed to work ? Or am I misunderstanding something ? -- Comment By: Vinay Sajip (vsajip) Date: 2004-08-20 12:36 Message: Logged In: YES user_id=308438 This is not a bug, it's by design. Current CVS throws an exception if raiseExceptions is set and you pass anything other than an integer as the log level. The CVS documentation has also been updated to clarify that the level passed in is the integer rather than the level name. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008295&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1562308 ] uninitialized memory read in parsetok()
Bugs item #1562308, was opened at 2006-09-20 11:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562308&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Luke Moore (lukemoore) Assigned to: Nobody/Anonymous (nobody) Summary: uninitialized memory read in parsetok() Initial Comment: When running python2.5 under valgrind and running exec "" valgrind issues the following warning: ==6661== Conditional jump or move depends on uninitialised value(s) ==6661==at 0x403EAF3: parsetok (parsetok.c:189) ==6661==by 0x40ED673: PyParser_ASTFromString (pythonrun.c:1354) ==6661==by 0x40EF852: PyRun_StringFlags (pythonrun.c:1225) ==6661==by 0x40CB7FF: PyEval_EvalFrameEx (ceval.c:4202) ==6661==by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==6661==by 0x40CCA74: PyEval_EvalCode (ceval.c:494) ==6661==by 0x40EF3A1: PyRun_InteractiveOneFlags (pythonrun.c:1264) ==6661==by 0x40EF5A2: PyRun_InteractiveLoopFlags (pythonrun.c:714) ==6661==by 0x40EF6CA: PyRun_AnyFileExFlags (pythonrun.c:683) ==6661==by 0x40F930D: Py_Main (main.c:496) ==6661==by 0x8048591: main (in /usr/bin/python2.5) Valgrind does not give warnings when doing the same thing with python2.4.3. After further investigation, it looks like tok->line_start is uninitialized. Initializing to null in tok_new() removes the valgrind warning, but I have no idea if this is the correct fix. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562308&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1562308 ] uninitialized memory read in parsetok()
Bugs item #1562308, was opened at 2006-09-20 08:50 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562308&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Luke Moore (lukemoore) Assigned to: Nobody/Anonymous (nobody) Summary: uninitialized memory read in parsetok() Initial Comment: When running python2.5 under valgrind and running exec "" valgrind issues the following warning: ==6661== Conditional jump or move depends on uninitialised value(s) ==6661==at 0x403EAF3: parsetok (parsetok.c:189) ==6661==by 0x40ED673: PyParser_ASTFromString (pythonrun.c:1354) ==6661==by 0x40EF852: PyRun_StringFlags (pythonrun.c:1225) ==6661==by 0x40CB7FF: PyEval_EvalFrameEx (ceval.c:4202) ==6661==by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==6661==by 0x40CCA74: PyEval_EvalCode (ceval.c:494) ==6661==by 0x40EF3A1: PyRun_InteractiveOneFlags (pythonrun.c:1264) ==6661==by 0x40EF5A2: PyRun_InteractiveLoopFlags (pythonrun.c:714) ==6661==by 0x40EF6CA: PyRun_AnyFileExFlags (pythonrun.c:683) ==6661==by 0x40F930D: Py_Main (main.c:496) ==6661==by 0x8048591: main (in /usr/bin/python2.5) Valgrind does not give warnings when doing the same thing with python2.4.3. After further investigation, it looks like tok->line_start is uninitialized. Initializing to null in tok_new() removes the valgrind warning, but I have no idea if this is the correct fix. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-20 10:49 Message: Logged In: YES user_id=33168 Thanks for the report. What is the python code that caused this warning to be generated? I've run valgrind with the standard tests and don't recall this error. Without looking at the code, the proposed fix seems to make sense (though from the name, I would have guessed that line_start is an int rather than a pointer). Also, what system and compiler are you using and how did you build python? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562308&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1562171 ] Fails to install on Fedora Core 5
Bugs item #1562171, was opened at 2006-09-20 05:33 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562171&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Mark Summerfield (mnsummerfield) Assigned to: Nobody/Anonymous (nobody) Summary: Fails to install on Fedora Core 5 Initial Comment: I am using an up-to-date version of Fedora Core 5. : gcc --version gcc (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1) configure I ran ./configure --prefix=/home/mark/opt/python25 and this ran without problems. Makefile I hand edited the Makefile to add -fwrapv to the BASECFLAGS as per the README file since I don't know how to add flags using configure. make make worked fine make test This reported some failures, but nothing that seems significant: ... test_zipfile test_zipfile64 test_zipfile64 skipped -- test requires loads of disk-space bytes and a long time to run test_zipimport test_zlib 281 tests OK. 38 tests skipped: test_aepack test_al test_applesingle test_bsddb test_bsddb185 test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dbm test_gdbm test_gl test_imgfile test_linuxaudiodev test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sqlite test_startfile test_sunaudiodev test_timeout test_urllib2net test_urllibnet test_winreg test_winsound test_zipfile64 3 skips unexpected on linux2: test_dbm test_gdbm test_bsddb make install This failed. ... Compiling /home/mark/opt/python25/lib/python2.5/zipfile.py ... make: *** [libinstall] Error 1 Just in case for some reason a dbm is needed I installed gdbm-devel and retried but the installation still failed in the same place. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-20 10:53 Message: Logged In: YES user_id=33168 This seems weird. Did you run out of disk space? Is the error reproducible (ie, fail in the same place each time)? Can you debug this further? The tests do a make install and I don't recall seeing this error. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562171&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1562308 ] uninitialized memory read in parsetok()
Bugs item #1562308, was opened at 2006-09-20 11:50 Message generated for change (Comment added) made by lukemoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562308&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Luke Moore (lukemoore) Assigned to: Nobody/Anonymous (nobody) Summary: uninitialized memory read in parsetok() Initial Comment: When running python2.5 under valgrind and running exec "" valgrind issues the following warning: ==6661== Conditional jump or move depends on uninitialised value(s) ==6661==at 0x403EAF3: parsetok (parsetok.c:189) ==6661==by 0x40ED673: PyParser_ASTFromString (pythonrun.c:1354) ==6661==by 0x40EF852: PyRun_StringFlags (pythonrun.c:1225) ==6661==by 0x40CB7FF: PyEval_EvalFrameEx (ceval.c:4202) ==6661==by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==6661==by 0x40CCA74: PyEval_EvalCode (ceval.c:494) ==6661==by 0x40EF3A1: PyRun_InteractiveOneFlags (pythonrun.c:1264) ==6661==by 0x40EF5A2: PyRun_InteractiveLoopFlags (pythonrun.c:714) ==6661==by 0x40EF6CA: PyRun_AnyFileExFlags (pythonrun.c:683) ==6661==by 0x40F930D: Py_Main (main.c:496) ==6661==by 0x8048591: main (in /usr/bin/python2.5) Valgrind does not give warnings when doing the same thing with python2.4.3. After further investigation, it looks like tok->line_start is uninitialized. Initializing to null in tok_new() removes the valgrind warning, but I have no idea if this is the correct fix. -- >Comment By: Luke Moore (lukemoore) Date: 2006-09-20 14:08 Message: Logged In: YES user_id=1437974 Running the python statement exec "" in the interactive shell will trigger the warning for me. I'm running Debian unstable, and can reproduce the problem with its RC1 python2.5 package built with gcc 4.1: Python 2.5c1 (r25c1:51305, Aug 19 2006, 18:23:29) [GCC 4.1.2 20060814 (prerelease) (Debian 4.1.1-11)] on linux2 I can also reproduce the problem with my own build of the official 2.5 release with built gcc 4.0: Python 2.5 (r25:51908, Sep 19 2006, 15:38:29) [GCC 4.0.4 20060904 (prerelease) (Debian 4.0.3-7)] on linux2 -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-20 13:49 Message: Logged In: YES user_id=33168 Thanks for the report. What is the python code that caused this warning to be generated? I've run valgrind with the standard tests and don't recall this error. Without looking at the code, the proposed fix seems to make sense (though from the name, I would have guessed that line_start is an int rather than a pointer). Also, what system and compiler are you using and how did you build python? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562308&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1562583 ] asyncore.dispatcher.set_reuse_addr not documented.
Bugs item #1562583, was opened at 2006-09-20 18:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562583&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Noah Spurrier (noah) Assigned to: Nobody/Anonymous (nobody) Summary: asyncore.dispatcher.set_reuse_addr not documented. Initial Comment: I could not find this in http://docs.python.org/lib/module-asyncore.html nor in http://docs.python.org/lib/genindex.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562583&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1562308 ] uninitialized memory read in parsetok()
Bugs item #1562308, was opened at 2006-09-20 08:50 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562308&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Luke Moore (lukemoore) Assigned to: Nobody/Anonymous (nobody) Summary: uninitialized memory read in parsetok() Initial Comment: When running python2.5 under valgrind and running exec "" valgrind issues the following warning: ==6661== Conditional jump or move depends on uninitialised value(s) ==6661==at 0x403EAF3: parsetok (parsetok.c:189) ==6661==by 0x40ED673: PyParser_ASTFromString (pythonrun.c:1354) ==6661==by 0x40EF852: PyRun_StringFlags (pythonrun.c:1225) ==6661==by 0x40CB7FF: PyEval_EvalFrameEx (ceval.c:4202) ==6661==by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==6661==by 0x40CCA74: PyEval_EvalCode (ceval.c:494) ==6661==by 0x40EF3A1: PyRun_InteractiveOneFlags (pythonrun.c:1264) ==6661==by 0x40EF5A2: PyRun_InteractiveLoopFlags (pythonrun.c:714) ==6661==by 0x40EF6CA: PyRun_AnyFileExFlags (pythonrun.c:683) ==6661==by 0x40F930D: Py_Main (main.c:496) ==6661==by 0x8048591: main (in /usr/bin/python2.5) Valgrind does not give warnings when doing the same thing with python2.4.3. After further investigation, it looks like tok->line_start is uninitialized. Initializing to null in tok_new() removes the valgrind warning, but I have no idea if this is the correct fix. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-20 21:15 Message: Logged In: YES user_id=33168 The proposed fix should be made, but I can't reproduce the problem. That bugs me. I'm running valgrind 3.2.0, what version are you running? I tried with gcc 3.3.x on x86 and gcc 3.4.x and 4.1.1 on amd64. Both are on gentoo. Have you run the entire regression suite with valgrind? I did, but given I'm not seeing these problems, I wonder if there might be issues lurking. -- Comment By: Luke Moore (lukemoore) Date: 2006-09-20 11:08 Message: Logged In: YES user_id=1437974 Running the python statement exec "" in the interactive shell will trigger the warning for me. I'm running Debian unstable, and can reproduce the problem with its RC1 python2.5 package built with gcc 4.1: Python 2.5c1 (r25c1:51305, Aug 19 2006, 18:23:29) [GCC 4.1.2 20060814 (prerelease) (Debian 4.1.1-11)] on linux2 I can also reproduce the problem with my own build of the official 2.5 release with built gcc 4.0: Python 2.5 (r25:51908, Sep 19 2006, 15:38:29) [GCC 4.0.4 20060904 (prerelease) (Debian 4.0.3-7)] on linux2 -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-20 10:49 Message: Logged In: YES user_id=33168 Thanks for the report. What is the python code that caused this warning to be generated? I've run valgrind with the standard tests and don't recall this error. Without looking at the code, the proposed fix seems to make sense (though from the name, I would have guessed that line_start is an int rather than a pointer). Also, what system and compiler are you using and how did you build python? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562308&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1562308 ] uninitialized memory read in parsetok()
Bugs item #1562308, was opened at 2006-09-20 08:50 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562308&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Luke Moore (lukemoore) >Assigned to: Neal Norwitz (nnorwitz) Summary: uninitialized memory read in parsetok() Initial Comment: When running python2.5 under valgrind and running exec "" valgrind issues the following warning: ==6661== Conditional jump or move depends on uninitialised value(s) ==6661==at 0x403EAF3: parsetok (parsetok.c:189) ==6661==by 0x40ED673: PyParser_ASTFromString (pythonrun.c:1354) ==6661==by 0x40EF852: PyRun_StringFlags (pythonrun.c:1225) ==6661==by 0x40CB7FF: PyEval_EvalFrameEx (ceval.c:4202) ==6661==by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==6661==by 0x40CCA74: PyEval_EvalCode (ceval.c:494) ==6661==by 0x40EF3A1: PyRun_InteractiveOneFlags (pythonrun.c:1264) ==6661==by 0x40EF5A2: PyRun_InteractiveLoopFlags (pythonrun.c:714) ==6661==by 0x40EF6CA: PyRun_AnyFileExFlags (pythonrun.c:683) ==6661==by 0x40F930D: Py_Main (main.c:496) ==6661==by 0x8048591: main (in /usr/bin/python2.5) Valgrind does not give warnings when doing the same thing with python2.4.3. After further investigation, it looks like tok->line_start is uninitialized. Initializing to null in tok_new() removes the valgrind warning, but I have no idea if this is the correct fix. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-20 21:15 Message: Logged In: YES user_id=33168 The proposed fix should be made, but I can't reproduce the problem. That bugs me. I'm running valgrind 3.2.0, what version are you running? I tried with gcc 3.3.x on x86 and gcc 3.4.x and 4.1.1 on amd64. Both are on gentoo. Have you run the entire regression suite with valgrind? I did, but given I'm not seeing these problems, I wonder if there might be issues lurking. -- Comment By: Luke Moore (lukemoore) Date: 2006-09-20 11:08 Message: Logged In: YES user_id=1437974 Running the python statement exec "" in the interactive shell will trigger the warning for me. I'm running Debian unstable, and can reproduce the problem with its RC1 python2.5 package built with gcc 4.1: Python 2.5c1 (r25c1:51305, Aug 19 2006, 18:23:29) [GCC 4.1.2 20060814 (prerelease) (Debian 4.1.1-11)] on linux2 I can also reproduce the problem with my own build of the official 2.5 release with built gcc 4.0: Python 2.5 (r25:51908, Sep 19 2006, 15:38:29) [GCC 4.0.4 20060904 (prerelease) (Debian 4.0.3-7)] on linux2 -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-20 10:49 Message: Logged In: YES user_id=33168 Thanks for the report. What is the python code that caused this warning to be generated? I've run valgrind with the standard tests and don't recall this error. Without looking at the code, the proposed fix seems to make sense (though from the name, I would have guessed that line_start is an int rather than a pointer). Also, what system and compiler are you using and how did you build python? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562308&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
