[ python-Bugs-417833 ] pydoc HTTP reload failure
Bugs item #417833, was opened at 2001-04-21 07:10 Message generated for change (Comment added) made by ping You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=417833&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: Garth T Kidd (gtk) Assigned to: Ka-Ping Yee (ping) Summary: pydoc HTTP reload failure Initial Comment: pydoc, when run as a web server, can't cope with reloads of modules which use 'from Package import Module' syntax for imports. To reproduce: * extract the attached DemonstratePydocBug tarchive into your Python 2.1 directory * python -c Lib\pydoc.py -p 8192 * visit http://localhost:8192/DemonstratePydocBug.html The rest of the instructions are there. Demonstrated on Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32. Funnily enough, there's no problem with trying the following under Python interactively: Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import DemonstratePydocBug.ReloadFails >>> import DemonstratePydocBug.ReloadFails >>> import DemonstratePydocBug.ReloadFails >>> import DemonstratePydocBug.ReloadFails Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> from DemonstratePydocBug import ReloadFails >>> from DemonstratePydocBug import ReloadFails >>> from DemonstratePydocBug import ReloadFails >>> from DemonstratePydocBug import ReloadFails I'm dropping additional debugging code into pydoc.py to see if I can figure out what's going on. -- >Comment By: Ka-Ping Yee (ping) Date: 2005-11-03 00:34 Message: Logged In: YES user_id=45338 I've uploaded a fixed version of pydoc.py. Please give it a try and let me know if it works for you. Thanks. -- Comment By: Ka-Ping Yee (ping) Date: 2005-11-02 20:56 Message: Logged In: YES user_id=45338 I've been looking into this problem, and unfortunately, the solution isn't as straightforward as rturpin's patch. The (sorry, undocumented) original reason that safeimport uses "del sys.modules[path]" instead of simply calling reload() is that reload() leaves old variables around in the module. For example, if the module initially contains "x = 3", it's loaded, the source file is changed to "y = 3", and then reloaded, the resulting loaded module will contain both x and y. I'm working on a way to safely clear the module without re-triggering the problem. -- Comment By: Russell Turpin (rturpin) Date: 2005-10-31 09:16 Message: Logged In: YES user_id=670280 There's a similar bug in Python 2.4. It causes the __import__ function to throw an AttributeError exception during safeimport(). I've patched our local copy of pydoc to fix this. The patch is to the safeimport() function. The patched lines are: # This keeps __import__ from throwing an exception on reloads. # del sys.modules[path] # This is sole original line module = sys.modules[path] # Added this line try: # Added this line reload(module) # Added this line except: # Added this line module = None# Added this line return module# Added this line This replaces the line: del sys.modules[path] -- Comment By: Eddie Parker (eparker) Date: 2004-08-31 14:41 Message: Logged In: YES user_id=991512 This is still current, as of 08/31/2004. Rather annoying, too. :( -- Comment By: Brett Cannon (bcannon) Date: 2003-05-16 16:43 Message: Logged In: YES user_id=357491 Just as an update, this still seeems to be an issue in Python 2.3b1 w/ version 1.82 of pydoc -- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 09:15 Message: Logged In: YES user_id=59803 Using pydoc in the interpreter doesn't tickle any of these bugs, so hopefully I can narrow my focus down to the difference in handling between serve() and help(). Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import pydoc >>> pydoc.help Welcome to Python 2.1! This is the online help utility. [...] help> modules Please wait a moment while I gather a list of all available modules... [list of modules] Enter any module name to get more he
[ python-Bugs-651124 ] pydoc ignores $PAGER if TERM=='dumb'
Bugs item #651124, was opened at 2002-12-09 14:00 Message generated for change (Comment added) made by ping You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651124&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.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Inyeol Lee (inyeol) Assigned to: Ka-Ping Yee (ping) Summary: pydoc ignores $PAGER if TERM=='dumb' Initial Comment: bug: pydoc ignores $PAGER environment variable if TERM=='dumb' symptom: when using pydoc as a keyword helper system (set keywordprg) pydoc scrolls all over its contents without paging, since gvim sets its terminal type to 'dumb' for shell escape. Fix: patch included. function getpager() rearranged. Inyeol Lee -- >Comment By: Ka-Ping Yee (ping) Date: 2005-11-03 01:01 Message: Logged In: YES user_id=45338 Accepted. -- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-31 05:12 Message: Logged In: YES user_id=33168 Ping, do you agree with this patch? -- Comment By: Inyeol Lee (inyeol) Date: 2002-12-09 14:06 Message: Logged In: YES user_id=595280 description on symptom above is for gvim. it was not clear there. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651124&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1346144 ] Segfaults from unaligned loads in floatobject.c
Bugs item #1346144, was opened at 2005-11-02 17:07 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346144&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.5 Status: Open Resolution: None Priority: 7 Submitted By: Rune Holm (titanstar) >Assigned to: Michael Hudson (mwh) Summary: Segfaults from unaligned loads in floatobject.c Initial Comment: Object/floatobject.c:_PyFloat_Unpack8 from svn head performs an unaligned load of a double, causing the cPickle unit test to fail on linux/mips and openbsd/sparc64. http://pxr.openlook.org/pxr/ diff/Objects/floatobject.c?v=release24- maint;diffval=head;diffvar=v reveals that somebody has added a fast path in _PyFloat_Unpack8 since 2.4 that fails to check for unaligned accesses, and therefore performs an illegal operation on architectures that don't support unaligned accesses. Here is the relevant traceback from linux/mips: (gdb) run Lib/test/test_cpickle.py Starting program: /ping/wirth/home0/runehol/projects/python-mips/ python Lib/test/test_cpickle.py [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 4379)] test_callapi (__main__.cPickleTests) ... ok test_dict_chunking (__main__.cPickleTests) ... ok test_dump_closed_file (__main__.cPickleTests) ... ok test_garyp (__main__.cPickleTests) ... ok test_getinitargs (__main__.cPickleTests) ... ok test_global_ext1 (__main__.cPickleTests) ... ok test_global_ext2 (__main__.cPickleTests) ... ok test_global_ext4 (__main__.cPickleTests) ... ok test_highest_protocol (__main__.cPickleTests) ... ok test_insecure_strings (__main__.cPickleTests) ... ok test_ints (__main__.cPickleTests) ... ok test_list_chunking (__main__.cPickleTests) ... ok test_load_closed_file (__main__.cPickleTests) ... ok Program received signal SIGBUS, Bus error. [Switching to Thread 16384 (LWP 4379)] 0x004414e0 in _PyFloat_Unpack8 (p=0x2b05282f "@", le=0) at Objects/floatobject.c:1737 1737return *(double*)p; (gdb) bt #0 0x004414e0 in _PyFloat_Unpack8 (p=0x2b05282f "@", le=0) at Objects/floatobject.c:1737 #1 0x2b10a750 in load_binfloat (self=0x2b0dc308) at /ping/wirth/home0/runehol/projects/python-mips/Modules/ cPickle.c:3361 #2 0x2b113674 in load (self=0x2b0dc308) at /ping/wirth/home0/runehol/projects/python-mips/Modules/ cPickle.c:4480 #3 0x2b1186ac in cpm_loads (self=0x0, args=0x2b2c2c78) at /ping/wirth/home0/runehol/projects/python-mips/Modules/ cPickle.c:5476 #4 0x005c45f4 in PyCFunction_Call (func=0x2b0d92b8, arg=0x2b2c2c78, kw=0x0) at Objects/methodobject.c:73 #5 0x0050f8f0 in call_function (pp_stack=0x7fff1e68, oparg=1) at Python/ceval.c:3565 #6 0x0050710c in PyEval_EvalFrameEx (f=0x10080868, throw=0) at Python/ceval.c:2181 #7 0x00510078 in fast_function (func=0x2b222da0, pp_stack=0x7fff2428, n=1, na=1, nk=0) at Python/ceval.c:3647 #8 0x0050fc14 in call_function (pp_stack=0x7fff2428, oparg=0)
[ python-Bugs-1337400 ] Python.h should include system headers properly [POSIX]
Bugs item #1337400, was opened at 2005-10-25 14:38 Message generated for change (Comment added) made by papadopo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337400&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: Open Resolution: None Priority: 5 Submitted By: Dimitri Papadopoulos (papadopo) Assigned to: Nobody/Anonymous (nobody) Summary: Python.h should include system headers properly [POSIX] Initial Comment: In Python 2.4.2, Python.h looks like this: #include [...] #include [...] #include #include #include #ifdef HAVE_UNISTD_H #include #endif On POSIX platforms should be included first! Indeed it includes headers such as on Solaris, on Irix, or on GNU systems, which define macros that specify the system interfaces to use, possibly depending on compiler options, which in turn may enable/disable/modify parts of other system headers such as or . By including , you ensure consistent systems interfaces are specified in all system headers included by Python sources. This may seem rather academic, but it actually breaks my Solaris builds: I need to compile Python using Sun's C compiler when building Python for performance and GNU's C++ compiler when building Python modules written in C++ for compatibility with C++ libraries used by these modules that can't be compiled with Sun's C++ compiler. So the same Python.h is used by Sun's C compiler (which it was created for in the first place) and GNU's C++ compiler. GNU's C++ compiler fails to compile some modules. Unfortunately I can't recall the exact modules and error messages right now, but including fixes the problem. -- >Comment By: Dimitri Papadopoulos (papadopo) Date: 2005-11-03 11:56 Message: Logged In: YES user_id=52414 Aaargh! I've rebuilt a version of Python 2.4.2 with Sun's C compiler and GNU's C++ compiler but I'm unable to reproduce the problem: $ cat > foo.cpp #include #include $ $ g++ -I/usr/local/python-2.4.2/include/python2.4 -c foo.cpp $ Same Solaris 8 workstation, no OS updates, same GCC and same Sun compilers. Oh well... I think it's still a good idea to include before , , , and . But that's your call, I don't mind as long as I'm able to build Python. -- Comment By: Dimitri Papadopoulos (papadopo) Date: 2005-11-02 09:42 Message: Logged In: YES user_id=52414 Ah, I didn't explain myself clearly. I meant to say that must be included before other system headers such as , , , and in this specific case. I totally agree it has to be included after "pyconfig.h". For example if "pyconfig.h" defined _HPUX_SOURCE and was included before "pyconfig.h", then wrong system APIs may be triggered (or at least system APIs that were not intended to be specified). Now why should be included in front of other system headers? This is because: 1) triggers specific POSIX or Single UNIX Specification APIs 2) most if not all system headers do not include , so different APIs may be triggered before including and after including I can't provide a section of the POSIX specification that explictly states that must be included before . This is however implicit: http://www.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html As you can see may or not define macros that trigger a specific API (POSIX.1-1988, SUSv1, SUSv2, SUSv3, etc.). I'll investigate what happens in the case of this specific failure and let you know. -- Comment By: Martin v. Löwis (loewis) Date: 2005-11-02 05:19 Message: Logged In: YES user_id=21627 Can you please point to the relevant section of the POSIX specification that states that unistdh.h must be included before stdlib.h? As for the specific problem: it may be that you are somehow working around the real problem by including unistd.h before Python.h. Python.h *must* be included before any system headers, as pyconfig.h defines certain compilation options which affect the feature tests. Including unistd.h before can actually break things, as structs may get defined differently depending on whether pyconfig.h was included first or not. So in the specific example, it would help if you could determine why ::btowc is defined in one case but not in the other. -- Comment By: Dimitri Papadopoulos (papadopo) Date: 2005-10-25 15:57 Message: Logged In: YES user_id=52414 Oops... Instead of including fixes the problem. please read including first fixes the problem. Here is an example to reproduce the problem: $ c
[ python-Bugs-1346874 ] httplib simply ignores CONTINUE
Bugs item #1346874, was opened at 2005-11-03 13:23 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=1346874&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: Mike Looijmans (cdwave) Assigned to: Nobody/Anonymous (nobody) Summary: httplib simply ignores CONTINUE Initial Comment: I bumped into this code in httplib.py HTTPConnection, begin(): # read until we get a non-100 response while True: version, status, reason = self._read_status() if status != CONTINUE: break # skip the header from the 100 response while True: skip = self.fp.readline().strip() if not skip: break if self.debuglevel > 0: print "header:", skip This basically silently eats any 100-continue response that the server may send to us. This is not according to the spec - the client should WAIT for the 100-continue, and then post the data. Because of this code snippet, it is impossible for a client to wait for a 100-continue response, since it is silently eaten by this code. A correct implementation would be: - Check the outgoing headers for "Expect: 100-continue" - If that is present, set an "expectcontinue" flag. - If the client tries to send data to the connection, or if the data member was set in the request, wait for the server to send the 100 response BEFORE sending out any data at all, if the flag is set. - If the server fails to send it, the connection will eventually time out. I'd be happy to provide an implementation myself, as it doesn't seem hard to implement and would really help my project. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346874&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-754449 ] Exceptions when a thread exits
Bugs item #754449, was opened at 2003-06-14 05:32 Message generated for change (Comment added) made by justincjohnson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&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: Threads Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 3 Submitted By: Matthias Klose (doko) Assigned to: Brett Cannon (bcannon) Summary: Exceptions when a thread exits Initial Comment: [forwarded from http://bugs.debian.org/195812] The application mentioned is offlineimap, available from ftp://ftp.debian.org/dists/unstable/main/source/. This behavior is new to Python 2.3. When my application exits, I get a lot of these messages: Traceback (most recent call last): File "/usr/lib/python2.3/threading.py", line 426, in __bootstrap self.__stop() File "/usr/lib/python2.3/threading.py", line 435, in __stop self.__block.notifyAll() File "/usr/lib/python2.3/threading.py", line 239, in notifyAll self.notify(len(self.__waiters)) File "/usr/lib/python2.3/threading.py", line 221, in notify currentThread() # for side-effect TypeError: 'NoneType' object is not callable [EMAIL PROTECTED]:~/tree/offlineimap-3.99.18$ ./offlineimap.py -l log -d maildir -a Personal,Excel Unhandled exception in thread started by> Traceback (most recent call last): File "/usr/lib/python2.3/threading.py", line 426, in __bootstrap self.__stop() File "/usr/lib/python2.3/threading.py", line 435, in __stop self.__block.notifyAll() File "/usr/lib/python2.3/threading.py", line 239, in notifyAll self.notify(len(self.__waiters)) File "/usr/lib/python2.3/threading.py", line 221, in notify currentThread() # for side-effect TypeError: 'NoneType' object is not callable Unhandled exception in thread started by > Traceback (most recent call last): File "/usr/lib/python2.3/threading.py", line 426, in __bootstrap self.__stop() File "/usr/lib/python2.3/threading.py", line 435, in __stop self.__block.notifyAll() File "/usr/lib/python2.3/threading.py", line 239, in notifyAll self.notify(len(self.__waiters)) File "/usr/lib/python2.3/threading.py", line 221, in notify currentThread() # for side-effect TypeError: 'NoneType' object is not callable -- Comment By: Justin Johnson (justincjohnson) Date: 2005-11-03 12:47 Message: Logged In: YES user_id=1049561 I'm seeing this problem still in Python 2.4.1 on Windows. Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 C:\src\Twisted>trial -r iocp twisted.test.test_iutils Using twisted.internet.iocpreactor reactor Running 6 tests. twisted.test.test_iutils UtilsTestCase testOutput ... ? [32;1m[OK]?[0m testOutputAndValue ... ? [32;1m[OK]?[0m testOutputSignal ... ? [32;1m[OK]?[0m testOutputWithErrorCollected ... ? [32;1m[OK]?[0m testOutputWithErrorIgnored ... ? [32;1m[OK]?[0m testValue ...? [32;1m[OK]?[0m --- Ran 6 tests in 1.513s PASSED (successes=6) Exception in thread iocpreactor.process_waiter.ProcessWaiter.waitForProcessExi t pid=2156 (most likely raised during interpreter shutdown): Traceback (most recent call last): File "C:\Python24\lib\threading.py", line 442, in __bootstrap File "C:\Python24\lib\threading.py", line 422, in run File "C:\src\Twisted\twisted\internet\iocpreactor\process_wait er.py", line 165, in doWaitForProcessExit exceptions.TypeError: 'NoneType' object is not callable -- Comment By: Brett Cannon (bcannon) Date: 2004-09-17 11:33 Message: Logged In: YES user_id=357491 Python 2.2 is no longer actively maintained, so I wouldn't count on the fix being backported. -- Comment By: Geoffrey Bache (gjb1002) Date: 2004-09-17 02:15 Message: Logged In: YES user_id=769182 I have this bug on Python 2.2.3 : occasionally getting a very similar stack when my daemon thread exits. I don't get the error for non-daemon threads. My problem seems pretty similar to carlosayam's problem, described in June. -- Comment
[ python-Bugs-1337400 ] Python.h should include system headers properly [POSIX]
Bugs item #1337400, was opened at 2005-10-25 14:38 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337400&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: Works For Me Priority: 5 Submitted By: Dimitri Papadopoulos (papadopo) Assigned to: Nobody/Anonymous (nobody) Summary: Python.h should include system headers properly [POSIX] Initial Comment: In Python 2.4.2, Python.h looks like this: #include [...] #include [...] #include #include #include #ifdef HAVE_UNISTD_H #include #endif On POSIX platforms should be included first! Indeed it includes headers such as on Solaris, on Irix, or on GNU systems, which define macros that specify the system interfaces to use, possibly depending on compiler options, which in turn may enable/disable/modify parts of other system headers such as or . By including , you ensure consistent systems interfaces are specified in all system headers included by Python sources. This may seem rather academic, but it actually breaks my Solaris builds: I need to compile Python using Sun's C compiler when building Python for performance and GNU's C++ compiler when building Python modules written in C++ for compatibility with C++ libraries used by these modules that can't be compiled with Sun's C++ compiler. So the same Python.h is used by Sun's C compiler (which it was created for in the first place) and GNU's C++ compiler. GNU's C++ compiler fails to compile some modules. Unfortunately I can't recall the exact modules and error messages right now, but including fixes the problem. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-11-03 22:34 Message: Logged In: YES user_id=21627 Thanks for the update. I believe nothing in the POSIX spec mandates to include unistd.h before anything else (unlike sys/types.h, which often is prerequisite to other headers), so I'm closing this report. -- Comment By: Dimitri Papadopoulos (papadopo) Date: 2005-11-03 11:56 Message: Logged In: YES user_id=52414 Aaargh! I've rebuilt a version of Python 2.4.2 with Sun's C compiler and GNU's C++ compiler but I'm unable to reproduce the problem: $ cat > foo.cpp #include #include $ $ g++ -I/usr/local/python-2.4.2/include/python2.4 -c foo.cpp $ Same Solaris 8 workstation, no OS updates, same GCC and same Sun compilers. Oh well... I think it's still a good idea to include before , , , and . But that's your call, I don't mind as long as I'm able to build Python. -- Comment By: Dimitri Papadopoulos (papadopo) Date: 2005-11-02 09:42 Message: Logged In: YES user_id=52414 Ah, I didn't explain myself clearly. I meant to say that must be included before other system headers such as , , , and in this specific case. I totally agree it has to be included after "pyconfig.h". For example if "pyconfig.h" defined _HPUX_SOURCE and was included before "pyconfig.h", then wrong system APIs may be triggered (or at least system APIs that were not intended to be specified). Now why should be included in front of other system headers? This is because: 1) triggers specific POSIX or Single UNIX Specification APIs 2) most if not all system headers do not include , so different APIs may be triggered before including and after including I can't provide a section of the POSIX specification that explictly states that must be included before . This is however implicit: http://www.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html As you can see may or not define macros that trigger a specific API (POSIX.1-1988, SUSv1, SUSv2, SUSv3, etc.). I'll investigate what happens in the case of this specific failure and let you know. -- Comment By: Martin v. Löwis (loewis) Date: 2005-11-02 05:19 Message: Logged In: YES user_id=21627 Can you please point to the relevant section of the POSIX specification that states that unistdh.h must be included before stdlib.h? As for the specific problem: it may be that you are somehow working around the real problem by including unistd.h before Python.h. Python.h *must* be included before any system headers, as pyconfig.h defines certain compilation options which affect the feature tests. Including unistd.h before can actually break things, as structs may get defined differently depending on whether pyconfig.h was included first or not. So in the specific example, it would help if you could determ
[ python-Bugs-754449 ] Exceptions when a thread exits
Bugs item #754449, was opened at 2003-06-14 03:32 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&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: Threads Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 3 Submitted By: Matthias Klose (doko) Assigned to: Brett Cannon (bcannon) Summary: Exceptions when a thread exits Initial Comment: [forwarded from http://bugs.debian.org/195812] The application mentioned is offlineimap, available from ftp://ftp.debian.org/dists/unstable/main/source/. This behavior is new to Python 2.3. When my application exits, I get a lot of these messages: Traceback (most recent call last): File "/usr/lib/python2.3/threading.py", line 426, in __bootstrap self.__stop() File "/usr/lib/python2.3/threading.py", line 435, in __stop self.__block.notifyAll() File "/usr/lib/python2.3/threading.py", line 239, in notifyAll self.notify(len(self.__waiters)) File "/usr/lib/python2.3/threading.py", line 221, in notify currentThread() # for side-effect TypeError: 'NoneType' object is not callable [EMAIL PROTECTED]:~/tree/offlineimap-3.99.18$ ./offlineimap.py -l log -d maildir -a Personal,Excel Unhandled exception in thread started by> Traceback (most recent call last): File "/usr/lib/python2.3/threading.py", line 426, in __bootstrap self.__stop() File "/usr/lib/python2.3/threading.py", line 435, in __stop self.__block.notifyAll() File "/usr/lib/python2.3/threading.py", line 239, in notifyAll self.notify(len(self.__waiters)) File "/usr/lib/python2.3/threading.py", line 221, in notify currentThread() # for side-effect TypeError: 'NoneType' object is not callable Unhandled exception in thread started by > Traceback (most recent call last): File "/usr/lib/python2.3/threading.py", line 426, in __bootstrap self.__stop() File "/usr/lib/python2.3/threading.py", line 435, in __stop self.__block.notifyAll() File "/usr/lib/python2.3/threading.py", line 239, in notifyAll self.notify(len(self.__waiters)) File "/usr/lib/python2.3/threading.py", line 221, in notify currentThread() # for side-effect TypeError: 'NoneType' object is not callable -- >Comment By: Brett Cannon (bcannon) Date: 2005-11-03 17:51 Message: Logged In: YES user_id=357491 This is not Python's fault. If you look at what triggers the exception it is code from Twisted. All of this is happening because the threads being run by the test are not being properly torn down before the interpreter begins to tear itself down. If you make sure all the threads have terminated before ending the test I am sure the error will go away. -- Comment By: Justin Johnson (justincjohnson) Date: 2005-11-03 10:47 Message: Logged In: YES user_id=1049561 I'm seeing this problem still in Python 2.4.1 on Windows. Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 C:\src\Twisted>trial -r iocp twisted.test.test_iutils Using twisted.internet.iocpreactor reactor Running 6 tests. twisted.test.test_iutils UtilsTestCase testOutput ... ? [32;1m[OK]?[0m testOutputAndValue ... ? [32;1m[OK]?[0m testOutputSignal ... ? [32;1m[OK]?[0m testOutputWithErrorCollected ... ? [32;1m[OK]?[0m testOutputWithErrorIgnored ... ? [32;1m[OK]?[0m testValue ...? [32;1m[OK]?[0m --- Ran 6 tests in 1.513s PASSED (successes=6) Exception in thread iocpreactor.process_waiter.ProcessWaiter.waitForProcessExi t pid=2156 (most likely raised during interpreter shutdown): Traceback (most recent call last): File "C:\Python24\lib\threading.py", line 442, in __bootstrap File "C:\Python24\lib\threading.py", line 422, in run File "C:\src\Twisted\twisted\internet\iocpreactor\process_wait er.py", line 165, in doWaitForProcessExit exceptions.TypeError: 'NoneType' object is not callable -- Comment By: Brett Cannon (bcannon) Date: 2004-09-17 09:33 Message: Logged In: YES user_id=357491 Python 2.2 is no longer actively maintained, so I would
[ python-Bugs-775414 ] bsddb3 hash craps out with threads
Bugs item #775414, was opened at 2003-07-22 12:29 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Gregory P. Smith (greg) Summary: bsddb3 hash craps out with threads Initial Comment: Richie Hindle presented something like the attached (hammer.py) on the spambayes-dev mailing list. On Win98SE and Win2K w/ Python 2.3c1 I usually see this death pretty quickly: Traceback (most recent call last): File "hammer.py", line 36, in ? main() File "hammer.py", line 33, in main hammer(db) File "hammer.py", line 15, in hammer x = db[str(int(random.random() * 10))] File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, in __getitem__ return self.db[key] bsddb._db.DBRunRecoveryError: (-30982, 'DB_RUNRECOVERY: Fatal error, run database recovery -- fatal region error detected; run recovery') Richie also reported "illegal operation" crashes on Win98SE. It's not clear whether a bsddb3 hash *can* be used with threads like this. If it can't, there's a doc bug. If it should be able to, there's a more serious problem. Note that it looks like hashopen() always merges DB_THREAD into the flags, so the absence of specifying DB_THREAD probably isn't the problem. -- >Comment By: Mark Hammond (mhammond) Date: 2005-11-04 13:00 Message: Logged In: YES user_id=14198 Sadly, I believe bsddb is working "as designed". Quoting from http://www.sleepycat.com/docs/api_c/env_open.html "When the DB_INIT_LOCK flag is specified, it is usually necessary to run a deadlock detector, as well." So I dig into my bsddb build tree, and found db_deadlock.exe. Sure enough, once studly_hammer.py had deadlocked, executing db_deadlock in the DB directory got things running again - although the threads all eventually died with: bsddb._db.DBLockDeadlockError: (-30996, 'DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock') Obviously it is PITA to need to run an external daemon, and as Python doesn't distribute db_deadlock.exe, the sleepycat license may mean not all applications are allowed to distribute it. This program also polls for deadlocks, meaning your app may hang as long as the poll period. All in all, it seems to suck :) -- Comment By: Gregory P. Smith (greg) Date: 2003-10-06 11:17 Message: Logged In: YES user_id=413 if you believe your application is properly using BerkeleyDB and you are having DB_RUNRECOVERY issues I suggest contacting sleepycat. -- Comment By: Rick Bradley (roundeye) Date: 2003-10-06 05:46 Message: Logged In: YES user_id=58334 This is also showing up in Syncato (http://www.syncato.org/), and the database isn't recoverable using the Berkeley DB db_recover utility (even using the "catastrophic" flag). Does anyone know of a reliable way to recover? Rick Bradley -- Comment By: Skip Montanaro (montanaro) Date: 2003-09-30 03:05 Message: Logged In: YES user_id=44345 Forgot to mention that without the DBEnv() object, it gets a segmentation violation on Solaris 8 seg faults pretty quickly (within 10,000 iterations for each thread) or raises bsddb._db.DBRunRecoveryError. -- Comment By: Skip Montanaro (montanaro) Date: 2003-09-30 02:41 Message: Logged In: YES user_id=44345 I built from CVS head on a Solaris machine. bsddb.__version__ reports '4.2.1'. When run, the studly_hammer.py script completes the dbenv.open() call, but appears to hang during the hashopen() call. Adding some print statements to hashopen() indicates that it hangs during d.open(). I don't know what to make of this. If others have some suggestions, I'll be happy to try them out. -- Comment By: Tim Peters (tim_one) Date: 2003-09-30 00:15 Message: Logged In: YES user_id=31435 Greg, I'm in a constant state of debugging (in other apps) thread problems that *appear* unique to Win9x. But in years of this, I have yet to see one that actually is unique to Win9x -- in the end, they always turn out to be legit races in the app I'm debugging, and can always be reproduced on other platforms if the test is made stressful enough and/or run long enough. Win9x appears especially good at provoking thread problems just because its scheduling is erratic, often acting like
[ python-Bugs-1346874 ] httplib simply ignores CONTINUE
Bugs item #1346874, was opened at 2005-11-03 04:23 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346874&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: Mike Looijmans (cdwave) Assigned to: Nobody/Anonymous (nobody) Summary: httplib simply ignores CONTINUE Initial Comment: I bumped into this code in httplib.py HTTPConnection, begin(): # read until we get a non-100 response while True: version, status, reason = self._read_status() if status != CONTINUE: break # skip the header from the 100 response while True: skip = self.fp.readline().strip() if not skip: break if self.debuglevel > 0: print "header:", skip This basically silently eats any 100-continue response that the server may send to us. This is not according to the spec - the client should WAIT for the 100-continue, and then post the data. Because of this code snippet, it is impossible for a client to wait for a 100-continue response, since it is silently eaten by this code. A correct implementation would be: - Check the outgoing headers for "Expect: 100-continue" - If that is present, set an "expectcontinue" flag. - If the client tries to send data to the connection, or if the data member was set in the request, wait for the server to send the 100 response BEFORE sending out any data at all, if the flag is set. - If the server fails to send it, the connection will eventually time out. I'd be happy to provide an implementation myself, as it doesn't seem hard to implement and would really help my project. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-03 18:17 Message: Logged In: YES user_id=33168 It's much easier to get a patch integrated since there should be less work than a bug. I encourage you to work on a patch. Don't forget that a patch, must do many things: 1) fix the code, 2) fix (or add!) tests, 3) fix the documentation with an appropriate \versionchanged (or \versionadded) tag, and finally 4) update Misc/NEWS. The old behaviour should generally be backwards compatible by default when adding new functionality. If it's a bug, it may still be desirable to maintain backwards compatibility. I don't know enough about HTTP to provide any guidance here. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346874&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1347874 ] FeedParser does not comply with RFC2822
Bugs item #1347874, was opened at 2005-11-04 02: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=1347874&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: Julian Phillips (quantumfyre)
Assigned to: Nobody/Anonymous (nobody)
Summary: FeedParser does not comply with RFC2822
Initial Comment:
FeedParser (from Lib/email/FeedParser.py) uses
the regular expression:
^(From |[\041-\071\073-\176]{2,}:|[\t ])
to recognise Mail headers. However RFC2822
says:
field-name := 1*ftext
which would give the regular expression:
^(From |[\041-\071\073-\176]{1,}:|[\t ])
This causes mails that use single character
header field names to be parsed incorrectly.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1347874&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1347874 ] FeedParser does not comply with RFC2822
Bugs item #1347874, was opened at 2005-11-03 21:58
Message generated for change (Settings changed) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1347874&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: Julian Phillips (quantumfyre)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: FeedParser does not comply with RFC2822
Initial Comment:
FeedParser (from Lib/email/FeedParser.py) uses
the regular expression:
^(From |[\041-\071\073-\176]{2,}:|[\t ])
to recognise Mail headers. However RFC2822
says:
field-name := 1*ftext
which would give the regular expression:
^(From |[\041-\071\073-\176]{1,}:|[\t ])
This causes mails that use single character
header field names to be parsed incorrectly.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1347874&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-775414 ] bsddb3 hash craps out with threads
Bugs item #775414, was opened at 2003-07-22 12:29 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Gregory P. Smith (greg) Summary: bsddb3 hash craps out with threads Initial Comment: Richie Hindle presented something like the attached (hammer.py) on the spambayes-dev mailing list. On Win98SE and Win2K w/ Python 2.3c1 I usually see this death pretty quickly: Traceback (most recent call last): File "hammer.py", line 36, in ? main() File "hammer.py", line 33, in main hammer(db) File "hammer.py", line 15, in hammer x = db[str(int(random.random() * 10))] File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, in __getitem__ return self.db[key] bsddb._db.DBRunRecoveryError: (-30982, 'DB_RUNRECOVERY: Fatal error, run database recovery -- fatal region error detected; run recovery') Richie also reported "illegal operation" crashes on Win98SE. It's not clear whether a bsddb3 hash *can* be used with threads like this. If it can't, there's a doc bug. If it should be able to, there's a more serious problem. Note that it looks like hashopen() always merges DB_THREAD into the flags, so the absence of specifying DB_THREAD probably isn't the problem. -- >Comment By: Mark Hammond (mhammond) Date: 2005-11-04 15:20 Message: Logged In: YES user_id=14198 The db_deadlock program ends up being equivalent to a thread repeatedly calling: dbenv.lock_detect(bsddb.db.DB_LOCK_DEFAULT, 0) For completeness, I attach deadlock_hammer.py - a version that uses yet another thread to perform this lock detection. It also catches the deadlock exceptions, printing but ignoring them. Also, due to the way shutdown is less than graceful, I found I needed to add DB_RECOVER_FATAL to the env flags, otherwise I would often hang on open unless I clobbered the DB directory. On both my box (where it took a little while to see a deadlock) and on a dual-processor box (which provoked it much quicker), this version seems to run forever (although with sporadic performance) -- Comment By: Mark Hammond (mhammond) Date: 2005-11-04 13:00 Message: Logged In: YES user_id=14198 Sadly, I believe bsddb is working "as designed". Quoting from http://www.sleepycat.com/docs/api_c/env_open.html "When the DB_INIT_LOCK flag is specified, it is usually necessary to run a deadlock detector, as well." So I dig into my bsddb build tree, and found db_deadlock.exe. Sure enough, once studly_hammer.py had deadlocked, executing db_deadlock in the DB directory got things running again - although the threads all eventually died with: bsddb._db.DBLockDeadlockError: (-30996, 'DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock') Obviously it is PITA to need to run an external daemon, and as Python doesn't distribute db_deadlock.exe, the sleepycat license may mean not all applications are allowed to distribute it. This program also polls for deadlocks, meaning your app may hang as long as the poll period. All in all, it seems to suck :) -- Comment By: Gregory P. Smith (greg) Date: 2003-10-06 11:17 Message: Logged In: YES user_id=413 if you believe your application is properly using BerkeleyDB and you are having DB_RUNRECOVERY issues I suggest contacting sleepycat. -- Comment By: Rick Bradley (roundeye) Date: 2003-10-06 05:46 Message: Logged In: YES user_id=58334 This is also showing up in Syncato (http://www.syncato.org/), and the database isn't recoverable using the Berkeley DB db_recover utility (even using the "catastrophic" flag). Does anyone know of a reliable way to recover? Rick Bradley -- Comment By: Skip Montanaro (montanaro) Date: 2003-09-30 03:05 Message: Logged In: YES user_id=44345 Forgot to mention that without the DBEnv() object, it gets a segmentation violation on Solaris 8 seg faults pretty quickly (within 10,000 iterations for each thread) or raises bsddb._db.DBRunRecoveryError. -- Comment By: Skip Montanaro (montanaro) Date: 2003-09-30 02:41 Message: Logged In: YES user_id=44345 I built from CVS head on a Solaris machine. bsddb.__version__ reports '4.2.1'. When run, the studly_hammer.py script completes the dbenv.open() call, but appears to hang during
