[ python-Bugs-1630794 ] Seg fault in readline call.
Bugs item #1630794, was opened at 2007-01-08 18:02 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630794&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.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: gnovak (gnovak) Assigned to: Nobody/Anonymous (nobody) Summary: Seg fault in readline call. Initial Comment: GDL is a free implementation of the IDL programming language that can be built as a Python module to allow one to call IDL code from Python. http://gnudatalanguage.sourceforge.net/ When "enough" of readline has been activated, I get a seg fault with the backtrace listed below when trying to call any GDL code from Python. I've also reported the problem there. One way to initialize enough of readline is to use IPython (http://ipython.scipy.org), an enhanced interactive Python shell (this is how I found the bug). Another way is to follow the instructions from IPython's author (no IPython required) listed below. I am using: OS X 10.4.8 Python 2.4.2 (#1, Mar 22 2006, 21:27:43) [GCC 4.0.1 (Apple Computer, Inc. build 5247)] on darwin GDL 0.9 pre 3 readline 5.0 -- >Comment By: Michael Hudson (mwh) Date: 2007-01-09 09:40 Message: Logged In: YES user_id=6656 Originator: NO Ah, I didn't see extra.txt, sorry about that. I'd advise a debug build, and continuing to try newer versions of Python and readline. The crashing line seems to be: line = history_get(state->length)->line; which suggests that readline has gotten confused somehow. But it could be Python misuse, of course. Or a memory scribbling bug in some extension module, that's always fun -- Comment By: gnovak (gnovak) Date: 2007-01-08 21:46 Message: Logged In: YES user_id=1037806 Originator: YES The GDB backtrace is (and was) in the attached text file extra.txt. Also in extra.txt are instructions for causing Python to crash using plain Python and GDL. Unfortunately I don't know a way to cause the seg fault without installing GDL. I'm working on trying it with Python2.5 and newer readlines. -- Comment By: Michael Hudson (mwh) Date: 2007-01-08 21:09 Message: Logged In: YES user_id=6656 Originator: NO You don't really provide enough information for us to be able to help you. A self-contained test case would be best, failing that a backtrace from gdb might help. Also, Python 2.5 and readline 5.1 are out now, maybe you could try with them? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630794&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1627575 ] RotatingFileHandler cannot recover from failed doRollover()
Bugs item #1627575, was opened at 2007-01-04 06:08 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627575&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.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Forest Wilkinson (forest) Assigned to: Vinay Sajip (vsajip) Summary: RotatingFileHandler cannot recover from failed doRollover() Initial Comment: When RotatingFileHandler.doRollover() raises an exception, it puts the handler object in a permanently failing state, with no way to recover using RotatingFileHandler methods. From that point on, the handler object raises an exception every time a message is logged, which renders logging in an application practically useless. Furthermore, a handleError() method has no good way of correcting the problem, because the API does not expose any way to re-open the file after doRollover() has closed it. Unfortunately, this is a common occurrence on Windows, because doRollover() will fail if someone is running tail -f on the log file. Suggestions: - Make doRollover() always leave the handler object in a usable state, even if the rollover fails. - Add a reOpen() method to FileHandler, which an error handler could use to recover from problems like this. (It would also be useful for applications that want to re-open log files in response to a SIGHUP.) -- >Comment By: Vinay Sajip (vsajip) Date: 2007-01-09 14:56 Message: Logged In: YES user_id=308438 Originator: NO I've added an _open() method to logging.FileHandler [checked into trunk]. This facilitates reopening by derived class error handlers. -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-01-04 06:27 Message: Logged In: YES user_id=33168 Originator: NO Vinay, was this addressed? I thought there was a similar issue. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627575&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1630894 ] Garbage output to file of specific size
Bugs item #1630894, was opened at 2007-01-08 21:40
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630894&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: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michael Culbertson (mculbert)
Assigned to: Nobody/Anonymous (nobody)
Summary: Garbage output to file of specific size
Initial Comment:
The attached script inexplicably fills the output file with garbage using the
input file available at:
http://cs.wheaton.edu/~mculbert/StdDetVol_Scaled_SMDS.dat (4.6Mb)
If the string outputed in line 26 is changed to f.write("bla "), the output
file is legible. If the expression is changed from f.write("%g " % k) to
f.write("%f " % k) or f.write("%e " % k), the file is legible. If, however,
the expression is changed to f.write('x'*len(str(k))+" "), the file remains
illegible. Adding a print statement:
print "%g " % k
before line 26 indicates that k is assuming the correct values and that the
string interpolation is functioning properly. This suggests that the problem
causing the garbage may be related to the specific file size created with this
particular set of data.
The problem occurs with Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310
32 bit (Intel)] under Windows XP. The problem doesn't occur with the same
script and input file using Python 2.3.5 on Mac OS 10.4.8.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2007-01-09 19:31
Message:
Logged In: YES
user_id=21627
Originator: NO
Can you please report what the expected output is? Mine (created on Linux)
starts with
40 40 32 64
followed by many "0.0 " values.
Also, can you please report what the actual output is that you get? In
what way is it
"illegible"?
What version of Numeric are you using?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630894&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1631769 ] Discrepancy between iterating empty and non-empty deques
Bugs item #1631769, was opened at 2007-01-09 22: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=1631769&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: Discrepancy between iterating empty and non-empty deques Initial Comment: >>> from collections import deque >>> empty= deque() >>> nonempty= deque([None]) >>> iter_empty= iter(empty) >>> iter_nonempty= iter(nonempty) >>> empty.append(1) >>> nonempty.append(1) >>> iter_empty.next() Traceback (most recent call last): File "", line 1, in iter_empty.next() StopIteration >>> iter_nonempty.next() Traceback (most recent call last): File "", line 1, in iter_nonempty.next() RuntimeError: deque mutated during iteration >>> If the RuntimeError is the intended behaviour for a modified deque after its iterator has been created, then iter_empty.next() should also raise the same RuntimeError. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1631769&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1631769 ] Discrepancy between iterating empty and non-empty deques
Bugs item #1631769, was opened at 2007-01-09 22:26 Message generated for change (Comment added) made by tzot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1631769&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christos Georgiou (tzot) >Assigned to: Raymond Hettinger (rhettinger) Summary: Discrepancy between iterating empty and non-empty deques Initial Comment: >>> from collections import deque >>> empty= deque() >>> nonempty= deque([None]) >>> iter_empty= iter(empty) >>> iter_nonempty= iter(nonempty) >>> empty.append(1) >>> nonempty.append(1) >>> iter_empty.next() Traceback (most recent call last): File "", line 1, in iter_empty.next() StopIteration >>> iter_nonempty.next() Traceback (most recent call last): File "", line 1, in iter_nonempty.next() RuntimeError: deque mutated during iteration >>> If the RuntimeError is the intended behaviour for a modified deque after its iterator has been created, then iter_empty.next() should also raise the same RuntimeError. -- >Comment By: Christos Georgiou (tzot) Date: 2007-01-09 22:29 Message: Logged In: YES user_id=539787 Originator: YES Assigned to Raymond as requested in http://mail.python.org/pipermail/python-dev/2007-January/070528.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1631769&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1630515 ] doc misleading in re.compile
Bugs item #1630515, was opened at 2007-01-08 14:09 Message generated for change (Comment added) made by tzot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630515&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 Private: No Submitted By: Keith Briggs (kbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: doc misleading in re.compile Initial Comment: http://www.python.org/doc/2.5/lib/node46.html has compile(pattern[, flags]) Compile a regular expression pattern into a regular expression object, which can be used for matching using its match() and search() methods, described below. This could be read as implying that the regular expression object can ONLY be used for matching using the match() and search() methods. In fact, I believe it can be used wherever "pattern" is mentioned. -- Comment By: Christos Georgiou (tzot) Date: 2007-01-09 22:32 Message: Logged In: YES user_id=539787 Originator: NO I like exact wording too, but I don't think this is a serious issue. I would suggest, unless you (kbriggs) offers a suitable patch, that this be dropped as a non-bug (it's a RFE, anyway). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630515&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1631769 ] Discrepancy between iterating empty and non-empty deques
Bugs item #1631769, was opened at 2007-01-09 15:26 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1631769&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.6 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Christos Georgiou (tzot) Assigned to: Raymond Hettinger (rhettinger) Summary: Discrepancy between iterating empty and non-empty deques Initial Comment: >>> from collections import deque >>> empty= deque() >>> nonempty= deque([None]) >>> iter_empty= iter(empty) >>> iter_nonempty= iter(nonempty) >>> empty.append(1) >>> nonempty.append(1) >>> iter_empty.next() Traceback (most recent call last): File "", line 1, in iter_empty.next() StopIteration >>> iter_nonempty.next() Traceback (most recent call last): File "", line 1, in iter_nonempty.next() RuntimeError: deque mutated during iteration >>> If the RuntimeError is the intended behaviour for a modified deque after its iterator has been created, then iter_empty.next() should also raise the same RuntimeError. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-01-09 15:46 Message: Logged In: YES user_id=80475 Originator: NO Fixed in rev 53299, -- Comment By: Christos Georgiou (tzot) Date: 2007-01-09 15:29 Message: Logged In: YES user_id=539787 Originator: YES Assigned to Raymond as requested in http://mail.python.org/pipermail/python-dev/2007-January/070528.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1631769&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1574593 ] ctypes: Returning c_void_p from callback doesn\'t work
Bugs item #1574593, was opened at 2006-10-10 17:18
Message generated for change (Comment added) made by theller
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574593&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.5
>Status: Closed
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Albert Strasheim (albertstrasheim)
Assigned to: Thomas Heller (theller)
Summary: ctypes: Returning c_void_p from callback doesn\'t work
Initial Comment:
C code:
extern CALLBACK_API void* foo(void*(*callback)()) {
printf("foo calling callback\n");
callback();
printf("callback returned in foo\n");
}
callback.py contains:
import sys
print sys.version
from ctypes import *
def callback(*args):
return c_void_p()
#lib = cdll['libcallback.so']
lib = cdll['callback.dll']
lib.foo.argtypes = [CFUNCTYPE(c_void_p)]
lib.foo(lib.foo.argtypes[0](callback))
With Python 2.4.3 and ctypes 1.0.0 + Thomas Heller's
patch for another issue (which doesn't seem to affect
this situation, but anyway) I get the following error:
2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit
(Intel)]
foo calling callback
Traceback (most recent call last):
File "source/callbacks.c", line 216, in 'converting
callback result'
TypeError: cannot be converted to pointer
Exception in None ignored
callback returned in foo
With Python 2.5 and ctypes 1.0.1 I get:
2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32
bit (Intel)]
foo calling callback
Traceback (most recent call last):
File "\loewis\25\python\Modules\_ctypes\callbacks.c",
line 216, in
'converting callback result'
TypeError: cannot be converted to pointer
Exception in ignored
callback returned in foo
Returning a Python integer from callback() doesn't
cause an error to be raised.
--
>Comment By: Thomas Heller (theller)
Date: 2007-01-09 21:50
Message:
Logged In: YES
user_id=11105
Originator: NO
Sorry for the late reply, and I hope you are still interested in this.
Basically, when you return something from the callback, ctypes does the
same as if you would do this "c_void_p(something)". Now, you cannot
construct a c_void_p instance from a c_void_p instance, you get exactly
the same error as you mention above:
>>> c_void_p(c_void_p(42))
Traceback (most recent call last):
File "", line 1, in ?
TypeError: cannot be converted to pointer
>>>
I'm not sure if this should be considered a bug or not, anyway there is an
easy workaround: Return an integer from the callback, or, if you have a
c_void_p instance, the .value attribute thereof.
I think this should not be fixed.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574593&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
