[ python-Bugs-1451717 ] OS/X on i386 framework build

[SourceForge.net]

Bugs item #1451717, was opened at 2006-03-16 23:22
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451717&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ian Holsman (webperf)
Assigned to: Nobody/Anonymous (nobody)
Summary: OS/X on i386 framework build

Initial Comment:
in Makefile.pre (374) it hard codes the architecture to
'ppc' which isn't correct for the new x86 boxes.

this needs to be i386 for the framework install to
actually build on the new macs.

regards
Ian

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 16:07

Message:
Logged In: YES 
user_id=580910

BTW. The 'also' bit has been fixed in the trunk.

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-02 21:21

Message:
Logged In: YES 
user_id=580910

This is a duplicate of bug 1447587  

--

Comment By: Ian Holsman (webperf)
Date: 2006-03-16 23:34

Message:
Logged In: YES 
user_id=5209

also..
in plat-mac/applesingle.py the fields
AS_HEADER_FORMAT
and 
AS_ENTRY_FORMAT
need a '>' infront of the definitions
AS_HEADER_FORMAT=">LL16sh"
AS_ENTRY_FORMAT=">lll"
(this is what the system-packaged python has.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451717&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-944394 ] No examples or usage docs for urllib2

[SourceForge.net]

Bugs item #944394, was opened at 2004-04-29 11:02
Message generated for change (Comment added) made by fresh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Withers (fresh)
Assigned to: Nobody/Anonymous (nobody)
Summary: No examples or usage docs for urllib2

Initial Comment:
Hi there,

I'm sure I reported this before, but it's a couple of
major releases later, and there's still no usage docs
for urllib2.

The examples given are too trivial to be helpful, but
I'm guessing people are using the module so there must
be some examples out there somewhere ;-)

With a bit o fhelp from Moshez, I found the docstring
in the module source. At the very least, it'd be handy
if that appeared somewhere at:

http://docs.python.org/lib/module-urllib2.html

But really, mroe extensive and helpful documentation on
this cool new module would be very handy.

Chris

--

>Comment By: Chris Withers (fresh)
Date: 2006-04-17 14:19

Message:
Logged In: YES 
user_id=24723

I still feel there could be more.

I guess the best course, for me, would be to leave this open
but at a really low priority.

However, I probably wouldn't scream too much if the issue
was closed.

--

Comment By: John J Lee (jjlee)
Date: 2006-04-15 18:49

Message:
Logged In: YES 
user_id=261020

They are here: http://docs.python.org/lib/urllib2-examples.html

--

Comment By: Chris Withers (fresh)
Date: 2006-04-15 18:07

Message:
Logged In: YES 
user_id=24723

Where are these examples you're referring to?

I don't see any at:
http://docs.python.org/lib/module-urllib2.html

I've already commented that the existing ones in the
docstring would be a start but still don't really much help
in taking full advantage of this module.

--

Comment By: John J Lee (jjlee)
Date: 2006-04-15 17:34

Message:
Logged In: YES 
user_id=261020

Examples for urllib2 were added some time ago, so I suggest
this bug is closed.

--

Comment By: Chris Withers (fresh)
Date: 2004-06-01 08:17

Message:
Logged In: YES 
user_id=24723

I'm certainly willing, but I am totally incapable :-S

The reason I opened this issue is because it would seem that
urllib2 is better the urllib, but seems to be severely
underdocumented, and hence I don't understand how to use it
and so can't provide examples.

As I said in the original submission, including the module's
docstring in the Python module documentation would be a
start, but doesn't cover what appears to be the full
potential of a great module...

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-05-31 21:15

Message:
Logged In: YES 
user_id=21627

Are you willing to provide examples?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-944394 ] No examples or usage docs for urllib2

[SourceForge.net]

Bugs item #944394, was opened at 2004-04-29 12:02
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Withers (fresh)
Assigned to: Nobody/Anonymous (nobody)
Summary: No examples or usage docs for urllib2

Initial Comment:
Hi there,

I'm sure I reported this before, but it's a couple of
major releases later, and there's still no usage docs
for urllib2.

The examples given are too trivial to be helpful, but
I'm guessing people are using the module so there must
be some examples out there somewhere ;-)

With a bit o fhelp from Moshez, I found the docstring
in the module source. At the very least, it'd be handy
if that appeared somewhere at:

http://docs.python.org/lib/module-urllib2.html

But really, mroe extensive and helpful documentation on
this cool new module would be very handy.

Chris

--

Comment By: John J Lee (jjlee)
Date: 2006-04-17 15:26

Message:
Logged In: YES 
user_id=261020

Do you have any specific suggestions for what is unhelpful
and/or missing?

Otherwise, nothing is likely to change.

Note that a little was added at the bottom of this page in
2.4, explaining how OpenerDirector uses the handlers to open
URLs:

http://docs.python.org/lib/opener-director-objects.html

Looking at the top-level page, I guess an introduction /
overview would help?  Did you have other stuff in mind too?


--

Comment By: Chris Withers (fresh)
Date: 2006-04-17 15:19

Message:
Logged In: YES 
user_id=24723

I still feel there could be more.

I guess the best course, for me, would be to leave this open
but at a really low priority.

However, I probably wouldn't scream too much if the issue
was closed.

--

Comment By: John J Lee (jjlee)
Date: 2006-04-15 19:49

Message:
Logged In: YES 
user_id=261020

They are here: http://docs.python.org/lib/urllib2-examples.html

--

Comment By: Chris Withers (fresh)
Date: 2006-04-15 19:07

Message:
Logged In: YES 
user_id=24723

Where are these examples you're referring to?

I don't see any at:
http://docs.python.org/lib/module-urllib2.html

I've already commented that the existing ones in the
docstring would be a start but still don't really much help
in taking full advantage of this module.

--

Comment By: John J Lee (jjlee)
Date: 2006-04-15 18:34

Message:
Logged In: YES 
user_id=261020

Examples for urllib2 were added some time ago, so I suggest
this bug is closed.

--

Comment By: Chris Withers (fresh)
Date: 2004-06-01 09:17

Message:
Logged In: YES 
user_id=24723

I'm certainly willing, but I am totally incapable :-S

The reason I opened this issue is because it would seem that
urllib2 is better the urllib, but seems to be severely
underdocumented, and hence I don't understand how to use it
and so can't provide examples.

As I said in the original submission, including the module's
docstring in the Python module documentation would be a
start, but doesn't cover what appears to be the full
potential of a great module...

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-05-31 22:15

Message:
Logged In: YES 
user_id=21627

Are you willing to provide examples?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1193190 ] MACOSX_DEPLOYMENT_TARGET checked incorrectly

[SourceForge.net]

Bugs item #1193190, was opened at 2005-05-01 02:15
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193190&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Bob Ippolito (etrepum)
Summary: MACOSX_DEPLOYMENT_TARGET checked incorrectly

Initial Comment:
MACOSX_DEPLOYMENT_TARGET should be checked to be >= 
the configure time value (or not set).  Currently, it checks for 
equality.

For example, this is necessary in order to use a Python built for Mac 
OS X 10.3 but build an extension with features specific to Mac OS X 
10.4.

Backport candidate to 2.4, patches attached.

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 16:44

Message:
Logged In: YES 
user_id=580910

Applied as revision 45490 on the trunk.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193190&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1471806 ] IDLE does not start 2.4.3

[SourceForge.net]

Bugs item #1471806, was opened at 2006-04-17 11:58
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=1471806&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Erin (egrimes)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE does not start 2.4.3

Initial Comment:
IDLE does not start. 2.4.3  
Installed Python 2.4.3 on Windows XP SP 2
I shutoff my ZoneAlarm Firewall and Stopped the 
Windows
Firewall, turned off all Anti-Virus services.

Python was 2.4.2 was previously installed on this 
machine and worked fine. Machine was wiped, reloaded 
and Python 2.4.3 was available.

Steps:
1. Click Start -> All Programs -> Python 2.4 -> IDLE 
(Python GUI)
2. pythonw.exe process starts for a few seconds, then 
stops
3. Nothing happens

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471806&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1464056 ] curses library in python 2.4.3 broken

[SourceForge.net]

Bugs item #1464056, was opened at 2006-04-04 10:47
Message generated for change (Comment added) made by atler_
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: nomind (vnainar)
Assigned to: Nobody/Anonymous (nobody)
Summary: curses library in python 2.4.3 broken

Initial Comment:
My python programs using curses  library do not work
with version 2.4.3.Even the 'ncurses.py ' demo program
in the Demo/curses directory does not work correctly.
The problem seems to be in the 'panels' library


--

Comment By: Jan Palus (atler_)
Date: 2006-04-17 20:50

Message:
Logged In: YES 
user_id=1497957

/me confirms

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-04-15 17:30

Message:
Logged In: YES 
user_id=21627

Good spotting! Can everybody please confirm that the
attached patch fixes the problem?

--

Comment By: Jan Palus (atler_)
Date: 2006-04-15 16:48

Message:
Logged In: YES 
user_id=1497957

Half day of debugging and it seems that I found an answer...
just by accident ;).

When curses module is linked against ncursesw it seems that
it also should be linked against panelw not plain panel.
After changing this in setup.py, ncurses.py demo finally
runs fine.

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-04-15 09:05

Message:
Logged In: YES 
user_id=21627

I couldn't reproduce the problem on a Linux console
(although my console had a different size); so it remains
unreproducable for me.

--

Comment By: nomind (vnainar)
Date: 2006-04-13 13:00

Message:
Logged In: YES 
user_id=1493752

Well ,  it is the linux console (in VGA mode ).
The local is en_US.The size of the console is
100X37.



--

Comment By: Martin v. Löwis (loewis)
Date: 2006-04-11 07:32

Message:
Logged In: YES 
user_id=21627

Ah, ok. vnainar, atler_: What terminal had you been using to
make it crash? What is your locale? Any other conditions
that might be relevant (e.g. dimension of the terminal)?

--

Comment By: nomind (vnainar)
Date: 2006-04-11 07:13

Message:
Logged In: YES 
user_id=1493752

Removing 'ncursesw' (there are two references  to it in
'setup.py') seems to solve the problem. I noticed one more
oddity. Even before the above recompilation , it  ran fine
on an Xterm !


--

Comment By: Martin v. Löwis (loewis)
Date: 2006-04-11 00:28

Message:
Logged In: YES 
user_id=21627

That's hard to tell. Somebody would have to debug ncurses to
find out why it crashes. Notice that it crashes only on some
installations, so it is likely rather a problem with your
ncurses installation, than with Python (or even with ncurses
itself).

--

Comment By: Jan Palus (atler_)
Date: 2006-04-10 23:24

Message:
Logged In: YES 
user_id=1497957

loewis: removing lines refering to ncursesw solves the
problem. ncurses.py runs fine as well as other programs.

What is actual problem then? Something with ncursesw or
with python?

Anyway, Thanks for your help.

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-04-09 22:58

Message:
Logged In: YES 
user_id=21627

atler_: around line 427, you find

if self.compiler.find_library_file(lib_dirs,
 'ncursesw'):
readline_libs.append('ncursesw')
elif self.compiler.find_library_file(lib_dirs,
 'ncurses'):

Replace that with

if self.compiler.find_library_file(lib_dirs,
 'ncurses'):

(i.e. dropping the ncursesw part), and rebuild.

--

Comment By: Jan Palus (atler_)
Date: 2006-04-09 15:48

Message:
Logged In: YES 
user_id=1497957

More complete backtrace, I hope it will help:
http://pastebin.com/649445

--

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-09 14:14

Message:
Logged In: YES 
user_id=29957

The buildbot boxes don't show this problem.

You might need to rebuild a Python with -g and u

[ python-Bugs-1471934 ] Python libcrypt build problem on Solaris 8

[SourceForge.net]

Bugs item #1471934, was opened at 2006-04-17 20:02
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=1471934&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Eggert (eggert)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python libcrypt build problem on Solaris 8

Initial Comment:
Python 2.5a1 and Python 2.4.3 both build incorrectly on
Solaris 8 when compiled in 64-bit mode, using Sun
Studio 11 cc.  Here is the diagnostic:

cc -O -xarch=v9 -G
build/temp.solaris-2.8-sun4u-2.5/cryptmodule.o
-L/u/cs/fac/eggert/seasnet/prefix/lib -lcrypt -o
build/lib.solaris-2.8-sun4u-2.5/crypt.so
ld: fatal: library -lcrypt: not found
ld: fatal: File processing errors. No output written to
build/lib.solaris-2.8-sun4u-2.5/crypt.so

The problem is that setup.py looks at 32-bit libraries
when trying to decide whether a 64-bit build will work.
 Using LIBS=' -lcrypt_i' does not work around the
problem, since the LIBS setting is not exported to the
module build.  I'll attach a proposed patch to the
README file to warn about the problem.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471934&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1471938 ] curses mvwgetnstr build problem on Solaris 8

[SourceForge.net]

Bugs item #1471938, was opened at 2006-04-17 20:07
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=1471938&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Eggert (eggert)
Assigned to: Nobody/Anonymous (nobody)
Summary: curses mvwgetnstr build problem on Solaris 8

Initial Comment:
The _curses extension doesn't build on Solaris 8
(64-bit) due to the following problem:

building '_curses' extension
cc -O -xarch=v9 -xcode=pic32 -DNDEBUG -O -I.
-I/w/fac.01/cs/eggert/seasnet/Python-2.5a1/./Include
-I/u/cs/fac/eggert/seasnet/prefix/include -I./Include
-I. -I/w/fac.01/cs/eggert/seasnet/Python-2.5a1/Include
-I/w/fac.01/cs/eggert/seasnet/Python-2.5a1 -c
/w/fac.01/cs/eggert/seasnet/Python-2.5a1/Modules/_cursesmodule.c
-o build/temp.solaris-2.8-sun4u-2.5/_cursesmodule.o
"/w/fac.01/cs/eggert/seasnet/Python-2.5a1/Modules/_cursesmodule.c",
line 822: warning: implicit function declaration:
mvwgetnstr
cc -O -xarch=v9 -G
build/temp.solaris-2.8-sun4u-2.5/_cursesmodule.o
-L/u/cs/fac/eggert/seasnet/prefix/lib -lcurses
-ltermcap -o build/lib.solaris-2.8-sun4u-2.5/_curses.so
*** WARNING: renaming "_curses" since importing it
failed: ld.so.1: python: fatal: relocation error: file
build/lib.solaris-2.8-sun4u-2.5/_curses.so: symbol
mvwgetnstr: referenced symbol not found
building '_curses_panel' extension

This problem occurs with both 2.4.3 and 2.5a1.

I'll attach the obvious patch.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471938&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1467080 ] Many functions in socket module are not thread safe

[SourceForge.net]

Bugs item #1467080, was opened at 2006-04-08 18:09
Message generated for change (Comment added) made by sobomax
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Maxim Sobolev (sobomax)
Assigned to: Nobody/Anonymous (nobody)
Summary: Many functions in socket module are not thread safe

Initial Comment:
The socket module make a great effort to be thread-safe, but misses one 
big point - it uses single per-instance buffer to hold resolved 
sockaddr_xxx structures. Therefore, on SMP system it is possible that 
several threads calling functions that perform address resolution in 
parallel will stomp on each other resulting in incorrect or invalid address 
to be used in each case.

For example, two threads calling sendto() in parallel can result in packets 
to be sent to incorrect addresses - packets from thread one from time to 
time will be sent to address requested by thread two and vice versa.

Another, smaller issue is that the call to getnameinfo() is not protected 
with netdb mutex on systems that don't have thread-safe resolver.

--

>Comment By: Maxim Sobolev (sobomax)
Date: 2006-04-17 13:26

Message:
Logged In: YES 
user_id=24670

> Why is it necessary to allocate the memory dynamically?
> Couldn't the caller provide the memory on the stack (i.e.
> through a local variable)?

Local variable is not very good IMHO since in threading 
environment with hundreds of threads running at the same 
time stack can be a scarce resource. Another issue is that 
the caller doesn't know the actual size it has to allocate 
until the resolution has been done, therefore it would need 
to overallocate in most cases.

-Maxim

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-04-10 22:22

Message:
Logged In: YES 
user_id=21627

Why is it necessary to allocate the memory dynamically?
Couldn't the caller provide the memory on the stack (i.e.
through a local variable)?

--

Comment By: Maxim Sobolev (sobomax)
Date: 2006-04-10 17:08

Message:
Logged In: YES 
user_id=24670

Sorry, for some reason the patch did not go through first time. See attached.

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-04-09 14:18

Message:
Logged In: YES 
user_id=21627

I wonder why the sock_addr member is there in the socket
object in the first place. AFAICT, there is no need for it;
it was introduced in r4509.

Would you like to work on a patch?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1467080 ] Many functions in socket module are not thread safe

[SourceForge.net]

Bugs item #1467080, was opened at 2006-04-09 03:09
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Maxim Sobolev (sobomax)
Assigned to: Nobody/Anonymous (nobody)
Summary: Many functions in socket module are not thread safe

Initial Comment:
The socket module make a great effort to be thread-safe, but misses one 
big point - it uses single per-instance buffer to hold resolved 
sockaddr_xxx structures. Therefore, on SMP system it is possible that 
several threads calling functions that perform address resolution in 
parallel will stomp on each other resulting in incorrect or invalid address 
to be used in each case.

For example, two threads calling sendto() in parallel can result in packets 
to be sent to incorrect addresses - packets from thread one from time to 
time will be sent to address requested by thread two and vice versa.

Another, smaller issue is that the call to getnameinfo() is not protected 
with netdb mutex on systems that don't have thread-safe resolver.

--

>Comment By: Martin v. Löwis (loewis)
Date: 2006-04-17 23:22

Message:
Logged In: YES 
user_id=21627

The argument of "hundreds of threads" is a red herring. The
address space available to each thread typically doesn't
depend on the number of threads. Instead, the stack size is
pre-determined, so it's vice versa: the number of threads
supported depends on that stack-size, which (currently)
isn't tunable. Also, stack space is typically a scarce
resource only for recursive functions. For leave functions,
it doesn't matter, unless a single function consumes the
majority of the stack (which certainly wouldn't be the case
here).

Allocation on the stack is cheap, and over-allocation
doesn't hurt. Please change the patch to use automatic
variables. It will become simpler and more maintainable that
way (in addition, it should also become minimally faster).

--

Comment By: Maxim Sobolev (sobomax)
Date: 2006-04-17 22:26

Message:
Logged In: YES 
user_id=24670

> Why is it necessary to allocate the memory dynamically?
> Couldn't the caller provide the memory on the stack (i.e.
> through a local variable)?

Local variable is not very good IMHO since in threading 
environment with hundreds of threads running at the same 
time stack can be a scarce resource. Another issue is that 
the caller doesn't know the actual size it has to allocate 
until the resolution has been done, therefore it would need 
to overallocate in most cases.

-Maxim

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-04-11 07:22

Message:
Logged In: YES 
user_id=21627

Why is it necessary to allocate the memory dynamically?
Couldn't the caller provide the memory on the stack (i.e.
through a local variable)?

--

Comment By: Maxim Sobolev (sobomax)
Date: 2006-04-11 02:08

Message:
Logged In: YES 
user_id=24670

Sorry, for some reason the patch did not go through first time. See attached.

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-04-09 23:18

Message:
Logged In: YES 
user_id=21627

I wonder why the sock_addr member is there in the socket
object in the first place. AFAICT, there is no need for it;
it was introduced in r4509.

Would you like to work on a patch?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1467080 ] Many functions in socket module are not thread safe

[SourceForge.net]

Bugs item #1467080, was opened at 2006-04-08 18:09
Message generated for change (Comment added) made by sobomax
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Maxim Sobolev (sobomax)
Assigned to: Nobody/Anonymous (nobody)
Summary: Many functions in socket module are not thread safe

Initial Comment:
The socket module make a great effort to be thread-safe, but misses one 
big point - it uses single per-instance buffer to hold resolved 
sockaddr_xxx structures. Therefore, on SMP system it is possible that 
several threads calling functions that perform address resolution in 
parallel will stomp on each other resulting in incorrect or invalid address 
to be used in each case.

For example, two threads calling sendto() in parallel can result in packets 
to be sent to incorrect addresses - packets from thread one from time to 
time will be sent to address requested by thread two and vice versa.

Another, smaller issue is that the call to getnameinfo() is not protected 
with netdb mutex on systems that don't have thread-safe resolver.

--

>Comment By: Maxim Sobolev (sobomax)
Date: 2006-04-17 15:10

Message:
Logged In: YES 
user_id=24670

> The address space available to each thread typically 
doesn't
> depend on the number of threads. Instead, the stack size 
is
> pre-determined, so it's vice versa: the number of threads
> supported depends on that stack-size, which (currently)
isn't tunable.

Yes, but my point is that on low-end and/or embedded system 
the system can be configured with as low stack per thread 
as possible (since with for example 100 threads, every 
extra 10K of stack per thread means 1M of extra memory, 
which in the absence of paging needs to be wired down) and 
if only one thread needs this stack 990K of it will be 
effectively wasted. And since getaddrinfo()-family already 
uses heap for its results I don't see any big win in 
avoiding extra malloc()/free() call. Expecially considering 
that we are dealing with i/o here, so that system call 
overhead will be much more than that anyway, even if the 
program calls those functions heavily.

-Maxim

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-04-17 14:22

Message:
Logged In: YES 
user_id=21627

The argument of "hundreds of threads" is a red herring. The
address space available to each thread typically doesn't
depend on the number of threads. Instead, the stack size is
pre-determined, so it's vice versa: the number of threads
supported depends on that stack-size, which (currently)
isn't tunable. Also, stack space is typically a scarce
resource only for recursive functions. For leave functions,
it doesn't matter, unless a single function consumes the
majority of the stack (which certainly wouldn't be the case
here).

Allocation on the stack is cheap, and over-allocation
doesn't hurt. Please change the patch to use automatic
variables. It will become simpler and more maintainable that
way (in addition, it should also become minimally faster).

--

Comment By: Maxim Sobolev (sobomax)
Date: 2006-04-17 13:26

Message:
Logged In: YES 
user_id=24670

> Why is it necessary to allocate the memory dynamically?
> Couldn't the caller provide the memory on the stack (i.e.
> through a local variable)?

Local variable is not very good IMHO since in threading 
environment with hundreds of threads running at the same 
time stack can be a scarce resource. Another issue is that 
the caller doesn't know the actual size it has to allocate 
until the resolution has been done, therefore it would need 
to overallocate in most cases.

-Maxim

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-04-10 22:22

Message:
Logged In: YES 
user_id=21627

Why is it necessary to allocate the memory dynamically?
Couldn't the caller provide the memory on the stack (i.e.
through a local variable)?

--

Comment By: Maxim Sobolev (sobomax)
Date: 2006-04-10 17:08

Message:
Logged In: YES 
user_id=24670

Sorry, for some reason the patch did not go through first time. See attached.

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-04-09 14:18

Message:
Logged In: YES 
user_id=21627

I wonder why the sock_addr member is there in the socket
object in the first place. AFAICT, there is no need for it;
it was introduced in r4509.

Would you like to work on a patch?

[ python-Bugs-1471985 ] mimetools module getencoding error

[SourceForge.net]

Bugs item #1471985, was opened at 2006-04-17 22:20
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=1471985&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: James G. sack (jim) (jgsack)
Assigned to: Nobody/Anonymous (nobody)
Summary:  mimetools module getencoding error

Initial Comment:
in Python 2.4.1
---

(accessing mimetools via utllib..)

getencoding() returns
  '7bit'

when header contains
  Content-Type: text/html; charset=UTF-8

shouldn't that substitute for a absent transfer-encoding 
field?




--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471985&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1467080 ] Many functions in socket module are not thread safe

[SourceForge.net]

Bugs item #1467080, was opened at 2006-04-09 03:09
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Maxim Sobolev (sobomax)
Assigned to: Nobody/Anonymous (nobody)
Summary: Many functions in socket module are not thread safe

Initial Comment:
The socket module make a great effort to be thread-safe, but misses one 
big point - it uses single per-instance buffer to hold resolved 
sockaddr_xxx structures. Therefore, on SMP system it is possible that 
several threads calling functions that perform address resolution in 
parallel will stomp on each other resulting in incorrect or invalid address 
to be used in each case.

For example, two threads calling sendto() in parallel can result in packets 
to be sent to incorrect addresses - packets from thread one from time to 
time will be sent to address requested by thread two and vice versa.

Another, smaller issue is that the call to getnameinfo() is not protected 
with netdb mutex on systems that don't have thread-safe resolver.

--

>Comment By: Martin v. Löwis (loewis)
Date: 2006-04-18 00:51

Message:
Logged In: YES 
user_id=21627

The big win is in simplification of the code. Also, we are
not talking about 10k here. On Linux, sock_addr_t is 128
bytes. Take a look at set_error: it allocates 100 bytes for
an error buffer. Or sock_repr: 512 bytes for a buffer. Or
socket_gethostname: 1024 bytes. Or socket_gethostbyname_ex:
16384 bytes. socket_getaddrinfo: 30 bytes. os_init: 100 bytes

Or, looking at other modules: symtable.c:check_unoptimized:
300 bytes. Py_GetVersion: 250 bytes. PySys_SetArgv:
2*MAXPATHLEN+1 (on Linux, this is 8193 bytes). I could go on.

Don't worry about stack consumption. Or, if you do, analyse
the Python source code, and fix the big offenders first. 

Premature optimization is the root of all evil.

--

Comment By: Maxim Sobolev (sobomax)
Date: 2006-04-18 00:10

Message:
Logged In: YES 
user_id=24670

> The address space available to each thread typically 
doesn't
> depend on the number of threads. Instead, the stack size 
is
> pre-determined, so it's vice versa: the number of threads
> supported depends on that stack-size, which (currently)
isn't tunable.

Yes, but my point is that on low-end and/or embedded system 
the system can be configured with as low stack per thread 
as possible (since with for example 100 threads, every 
extra 10K of stack per thread means 1M of extra memory, 
which in the absence of paging needs to be wired down) and 
if only one thread needs this stack 990K of it will be 
effectively wasted. And since getaddrinfo()-family already 
uses heap for its results I don't see any big win in 
avoiding extra malloc()/free() call. Expecially considering 
that we are dealing with i/o here, so that system call 
overhead will be much more than that anyway, even if the 
program calls those functions heavily.

-Maxim

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-04-17 23:22

Message:
Logged In: YES 
user_id=21627

The argument of "hundreds of threads" is a red herring. The
address space available to each thread typically doesn't
depend on the number of threads. Instead, the stack size is
pre-determined, so it's vice versa: the number of threads
supported depends on that stack-size, which (currently)
isn't tunable. Also, stack space is typically a scarce
resource only for recursive functions. For leave functions,
it doesn't matter, unless a single function consumes the
majority of the stack (which certainly wouldn't be the case
here).

Allocation on the stack is cheap, and over-allocation
doesn't hurt. Please change the patch to use automatic
variables. It will become simpler and more maintainable that
way (in addition, it should also become minimally faster).

--

Comment By: Maxim Sobolev (sobomax)
Date: 2006-04-17 22:26

Message:
Logged In: YES 
user_id=24670

> Why is it necessary to allocate the memory dynamically?
> Couldn't the caller provide the memory on the stack (i.e.
> through a local variable)?

Local variable is not very good IMHO since in threading 
environment with hundreds of threads running at the same 
time stack can be a scarce resource. Another issue is that 
the caller doesn't know the actual size it has to allocate 
until the resolution has been done, therefore it would need 
to overallocate in most cases.

-Maxim

-

[ python-Bugs-1471938 ] curses mvwgetnstr build problem on Solaris 8

[SourceForge.net]

Bugs item #1471938, was opened at 2006-04-17 22:07
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471938&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Eggert (eggert)
Assigned to: Nobody/Anonymous (nobody)
Summary: curses mvwgetnstr build problem on Solaris 8

Initial Comment:
The _curses extension doesn't build on Solaris 8
(64-bit) due to the following problem:

building '_curses' extension
cc -O -xarch=v9 -xcode=pic32 -DNDEBUG -O -I.
-I/w/fac.01/cs/eggert/seasnet/Python-2.5a1/./Include
-I/u/cs/fac/eggert/seasnet/prefix/include -I./Include
-I. -I/w/fac.01/cs/eggert/seasnet/Python-2.5a1/Include
-I/w/fac.01/cs/eggert/seasnet/Python-2.5a1 -c
/w/fac.01/cs/eggert/seasnet/Python-2.5a1/Modules/_cursesmodule.c
-o build/temp.solaris-2.8-sun4u-2.5/_cursesmodule.o
"/w/fac.01/cs/eggert/seasnet/Python-2.5a1/Modules/_cursesmodule.c",
line 822: warning: implicit function declaration:
mvwgetnstr
cc -O -xarch=v9 -G
build/temp.solaris-2.8-sun4u-2.5/_cursesmodule.o
-L/u/cs/fac/eggert/seasnet/prefix/lib -lcurses
-ltermcap -o build/lib.solaris-2.8-sun4u-2.5/_curses.so
*** WARNING: renaming "_curses" since importing it
failed: ld.so.1: python: fatal: relocation error: file
build/lib.solaris-2.8-sun4u-2.5/_curses.so: symbol
mvwgetnstr: referenced symbol not found
building '_curses_panel' extension

This problem occurs with both 2.4.3 and 2.5a1.

I'll attach the obvious patch.


--

Comment By: Martin v. Löwis (loewis)
Date: 2006-04-18 00:53

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471938&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1467080 ] Many functions in socket module are not thread safe

[SourceForge.net]

Bugs item #1467080, was opened at 2006-04-08 18:09
Message generated for change (Comment added) made by sobomax
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Maxim Sobolev (sobomax)
Assigned to: Nobody/Anonymous (nobody)
Summary: Many functions in socket module are not thread safe

Initial Comment:
The socket module make a great effort to be thread-safe, but misses one 
big point - it uses single per-instance buffer to hold resolved 
sockaddr_xxx structures. Therefore, on SMP system it is possible that 
several threads calling functions that perform address resolution in 
parallel will stomp on each other resulting in incorrect or invalid address 
to be used in each case.

For example, two threads calling sendto() in parallel can result in packets 
to be sent to incorrect addresses - packets from thread one from time to 
time will be sent to address requested by thread two and vice versa.

Another, smaller issue is that the call to getnameinfo() is not protected 
with netdb mutex on systems that don't have thread-safe resolver.

--

>Comment By: Maxim Sobolev (sobomax)
Date: 2006-04-17 16:05

Message:
Logged In: YES 
user_id=24670

> The big win is in simplification of the code.

What do you call "big simplification"? Several malloc/free 
calls and appropriate NULL checks?

Aside from stack usage issues the big loss here is 
portability - we either need to use some fixed length 
buffer with the size sufficient to hold any type of address 
(ugly!) or use sockaddr_storage, which may not exist on all 
platforms supported by the python.

-Maxim

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-04-17 15:51

Message:
Logged In: YES 
user_id=21627

The big win is in simplification of the code. Also, we are
not talking about 10k here. On Linux, sock_addr_t is 128
bytes. Take a look at set_error: it allocates 100 bytes for
an error buffer. Or sock_repr: 512 bytes for a buffer. Or
socket_gethostname: 1024 bytes. Or socket_gethostbyname_ex:
16384 bytes. socket_getaddrinfo: 30 bytes. os_init: 100 bytes

Or, looking at other modules: symtable.c:check_unoptimized:
300 bytes. Py_GetVersion: 250 bytes. PySys_SetArgv:
2*MAXPATHLEN+1 (on Linux, this is 8193 bytes). I could go on.

Don't worry about stack consumption. Or, if you do, analyse
the Python source code, and fix the big offenders first. 

Premature optimization is the root of all evil.

--

Comment By: Maxim Sobolev (sobomax)
Date: 2006-04-17 15:10

Message:
Logged In: YES 
user_id=24670

> The address space available to each thread typically 
doesn't
> depend on the number of threads. Instead, the stack size 
is
> pre-determined, so it's vice versa: the number of threads
> supported depends on that stack-size, which (currently)
isn't tunable.

Yes, but my point is that on low-end and/or embedded system 
the system can be configured with as low stack per thread 
as possible (since with for example 100 threads, every 
extra 10K of stack per thread means 1M of extra memory, 
which in the absence of paging needs to be wired down) and 
if only one thread needs this stack 990K of it will be 
effectively wasted. And since getaddrinfo()-family already 
uses heap for its results I don't see any big win in 
avoiding extra malloc()/free() call. Expecially considering 
that we are dealing with i/o here, so that system call 
overhead will be much more than that anyway, even if the 
program calls those functions heavily.

-Maxim

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-04-17 14:22

Message:
Logged In: YES 
user_id=21627

The argument of "hundreds of threads" is a red herring. The
address space available to each thread typically doesn't
depend on the number of threads. Instead, the stack size is
pre-determined, so it's vice versa: the number of threads
supported depends on that stack-size, which (currently)
isn't tunable. Also, stack space is typically a scarce
resource only for recursive functions. For leave functions,
it doesn't matter, unless a single function consumes the
majority of the stack (which certainly wouldn't be the case
here).

Allocation on the stack is cheap, and over-allocation
doesn't hurt. Please change the patch to use automatic
variables. It will become simpler and more maintainable that
way (in addition, it should also become minimally faster).

--

Comment By: Maxim Sobolev (sobomax)
Date: 

[ python-Bugs-532646 ] Recursive class instance "error"

[SourceForge.net]

Bugs item #532646, was opened at 2002-03-20 10:56
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.3
>Status: Open
>Resolution: None
Priority: 5
Submitted By: Gregor Mirai (gregmi)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Recursive class instance "error"

Initial Comment:
If one writes the following code (tested on Python  
2.1, 2.2 on platforms MacOS X Server, MacOS X, Windows 
98, NT, 2000) one can easily produce several "errors".

MacOS X, MacOS X Server (Python 2.1, 2.2)
--
class A:
   def __getattr__(self, name):
 print name,
 return A()
--

>>> a=A()
>>> a.foo
Segmentation fault

Win98, NT, 2000 (Python 2.1, 2.2)
--
class A:
   def __getattr__(self, name):
 print name
 return A()
--

>>> a=A()
>>> a.foo
foo
__repr__ __call__ __call__ __call__ ... ad inf



--

>Comment By: Brett Cannon (bcannon)
Date: 2006-04-17 17:00

Message:
Logged In: YES 
user_id=357491

This was not fixed for new-style classes and still segfaults
the interpreter at least back to 2.4.

Reopening.

--

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-13 14:50

Message:
Logged In: YES 
user_id=6380

It was very specific to __call__ after all, and I found an
example that didn't involve __getattr__. See the comments I
checked in as part of the fix in classobject.c.

--

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-13 13:41

Message:
Logged In: YES 
user_id=6380

Hm. I'm tracing this in the debugger now, and it appears
that the problem is when trying to *print* an A instance.
The statement a.foo causes the problem simply because it
returns an A instance. (Proof: "a=A().foo; print a" fails in
the print.)

I think that instance_call may not be the real cause of the
problem...

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-12 15:38

Message:
Logged In: YES 
user_id=33168

The problem is that there is mutual recursion
between instance_call() and PyObject_Call().
The recursion apparently goes through the eval_frame() loop.

This patch increases the recursion depth so the mutual recursion
will eventually end (otherwise, the stack grows without bounds).

ISTM the first check SHOULD be reached, but it is not.
I don't understand why.  The recursion error must be set
in eval_frame().

The first block in the patch could be just this line:
++tstate->recursion_depth;

I didn't do it that way, since I didn't expect returning to
eval_frame().  I'm not sure if it's guaranteed to return
to eval_frame() which is why I left the first condition
in with the comment.  I suppose the comment should say
something like:  /* this condition doesn't seem to be triggered,
the recursion depth limit is exceeded in eval_frame */

The test for recursion_depth is necessary to ensure
that the recursion error isn't overwritten.  If this check
is removed, the follow exception is raised:
AttributeError: A instance has no __call__ method

Hopefully this makes sense.


--

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 09:08

Message:
Logged In: YES 
user_id=6380

Can you explain how the fix works? Why does the first
comment say

/* this shouldn't be reached, but just in case */

and why is this test necesary

if (tstate->recursion_depth < Py_GetRecursionLimit()) {

???

And who *does* report the recursion error?

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 15:52

Message:
Logged In: YES 
user_id=33168

The recursion fields are shared in the new patch.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 13:35

Message:
Logged In: YES 
user_id=33168

That sounds more reasonable.
I'll take a look and see if they can be integrated.


--

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-07 13:27

Message:
Logged In: YES 
user_id=6380

Fair enough.  Ideally this should share the recursion_limit
variable from ceval.c and the recursion_depth field of the
stack frame.

--

Comment By: Neal Norwi

[ python-Bugs-1472084 ] sgmllib do_tag description error

[SourceForge.net]

Bugs item #1472084, was opened at 2006-04-18 03:52
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=1472084&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: James G. sack (jim) (jgsack)
Assigned to: Nobody/Anonymous (nobody)
Summary: sgmllib do_tag description error

Initial Comment:
section 13.2 sgmllib -- Simple SGML parser

do_tag(attributes)  
This method is called to process an opening tag that does 
not come with a matching closing tag...

(that's incorrect)

It should say something like
This method is called to process an opening tag (only) if 
there is no corresponding start_tag function defined.





--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472084&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-532646 ] Recursive class instance "error"

[SourceForge.net]

Bugs item #532646, was opened at 2002-03-20 10:56
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregor Mirai (gregmi)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Recursive class instance "error"

Initial Comment:
If one writes the following code (tested on Python  
2.1, 2.2 on platforms MacOS X Server, MacOS X, Windows 
98, NT, 2000) one can easily produce several "errors".

MacOS X, MacOS X Server (Python 2.1, 2.2)
--
class A:
   def __getattr__(self, name):
 print name,
 return A()
--

>>> a=A()
>>> a.foo
Segmentation fault

Win98, NT, 2000 (Python 2.1, 2.2)
--
class A:
   def __getattr__(self, name):
 print name
 return A()
--

>>> a=A()
>>> a.foo
foo
__repr__ __call__ __call__ __call__ ... ad inf



--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-17 21:37

Message:
Logged In: YES 
user_id=33168

Please add a test case to Lib/test/crashers.

--

Comment By: Brett Cannon (bcannon)
Date: 2006-04-17 17:00

Message:
Logged In: YES 
user_id=357491

This was not fixed for new-style classes and still segfaults
the interpreter at least back to 2.4.

Reopening.

--

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-13 14:50

Message:
Logged In: YES 
user_id=6380

It was very specific to __call__ after all, and I found an
example that didn't involve __getattr__. See the comments I
checked in as part of the fix in classobject.c.

--

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-13 13:41

Message:
Logged In: YES 
user_id=6380

Hm. I'm tracing this in the debugger now, and it appears
that the problem is when trying to *print* an A instance.
The statement a.foo causes the problem simply because it
returns an A instance. (Proof: "a=A().foo; print a" fails in
the print.)

I think that instance_call may not be the real cause of the
problem...

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-12 15:38

Message:
Logged In: YES 
user_id=33168

The problem is that there is mutual recursion
between instance_call() and PyObject_Call().
The recursion apparently goes through the eval_frame() loop.

This patch increases the recursion depth so the mutual recursion
will eventually end (otherwise, the stack grows without bounds).

ISTM the first check SHOULD be reached, but it is not.
I don't understand why.  The recursion error must be set
in eval_frame().

The first block in the patch could be just this line:
++tstate->recursion_depth;

I didn't do it that way, since I didn't expect returning to
eval_frame().  I'm not sure if it's guaranteed to return
to eval_frame() which is why I left the first condition
in with the comment.  I suppose the comment should say
something like:  /* this condition doesn't seem to be triggered,
the recursion depth limit is exceeded in eval_frame */

The test for recursion_depth is necessary to ensure
that the recursion error isn't overwritten.  If this check
is removed, the follow exception is raised:
AttributeError: A instance has no __call__ method

Hopefully this makes sense.


--

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 09:08

Message:
Logged In: YES 
user_id=6380

Can you explain how the fix works? Why does the first
comment say

/* this shouldn't be reached, but just in case */

and why is this test necesary

if (tstate->recursion_depth < Py_GetRecursionLimit()) {

???

And who *does* report the recursion error?

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 15:52

Message:
Logged In: YES 
user_id=33168

The recursion fields are shared in the new patch.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 13:35

Message:
Logged In: YES 
user_id=33168

That sounds more reasonable.
I'll take a look and see if they can be integrated.


--

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-07 13:27

Message:
Logged In: YES 
user_id=6380

Fair enoug

[ python-Bugs-1471806 ] IDLE does not start 2.4.3

[SourceForge.net]

Bugs item #1471806, was opened at 2006-04-17 08:58
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471806&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Erin (egrimes)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE does not start 2.4.3

Initial Comment:
IDLE does not start. 2.4.3  
Installed Python 2.4.3 on Windows XP SP 2
I shutoff my ZoneAlarm Firewall and Stopped the 
Windows
Firewall, turned off all Anti-Virus services.

Python was 2.4.2 was previously installed on this 
machine and worked fine. Machine was wiped, reloaded 
and Python 2.4.3 was available.

Steps:
1. Click Start -> All Programs -> Python 2.4 -> IDLE 
(Python GUI)
2. pythonw.exe process starts for a few seconds, then 
stops
3. Nothing happens

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471806&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com