On 1/10/06, Thomas Wouters wrote:

Aside from 'dl', what was also pointed out in c.l.py was the crashability of Python in general, even from pure Python code:

centurion:~ > python < . Segmentation fault

This I think ought to be fixed; it's just (I presume) the parser stumbling over extremely invalid input.

[...]

...

...

...

sys.setrecursionlimit(1<<30) f = lambda f:f(f) f(f) Segmentation fault

OK, point taken.

There's more, all from Python itself. And sure, "well, don't do that then" is a perfectly valid response to most of these harebrained tricks, but it does put a lie to the 'uncrashable python' idea :)

I'm not saying it's uncrashable. I'm saying that if you crash it, it's a bug unless proven harebrained. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

Thomas Wouters wrote:

centurion:~ > python < . Segmentation fault

[...]

...

...

...

sys.setrecursionlimit(1<<30) f = lambda f:f(f) f(f) Segmentation fault

There's more, all from Python itself. And sure, "well, don't do that then" is a perfectly valid response to most of these harebrained tricks, but it does put a lie to the 'uncrashable python' idea :)

Many of the "segfaulting Python" issues are platform specific. On a platform with a sane malloc, you get a MemoryError for the recursion. On a platform which doesn't see the current path as a readable file, you get "Access is denied." on the redirection attempt. As always, I'm sure that reasonable patches which work around such segfaulting cases will be acceptable, though remember that it may not be clear how to work around them. - Josiah

On 1/10/06, Thomas Wouters wrote:

Sorry, I missed the point I was aiming at, I guess. I wasn't aiming for fixable bugs; I see these things as, with great effort, holding up your foot at an awkward angle so that it ends up right at the business end of your primed and lit medieval cannon. We can jump through hoops to stop those particular examples, but I'd rather spend time and effort to fix *real* bugs instead.

I'm not sure what makes those particular examples less than real bugs. Users *will* trip over these things. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum writes:

On 1/10/06, Thomas Wouters wrote:

...

Sorry, I missed the point I was aiming at, I guess. I wasn't aiming for fixable bugs; I see these things as, with great effort, holding up your foot at an awkward angle so that it ends up right at the business end of your primed and lit medieval cannon. We can jump through hoops to stop those particular examples, but I'd rather spend time and effort to fix *real* bugs instead.

I'm not sure what makes those particular examples less than real bugs.

I think the sys.setrecursionlimit(1<<30) one is fairly well into the terriotory of "don't do that", isn't it? Cheers, mwh -- <exarkun> today's lesson <exarkun> don't strace X in an xterm -- from Twisted.Quotes

On 1/10/06, Thomas Wouters wrote:

centurion:~ > python < . Segmentation fault

I fixed that in Oct in head and 2.4 branch. Although Skip filed a bug since Py_FatalError() is called which generates a core dump in debug builds at least. http://python.org/sf/1353504 I'm not sure what else can be done except perhaps just print to stderr and exit() rather than abort().

...

...

...

sys.setrecursionlimit(1<<30) f = lambda f:f(f) f(f) Segmentation fault

Added as Lib/test/crashers/recursive_call.py I'm sure there are many more similar to this one though.

There's more, all from Python itself.

We should at least try to clearly document limitations such as these. That's why I added the crashers directory. Maybe we can even find volunteers to fix these. n

On 1/11/06, skip@pobox.com wrote:

>>> sys.setrecursionlimit(1<<30) >>> f = lambda f:f(f) >>> f(f) Segmentation fault

Is there some way that Python can determine that 1<<30 is an unreasonable recursion limit?

Yes, but that doesn't help -- there's some value in the middle where you may or may not get a crash depending on random other stuff that is going on, and the only way to know is to try. It's easy enough to code a loop that tries higher and higher values until it finds a crash. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

"Martin v. Löwis" writes:

Guido van Rossum wrote:

...

On the other hand it breaks one of the most fundamental Python guidelines: if you get a core dump (segfault etc.) it's a bug in Python or in a 3rd party extension, not in *your* Python code. An exception would have to be made for any code that uses ctypes, as it is usually trivial to cause core dumps with ctypes (I'd venture it's hard to avoid them ;-).

I don't expect this to count against including ctypes; but I do want it to be dealt with somehow!

I think the strongest point *for* ctypes is the inclusion of dl in the source distribution, which has the very same flaws as ctypes in terms of crashability.

So as for dealing with it "somehow": I would make ctypes a dynamically loaded module (ctypes.pyd), so administrators could remove it, and I could also make it a separate option in the Windows installer, so administrators could reject to install it.

Sounds good, although it should be noted that ctypes is a package now, with a ctypes.wrap subpackage (contains the code generator), a ctypes.macholib subpackage (contains Bob Ippolitos macholib for OS X), and ctypes.test subpackage whcih contains several test modules. Plus the _ctypes.(dll|so) extension module. Thomas

"Martin v. Löwis" writes:

Thomas Heller wrote:

...

Sounds good, although it should be noted that ctypes is a package now, with a ctypes.wrap subpackage (contains the code generator), a ctypes.macholib subpackage (contains Bob Ippolitos macholib for OS X), and ctypes.test subpackage whcih contains several test modules. Plus the _ctypes.(dll|so) extension module.

Ok. The installer should then combine them all into a feature.

Still, the admin could disable all of this just by removing _ctypes.dll, right?

Right. Thomas

...

...

...

...

Thomas Heller writes:

It looks like we need a pronouncement now.

+1 I am a lurker in this list. I maintain ctypes for Debian and I would love to see it in core python. Debian now includes ctypes for 10 Linux architectures and kFreeBSD. The only missing significant architecture is ARM because of lack of FFI support. Ganesan -- Ganesan Rajagopal (rganesan at debian.org) | GPG Key: 1024D/5D8C12EA Web: http://employees.org/~rganesan | http://rganesan.blogspot.com

Guido van Rossum wrote:

On 1/16/06, Thomas Heller wrote:

...

It looks like we need a pronouncement now.

Sorry. It appeared to me that there was general agreement to using a strongly worded warning in the docs, so I tuned out of the rest of the discussion. So for the record, I'm fine with that.

Ok. If Thomas checks in the code and the documentation, I'll do the Windows/setup part of it. Regards, Martin

"Martin v. Löwis" writes:

Guido van Rossum wrote:

...

On 1/16/06, Thomas Heller wrote:

...

It looks like we need a pronouncement now.

Sorry. It appeared to me that there was general agreement to using a strongly worded warning in the docs, so I tuned out of the rest of the discussion. So for the record, I'm fine with that.

ctypes includes libffi. libffi is build with GNU tools, which would have to be committed in the python svn repository. Several of these files are licensed under GPL: aclocal.m4 config-ml.in config.guess config.sub depcomp ltcf-c.sh ltconfig missing AFAICT, these files are only used to *build* libffi, and are not linked into or have to be distributed with the binaries. Is it a problem to have these files in the Python source code? Maybe it would be possible to reimplement the functionality in the setup.py script, but this is way beyond my expertise. Thanks, Thomas

On Jan 19, 2006, at 4:24 PM, Thomas Heller wrote:

Several of these files are licensed under GPL:

aclocal.m4 config-ml.in config.guess config.sub depcomp ltcf-c.sh ltconfig missing

Are you sure? The copies of aclocal.m4 and config-ml.in both disagree with you. aclocal seems to have a completely liberal license, and config-ml has a "whatever the license of the program it's building" license. James aclocal.m4:: # generated automatically by aclocal 1.7.3 -*- Autoconf -*- # Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002 # Free Software Foundation, Inc. # This file is free software; the Free Software Foundation # gives unlimited permission to copy and/or distribute it, # with or without modifications, as long as this notice is preserved. # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY, to the extent permitted by law; without # even the implied warranty of MERCHANTABILITY or FITNESS FOR A # PARTICULAR PURPOSE. # libtool.m4 - Configure libtool for the host system. -*-Autoconf-*- config-ml.in:: # Configure fragment invoked in the post-target section for subdirs # wanting multilib support. # # Copyright (C) 1995, 1997, 1998, 1999, 2000, 2001, 2002, 2003 # Free Software Foundation, Inc. # # This file is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place - Suite 330, # Boston, MA 02111-1307, USA. # # As a special exception to the GNU General Public License, if you # distribute this file as part of a program that contains a # configuration script generated by Autoconf, you may include it under # the same distribution terms that you use for the rest of that program.