[ python-Bugs-1066546 ] test_pwd fails on 64bit system (Opteron)
Bugs item #1066546, was opened at 2004-11-15 11:34
Message generated for change (Comment added) made by tebeka
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066546&group_id=5470
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_pwd fails on 64bit system (Opteron)
Initial Comment:
test test_pwd failed -- Traceback (most recent call last):
File "/tmp/miki/Python-2.4b2/Lib/test/test_pwd.py",
line 42, in test_values
self.assert_(pwd.getpwuid(e.pw_uid) in
entriesbyuid[e.pw_uid])
OverflowError: signed integer is greater than maximum
$ cat /proc/version
Linux version 2.4.21-20.ELsmp
([EMAIL PROTECTED]) (gcc version 3.2.3
20030502 (Red Hat Linux 3.2.3-42)) #1 SMP Wed Aug 18
20:34:58 EDT 2004
Processor is AMD Opteron 2.4MHz
--
>Comment By: Miki Tebeka (tebeka)
Date: 2005-03-17 11:20
Message:
Logged In: YES
user_id=358087
I've tried the patch - no luck :-(
I'm stealing time on these machines since they belong to
another group.
However I see that SF's compile farm
(http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1)
have an AMD64 host (amd64-linux1)
Maybe you can shorten the loop ...
--
Comment By: Walter Dörwald (doerwalter)
Date: 2005-03-15 00:17
Message:
Logged In: YES
user_id=89016
On a 32bit system adding the line
nobody:x:4294967294:65534:nobody:/:/bin/false
to /etc/passwd pwd.getpwall() gives me an entry:
('nobody', 'x', -2, 65534, 'nobody', '/', '/bin/false')
and
pwd.getpwuid(-2)
gives me
('nobody', 'x', -2, 65534, 'nobody', '/', '/bin/false')
Maybe for 64bit systems the SETI macro should use
PyLong_FromUnsignedLong() instead of PyInt_FromLong()? Can
you try the following patch?
--
Comment By: Miki Tebeka (tebeka)
Date: 2004-11-17 10:43
Message:
Logged In: YES
user_id=358087
1. How do I find the largest user id?
2. It's 4294967294
3. Can't attach etc/password since it's a company machine
(IT will kill me :-)
However there is a similar line for nobody with 65534
The hardware is 4 CPU with 16GB of memory.
OS is: Red Hat Enterprise Linux AS release 3 (Taroon Update 3)
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2004-11-17 03:58
Message:
Logged In: YES
user_id=33168
I just tested this on an opteron and it ran ok, so this
problem isn't necessarily opteron/64-bit specific. What is
the largest user id on the system? What is the value of
pw_uid that is causing a problem? Can you attach your
/etc/passwd file? If so, you may want to change any user info.
I have:
nobody:x:65534:65534:nobody:/:/bin/false
I tried adding another nobody with a larger uid, but did not
have any problems with the test. This is on a gentoo system.
--
Comment By: Miki Tebeka (tebeka)
Date: 2004-11-15 11:36
Message:
Logged In: YES
user_id=358087
Ran with -v:
$ ./python Lib/test/test_pwd.py -v
test_errors (__main__.PwdTest) ... ok
test_values (__main__.PwdTest) ... ERROR
==
ERROR: test_values (__main__.PwdTest)
--
Traceback (most recent call last):
File "Lib/test/test_pwd.py", line 42, in test_values
self.assert_(pwd.getpwuid(e.pw_uid) in
entriesbyuid[e.pw_uid])
OverflowError: signed integer is greater than maximum
--
Ran 2 tests in 0.480s
FAILED (errors=1)
Traceback (most recent call last):
File "Lib/test/test_pwd.py", line 92, in ?
test_main()
File "Lib/test/test_pwd.py", line 89, in test_main
test_support.run_unittest(PwdTest)
File "/tmp/miki/Python-2.4b2/Lib/test/test_support.py",
line 290, in run_unitt
est
run_suite(suite, testclass)
File "/tmp/miki/Python-2.4b2/Lib/test/test_support.py",
line 275, in run_suite
raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
File "Lib/test/test_pwd.py", line 42, in test_values
self.assert_(pwd.getpwuid(e.pw_uid) in
entriesbyuid[e.pw_uid])
OverflowError: signed integer is greater than maximum
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066546&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1164953 ] logging.basicConfig creates phantom handler
Bugs item #1164953, was opened at 2005-03-17 02:38
Message generated for change (Comment added) made by vsajip
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164953&group_id=5470
Category: Python Library
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: logistix (logistix)
Assigned to: Vinay Sajip (vsajip)
Summary: logging.basicConfig creates phantom handler
Initial Comment:
calling logging.basicConfig() creates a phantom handler
that doesn't operate in an intuitive way. A reproducable
follows.
My actual use case: I started off using the logging
module on a project with the builting logging.info(),
logging.debug(), logging.error() functions. As my needs
got more sophisticated, I started creating some loggers
via logging.getLogger('a.b.c') I setup a custom handler
to do formatting without printing "INFO:a.b.c" headers.
One of my import statements triggered a call to
logging.basicConfig. Halfway through the running
program, my logging messages started showing up
twice. Once without the header and once with. I
eventually tracked this down to usage of a logging.info()
statement. I tried explicitly calling logging.basicConfig
(level=logging.ERROR) to disable the duplicate errors,
but that didn't work.
A trivial patch is attached. It fixes the problem if you
explicitly call logging.basicConfig. I don't know if it will
fix the implicit calls by logging.info(), etc.
C:\Python24>python
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> import logging
>>>
>>> logger = logging.getLogger('foo')
>>> logger.setLevel(logging.INFO)
>>> logger.info('bar') # no output yet
No handlers could be found for logger "foo"
>>>
>>> console = logging.StreamHandler()
>>> console.setLevel(logging.INFO)
>>> console.setFormatter(logging.Formatter("%
(message)s")
... )
>>> logger.addHandler(console)
>>>
>>> logger.info('foo')
foo
>>>
>>> logger.warning('foo')
foo
>>>
>>> logger.debug('foo')
>>>
>>> logger.info('foo')
foo
>>>
>>> logging.basicConfig(level=logging.ERROR)
>>>
>>> logger.info('foo')
foo
INFO:foo:foo
>>> ^Z
C:\Python24>
--
>Comment By: Vinay Sajip (vsajip)
Date: 2005-03-17 10:52
Message:
Logged In: YES
user_id=308438
Thanks for the feedback, but it's not a bug. Check the
docstring for basicConfig: "This function does nothing if the
root logger already has handlers configured. It is a
convenience method intended for use by simple scripts to do
one-shot configuration of the logging package. The default
behaviour is to create a StreamHandler which writes to
sys.stderr, set a formatter using the BASIC_FORMAT format
string, and add the handler to the root logger."
The logging.debug(), etc. methods are for simple use of the
logging package. If you are using named loggers, then don't
use basicConfig() except to configure a handler at the root
level - and do this early in your application. Thereafter you
can log to the root logger (using logging.debug() and its
brethren) or to a named logger which has no handlers set (the
root's handlers will be used).
If you add a console handler manually to logger "foo" and
then add another one to the root handler via basicConfig(),
then both handlers will be called (correctly). This is what you
are seeing.
Your fix (add the level to the handler as well) does not fit the
contract of basicConfig(). Users working in simple mode will
just use the logger's level. Setting levels in the handler is for
more sophisticated use of the logging package than implied
by use of basicConfig() and logging.debug(), etc.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164953&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-932563 ] logging: need a way to discard Logger objects
Bugs item #932563, was opened at 2004-04-09 21:51
Message generated for change (Comment added) made by vsajip
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=932563&group_id=5470
Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 7
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: logging: need a way to discard Logger objects
Initial Comment:
There needs to be a way to tell the logging package
that an application is done with a particular logger
object. This is important for long-running processes
that want to use a logger to represent a related set of
activities over a relatively short period of time
(compared to the life of the process).
This is useful to allow creating per-connection loggers
for internet servers, for example. Using a
connection-specific logger allows the application to
provide an identifier for the session that can be
automatically included in the logs without having the
application encode it into each message (a far more
error prone approach).
--
>Comment By: Vinay Sajip (vsajip)
Date: 2005-03-17 10:53
Message:
Logged In: YES
user_id=308438
Hi Fred,
Any update on this? If you haven't the time (which I quite
understand), please post the code which does the Right Thing
(or mail it to me) without an explanation, and I'll try to
understand it.
--
Comment By: Vinay Sajip (vsajip)
Date: 2004-09-22 13:43
Message:
Logged In: YES
user_id=308438
Hi Fred,
Any update on this? If you haven't the time (which I quite
understand), please post the code which does the Right Thing
(or mail it to me) without an explanation, and I'll try to
understand it.
--
Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-07-01 03:53
Message:
Logged In: YES
user_id=3066
Vinay: I don't think that will work. Another issue that
crops up once I start looking into the Logger class is that
findCaller() won't do (what I think is) the Right Thing when
wrappers and subclasses are involved.
After reviewing my application, I think the only thing the
application really needs to control is the creation of the
record objects, but that has to happen on the wrapper, or
there's no way to get the necessary information into the
record (without seriously performing surgery on the
underlying logger).
I think I've come up with a base class that does the Right
Thing, but I need to write up an explanation of why it works
the way it does. It's not massively mysterious, but does
end up dealing with more than I really like worrying about.
I don't have any more time for this tonight, but will write
up what I have and post it here in the next few days.
It shouldn't be hard to refactor what's in logging.Logger
and my base class to share most of the code. Having the
base class in the logging package would avoid having to use
a separate findCaller() implementation.
Boosting the priority to make sure this stays on my radar.
--
Comment By: Vinay Sajip (vsajip)
Date: 2004-06-29 22:10
Message:
Logged In: YES
user_id=308438
I just had a further thought: is the approach below any good
to you? Apart from not being able to use the root logger, it
seems to meet your need.
import logging
class MyLogger(logging.Logger):
def makeRecord(self, name, level, fn, lno, msg, args,
exc_info):
record = logging.Logger.makeRecord(self, name, level, fn,
lno, msg, args, exc_info)
record.magicnumber = 0xDECAFBAD# special number
return record
logging._loggerClass = MyLogger
h = logging.StreamHandler()
logger = logging.getLogger("mylogger")
h.setFormatter(logging.Formatter("%(asctime)s %(levelname)
s %(magicnumber)X %(message)s"))
logger.addHandler(h)
logger.warn("There's a custom attribute in my message!")
--
Comment By: Vinay Sajip (vsajip)
Date: 2004-06-24 15:28
Message:
Logged In: YES
user_id=308438
Suppose I add a callable "recordMaker" to logging, and modify
makeRecord() to call it with logger + the args passed to
makeRecord(). If it's necessary to add extra attrs to the
LogRecord, this can be done by replacing recordMaker with
your own callable. Seems less icky - what do you think? If
you think it'll fly, are there any other args you think I need to
pass into the callable?
--
Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-06-24 14:06
Message:
Logged In: YES
user_id=3066
I've attached a file showing the class I came up with. I
don't consider this to be a good wrapper, just what worked.
I think one of the problems is that what I really want to
override is the makeRecord
[ python-Bugs-1153226 ] string interpolation breaks with %d and large float
Bugs item #1153226, was opened at 2005-02-28 05:10
Message generated for change (Comment added) made by arigo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153226&group_id=5470
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Thorne (jerub)
Assigned to: Nobody/Anonymous (nobody)
Summary: string interpolation breaks with %d and large float
Initial Comment:
We have experienced a problem recently when wanting to
render a large float as a string. Converting the float
to an int/long manuall was required.
'%d' % f
throws an exception for all floats f, f >= 2**31
Expected output, shown with 'int()' and 'long()':
>>> '%d %d' % (long(float(2**31)), int(float(2**31)))
'2147483648 2147483648'
Non-Working Example.
>>> '%d' % float(2**31)
Traceback (most recent call last):
File "", line 1, in ?
TypeError: int argument required
Tested on:
Python 2.3.4 (#1, Oct 26 2004, 16:42:40)
Python 2.4.1a0 (#2, Feb 9 2005, 22:42:24)
--
>Comment By: Armin Rigo (arigo)
Date: 2005-03-17 12:21
Message:
Logged In: YES
user_id=4771
I am afraid that the same problem occurs all over the place, wherever long
integers are accepted by built-in operations or functions. Most of these
places accept (and round) a float argument as well, though this is supposedly
deprecated. For example:
f = open('filename')
f.seek()# ok
f.seek(12.0)# ok
f.seek(.0) # OverflowError
Unless someone is willing to conduct a systematic review I believe it unlikely
that it will get fixed, given the deprecation status.
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-03-02 00:42
Message:
Logged In: YES
user_id=44345
Sorry, I got corn-fused and misinterpreted 2**50 as 2e50.
--
Comment By: Stephen Thorne (jerub)
Date: 2005-03-01 23:53
Message:
Logged In: YES
user_id=100823
%ld doesn't help. see the following example:
>>> "%.f" % float(2**31)
'2147483648'
>>> "%ld" % float(2**31)
Traceback (most recent call last):
File "", line 1, in ?
TypeError: int argument required
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-03-01 15:38
Message:
Logged In: YES
user_id=44345
This is probably a corner case that got missed in the
int/long convergence. Still, is there a reason not to use
%.f when you know you are passing a float and want to
display it with no fractional component?
>>> '%.f' % 2**50
'1125899906842624'
or %ld if you expect the range to exceed the integer limits of
your hardware?
>>> '%ld' % 2**50
'1125899906842624'
I agree the documentation could probably be improved
in this area.
--
Comment By: Stephen Thorne (jerub)
Date: 2005-03-01 13:21
Message:
Logged In: YES
user_id=100823
My immediate reaction is, yes. This is a bug.
Either floats should work with %d, or they should not at
all. Having a platform dependant upper bound on the size of
the float allowed is a bug.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-03-01 06:36
Message:
Logged In: YES
user_id=341410
Note that it will also raise a TypeError when the float f, f
< -2**31
Is this a bug? I don't know. I tend to not pass floats
when string interpolation is expecting integers. Maybe the
documentation should be cleared up.
If you really want a truncated float, perhaps "%.0f" is the
format you are looking for, to save you the effort of using
int() or long().
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153226&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1165306 ] Property access with decorator makes interpreter crash
Bugs item #1165306, was opened at 2005-03-17 15:56 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=1165306&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Remy Blank (remyblank) Assigned to: Nobody/Anonymous (nobody) Summary: Property access with decorator makes interpreter crash Initial Comment: The attached file makes the interpreter crash. Basially, a method is decorated, and used as the getter function for a property. Accessing the property provokes the crash. I get the following output (linux-2.6.10): [EMAIL PROTECTED] TestCases $ ./crashTest.py Creating instance Getting value Segmentation fault Using python-2.3.4 from Gentoo, i.e. it has a few patches from 2.3.5. On Windows XP with python-2.4, I get a "Python has encountered a problem and needs to close." dialog box. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1165306 ] Property access with decorator makes interpreter crash
Bugs item #1165306, was opened at 2005-03-17 14:56 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None >Priority: 6 Submitted By: Remy Blank (remyblank) Assigned to: Nobody/Anonymous (nobody) Summary: Property access with decorator makes interpreter crash Initial Comment: The attached file makes the interpreter crash. Basially, a method is decorated, and used as the getter function for a property. Accessing the property provokes the crash. I get the following output (linux-2.6.10): [EMAIL PROTECTED] TestCases $ ./crashTest.py Creating instance Getting value Segmentation fault Using python-2.3.4 from Gentoo, i.e. it has a few patches from 2.3.5. On Windows XP with python-2.4, I get a "Python has encountered a problem and needs to close." dialog box. -- >Comment By: Michael Hudson (mwh) Date: 2005-03-17 15:17 Message: Logged In: YES user_id=6656 Confirmed, on 2.4 HEAD, even. There's a lot going on in your test file that is unecessary, though; this is a smaller test case: types.MethodType(lambda :None, None)(1) instancemethod_call doesn't seem to expect im_class to be NULL... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&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-1165404 ] ConfigParser alternative key-value delimitier
Feature Requests item #1165404, was opened at 2005-03-17 19:57 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=1165404&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sergey Dorofeev (fidoman) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser alternative key-value delimitier Initial Comment: ConfigParser is module which parses commonly used INI files. It gets sections from file and values from sections. By now, it gets from file key and value divided by symbol ":" or "=". For FTN application, a want to use FTN addresses as keys. FTN address looks like "2:5020/12000". So if I try to use it as key, ConfigParser considers "2" as key and "5020/12000 = ..." as value. I made patch, which allows to use any set of symbols (or '=' and ':' by default for compatibility) as delimitier between key and value in INI file. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1165404&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1165306 ] Property access with decorator makes interpreter crash
Bugs item #1165306, was opened at 2005-03-17 09:56 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Remy Blank (remyblank) Assigned to: Guido van Rossum (gvanrossum) Summary: Property access with decorator makes interpreter crash Initial Comment: The attached file makes the interpreter crash. Basially, a method is decorated, and used as the getter function for a property. Accessing the property provokes the crash. I get the following output (linux-2.6.10): [EMAIL PROTECTED] TestCases $ ./crashTest.py Creating instance Getting value Segmentation fault Using python-2.3.4 from Gentoo, i.e. it has a few patches from 2.3.5. On Windows XP with python-2.4, I get a "Python has encountered a problem and needs to close." dialog box. -- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-03-17 12:03 Message: Logged In: YES user_id=6380 Looks like I wasn't finished with the thought when I checked it in. I think I was trying to make instancemethod generally useful as a currying primitive. That should probably be considered more careful; please roll it back. (I think it may have been part of the aborted experiment to get rid of bound methods.) Is there time to backport this to 2.4.1? -- Comment By: Michael Hudson (mwh) Date: 2005-03-17 11:44 Message: Logged In: YES user_id=6656 Hmm. A little CVS log reading finds us this: revision 2.170 date: 2003/04/09 19:35:08; author: gvanrossum; state: Exp; lines: +2 -2 branches: 2.170.10; Make it possible to call instancemethod() with 2 arguments. Guido, what was the motivation for this? Is it possible to create instancemethods with im_class == NULL some other way? (If there is, I don't see it). Also, you didn't add a unit test (in fact, instancemethod_new only gets called twice during a run of the test suite, both times with three arguments). -- Comment By: Michael Hudson (mwh) Date: 2005-03-17 10:17 Message: Logged In: YES user_id=6656 Confirmed, on 2.4 HEAD, even. There's a lot going on in your test file that is unecessary, though; this is a smaller test case: types.MethodType(lambda :None, None)(1) instancemethod_call doesn't seem to expect im_class to be NULL... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1165306 ] Property access with decorator makes interpreter crash
Bugs item #1165306, was opened at 2005-03-17 14:56 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Remy Blank (remyblank) Assigned to: Guido van Rossum (gvanrossum) Summary: Property access with decorator makes interpreter crash Initial Comment: The attached file makes the interpreter crash. Basially, a method is decorated, and used as the getter function for a property. Accessing the property provokes the crash. I get the following output (linux-2.6.10): [EMAIL PROTECTED] TestCases $ ./crashTest.py Creating instance Getting value Segmentation fault Using python-2.3.4 from Gentoo, i.e. it has a few patches from 2.3.5. On Windows XP with python-2.4, I get a "Python has encountered a problem and needs to close." dialog box. -- >Comment By: Michael Hudson (mwh) Date: 2005-03-17 17:15 Message: Logged In: YES user_id=6656 Well, it's a bit more subtle than I thought: >>> def f(): pass ... >>> print f.__get__(1).im_class None The problem occurs when *both* im_self and im_class are None; and I'm now reasonably convinced that calling the type object is the only way this can be acheived. So a simple check along these lines in instancemethod_new would suffice (patch attached), and seems less likely to break code. I suspect this has missed 2.4.1. remyblank: let me guess your code wasn't doing what you thought it did? :) -- Comment By: Guido van Rossum (gvanrossum) Date: 2005-03-17 17:03 Message: Logged In: YES user_id=6380 Looks like I wasn't finished with the thought when I checked it in. I think I was trying to make instancemethod generally useful as a currying primitive. That should probably be considered more careful; please roll it back. (I think it may have been part of the aborted experiment to get rid of bound methods.) Is there time to backport this to 2.4.1? -- Comment By: Michael Hudson (mwh) Date: 2005-03-17 16:44 Message: Logged In: YES user_id=6656 Hmm. A little CVS log reading finds us this: revision 2.170 date: 2003/04/09 19:35:08; author: gvanrossum; state: Exp; lines: +2 -2 branches: 2.170.10; Make it possible to call instancemethod() with 2 arguments. Guido, what was the motivation for this? Is it possible to create instancemethods with im_class == NULL some other way? (If there is, I don't see it). Also, you didn't add a unit test (in fact, instancemethod_new only gets called twice during a run of the test suite, both times with three arguments). -- Comment By: Michael Hudson (mwh) Date: 2005-03-17 15:17 Message: Logged In: YES user_id=6656 Confirmed, on 2.4 HEAD, even. There's a lot going on in your test file that is unecessary, though; this is a smaller test case: types.MethodType(lambda :None, None)(1) instancemethod_call doesn't seem to expect im_class to be NULL... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1165306 ] Property access with decorator makes interpreter crash
Bugs item #1165306, was opened at 2005-03-17 14:56 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Remy Blank (remyblank) >Assigned to: Guido van Rossum (gvanrossum) Summary: Property access with decorator makes interpreter crash Initial Comment: The attached file makes the interpreter crash. Basially, a method is decorated, and used as the getter function for a property. Accessing the property provokes the crash. I get the following output (linux-2.6.10): [EMAIL PROTECTED] TestCases $ ./crashTest.py Creating instance Getting value Segmentation fault Using python-2.3.4 from Gentoo, i.e. it has a few patches from 2.3.5. On Windows XP with python-2.4, I get a "Python has encountered a problem and needs to close." dialog box. -- >Comment By: Michael Hudson (mwh) Date: 2005-03-17 16:44 Message: Logged In: YES user_id=6656 Hmm. A little CVS log reading finds us this: revision 2.170 date: 2003/04/09 19:35:08; author: gvanrossum; state: Exp; lines: +2 -2 branches: 2.170.10; Make it possible to call instancemethod() with 2 arguments. Guido, what was the motivation for this? Is it possible to create instancemethods with im_class == NULL some other way? (If there is, I don't see it). Also, you didn't add a unit test (in fact, instancemethod_new only gets called twice during a run of the test suite, both times with three arguments). -- Comment By: Michael Hudson (mwh) Date: 2005-03-17 15:17 Message: Logged In: YES user_id=6656 Confirmed, on 2.4 HEAD, even. There's a lot going on in your test file that is unecessary, though; this is a smaller test case: types.MethodType(lambda :None, None)(1) instancemethod_call doesn't seem to expect im_class to be NULL... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1165306 ] Property access with decorator makes interpreter crash
Bugs item #1165306, was opened at 2005-03-17 14:56 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Remy Blank (remyblank) Assigned to: Guido van Rossum (gvanrossum) Summary: Property access with decorator makes interpreter crash Initial Comment: The attached file makes the interpreter crash. Basially, a method is decorated, and used as the getter function for a property. Accessing the property provokes the crash. I get the following output (linux-2.6.10): [EMAIL PROTECTED] TestCases $ ./crashTest.py Creating instance Getting value Segmentation fault Using python-2.3.4 from Gentoo, i.e. it has a few patches from 2.3.5. On Windows XP with python-2.4, I get a "Python has encountered a problem and needs to close." dialog box. -- >Comment By: Michael Hudson (mwh) Date: 2005-03-17 17:28 Message: Logged In: YES user_id=6656 Let's attach a test case too. -- Comment By: Michael Hudson (mwh) Date: 2005-03-17 17:15 Message: Logged In: YES user_id=6656 Well, it's a bit more subtle than I thought: >>> def f(): pass ... >>> print f.__get__(1).im_class None The problem occurs when *both* im_self and im_class are None; and I'm now reasonably convinced that calling the type object is the only way this can be acheived. So a simple check along these lines in instancemethod_new would suffice (patch attached), and seems less likely to break code. I suspect this has missed 2.4.1. remyblank: let me guess your code wasn't doing what you thought it did? :) -- Comment By: Guido van Rossum (gvanrossum) Date: 2005-03-17 17:03 Message: Logged In: YES user_id=6380 Looks like I wasn't finished with the thought when I checked it in. I think I was trying to make instancemethod generally useful as a currying primitive. That should probably be considered more careful; please roll it back. (I think it may have been part of the aborted experiment to get rid of bound methods.) Is there time to backport this to 2.4.1? -- Comment By: Michael Hudson (mwh) Date: 2005-03-17 16:44 Message: Logged In: YES user_id=6656 Hmm. A little CVS log reading finds us this: revision 2.170 date: 2003/04/09 19:35:08; author: gvanrossum; state: Exp; lines: +2 -2 branches: 2.170.10; Make it possible to call instancemethod() with 2 arguments. Guido, what was the motivation for this? Is it possible to create instancemethods with im_class == NULL some other way? (If there is, I don't see it). Also, you didn't add a unit test (in fact, instancemethod_new only gets called twice during a run of the test suite, both times with three arguments). -- Comment By: Michael Hudson (mwh) Date: 2005-03-17 15:17 Message: Logged In: YES user_id=6656 Confirmed, on 2.4 HEAD, even. There's a lot going on in your test file that is unecessary, though; this is a smaller test case: types.MethodType(lambda :None, None)(1) instancemethod_call doesn't seem to expect im_class to be NULL... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1161187 ] Install problem 2.4.1rc1 on Win98
Bugs item #1161187, was opened at 2005-03-11 09:56
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470
Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Spider (m_webber_sydney)
Assigned to: Martin v. Löwis (loewis)
Summary: Install problem 2.4.1rc1 on Win98
Initial Comment:
Python 2.4.1 Release Candidate 1.
I installed (with all the defautl settings)
python-2.4.1c1.msi on a Windows 98 machine.
The shortcuts in the Start / Programs / Python 2.4
group includes a shortcut named "Python Manuals".
This shortcut is inactive - does not point to anything
valid, and clicking on it does not bring up the manuals.
I assume that the shortcut should point to
C:/Python24/Doc/Python24.chm which certainly exists on
my machine and works ok if I access it directly.
I guess the install builds the shortcut wrongly.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2005-03-17 18:46
Message:
Logged In: YES
user_id=21627
I'm sorry about this. Please try
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-
2.4.1c2.msi
(which you can also get from python.org when its released)
--
Comment By: Spider (m_webber_sydney)
Date: 2005-03-16 12:32
Message:
Logged In: YES
user_id=1237039
I tried
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.4.12857.ms
i
(which is only 96K) and got "the installer has encountered
an unexpected error installing this package. This may
indicate a problem with this package. The error code is 2235."
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-03-16 08:05
Message:
Logged In: YES
user_id=21627
Can you please try
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.4.12857.msi
and confirm that it "works"? This has the CHM shortcut
non-advertised.
As for the log file: the link creation is correct IMO; it is
no problem that the argument is missing (as the CHM file is
the target of the link, and needs no arguments). I was
curious whether an error is logged, but that appears not to
be the case.
--
Comment By: Tim Peters (tim_one)
Date: 2005-03-15 03:20
Message:
Logged In: YES
user_id=31435
Martin, re "resiliency": Cool -- that works! Microsoft has too
much spare cash .
--
Comment By: Spider (m_webber_sydney)
Date: 2005-03-14 09:50
Message:
Logged In: YES
user_id=1237039
I looked at the log file, and an extract is below. It shows
fairly clearly that when the "Manuals" shortcut is created,
the arguments are missing.
Let me know if you still want the full log.
MSI (c) (63:E3): Note: 1: 2360
MSI (c) (63:E3): Note: 1: 2360
MSI (c) (63:E3): Note: 1: 2360
MSI (c) (63:E3): Note: 1: 2360
MSI (c) (63:E3): Executing op: InstallProtectedFiles(AllowUI=1)
MSI (c) (63:E3): Executing op:
ActionStart(Name=CreateShortcuts,Description=Creating
shortcuts,Template=Shortcut: )
Action 08:30:42: CreateShortcuts. Creating shortcuts
MSI (c) (63:E3): Executing op:
SetTargetFolder(Folder=23\Python 2.4\)
MSI (c) (63:E3): SHFOLDER::SHGetFolderPath returned:
C:\WINDOWS\Start Menu\Programs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=PYTHON|Python (command
line),Feature=DefaultFeature,Component={4DC71ADD-ADA5-4029-A5BC-5E8858F4243C},,,WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=2,,,)
CreateShortcuts: Shortcut: PYTHON|Python (command line)
MSI (c) (63:E3): Executing op: ShortcutCreate(Name=IDLE|IDLE
(Python
GUI),Feature=TclTk,Component={1E82B1B6-0262-4141-918C-8A03ED896CB7},,Arguments="C:\Python24\Lib\idlelib\idle.pyw",WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=0,,,)
CreateShortcuts: Shortcut: IDLE|IDLE (Python GUI)
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=MODDOCS|Module
Docs,Feature=TclTk,Component={1E82B1B6-0262-4141-918C-8A03ED896CB7},,Arguments="C:\Python24\Tools\scripts\pydocgui.pyw",WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=0,,,)
CreateShortcuts: Shortcut: MODDOCS|Module Docs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=MANUAL|Python
Manuals,Feature=Documentation,Component={A7ED4080-C9C8-4AD4-BBAF-2D2846B7FF95}
CreateShortcuts: Shortcut: MANUAL|Python Manuals
MSI (c) (63:E3): Executing op:
SetTargetFolder(Folder=23\Python 2.4\)
MSI (c) (63:E3): SHFOLDER::SHGetFolderPath returned:
C:\WINDOWS\Start Menu\Programs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=UNINST|Uninstall
Python,,,FileName=C:\WINDOWS\SYSTEM\msiexec,Arguments=/x{be027411-8e6b-4440-a29b-b07df0690230},,)
CreateShortcuts: Shortcut: UNINST|Uninstall Python
MSI (c) (63:E3): Executing op:
ActionStart(Name=WriteRegistryValues,Description=Writing
system registr
[ python-Bugs-1161187 ] Install problem 2.4.1rc1 on Win98
Bugs item #1161187, was opened at 2005-03-11 08:56
Message generated for change (Comment added) made by m_webber_sydney
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470
Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Spider (m_webber_sydney)
Assigned to: Martin v. Löwis (loewis)
Summary: Install problem 2.4.1rc1 on Win98
Initial Comment:
Python 2.4.1 Release Candidate 1.
I installed (with all the defautl settings)
python-2.4.1c1.msi on a Windows 98 machine.
The shortcuts in the Start / Programs / Python 2.4
group includes a shortcut named "Python Manuals".
This shortcut is inactive - does not point to anything
valid, and clicking on it does not bring up the manuals.
I assume that the shortcut should point to
C:/Python24/Doc/Python24.chm which certainly exists on
my machine and works ok if I access it directly.
I guess the install builds the shortcut wrongly.
--
>Comment By: Spider (m_webber_sydney)
Date: 2005-03-17 17:53
Message:
Logged In: YES
user_id=1237039
c2 installed ok on Win98, and the "Manuals" shortcut was
correctly built. I didn't do any testing beyond that point.
Thanks! I guess this one can be closed.
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-03-17 17:46
Message:
Logged In: YES
user_id=21627
I'm sorry about this. Please try
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-
2.4.1c2.msi
(which you can also get from python.org when its released)
--
Comment By: Spider (m_webber_sydney)
Date: 2005-03-16 11:32
Message:
Logged In: YES
user_id=1237039
I tried
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.4.12857.ms
i
(which is only 96K) and got "the installer has encountered
an unexpected error installing this package. This may
indicate a problem with this package. The error code is 2235."
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-03-16 07:05
Message:
Logged In: YES
user_id=21627
Can you please try
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.4.12857.msi
and confirm that it "works"? This has the CHM shortcut
non-advertised.
As for the log file: the link creation is correct IMO; it is
no problem that the argument is missing (as the CHM file is
the target of the link, and needs no arguments). I was
curious whether an error is logged, but that appears not to
be the case.
--
Comment By: Tim Peters (tim_one)
Date: 2005-03-15 02:20
Message:
Logged In: YES
user_id=31435
Martin, re "resiliency": Cool -- that works! Microsoft has too
much spare cash .
--
Comment By: Spider (m_webber_sydney)
Date: 2005-03-14 08:50
Message:
Logged In: YES
user_id=1237039
I looked at the log file, and an extract is below. It shows
fairly clearly that when the "Manuals" shortcut is created,
the arguments are missing.
Let me know if you still want the full log.
MSI (c) (63:E3): Note: 1: 2360
MSI (c) (63:E3): Note: 1: 2360
MSI (c) (63:E3): Note: 1: 2360
MSI (c) (63:E3): Note: 1: 2360
MSI (c) (63:E3): Executing op: InstallProtectedFiles(AllowUI=1)
MSI (c) (63:E3): Executing op:
ActionStart(Name=CreateShortcuts,Description=Creating
shortcuts,Template=Shortcut: )
Action 08:30:42: CreateShortcuts. Creating shortcuts
MSI (c) (63:E3): Executing op:
SetTargetFolder(Folder=23\Python 2.4\)
MSI (c) (63:E3): SHFOLDER::SHGetFolderPath returned:
C:\WINDOWS\Start Menu\Programs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=PYTHON|Python (command
line),Feature=DefaultFeature,Component={4DC71ADD-ADA5-4029-A5BC-5E8858F4243C},,,WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=2,,,)
CreateShortcuts: Shortcut: PYTHON|Python (command line)
MSI (c) (63:E3): Executing op: ShortcutCreate(Name=IDLE|IDLE
(Python
GUI),Feature=TclTk,Component={1E82B1B6-0262-4141-918C-8A03ED896CB7},,Arguments="C:\Python24\Lib\idlelib\idle.pyw",WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=0,,,)
CreateShortcuts: Shortcut: IDLE|IDLE (Python GUI)
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=MODDOCS|Module
Docs,Feature=TclTk,Component={1E82B1B6-0262-4141-918C-8A03ED896CB7},,Arguments="C:\Python24\Tools\scripts\pydocgui.pyw",WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=0,,,)
CreateShortcuts: Shortcut: MODDOCS|Module Docs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=MANUAL|Python
Manuals,Feature=Documentation,Component={A7ED4080-C9C8-4AD4-BBAF-2D2846B7FF95}
CreateShortcuts: Shortcut: MANUAL|Python Manuals
MSI (c) (63:E3): Executing op:
SetTargetFolder(Folder=23\Python 2.4\)
MSI (c) (63:E3): SHFOLDER::SHGetFolderPath returned:
C:\WINDO
[ python-Bugs-1165306 ] Property access with decorator makes interpreter crash
Bugs item #1165306, was opened at 2005-03-17 09:56 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Remy Blank (remyblank) >Assigned to: Michael Hudson (mwh) Summary: Property access with decorator makes interpreter crash Initial Comment: The attached file makes the interpreter crash. Basially, a method is decorated, and used as the getter function for a property. Accessing the property provokes the crash. I get the following output (linux-2.6.10): [EMAIL PROTECTED] TestCases $ ./crashTest.py Creating instance Getting value Segmentation fault Using python-2.3.4 from Gentoo, i.e. it has a few patches from 2.3.5. On Windows XP with python-2.4, I get a "Python has encountered a problem and needs to close." dialog box. -- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-03-17 13:43 Message: Logged In: YES user_id=6380 Looks OK on cursory inspection. -- Comment By: Michael Hudson (mwh) Date: 2005-03-17 12:28 Message: Logged In: YES user_id=6656 Let's attach a test case too. -- Comment By: Michael Hudson (mwh) Date: 2005-03-17 12:15 Message: Logged In: YES user_id=6656 Well, it's a bit more subtle than I thought: >>> def f(): pass ... >>> print f.__get__(1).im_class None The problem occurs when *both* im_self and im_class are None; and I'm now reasonably convinced that calling the type object is the only way this can be acheived. So a simple check along these lines in instancemethod_new would suffice (patch attached), and seems less likely to break code. I suspect this has missed 2.4.1. remyblank: let me guess your code wasn't doing what you thought it did? :) -- Comment By: Guido van Rossum (gvanrossum) Date: 2005-03-17 12:03 Message: Logged In: YES user_id=6380 Looks like I wasn't finished with the thought when I checked it in. I think I was trying to make instancemethod generally useful as a currying primitive. That should probably be considered more careful; please roll it back. (I think it may have been part of the aborted experiment to get rid of bound methods.) Is there time to backport this to 2.4.1? -- Comment By: Michael Hudson (mwh) Date: 2005-03-17 11:44 Message: Logged In: YES user_id=6656 Hmm. A little CVS log reading finds us this: revision 2.170 date: 2003/04/09 19:35:08; author: gvanrossum; state: Exp; lines: +2 -2 branches: 2.170.10; Make it possible to call instancemethod() with 2 arguments. Guido, what was the motivation for this? Is it possible to create instancemethods with im_class == NULL some other way? (If there is, I don't see it). Also, you didn't add a unit test (in fact, instancemethod_new only gets called twice during a run of the test suite, both times with three arguments). -- Comment By: Michael Hudson (mwh) Date: 2005-03-17 10:17 Message: Logged In: YES user_id=6656 Confirmed, on 2.4 HEAD, even. There's a lot going on in your test file that is unecessary, though; this is a smaller test case: types.MethodType(lambda :None, None)(1) instancemethod_call doesn't seem to expect im_class to be NULL... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1165306 ] Property access with decorator makes interpreter crash
Bugs item #1165306, was opened at 2005-03-17 15:56 Message generated for change (Comment added) made by remyblank You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Remy Blank (remyblank) Assigned to: Michael Hudson (mwh) Summary: Property access with decorator makes interpreter crash Initial Comment: The attached file makes the interpreter crash. Basially, a method is decorated, and used as the getter function for a property. Accessing the property provokes the crash. I get the following output (linux-2.6.10): [EMAIL PROTECTED] TestCases $ ./crashTest.py Creating instance Getting value Segmentation fault Using python-2.3.4 from Gentoo, i.e. it has a few patches from 2.3.5. On Windows XP with python-2.4, I get a "Python has encountered a problem and needs to close." dialog box. -- >Comment By: Remy Blank (remyblank) Date: 2005-03-17 21:13 Message: Logged In: YES user_id=568100 > remyblank: let me guess your code wasn't doing what you thought it did? :) Err... Not sure what you mean... What would be the correct way to do what I thought it did? The code was largely inspired by a Cookbook entry. These are still my first steps with decorators, and I have to admit I don't yet fully understand why I have to create a MethodType manually. -- Comment By: Guido van Rossum (gvanrossum) Date: 2005-03-17 19:43 Message: Logged In: YES user_id=6380 Looks OK on cursory inspection. -- Comment By: Michael Hudson (mwh) Date: 2005-03-17 18:28 Message: Logged In: YES user_id=6656 Let's attach a test case too. -- Comment By: Michael Hudson (mwh) Date: 2005-03-17 18:15 Message: Logged In: YES user_id=6656 Well, it's a bit more subtle than I thought: >>> def f(): pass ... >>> print f.__get__(1).im_class None The problem occurs when *both* im_self and im_class are None; and I'm now reasonably convinced that calling the type object is the only way this can be acheived. So a simple check along these lines in instancemethod_new would suffice (patch attached), and seems less likely to break code. I suspect this has missed 2.4.1. remyblank: let me guess your code wasn't doing what you thought it did? :) -- Comment By: Guido van Rossum (gvanrossum) Date: 2005-03-17 18:03 Message: Logged In: YES user_id=6380 Looks like I wasn't finished with the thought when I checked it in. I think I was trying to make instancemethod generally useful as a currying primitive. That should probably be considered more careful; please roll it back. (I think it may have been part of the aborted experiment to get rid of bound methods.) Is there time to backport this to 2.4.1? -- Comment By: Michael Hudson (mwh) Date: 2005-03-17 17:44 Message: Logged In: YES user_id=6656 Hmm. A little CVS log reading finds us this: revision 2.170 date: 2003/04/09 19:35:08; author: gvanrossum; state: Exp; lines: +2 -2 branches: 2.170.10; Make it possible to call instancemethod() with 2 arguments. Guido, what was the motivation for this? Is it possible to create instancemethods with im_class == NULL some other way? (If there is, I don't see it). Also, you didn't add a unit test (in fact, instancemethod_new only gets called twice during a run of the test suite, both times with three arguments). -- Comment By: Michael Hudson (mwh) Date: 2005-03-17 16:17 Message: Logged In: YES user_id=6656 Confirmed, on 2.4 HEAD, even. There's a lot going on in your test file that is unecessary, though; this is a smaller test case: types.MethodType(lambda :None, None)(1) instancemethod_call doesn't seem to expect im_class to be NULL... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1161187 ] Install problem 2.4.1rc1 on Win98
Bugs item #1161187, was opened at 2005-03-11 09:56
Message generated for change (Settings changed) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470
Category: Installation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Spider (m_webber_sydney)
Assigned to: Martin v. Löwis (loewis)
Summary: Install problem 2.4.1rc1 on Win98
Initial Comment:
Python 2.4.1 Release Candidate 1.
I installed (with all the defautl settings)
python-2.4.1c1.msi on a Windows 98 machine.
The shortcuts in the Start / Programs / Python 2.4
group includes a shortcut named "Python Manuals".
This shortcut is inactive - does not point to anything
valid, and clicking on it does not bring up the manuals.
I assume that the shortcut should point to
C:/Python24/Doc/Python24.chm which certainly exists on
my machine and works ok if I access it directly.
I guess the install builds the shortcut wrongly.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2005-03-17 22:37
Message:
Logged In: YES
user_id=21627
Thanks for the confirmation, and for the report! Closing as
fixed.
--
Comment By: Spider (m_webber_sydney)
Date: 2005-03-17 18:53
Message:
Logged In: YES
user_id=1237039
c2 installed ok on Win98, and the "Manuals" shortcut was
correctly built. I didn't do any testing beyond that point.
Thanks! I guess this one can be closed.
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-03-17 18:46
Message:
Logged In: YES
user_id=21627
I'm sorry about this. Please try
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-
2.4.1c2.msi
(which you can also get from python.org when its released)
--
Comment By: Spider (m_webber_sydney)
Date: 2005-03-16 12:32
Message:
Logged In: YES
user_id=1237039
I tried
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.4.12857.ms
i
(which is only 96K) and got "the installer has encountered
an unexpected error installing this package. This may
indicate a problem with this package. The error code is 2235."
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-03-16 08:05
Message:
Logged In: YES
user_id=21627
Can you please try
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.4.12857.msi
and confirm that it "works"? This has the CHM shortcut
non-advertised.
As for the log file: the link creation is correct IMO; it is
no problem that the argument is missing (as the CHM file is
the target of the link, and needs no arguments). I was
curious whether an error is logged, but that appears not to
be the case.
--
Comment By: Tim Peters (tim_one)
Date: 2005-03-15 03:20
Message:
Logged In: YES
user_id=31435
Martin, re "resiliency": Cool -- that works! Microsoft has too
much spare cash .
--
Comment By: Spider (m_webber_sydney)
Date: 2005-03-14 09:50
Message:
Logged In: YES
user_id=1237039
I looked at the log file, and an extract is below. It shows
fairly clearly that when the "Manuals" shortcut is created,
the arguments are missing.
Let me know if you still want the full log.
MSI (c) (63:E3): Note: 1: 2360
MSI (c) (63:E3): Note: 1: 2360
MSI (c) (63:E3): Note: 1: 2360
MSI (c) (63:E3): Note: 1: 2360
MSI (c) (63:E3): Executing op: InstallProtectedFiles(AllowUI=1)
MSI (c) (63:E3): Executing op:
ActionStart(Name=CreateShortcuts,Description=Creating
shortcuts,Template=Shortcut: )
Action 08:30:42: CreateShortcuts. Creating shortcuts
MSI (c) (63:E3): Executing op:
SetTargetFolder(Folder=23\Python 2.4\)
MSI (c) (63:E3): SHFOLDER::SHGetFolderPath returned:
C:\WINDOWS\Start Menu\Programs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=PYTHON|Python (command
line),Feature=DefaultFeature,Component={4DC71ADD-ADA5-4029-A5BC-5E8858F4243C},,,WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=2,,,)
CreateShortcuts: Shortcut: PYTHON|Python (command line)
MSI (c) (63:E3): Executing op: ShortcutCreate(Name=IDLE|IDLE
(Python
GUI),Feature=TclTk,Component={1E82B1B6-0262-4141-918C-8A03ED896CB7},,Arguments="C:\Python24\Lib\idlelib\idle.pyw",WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=0,,,)
CreateShortcuts: Shortcut: IDLE|IDLE (Python GUI)
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=MODDOCS|Module
Docs,Feature=TclTk,Component={1E82B1B6-0262-4141-918C-8A03ED896CB7},,Arguments="C:\Python24\Tools\scripts\pydocgui.pyw",WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=0,,,)
CreateShortcuts: Shortcut: MODDOCS|Module Docs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=MANUAL|Python
Manuals,Feature=Doc
[ python-Bugs-853411 ] After fork in subthread, signals are blocked
Bugs item #853411, was opened at 2003-12-03 16:55 Message generated for change (Comment added) made by moculus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853411&group_id=5470 Category: Threads Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Göran Uddeborg (goeran) Assigned to: Nobody/Anonymous (nobody) Summary: After fork in subthread, signals are blocked Initial Comment: When a Python program starts a new thread, and this new thread forks, the forked process ingores signals. It will not terminate, or dump core if that would be applicable, when it receives a signal. I attach a test case which illustrates the behaviour. In this example, the child process is sent a SEGV signal from the subthread of the parent process. This should cause the child process to die and produce a core. But execution of the parent program threads finishes, there is still a python process around, continuing to sleep. Apparently, Python subthreads blocks signals. On Linux, /proc/*/status for subthreads includes the line SigBlk: 7ffbfeff The Python documentation says one should only install signal handlers in the main thread, and only the main thread will recieve signals. So this makes sense. But when the subthread forks, the new process inherits this signal mask, which seems to be incorrect behaviour. I would assume, if Python sets this signal mask for threads, it should also reset it again after a fork. I've seen this on these two platforms: Python 2.2.3 on Red Hat Linux RHEL 3WS (IA32) Python 2.2.1 on Sun Solaris 8 (Sparc) -- Comment By: Erik Osheim (moculus) Date: 2005-03-18 03:45 Message: Logged In: YES user_id=542811 This bug is still around. I have been experiencing it firsthand: if I write a simple program with one parent and one child thread and run rsync in the parent thread (via os.system), all is well. In the child thread it hangs indefinitely. After putting a bunch of debugging into rsync, I discovered that a USR2 signal was getting sent but never received, and rsyncs parent thread was waiting for the child to exit, and that the child was sleeping (having not gotten the signal). Is there any clue as to why this happens? This has been widely observed on Linux 2.6.* (this particular case affects Gentoo). -- Comment By: gmanipon (pymonger) Date: 2004-12-06 21:24 Message: Logged In: YES user_id=1173063 Sorry for the bother. Was there any resolution to this bug report? -- Comment By: Jack Jansen (jackjansen) Date: 2004-01-26 10:02 Message: Logged In: YES user_id=45365 I have absolutely no idea where the bug could be, someone better versed in the threading ideosyncracies of the various platforms needs to look at this, but I do want to point at hairy_flange's comment that fink-python 2.2.3 on OSX does *not* exhibit the bug (while on other platforms it does). It may be worthwhile to download a fink-python in source form, and see whether they do any configure magic. -- Comment By: Steve Muir (hairy_flange) Date: 2004-01-26 04:04 Message: Logged In: YES user_id=960132 I just submitted a bug report that is a duplicate of this bug (apologies!), I observed the same behaviour with the Python shipped with Mac OS X (Python 2.3), and Python 2.2.2 on RedHat/x86, but Fink Python 2.2.3 for OS X does not have this bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853411&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1165761 ] KeyboardInterrupt causes segmentation fault with threads
Bugs item #1165761, was opened at 2005-03-17 21:18
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=1165761&group_id=5470
Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Stearns (jeffstearns)
Assigned to: Nobody/Anonymous (nobody)
Summary: KeyboardInterrupt causes segmentation fault with threads
Initial Comment:
The attached sample program crashes Python 2.4.1c1 with a
segmentation fault if it is interupted.
I wrote a simple program which simulates multiple HTTP clients.
The program is mult-threaded.
It runs on Debian with a 2.6 kernel.
If the program is interrupted (via ^C), Python 2.4.1c1 takes a
segmentation fault.
Investigation with gdb shows that the error occurs within
PyEval_EvalFrame at line 1661 below.
It's executing an END_FINALLY bytecode.
The offending statement is
v = POP();
The value of v is 0.
This is then passed to PyInt_Check(), which attempts to dereference
a NULL pointer.
1659case END_FINALLY:
1660v = POP();
1661if (PyInt_Check(v)) {
1662why = (enum why_code)
PyInt_AS_LONG(v);
1663assert(why != WHY_YIELD);
1664if (why == WHY_RETURN ||
1665why == WHY_CONTINUE)
1666retval = POP();
1667}
#0 PyEval_EvalFrame (f=0x821cd04) at Python/ceval.c:1661
#1 0x080ae6bd in fast_function (func=0x4030df8d,
pp_stack=0xbfffe85c, n=1, na=1076944740, nk=1079484852) at
Python/ceval.c:3629
#2 0x080ae254 in call_function (pp_stack=0xbfffe85c,
oparg=1076944740) at Python/ceval.c:3568
#3 0x080ac7a6 in PyEval_EvalFrame (f=0x8227d04) at Python/
ceval.c:2163
#4 0x080ad21e in PyEval_EvalCodeEx (co=0x4037e660,
globals=0x4030df64, locals=0x4030df8d, args=0x40295c78,
argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0,
closure=0x0)
at Python/ceval.c:2730
#5 0x08105647 in function_call (func=0x4038a304,
arg=0x40295c6c, kw=0x0) at Objects/funcobject.c:548
#6 0x0805c409 in PyObject_Call (func=0x8148088,
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#7 0x08062e38 in instancemethod_call (func=0x4038a304,
arg=0x40295c6c, kw=0x4030df64) at Objects/classobject.c:2431
#8 0x0805c409 in PyObject_Call (func=0x8148088,
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#9 0x080ae0e7 in PyEval_CallObjectWithKeywords
(func=0x4030df64, arg=0x4028702c, kw=0x405785a4) at Python/
ceval.c:3419
#10 0x0809101c in slot_tp_del (self=0x4057a1b4) at Objects/
typeobject.c:4818
#11 0x08086f93 in subtype_dealloc (self=0x4057a1b4) at Objects/
typeobject.c:669
#12 0x08062a4c in instancemethod_dealloc (im=0x4057857c) at
Objects/classobject.c:2225
#13 0x080790a4 in dict_dealloc (mp=0x4056aacc) at Objects/
dictobject.c:734
#14 0x0805e544 in instance_dealloc (inst=0x40569dcc) at Objects/
classobject.c:687
#15 0x081042cb in frame_dealloc (f=0x8218f14) at Objects/
frameobject.c:418
#16 0x080dc1e9 in PyThreadState_Clear (tstate=0x81f9820) at
Python/pystate.c:217
#17 0x080dbdf8 in PyInterpreterState_Clear (interp=0x8148048) at
Python/pystate.c:93
#18 0x080dcef2 in Py_Finalize () at Python/pythonrun.c:408
#19 0x08055391 in Py_Main (argc=1, argv=0xbfffee14) at Modules/
main.c:504
#20 0x08054eeb in main (argc=1076944740, argv=0x4030df64) at
Modules/python.c:23
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1165761 ] KeyboardInterrupt causes segmentation fault with threads
Bugs item #1165761, was opened at 2005-03-17 21:18
Message generated for change (Comment added) made by jeffstearns
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470
Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Stearns (jeffstearns)
Assigned to: Nobody/Anonymous (nobody)
Summary: KeyboardInterrupt causes segmentation fault with threads
Initial Comment:
The attached sample program crashes Python 2.4.1c1 with a
segmentation fault if it is interupted.
I wrote a simple program which simulates multiple HTTP clients.
The program is mult-threaded.
It runs on Debian with a 2.6 kernel.
If the program is interrupted (via ^C), Python 2.4.1c1 takes a
segmentation fault.
Investigation with gdb shows that the error occurs within
PyEval_EvalFrame at line 1661 below.
It's executing an END_FINALLY bytecode.
The offending statement is
v = POP();
The value of v is 0.
This is then passed to PyInt_Check(), which attempts to dereference
a NULL pointer.
1659case END_FINALLY:
1660v = POP();
1661if (PyInt_Check(v)) {
1662why = (enum why_code)
PyInt_AS_LONG(v);
1663assert(why != WHY_YIELD);
1664if (why == WHY_RETURN ||
1665why == WHY_CONTINUE)
1666retval = POP();
1667}
#0 PyEval_EvalFrame (f=0x821cd04) at Python/ceval.c:1661
#1 0x080ae6bd in fast_function (func=0x4030df8d,
pp_stack=0xbfffe85c, n=1, na=1076944740, nk=1079484852) at
Python/ceval.c:3629
#2 0x080ae254 in call_function (pp_stack=0xbfffe85c,
oparg=1076944740) at Python/ceval.c:3568
#3 0x080ac7a6 in PyEval_EvalFrame (f=0x8227d04) at Python/
ceval.c:2163
#4 0x080ad21e in PyEval_EvalCodeEx (co=0x4037e660,
globals=0x4030df64, locals=0x4030df8d, args=0x40295c78,
argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0,
closure=0x0)
at Python/ceval.c:2730
#5 0x08105647 in function_call (func=0x4038a304,
arg=0x40295c6c, kw=0x0) at Objects/funcobject.c:548
#6 0x0805c409 in PyObject_Call (func=0x8148088,
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#7 0x08062e38 in instancemethod_call (func=0x4038a304,
arg=0x40295c6c, kw=0x4030df64) at Objects/classobject.c:2431
#8 0x0805c409 in PyObject_Call (func=0x8148088,
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#9 0x080ae0e7 in PyEval_CallObjectWithKeywords
(func=0x4030df64, arg=0x4028702c, kw=0x405785a4) at Python/
ceval.c:3419
#10 0x0809101c in slot_tp_del (self=0x4057a1b4) at Objects/
typeobject.c:4818
#11 0x08086f93 in subtype_dealloc (self=0x4057a1b4) at Objects/
typeobject.c:669
#12 0x08062a4c in instancemethod_dealloc (im=0x4057857c) at
Objects/classobject.c:2225
#13 0x080790a4 in dict_dealloc (mp=0x4056aacc) at Objects/
dictobject.c:734
#14 0x0805e544 in instance_dealloc (inst=0x40569dcc) at Objects/
classobject.c:687
#15 0x081042cb in frame_dealloc (f=0x8218f14) at Objects/
frameobject.c:418
#16 0x080dc1e9 in PyThreadState_Clear (tstate=0x81f9820) at
Python/pystate.c:217
#17 0x080dbdf8 in PyInterpreterState_Clear (interp=0x8148048) at
Python/pystate.c:93
#18 0x080dcef2 in Py_Finalize () at Python/pythonrun.c:408
#19 0x08055391 in Py_Main (argc=1, argv=0xbfffee14) at Modules/
main.c:504
#20 0x08054eeb in main (argc=1076944740, argv=0x4030df64) at
Modules/python.c:23
--
>Comment By: Jeff Stearns (jeffstearns)
Date: 2005-03-17 22:44
Message:
Logged In: YES
user_id=660929
The bug also exists when Python is compiled with --with-pydebug:
% ./python2.4 -c 'import clientLoadSimulator; clientLoadSimulator.run(20)'
cCc.cCcCccCcc.CCC..CCC..C...C.C..Traceback (most
recent call last):
File "", line 1, in ?
File "clientLoadSimulator.py", line 67, in run
thread.join (1.0)
File "/usr/local/lib/python2.4/threading.py", line 550, in join
self.__block.wait(delay)
File "/usr/local/lib/python2.4/threading.py", line 222, in wait
_sleep(delay)
KeyboardInterrupt
[29492 refs]
Segmentation fault (core dumped)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
