[ python-Bugs-1113244 ] Please add do-while guard to Py_DECREF etc.
Bugs item #1113244, was opened at 2005-01-31 16:01 Message generated for change (Comment added) made by rjk1002 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113244&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Richard Kettlewell (rjk1002) Assigned to: Tim Peters (tim_one) Summary: Please add do-while guard to Py_DECREF etc. Initial Comment: Py_DECREF() is missing do-while macro guards (as found e.g. in Py_CLEAR), instead relying on being an if-else to avoid the usual problems associated with such macros. However if it is used as e.g. "if (newref) Py_DECREF(obj);" then gcc -Wall still complains about an ambiguous else clause. (gcc version is 3.3.5) Granted it is only a warning but like many people we build with -Werror, and the code in question is in SWIG output rather than our own code, so this is quite painful for us. At least Py_DECREF, Py_XDECREF and Py_XINCREF need fixing; I've not checked beyond this. -- >Comment By: Richard Kettlewell (rjk1002) Date: 2005-02-01 09:51 Message: Logged In: YES user_id=217390 Making it compiler-specific seems silly. It's not like the do-while idiom for macros is some strange gcc-specific thing; most people just use it unconditionally on complicated macros. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-01 02:53 Message: Logged In: YES user_id=80475 Tim, what you think about doing this with a conditional compile to only redefine for GCC? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113244&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1108992 ] idle freezes when run over ssh
Bugs item #1108992, was opened at 2005-01-25 10:44 Message generated for change (Comment added) made by mgpoolman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Poolman (mgpoolman) Assigned to: Nobody/Anonymous (nobody) Summary: idle freezes when run over ssh Initial Comment: Python 2.3.4 (#2, Aug 13 2004, 00:36:58) [GCC 3.3.4 (Debian 1:3.3.4-5ubuntu2)] on linux2 IDLE 1.0.3 When running idle over an ssh link, idle freezes after an unpredictable length of time. Over 3 days the longest it has stayed allive for is ~4hrs, but a few minutes before freezing is the norm. Niether idle nor python are consuming cpu time once frozen. I can find no definete recipie to bring about the freeze, although (I think) there has always been at least one editor window open when it happens. There is no output on stderr, or other diagnostics that I can see. ssh server(ubuntu warty): OpenSSH_3.8.1p1 Debian 1:3.8.1p1-11ubuntu3.1, OpenSSL 0.9.7d 17 Mar 2004 ssh client (RH9): OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f /best/* Mark -- >Comment By: Mark Poolman (mgpoolman) Date: 2005-02-01 13:35 Message: Logged In: YES user_id=993923 > So if I follow correctly, IDLE -n freezes on your ubuntu box without using ssh tunneling. That is correct. The problem appears exactly the same when run over ssh though, which, I guess rules out any gnome/metacity/X wierdness. > I suspect a hardware problem I' sceptical about that. There's nothing in dmesg or /var/log to suggest it, and absolutely no other problems with the machine in question. >Are you starting IDLE from the command line Yes, but no messages are shown. > How much memory 255MB, IDLE uses about 3.5% of that on startup, grew to 5.7% at time of last crash -- Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-01 02:01 Message: Logged In: YES user_id=149084 Right, there is no subprocess when you use the -n switch. It causes IDLE to run like IDLE 0.8. So if I follow correctly, IDLE -n freezes on your ubuntu box without using ssh tunneling. I suspect a hardware problem with that system. Are you starting IDLE on the ubuntu box from the command line? If so, are there any messages left in the command line window? How much memory does the ubuntu box have? Does 'top' show increasing memory requirement for the IDLE -n process? -- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-31 16:46 Message: Logged In: YES user_id=993923 2 - erm forgive me for sounding stupid, but with the -n switch I see no sub-process, only the Idle process. It still freezes though, and killing it just kills it. -- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-31 16:27 Message: Logged In: YES user_id=993923 1 - OK It's not ssh it's ubuntu. 2 - I'll try this with ububtu. ...And by frozen, I assume ... All Idle windows are unresponsive to screen and kbd events. -- Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-31 06:26 Message: Logged In: YES user_id=149084 Please try two things: 1. Run IDLE directly on the ubuntu machine long enough to assure there is no problem standalone. 2. Run IDLE on the xclient but start it with the -n switch so it runs without the subprocess. When IDLE freezes, walk over to the server and kill the subprocess. It should restart itself. Is the system still frozen? And by frozen, I assume you mean all screen and keyboard events are unresponsive. -- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-30 20:06 Message: Logged In: YES user_id=993923 Yes, I've used Idle on that (although only ~ 1 hour) and not seen the problem there. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-30 19:43 Message: Logged In: YES user_id=341410 Do you have physical access to the ubuntu warty machine, and if so, does Idle run very well locally on that machine, not X forwarded? -- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-30 17:02 Message: Logged In: YES user_id=993923 Yes, exactly. I'm pretty sure it's not an X/ssh/network problem, everything else works fine (including Idle 0.8). Mark -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-29 20:23 Message: Logged In: YES user_id=341410 It has been a while since I ran Idle, but I am curious as to w
[ python-Bugs-1113984 ] keywords in keyword_arguments not possible
Bugs item #1113984, was opened at 2005-02-01 14:47
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=1113984&group_id=5470
Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Christoph Zwerschke (cito)
Assigned to: Nobody/Anonymous (nobody)
Summary: keywords in keyword_arguments not possible
Initial Comment:
Currently it is not possible to use keywords in
expressions of the type "keyword_arguments". Example:
d = {'fi': 1, 'if': 1}
d.update(fi = 2) # ok
d.update(if = 2) # error
If possible, this restriction should be removed.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113984&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1114093 ] inicode.decode
Bugs item #1114093, was opened at 2005-02-01 16:13
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=1114093&group_id=5470
Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Manlio Perillo (manlioperillo)
Assigned to: M.-A. Lemburg (lemburg)
Summary: inicode.decode
Initial Comment:
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32
bit (Intel)] on win32
>>> print sys.getdefaultencoding()
ascii
Regards.
The problem is this code:
# -*- coding: cp1252 -*-
>>> u'\xe0\xe8\xec\xf2\xf9'.decode('latin1')
Traceback (most recent call last):
File "", line 1, in ?
u'\xe0\xe8\xec\xf2\xf9'.decode('latin1')
UnicodeEncodeError: 'ascii' codec can't encode
characters in position 0-4: ordinal not in range(128)
I think this is a bug.
Indeed this is the behaviour of str.encode:
>>> '\xe0\xe8\xec\xf2\xf9'.encode('latin1')
Traceback (most recent call last):
File "", line 1, in ?
'\xe0\xe8\xec\xf2\xf9'.encode('latin1')
UnicodeDecodeError: 'ascii' codec can't decode byte
0xe0 in position 0: ordinal not in range(128)
But this makes no sense for Unicode strings!
I think unicode.decode should be a no-op.
Manlio Perillo
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1114093&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1114093 ] unicode.decode
Bugs item #1114093, was opened at 2005-02-01 17:13
Message generated for change (Comment added) made by lemburg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1114093&group_id=5470
Category: Unicode
Group: Python 2.4
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Manlio Perillo (manlioperillo)
Assigned to: M.-A. Lemburg (lemburg)
>Summary: unicode.decode
Initial Comment:
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32
bit (Intel)] on win32
>>> print sys.getdefaultencoding()
ascii
Regards.
The problem is this code:
# -*- coding: cp1252 -*-
>>> u'\xe0\xe8\xec\xf2\xf9'.decode('latin1')
Traceback (most recent call last):
File "", line 1, in ?
u'\xe0\xe8\xec\xf2\xf9'.decode('latin1')
UnicodeEncodeError: 'ascii' codec can't encode
characters in position 0-4: ordinal not in range(128)
I think this is a bug.
Indeed this is the behaviour of str.encode:
>>> '\xe0\xe8\xec\xf2\xf9'.encode('latin1')
Traceback (most recent call last):
File "", line 1, in ?
'\xe0\xe8\xec\xf2\xf9'.encode('latin1')
UnicodeDecodeError: 'ascii' codec can't decode byte
0xe0 in position 0: ordinal not in range(128)
But this makes no sense for Unicode strings!
I think unicode.decode should be a no-op.
Manlio Perillo
--
>Comment By: M.-A. Lemburg (lemburg)
Date: 2005-02-01 18:23
Message:
Logged In: YES
user_id=38388
What the .encode() and .decode() methods do depends on the
codec being used.
In your example, the Latin-1 codec is used which is a codec
that encodes from Unicode to 8-bit character strings and
decodes the other way around. As a result the Unicode string
in your first example is first converted to an 8-bit string
using the default encoding (which is ASCII) and this fails.
Same in the second case: Python tries to convert the 8-bit
string to Unicode but this fails since the string contains
non-ASCII characters.
If you switch the types of the strings in both examples,
you'll have no problem at all.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1114093&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1113984 ] keywords in keyword_arguments not possible
Bugs item #1113984, was opened at 2005-02-01 08:47
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113984&group_id=5470
Category: Parser/Compiler
Group: Python 2.4
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Christoph Zwerschke (cito)
Assigned to: Nobody/Anonymous (nobody)
Summary: keywords in keyword_arguments not possible
Initial Comment:
Currently it is not possible to use keywords in
expressions of the type "keyword_arguments". Example:
d = {'fi': 1, 'if': 1}
d.update(fi = 2) # ok
d.update(if = 2) # error
If possible, this restriction should be removed.
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-02-01 12:46
Message:
Logged In: YES
user_id=80475
It's possible, but hard to implement and unwise in any case.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113984&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1113984 ] keywords in keyword_arguments not possible
Bugs item #1113984, was opened at 2005-02-01 14:47
Message generated for change (Comment added) made by cito
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113984&group_id=5470
Category: Parser/Compiler
Group: Python 2.4
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Christoph Zwerschke (cito)
Assigned to: Nobody/Anonymous (nobody)
Summary: keywords in keyword_arguments not possible
Initial Comment:
Currently it is not possible to use keywords in
expressions of the type "keyword_arguments". Example:
d = {'fi': 1, 'if': 1}
d.update(fi = 2) # ok
d.update(if = 2) # error
If possible, this restriction should be removed.
--
>Comment By: Christoph Zwerschke (cito)
Date: 2005-02-01 19:49
Message:
Logged In: YES
user_id=193957
Maybe I should explain my motivation for making this request.
In Kid [http://kid-template.sf.net], a xml templating
language, it is possible to set xml attributes with a
Pythonic syntax, like this:
This expression is dynamically evaluated. If
myclass="aclass" and bgcolor="blue", then this would produce
the following:
Internally, this is of course realized by creating a
dictionary that contains the attributes of the tag, and then
creating an update statement with the string in py:attrs as
argument.
The problem arises when one of the attributes is a Python
keyword, "class" being a particularly embarassing example.
My current solution is to parse the py:attrs expression
manually and mangle the names. If Python could handle Python
keywords here, it would be a whole lot easier and faster.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-02-01 18:46
Message:
Logged In: YES
user_id=80475
It's possible, but hard to implement and unwise in any case.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113984&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1113984 ] keywords in keyword_arguments not possible
Bugs item #1113984, was opened at 2005-02-01 08:47
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113984&group_id=5470
Category: Parser/Compiler
Group: Python 2.4
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Christoph Zwerschke (cito)
Assigned to: Nobody/Anonymous (nobody)
Summary: keywords in keyword_arguments not possible
Initial Comment:
Currently it is not possible to use keywords in
expressions of the type "keyword_arguments". Example:
d = {'fi': 1, 'if': 1}
d.update(fi = 2) # ok
d.update(if = 2) # error
If possible, this restriction should be removed.
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-02-01 15:13
Message:
Logged In: YES
user_id=80475
I have no doubt that there are good use cases, your included.
The two issues are that it would complicate the snot out of
parsing (not a good thing) and that allowing keywords in
non-keyword roles would throw-off many existing tools (esp.
syntax highlighters).
In addition, human eye parsing also suffers when keywords
can be used in non-keyword roles. IOW, readability suffers.
For your app, it is a reasonable solution to wrap your code
with in preprocessing that converts keywords to non-keywords:
s = s.replace('class=', '_class=')
--
Comment By: Christoph Zwerschke (cito)
Date: 2005-02-01 13:49
Message:
Logged In: YES
user_id=193957
Maybe I should explain my motivation for making this request.
In Kid [http://kid-template.sf.net], a xml templating
language, it is possible to set xml attributes with a
Pythonic syntax, like this:
This expression is dynamically evaluated. If
myclass="aclass" and bgcolor="blue", then this would produce
the following:
Internally, this is of course realized by creating a
dictionary that contains the attributes of the tag, and then
creating an update statement with the string in py:attrs as
argument.
The problem arises when one of the attributes is a Python
keyword, "class" being a particularly embarassing example.
My current solution is to parse the py:attrs expression
manually and mangle the names. If Python could handle Python
keywords here, it would be a whole lot easier and faster.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-02-01 12:46
Message:
Logged In: YES
user_id=80475
It's possible, but hard to implement and unwise in any case.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113984&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1113984 ] keywords in keyword_arguments not possible
Bugs item #1113984, was opened at 2005-02-01 14:47
Message generated for change (Comment added) made by cito
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113984&group_id=5470
Category: Parser/Compiler
Group: Python 2.4
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Christoph Zwerschke (cito)
Assigned to: Nobody/Anonymous (nobody)
Summary: keywords in keyword_arguments not possible
Initial Comment:
Currently it is not possible to use keywords in
expressions of the type "keyword_arguments". Example:
d = {'fi': 1, 'if': 1}
d.update(fi = 2) # ok
d.update(if = 2) # error
If possible, this restriction should be removed.
--
>Comment By: Christoph Zwerschke (cito)
Date: 2005-02-01 22:18
Message:
Logged In: YES
user_id=193957
Your argument about syntax highlighters is valid.
s.replace('class=', '_class=') will not suffice, since
'class="aclass"' would be translated to 'class_=aclass_'
which would fail because aclass_ is not defined.
The only solution for me is to carefully parse the
keyword_argument string using the tokenize module.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-02-01 21:13
Message:
Logged In: YES
user_id=80475
I have no doubt that there are good use cases, your included.
The two issues are that it would complicate the snot out of
parsing (not a good thing) and that allowing keywords in
non-keyword roles would throw-off many existing tools (esp.
syntax highlighters).
In addition, human eye parsing also suffers when keywords
can be used in non-keyword roles. IOW, readability suffers.
For your app, it is a reasonable solution to wrap your code
with in preprocessing that converts keywords to non-keywords:
s = s.replace('class=', '_class=')
--
Comment By: Christoph Zwerschke (cito)
Date: 2005-02-01 19:49
Message:
Logged In: YES
user_id=193957
Maybe I should explain my motivation for making this request.
In Kid [http://kid-template.sf.net], a xml templating
language, it is possible to set xml attributes with a
Pythonic syntax, like this:
This expression is dynamically evaluated. If
myclass="aclass" and bgcolor="blue", then this would produce
the following:
Internally, this is of course realized by creating a
dictionary that contains the attributes of the tag, and then
creating an update statement with the string in py:attrs as
argument.
The problem arises when one of the attributes is a Python
keyword, "class" being a particularly embarassing example.
My current solution is to parse the py:attrs expression
manually and mangle the names. If Python could handle Python
keywords here, it would be a whole lot easier and faster.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-02-01 18:46
Message:
Logged In: YES
user_id=80475
It's possible, but hard to implement and unwise in any case.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113984&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1114404 ] All Statements Should Have Return Values (Syntax Proposal)
Feature Requests item #1114404, was opened at 2005-02-01 20:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1114404&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lenny Domnitser (ldrhcp) Assigned to: Nobody/Anonymous (nobody) Summary: All Statements Should Have Return Values (Syntax Proposal) Initial Comment: Python should allow a return value for some statements or blocks such as `print` or `def`. This should not always happen, but could certainly be useful. This can be used instead of lambdas when something more complex is required (the `def` example.) What seems to me to be the most natural syntax is to simply wrap the statement in parentheses. For example: >>> foo = (print 'bar') bar >>> foo 'bar' >>> f = (def f(x): if x < 0: return -5 return x ** 2 ) >>> f >>> # A useful example: >>> do_some_sort_of_logging( ( raise SomeSortOfError ) ) It will generally be obvious what should be returned, but why not be more explicit? Here are some loose specs: `def` would return the defined function. `class` would return the defined class. `print` would return the string representation of the printed object. `raise` will return the exception. `import` returns the module or a tuple of modules. This is not mean to be complete or a definitive syntax, but I'd certainly like this discussed and something along the lines of this proposal implemented. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1114404&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1113244 ] Please add do-while guard to Py_DECREF etc.
Bugs item #1113244, was opened at 2005-01-31 11:01
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113244&group_id=5470
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Kettlewell (rjk1002)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Please add do-while guard to Py_DECREF etc.
Initial Comment:
Py_DECREF() is missing do-while macro guards (as found
e.g. in Py_CLEAR), instead relying on being an if-else
to avoid the usual problems associated with such macros.
However if it is used as e.g. "if (newref)
Py_DECREF(obj);" then gcc -Wall still complains about
an ambiguous else clause. (gcc version is 3.3.5)
Granted it is only a warning but like many people we
build with -Werror, and the code in question is in SWIG
output rather than our own code, so this is quite
painful for us.
At least Py_DECREF, Py_XDECREF and Py_XINCREF need
fixing; I've not checked beyond this.
--
>Comment By: Tim Peters (tim_one)
Date: 2005-02-01 21:03
Message:
Logged In: YES
user_id=31435
rjk1002: it's idiotic complaints about unambigous (in reality)
if/else structures that are unique to gcc. Not all compilers
optimize away the "do {...} while(0)" cruft in debug builds;
the most important examples for Python are the Microsoft
compilers. Because the incref and decref macros are used a
*lot*, it's unattractive to burden all platforms with this just
to shut up one compiler. I don't care about Py_CLEAR()
(etc), because they're so lightly used. The incref/decref
macros are ubiquitous.
I would much rather see SWIG change to insert curlies. That
is, generating "if (newref) {Py_DECREF(obj);}" should be just
as effective at shutting up this gcc nag. Has anyone asked
the SWIG project to do this?
--
Comment By: Richard Kettlewell (rjk1002)
Date: 2005-02-01 04:51
Message:
Logged In: YES
user_id=217390
Making it compiler-specific seems silly. It's not like the
do-while idiom for macros is some strange gcc-specific
thing; most people just use it unconditionally on
complicated macros.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-01-31 21:53
Message:
Logged In: YES
user_id=80475
Tim, what you think about doing this with a conditional
compile to only redefine for GCC?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113244&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1075984 ] Memory fault pyexpat.so on SGI
Bugs item #1075984, was opened at 2004-11-30 05:13
Message generated for change (Comment added) made by bos
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470
Category: XML
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Maik Hertha (mhertha)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory fault pyexpat.so on SGI
Initial Comment:
I build the latest RC1 of python 2.4.
System SGI Fuel IP35, Irix 6.5.26m
cc -version
MIPSpro Compilers: Version 7.3.1.3m
- make tests passes test_pyexpat without error
- running this code leads to a core dump
-- code ---
import xml.dom.minidom
doc = xml.dom.minidom.parseString(fstream)
<<< core dump >>>
--- runing python -v test.py
#
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
matches
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.py
import xml.dom.expatbuilder # precompiled from
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
import xml.parsers # directory
/opt/python24c1/lib/python2.4/xml/parsers
#
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
matches
/opt/python24c1/lib/python2.4/xml/parsers/__init__.py
import xml.parsers # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
# /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
matches /opt/python24c1/lib/python2.4/xml/parsers/expat.py
import xml.parsers.expat # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
dlopen("/opt/python24c1/lib/python2.4/lib-dynload/pyexpat.so",
2);
Memory fault(coredump)
- running this code from an interactive session leads
not to a coredump
I need some assistance howto provide further debug
information.
--maik./
--
Comment By: Bryan O'Sullivan (bos)
Date: 2005-02-01 22:09
Message:
Logged In: YES
user_id=28380
By the way, this is not an SGI-specific bug. This will bite any Unix system
with a modern sysv-style dynamic linker. The priority of this bug should be
higher, IMO.
--
Comment By: Bryan O'Sullivan (bos)
Date: 2005-01-31 23:53
Message:
Logged In: YES
user_id=28380
I've been bitten by the same bug. In my case, the problem was with Qt, not GTK.
It's not actually necessary to check the expat version; just see if
XML_ErrorString actually returns anything.
Here's the patch I use for this problem:
--- python/Modules/pyexpat.c2005-01-06 16:26:13 -08:00
+++ python/Modules/pyexpat.c 2005-01-31 23:46:36 -08:00
@@ -1936,9 +1936,12 @@
}
#endif
-#define MYCONST(name) -PyModule_AddStringConstant(errors_module, #name, -
(char*)XML_ErrorString(name))
+#define MYCONST(name) +{ +char *_v =
(char*)XML_ErrorString(name); +if (_v) +
PyModule_AddStringConstant(errors_module, #name, _v); +}
MYCONST(XML_ERROR_NO_MEMORY);
MYCONST(XML_ERROR_SYNTAX);
--
Comment By: Stephen Watson (kerofin)
Date: 2004-12-13 05:46
Message:
Logged In: YES
user_id=471223
pyexpat initializes using its internal copy of expat.
libexpat.so is still mapped in (after pyexpat has
initilized), but gdb finds the python copy of
XML_ErrorString and other functions.
I suspect that this will be a problem if the system version
of expat is newer than Python's.
--
Comment By: Michael Hudson (mwh)
Date: 2004-12-13 05:01
Message:
Logged In: YES
user_id=6656
1) Good sleuthing.
2) Argh!
3) What happens if you import pyexpat before pygtk?
--
Comment By: Stephen Watson (kerofin)
Date: 2004-12-13 01:29
Message:
Logged In: YES
user_id=471223
I've looked at the program that was dumping core and the
sequence is this:
1) Program imports pygtk, which links in the GTK libraries
2) Program loads SVG image which links in librsvg.so which
in turn links in /usr/local/lib/libexpat.so
3) Program imports pyexpat.
4) pyexpat calls XML_ErrorString, but as ld.so has already
linked in XML_ErrorString from /usr/local/lib/libexpat.so it
calls that version, not the one in pyexpat.so.
5) pyexpat looks up an error defined by the later version of
expat it is expecting and gets a NULL pointer from the
earlier version it has. It attempts to use it without
checking (strlen) and dumps core.
--
Comment By: Stephen Watson (kerofin)
Date: 2004-12-10 09:01
Message:
Logged In: YES
user_id=471223
Maybe it compiled against its own copy of expat, but pulled
in the system's copy when run?
--
Comment By: Michael Hudson (mwh)
Date: 2004-12-10 08:52
Message:
Logged In: YES
user_id=6656
Uh, Py
