[ python-Bugs-1350188 ] "setdlopenflags" leads to crash upon "import"
Bugs item #1350188, was opened at 2005-11-07 22:26
Message generated for change (Comment added) made by jdpipe
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350188&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.4
Status: Closed
Resolution: Fixed
Priority: 7
Submitted By: John Pye (jdpipe)
Assigned to: Neal Norwitz (nnorwitz)
Summary: "setdlopenflags" leads to crash upon "import"
Initial Comment:
While playing around with correct values of the
dl.RTLD_ flags in the dl module, I found that I
could crash python as follows:
python -v
[...]
>>> import sys; import dl
dlopen("/usr/lib/python2.4/lib-dynload/dlmodule.so", 2);
import dl # dynamically loaded from
/usr/lib/python2.4/lib-dynload/dlmodule.so
>>> sys.setdlopenflags(15)
>>> import ascend
# ascend.pyc matches ascend.py
import ascend # precompiled from ascend.pyc
dlopen("./_ascend.so", f);
python: Objects/stringobject.c:105:
PyString_FromString: Assertion `str != ((void *)0)' failed.
Aborted
JP
--
>Comment By: John Pye (jdpipe)
Date: 2005-11-09 20:14
Message:
Logged In: YES
user_id=849068
Hi Neal,
Yeah the ascend.so thing is something I'm working on with
SWIG, basically some bindings for ASCEND, see
http://pye.dyndns.org/ascend/.
I'm probably not going to check out and build python from
sources, so I'll just have to take your word for it ;-)
Cheers
JP
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-09 18:03
Message:
Logged In: YES
user_id=33168
Thanks!
I don't have ascend.so. I tried importing time and it
crashed hard. I checked in a fix for me. Let me know if it
doesn't fix the problem for you.
Committed revision 41412.
Committed revision 41413. (2.4)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350188&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-799428 ] tk_focusNext() fails
Bugs item #799428, was opened at 2003-09-02 23:58
Message generated for change (Comment added) made by douardda
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=799428&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: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Perry Greenfield (perrygreenfield)
Assigned to: Nobody/Anonymous (nobody)
Summary: tk_focusNext() fails
Initial Comment:
Calls to the widget method tk_focusNext() fail with
"unsubscriptable object" error. Looking at the Tkinter.py
code for the routine shows this statement:
name = self.tk.call('tk_focusNext', self._w)
(line 433)
which used to return a string in 2.2 but now returns
a "cmdName object". When this is passed to
self._nametowidget(name), it fails when it tries to
subscript name (line 1006) since the object does
not support indexing. Perhaps str(name) or
name.string is more appropriate now? (when
that change is made, it works--well, I tested
name.string and that worked)
Perry Greenfield ([EMAIL PROTECTED])
--
Comment By: David Douard (douardda)
Date: 2005-11-09 16:03
Message:
Logged In: YES
user_id=692511
The problem is still not resolved for now (AFAIK).
Here is a very simple patch for Tkinter.py:
*** 432,442
--- 432,446
to 0."""
name = self.tk.call('tk_focusNext', self._w)
if not name: return None
+ try: name=name.string
+ except: pass
return self._nametowidget(name)
def tk_focusPrev(self):
"""Return previous widget in the focus order. See
tk_focusNext for details."""
name = self.tk.call('tk_focusPrev', self._w)
if not name: return None
+ try: name=name.string
+ except: pass
return self._nametowidget(name)
def after(self, ms, func=None, *args):
"""Call function once after given time.
Note: I have made this (try/except) cause I have encountered
cases where "name" was still a string (well, at least with
Python 2.3.1).
David (david.douard*gmail.com)
--
Comment By: Jeff Epler (jepler)
Date: 2003-09-07 17:23
Message:
Logged In: YES
user_id=2772
Presumably, _nametowidget() should be modified to work properly with a
"cmdName object", rather than modifying each site that gets a widget
path from a tk command.
--
Comment By: Perry Greenfield (perrygreenfield)
Date: 2003-09-03 15:29
Message:
Logged In: YES
user_id=252130
Presumably the same problem exists with tk_focusPrev.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=799428&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs
Bugs item #1338995, was opened at 2005-10-27 01:08
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&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: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Greg Couch (gregcouch)
Assigned to: Nobody/Anonymous (nobody)
Summary: CVS webbrowser.py (1.40) bugs
Initial Comment:
There are two calls to _safequote that are only made on
darwin, aka, Mac OS X. That function is missing.
And the UnixBrowser is missing an & in the "simpler
command" and thus causes python to hang until the
browser is exited (if it wasn't running already).
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-11-09 22:43
Message:
Logged In: YES
user_id=1188172
Fixed in Revision 41419.
--
Comment By: Greg Couch (gregcouch)
Date: 2005-10-31 23:01
Message:
Logged In: YES
user_id=131838
Breaking applications that use webbrowser does not help
application writers. It would be much more useful to me, as
an application writer, if the webbrowser module gave an
error saying it couldn't contact a web browser, rather than
the new behavior of hanging my application. You have yet to
address this common use case.
Running the webbrowser in the background is a contract that
the webbrowser module can't break and still be called the
webbrowser module. I agree that the 2.4.2 version is a
practical hack that should be fixed, but the CVS webbrower
almost fixes it while breaking existing applications. Since
adding an & is so bad (the web browser is already confirmed
to exist and to be executable), the CVS webbrower could be
changed to use the subprocess module instead of os.system,
and the original webbrowser contract could be preserved.
The wrong display or wrong xhost/xauth permissions are not a
problem because the python GUI application that calls
webbrowser would have failed to start up in the first place
if those problems existed. Starting the web browser in the
background only needs to confirm that the web browser
actually started up.
--
Comment By: Oleg Broytmann (phd)
Date: 2005-10-31 14:11
Message:
Logged In: YES
user_id=4799
Yes, I want.
Current practice of running a browser in the background by
default is deadly broken. The old code of webbrowser.py is
full of dirty hacks. Look at Netscape._remote(). It tries to
start a browser to send a remote command; if that fails it
tries to start the browser in the background, waits an
arbitrary number of seconds (why this? why not less? why not
more?) and without testing if the browser in the background
was started it retries sending the remote command. You can
never know if the browser was started and if the command was
sent becuase .open() does not return a result code.
At the global level the bug is that webbrowser.py doesn't
tri all browsers in the tryorder - it only concentrates on
the first it found in PATH. What if the brwoser cannot be
started (damaged disk image; wrong DISAPLY; wrong
xhost/xauth permissions)?
My patched webbrowser.py is much safer. It runs all browsers
in the tryorder until it finds one that can be started. One
doesn't need to wait a random number of seconds, too little
for slow systems, too many for fast. .open() returns a
success/fail status (on systems where it is possible to
obtain one).
The framework still alows you to shoot yourself in the foot,
but you must do it explicitly. Either run
os.system("shotgun-browser &")
yourself or register your own ShotgunBrowser. Thus the new
framework is safe by default but still flexible.
--
Comment By: Greg Couch (gregcouch)
Date: 2005-10-28 20:49
Message:
Logged In: YES
user_id=131838
So you really want to change existing practice and break all
Python GUI programs that invoke webbrowser.open?
And the Elinks example proves my point. What is the point
of it being a UnixBrowser, in the terminal window, if you
can't send remote commands to it (because the Python GUI
application is blocked until the browser exits)? Tty-based
browsers are nice for completeness, but are really a last
resort for a Python application, and imply that no windowing
system is available (i.e, remotely logged in and not
forwarding X connections, so not running GUI applications
either).
--
Comment By: Oleg Broytmann (phd)
Date: 2005-10-28 13:56
Message:
Logged In: YES
user_id=4799
No, I still think it is a bad idea to put a generic Unix
browser to background by d
[ python-Feature Requests-1351692 ] Switch to make pprint.pprint display ints and longs in hex
Feature Requests item #1351692, was opened at 2005-11-08 22:29 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&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: Mark Hirota (markhirota) Assigned to: Nobody/Anonymous (nobody) Summary: Switch to make pprint.pprint display ints and longs in hex Initial Comment: It would be nice to have some sort of switch or hook to allow 'pretty-printing' of integers and long integers in hexidecimal. So, for example: >>> import pprint >>> pprint.pprint(range(10)) # instead of this: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> pprint.hexint = True >>> pprint.pprint(range(10)) # you would get this: [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> pprint.pprint(range(0x1,0x10010)) # and this: [0x1L, 0x10001L, 0x10002L, 0x10003L, 0x10004L, 0x10005L, 0x10006L, 0x10007L, 0x10008L, 0x10009L, 0x1000AL, 0x1000BL, 0x1000CL, 0x1000DL, 0x1000EL, 0x1000FL] >>> Thanks, --MH -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-09 22:45 Message: Logged In: YES user_id=1188172 Moving to Feature Requests. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1352621 ] SVN webbrowser.py fix 41419 didn't
Bugs item #1352621, was opened at 2005-11-09 14:26 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=1352621&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: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: SVN webbrowser.py fix 41419 didn't Initial Comment: The new fix of setting remote_background to True and adding an & in the "simplier command" case can't work. If remote_background is True, then the first os.system call will always succeed and thus the second one will never be called. So if the web browser isn't already running, it will never start up. As I alluded to in my previous bug submission 1338995, the real fix will involve using the subprocess module -- I will try to find some time to develop and test a patch and submit it. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1352621&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1351707 ] zipimport produces incomplete IOError instances
Bugs item #1351707, was opened at 2005-11-09 07:43 Message generated for change (Comment added) made by krumms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1351707&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: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Nobody/Anonymous (nobody) Summary: zipimport produces incomplete IOError instances Initial Comment: The get_data() method on the zipimport.zipimporter object produces IOError exceptions that only have an error message. It should use PyErr_SetFromErrnoWithFilename() instead of PyErr_Format() for IOError exceptions. This should be fixed for both Python 2.4.3 and 2.5. -- Comment By: Thomas Lee (krumms) Date: 2005-11-10 10:46 Message: Logged In: YES user_id=315535 Patch against HEAD here: http://sourceforge.net/tracker/index.php?func=detail&aid=1352711&group_id=5470&atid=305470 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1351707&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1350498 ] CVS migration not in www.python.org docs
Bugs item #1350498, was opened at 2005-11-07 08:52 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350498&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) >Assigned to: Brett Cannon (bcannon) Summary: CVS migration not in www.python.org docs Initial Comment: The development head has recently moved from CVS on sourceforge to subversion on python.org. The www.python.org documentation still sends people to the sourceforge cvs via (1) The left hand navigation link (main page) under Documenation section, python project, cvs. (The similar link on http://www.python.org/dev/ has been updated.) (2) The text of http://www.python.org/dev/ still says that deveopment takes place on sourceforge and sends people to the sourceforge cvs browser It also includes a link to (sourceforge) CVS instructions, but no mention of subversion. (3) The tools link then points to http://www.python. org/dev/tools.html, which still refers to CVS and CVS instructions. (4) The developer FAQ (http://www.python.org/dev/ devfaq.html) contains sections 1.2 and 1.4 for subversion (combine them?) and 1.3 for CVS -- section 1.3 seems to imply that the CVS tree is still active. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-09 21:48 Message: Logged In: YES user_id=33168 Brett, did you finish updating all these docs? Is this bug dead now? -- Comment By: Martin v. Löwis (loewis) Date: 2005-11-07 15:19 Message: Logged In: YES user_id=21627 I fixed the first two. The latter will be modified later this year, or next year. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350498&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1092502 ] Memory leak in socket.py on Mac OS X 10.3
Bugs item #1092502, was opened at 2004-12-29 03:09
Message generated for change (Comment added) made by a_lauer
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092502&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: bacchusrx (bacchusrx)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory leak in socket.py on Mac OS X 10.3
Initial Comment:
Some part of socket.py leaks memory on Mac OS X 10.3 (both with
the python 2.3 that ships with the OS and with python 2.4).
I encountered the problem in John Goerzen's offlineimap.
Transfers of messages over a certain size would cause the program
to bail with malloc errors, eg
*** malloc: vm_allocate(size=5459968) failed (error code=3)
*** malloc[13730]: error: Can't allocate region
Inspecting the process as it runs shows that python's total memory
size grows wildly during such transfers.
The bug manifests in _fileobject.read() in socket.py. You can
replicate the problem easily using the attached example with "nc -l
-p 9330 < /dev/zero" running on some some remote host.
The way _fileobject.read() is written, socket.recv is called with the
larger of the minimum rbuf size or whatever's left to be read.
Whatever is received is then appended to a buffer which is joined
and returned at the end of function.
It looks like each time through the loop, space for recv_size is
allocated but not freed, so if the loop runs for enough iterations,
python exhausts the memory available to it.
You can sidestep the condition if recv_size is small (like
_fileobject.default_bufsize small).
I can't replicate this problem with python 2.3 on FreeBSD 4.9 or
FreeBSD 5.2, nor on Mac OS X 10.3 if the logic from
_fileobject.read() is re-written in Perl (for example).
--
Comment By: Andreas Lauer (a_lauer)
Date: 2005-11-10 08:42
Message:
Logged In: YES
user_id=1376343
The problem also occurs in rare cases under Windows XP with
Python 2.3.4. I Suspect the code line
recv_size = max(self._rbufsize, left)
in socket.py to be a part of the problem.
In the case that I investigated, this caused >600 allocations
of up to 5 MBytes (which came in 8 KB packets).
Sure, the memory allocator should be able to handle this in
_socket.recv (first it allocates the X MBytes buffer, which
is later
resized with _PyString_Resize), but it I think the correct
line in socket.py
is
recv_size = min(self._rbufsize, left).
At least, after this my problem was gone.
--
Comment By: Bob Ippolito (etrepum)
Date: 2005-01-02 03:25
Message:
Logged In: YES
user_id=139309
that code paste is missing an "int i" at the beginning of main..
--
Comment By: Bob Ippolito (etrepum)
Date: 2005-01-02 03:23
Message:
Logged In: YES
user_id=139309
#include
#define NUM_ALLOCATIONS 10
#define ALLOC_SIZE 10485760
#define ALLOC_RESIZE 1492
int main(int argc, char **argv) {
/* exiting will free all this leaked memory */
for (i = 0; i < NUM_ALLOCATIONS; i++) {
void *orig_ptr, *new_ptr;
size_t new_size, orig_size;
orig_ptr = malloc(ALLOC_SIZE);
orig_size = malloc_size(orig_ptr);
if (orig_ptr == NULL) {
printf("failure to malloc %d\n", i);
abort();
}
new_ptr = realloc(orig_ptr, ALLOC_RESIZE);
new_size = malloc_size(new_ptr);
printf("resized %d[%p] -> %d[%p]\n",
orig_size, orig_ptr, new_size, new_ptr);
if (new_ptr == NULL) {
printf("failure to realloc %d\n", i);
abort();
}
}
return 0;
}
--
Comment By: Bob Ippolito (etrepum)
Date: 2005-01-02 03:22
Message:
Logged In: YES
user_id=139309
Ok. I've tracked it down. realloc(...) on Darwin doesn't actually resize
memory unless it *has* to. For shrinking an allocation, it does not have
to, therefore realloc(...) with a smaller size is a no-op.
It seems that this may be a misunderstanding by Python. The man page
for realloc(...) does not say that it will EVER free memory, EXCEPT in the
case where it has to allocate a larger region.
I'll attach an example that demonstrates this outside of Python.
--
Comment By: bacchusrx (bacchusrx)
Date: 2005-01-02 00:01
Message:
Logged In: YES
user_id=646321
I've been able to replicate the problem reliably on both 10.3.5 and
10.3.7. I've attached two more examples to demonstrate:
Try this: Do, "dd if=/dev/zero of=./data bs=1024 count=102
