[ python-Bugs-1756343 ] Python 2.5.1 fails to build on AIX
Bugs item #1756343, was opened at 2007-07-18 19:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1756343&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 Private: No Submitted By: Tom Epperly (tepperly) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.5.1 fails to build on AIX Initial Comment: ./configure --prefix=/usr/casc/babel/apps/aix --enable-shared --disable-ipv6 checking MACHDEP... aix5 checking EXTRAPLATDIR... checking for --without-gcc... checking for gcc... cc_r checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... no checking whether cc_r accepts -g... yes checking for cc_r option to accept ANSI C... none needed checking for --with-cxx-main=... no checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking for AIX... yes checking for --with-suffix... checking for case-insensitive build directory... no checking LIBRARY... libpython$(VERSION).a checking LINKCC... $(srcdir)/Modules/makexp_aix Modules/python.exp . $(LIBRARY); $(PURIFY) $(MAINCC) checking for --enable-shared... yes checking for --enable-profiling... checking LDLIBRARY... libpython$(VERSION).a checking for ranlib... ranlib checking for ar... ar checking for svnversion... not-found checking for a BSD-compatible install... ./install-sh -c checking for --with-pydebug... no checking whether cc_r accepts -OPT:Olimit=0... no checking whether cc_r accepts -Olimit 1500... no checking whether pthreads are available without options... yes checking whether newxlC also accepts flags for thread support... no checking for --enable-framework... no checking for dyld... no checking SO... .so checking LDSHARED... $(BINLIBDEST)/config/ld_so_aix $(CC) -bI:$(BINLIBDEST)/config/python.exp checking CCSHARED... checking LINKFORSHARED... -Wl,-bE:Modules/python.exp -lld checking CFLAGSFORSHARED... checking SHLIBS... $(LIBS) checking for dlopen in -ldl... yes checking for shl_load in -ldld... no checking for library containing sem_init... none required checking for textdomain in -lintl... yes checking for build directories... done configure: creating ./config.status config.status: creating Makefile.pre config.status: creating Modules/Setup.config config.status: creating pyconfig.h creating Modules/Setup creating Modules/Setup.local creating Makefile bash-2.05a$ make cc_r -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c cc_r -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Modules/_typesmodule.o Modules/_typesmodule.c cc_r -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Parser/acceler.o Parser/acceler.c cc_r -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Parser/grammar1.o Parser/grammar1.c cc_r -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Parser/listnode.o Parser/listnode.c cc_r -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Parser/node.o Parser/node.c cc_r -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Parser/parser.o Parser/parser.c cc_r -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Parser/parsetok.o Parser/parsetok.c cc_r -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Parser/bitset.o Parser/bitset.c cc_r -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Parser/metagrammar.o Parser/metagrammar.c cc_r -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Parser/firstsets.o Parser/firstsets.c cc_r -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Parser/grammar.o Parser/grammar.c cc_r -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Parser/pgen.o Parser/pgen.c cc_r -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Parser/myreadline.o Parser/myreadline.c cc_r -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Parser/tokenizer.o Parser/tokenizer.c cc_r -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Objects/abstract.o Objects/abstract.c cc_r -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Objects/boolobject.o Objects/boolobject.c cc_r -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Objects/bufferobject.o Objects/bufferobject.c cc_r -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Objects/cellobject.o Objects/cellobject.c cc_r -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Objects/classobject.o Objects/classobject.c cc_r -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_COR
[ python-Bugs-1758146 ] Crash in PyObject_Malloc
Bugs item #1758146, was opened at 2007-07-21 18:12
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=1758146&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: 5
Private: No
Submitted By: Tim Bishop (timbishop)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash in PyObject_Malloc
Initial Comment:
I'm running the following on Solaris 9 SPARC:
python 2.5
apache 2.2
mod_python 3.3.1
subversion 1.4.4
trac 0.11dev
Trac is a web application that's written in python and is running through
apache using mod_python. It also uses the subversion python libraries.
After an undetermined amount of clicks (usually in the order of a minute or two
of randomly clicking around) the apache child process dies:
[Sat Jul 21 17:47:27 2007] [error] [client myip] mod_python (pid=15138,
interpreter='my.site.com', phase='PythonHandler',
handler='trac.web.modpython_frontend'): Application error, referer:
http://my.site.com/
[Sat Jul 21 17:47:27 2007] [error] [client myip] ServerName: 'my.site.com',
referer: http://my.site.com/
[Sat Jul 21 17:47:27 2007] [error] [client myip] DocumentRoot:
'/path/to/docroot', referer: http://my.site.com/
[Sat Jul 21 17:47:27 2007] [error] [client myip] URI: '/trac/', referer:
http://my.site.com/
[Sat Jul 21 17:47:27 2007] [error] [client myip] Location: '/trac', referer:
http://my.site.com/
[Sat Jul 21 17:47:27 2007] [error] [client myip] Directory: None, referer:
http://my.site.com/
[Sat Jul 21 17:47:27 2007] [error] [client myip] Filename: '/path/to/docroot',
referer: http://my.site.com/
[Sat Jul 21 17:47:27 2007] [error] [client myip] PathInfo: '/trac/', referer:
http://my.site.com/
It's dumped a core file. Examining that with gdb shows a Bus error here:
Core was generated by `/usr/local/sbin/httpd -DLocalConfig -k start'.
Program terminated with signal 10, Bus error.
#0 PyObject_Malloc (nbytes=16) at Objects/obmalloc.c:747
747 if ((pool->freeblock = *(block **)bp) != NULL) {
(gdb) l
742 * Pick up the head block of its free list.
743 */
744 ++pool->ref.count;
745 bp = pool->freeblock;
746 assert(bp != NULL);
747 if ((pool->freeblock = *(block **)bp) != NULL) {
748 UNLOCK();
749 return (void *)bp;
750 }
751 /*
(gdb)
Full gdb output is attached.
I've tried disabling pymalloc when building python, but the problem just moves
elsewhere. However, with pymalloc enabled it's consistently on this line.
Do you have advice on how to debug this further?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1758146&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1758146 ] Crash in PyObject_Malloc
Bugs item #1758146, was opened at 2007-07-21 10:12
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1758146&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: 5
Private: No
Submitted By: Tim Bishop (timbishop)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash in PyObject_Malloc
Initial Comment:
I'm running the following on Solaris 9 SPARC:
python 2.5
apache 2.2
mod_python 3.3.1
subversion 1.4.4
trac 0.11dev
Trac is a web application that's written in python and is running through
apache using mod_python. It also uses the subversion python libraries.
After an undetermined amount of clicks (usually in the order of a minute or two
of randomly clicking around) the apache child process dies:
[Sat Jul 21 17:47:27 2007] [error] [client myip] mod_python (pid=15138,
interpreter='my.site.com', phase='PythonHandler',
handler='trac.web.modpython_frontend'): Application error, referer:
http://my.site.com/
[Sat Jul 21 17:47:27 2007] [error] [client myip] ServerName: 'my.site.com',
referer: http://my.site.com/
[Sat Jul 21 17:47:27 2007] [error] [client myip] DocumentRoot:
'/path/to/docroot', referer: http://my.site.com/
[Sat Jul 21 17:47:27 2007] [error] [client myip] URI: '/trac/', referer:
http://my.site.com/
[Sat Jul 21 17:47:27 2007] [error] [client myip] Location: '/trac', referer:
http://my.site.com/
[Sat Jul 21 17:47:27 2007] [error] [client myip] Directory: None, referer:
http://my.site.com/
[Sat Jul 21 17:47:27 2007] [error] [client myip] Filename: '/path/to/docroot',
referer: http://my.site.com/
[Sat Jul 21 17:47:27 2007] [error] [client myip] PathInfo: '/trac/', referer:
http://my.site.com/
It's dumped a core file. Examining that with gdb shows a Bus error here:
Core was generated by `/usr/local/sbin/httpd -DLocalConfig -k start'.
Program terminated with signal 10, Bus error.
#0 PyObject_Malloc (nbytes=16) at Objects/obmalloc.c:747
747 if ((pool->freeblock = *(block **)bp) != NULL) {
(gdb) l
742 * Pick up the head block of its free list.
743 */
744 ++pool->ref.count;
745 bp = pool->freeblock;
746 assert(bp != NULL);
747 if ((pool->freeblock = *(block **)bp) != NULL) {
748 UNLOCK();
749 return (void *)bp;
750 }
751 /*
(gdb)
Full gdb output is attached.
I've tried disabling pymalloc when building python, but the problem just moves
elsewhere. However, with pymalloc enabled it's consistently on this line.
Do you have advice on how to debug this further?
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-07-21 14:47
Message:
Logged In: YES
user_id=33168
Originator: NO
Firstly, take a deep breath. This probably isn't going to be easy. This
seems like memory corruption, possibly due to threads. That's a guess,
since I don't know if you are running with threads.
The first (probably faster alternative) is to build python and all the C
extension modules --with-pydebug (passed when you run ./configure). That
might catch the error slightly earlier. It won't necessarily point to the
cause of the problem, but may help narrow down the potential causes.
The second alternative is to try running this under valgrind or purify or
with some memory debugger. It seems like there is memory corruption (I'm
guessing from mod_python). This will be more robust at finding the problem
nearer to the root cause. Unfortunately, it might prove too slow to be
useful or find the problem.
If you can narrow down the test case that would help a lot. For example,
could you eliminate subversion (presumably using the C extension module) or
mod_python? If you could eliminate one and remove the problem, that would
help a lot.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1758146&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1721083 ] Add File - Reload
Feature Requests item #1721083, was opened at 2007-05-17 22:15 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1721083&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.6 Status: Open Resolution: None >Priority: 3 Private: No Submitted By: Raymond Hettinger (rhettinger) Assigned to: Kurt B. Kaiser (kbk) Summary: Add File - Reload Initial Comment: When using CVS or SVN, it is common to revert or merge a file that is open in the editor. It would be great to have a reload/refresh option on the menu to bring in the changed file. Without that option, the only approach is to close without saving, fire-up the editor again, and reload the file manually. -- >Comment By: Kurt B. Kaiser (kbk) Date: 2007-07-21 21:04 Message: Logged In: YES user_id=149084 Originator: NO If you have more than one IDLE window open (even a shell), it's not necessary to shut down. Just close the edit window, confirm the unsaved warning, and use the Recent Files menu item to reopen with the current disk contents. We are talking about five mouse clicks instead of three, counting confirmation dialogs. In my opinion, it's not worth complicating IDLE and confusing beginners with a 'revert' menu item to save two clicks every other day or so. I normally use IDLE with svn and never feel the need to reload something that was merged. After all, you should have updated before you opened the file in IDLE. If you modified the file in IDLE, saved, and checked it in, IDLE's copy is the same as svn. Maybe you have a use case I haven't considered. If it's a good one, then a (normally inactive) IDLE extension might be warranted for those who really need this. Adding a warning when saving that the file has changed on disk is a good emacs feature which has saved my bacon a number of times. That would be a good feature to add to IDLE, but that's a different request. Rejecting this one. -- Comment By: Tal Einat (taleinat) Date: 2007-07-20 19:29 Message: Logged In: YES user_id=1330769 Originator: NO I agree with KBK that what you suggest goes against IDLE's philosophy, which is to be simple and uncluttered, avoiding "bells and whistles". However, I do think that a simple "revert file" menu item in the File menu, which would just reload the file from the file system, could be generally useful. Additionally, IDLE could monitor the file on the file system, and if it is changed outside of IDLE, ask the user whether to continue with the current version or switch to the new version on disk. I've seen some text editors do this, and it can save some headaches. Drawbacks are that some users may find this annoying (at least at first), and it could be somewhat complex to implement. Thoughts on this? Perhaps this should be brought up on IDLE-dev? Each of the above would allow you to revert/merge using whatever CVS/SVN/etc. tools you normally use, then just load the new version inside the already open instance of IDLE. I think this would be a good separation of roles between IDLE and version control tools. -- Comment By: Kurt B. Kaiser (kbk) Date: 2007-05-22 19:18 Message: Logged In: YES user_id=149084 Originator: NO But isn't this an example of a bell/whistle which is outside IDLE's design policies? It would add a menu item which would be rather rarely used, especially by beginners, it seems to me. Why not just close the edit window (not IDLE) and re-open using the Files / Recent Files feature? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1721083&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1757831 ] Allow opening just an editor window
Feature Requests item #1757831, was opened at 2007-07-20 18:17 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1757831&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tal Einat (taleinat) Assigned to: Nobody/Anonymous (nobody) Summary: Allow opening just an editor window Initial Comment: Currently, if IDLE is configured to open a shell window by default, there is no way to override this from the command line. There should be a way to just open an editor window from the command line. Perhaps this should be the behavior when the -e option is given? The shell could still be opened (if IDLE is so configured) for just "idle.py ", without the -e. -- >Comment By: Kurt B. Kaiser (kbk) Date: 2007-07-21 21:08 Message: Logged In: YES user_id=149084 Originator: NO Yes, I think you are right about this. That would also allow us to configure IDLE on Windows so if someone selects "Edit with IDLE" on the right click menu, it won't also open a shell, which is generally not needed. The command line options should override the config options. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1757831&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
