[ python-Bugs-1241545 ] garbage collection asserts failing
Bugs item #1241545, was opened at 2005-07-20 08:27 Message generated for change (Comment added) made by munder12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&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: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: munder12 (munder12) Assigned to: Nobody/Anonymous (nobody) Summary: garbage collection asserts failing Initial Comment: Modules/gcmodule.c:294: visit_reachable: Assertion `gc_refs > 0 || gc_refs == (-3) || gc_refs == (-2)' failed. Running Python 2.3.4 on Fedora Core 3 (2.6.11-1.35_FC3smp). Also tried Python 2.3.5. When searching Google for this error, found following link where someone using yum updates was getting same error from python http://forums.fedoraforum.org/showthread.php?t=54704 -- >Comment By: munder12 (munder12) Date: 2005-07-25 07:55 Message: Logged In: YES user_id=1156202 Well, I have what appears to be a working solution: Use python 2.5a0 from CVS. This version works with psyco. I suspect the bug fix to gcmodules.c that added the missing INCREF is the culprit (the one labelled as a backport candidate). As for why the assert was triggering, I have my thoughts. First, gdb when trying to read the core files was confirming the absolute path to the (non-debug) executable I thought I was running but also would not give a valid traceback due to stack corruption. Is it possible that the memory corruption was making it where (__ASSERT_VOID_CAST (0)) was unable to succeed? (This is what assert(expr) is macro'd to when defining NDEBUG.) Thanks. -- Comment By: Tim Peters (tim_one) Date: 2005-07-21 13:25 Message: Logged In: YES user_id=31435 This part of the command line you showed: -DNDEBUG causes C's assert() macro to "expand to nothing". That's part of the definition of the C language, not a Python convention. So if you compiled Python with -DNDEBUG, and are seeing an assert() trigger, then I can only conclude one of two things: 1. Your C compiler has a very bad bug. or 2. You're not actually using the Python you think you're using. That said, I've seen very strange bugs triggered by psyco too, but not even psyco can cause code to execute that doesn't exist. No code is generated for an assert() when compiling with -DNDEBUG: the C preprocessor throws assert()s away when NDEBUG is #define'd. -- Comment By: munder12 (munder12) Date: 2005-07-21 13:05 Message: Logged In: YES user_id=1156202 Well, this gets even stranger. I am not running a debug version of python as far as I can tell. I built 2.4.1 in a fresh directory by: ./configure --prefix=/blah make make test make install The gcmodule was echo'd as being built this way: gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Modules/gcmodule.o Modules/gcmodule.c I am leaning toward psyco as being the culprit based on your suggestions since it is the only one that has extra C libraries. I'm running the case with Tkinter, pyro, and psyco all not being imported. Thanks again, Mark -- Comment By: Tim Peters (tim_one) Date: 2005-07-20 19:35 Message: Logged In: YES user_id=31435 I'm intimately familiar with the gc code, and I'm sure this assert has never triggered in any core Python release, or in any Zope release, not even in between-releases buggy development states. It means some memory gc is staring at has an insane value, one that can't possibly arise in intended operation. If you get into gdb (whatever debugger you have), it might be useful to know what value gc_refs _does_ have at this point. One possibility is that you're mixing a debug-build Python (which you are using: asserts never trigger in a release-build Python, simply because the assert() macro expands to nothing then) with one or more release-build extension modules. Trying to mix like that can blow up in all sorts of "impossible" ways. -- Comment By: munder12 (munder12) Date: 2005-07-20 19:04 Message: Logged In: YES user_id=1156202 Sorry, I realize it is not much to go on but I cannot currently get it to fail other than when I run this one script. It is all written in python. It is a simulation running a genetic algorithm that is set up to run about 24 hours straight. This error occurs within about 5 hours into the simulation (repeatedly). Running similar simulations that complete in less than a couple hours run without a problem. Was
[ python-Bugs-1244610 ] 2.4.1 build fails on OpenBSD 3.7
Bugs item #1244610, was opened at 2005-07-25 09:31 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=1244610&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.4 Status: Open Resolution: None Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.1 build fails on OpenBSD 3.7 Initial Comment: Python 2.4.1, OpenBSD 3.7, gcc (GCC) 3.3.5 (propolice). I'm including the logs here because they are short. "./configure" printed the following: checking curses.h usability... no checking curses.h presence... yes configure: WARNING: curses.h: present but cannot be compiled configure: WARNING: curses.h: check for missing prerequisite headers? configure: WARNING: curses.h: see the Autoconf documentation configure: WARNING: curses.h: section "Present But Cannot Be Compiled" configure: WARNING: curses.h: proceeding with the preprocessor's result configure: WARNING: curses.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to http://www.python.org/python-bugs ## configure: WARNING: ## ## checking for curses.h... yes This warning was printed for curses.h, ncurses.h, sys/audioio.h, and sys/lock.h. (The reference to "Autoconf documentation" is useless, because autoconf is not used during the configure process, and is not even installed on the system where I was doing the build.) Then: % make gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o Modules/python.c In file included from /usr/include/sys/select.h:38, from Include/pyport.h:116, from Include/Python.h:55, from Modules/python.c:3: /usr/include/sys/event.h:53: error: syntax error before "u_int" /usr/include/sys/event.h:55: error: syntax error before "u_short" *** Error code 1 Stop in /usr/src/Python-2.4.1. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244610&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1244683 ] logging module needs to that it changed in 2.4
Bugs item #1244683, was opened at 2005-07-25 13:09 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=1244683&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: None Status: Open Resolution: None Priority: 5 Submitted By: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: logging module needs to that it changed in 2.4 Initial Comment: http://docs.python.org/lib/module-logging.html lacks the standard note "changed in version 2.4". This affects the basic example at http://docs.python.org/lib/minimal-example.html because in 2.3 (including 2.3.5) basicConfig did not accept the example's keyword arguments. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244683&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1244683 ] logging module doc needs to note that it changed in 2.4
Bugs item #1244683, was opened at 2005-07-25 13:09 Message generated for change (Settings changed) made by aisaac0 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244683&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: None Status: Open Resolution: None Priority: 5 Submitted By: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) >Summary: logging module doc needs to note that it changed in 2.4 Initial Comment: http://docs.python.org/lib/module-logging.html lacks the standard note "changed in version 2.4". This affects the basic example at http://docs.python.org/lib/minimal-example.html because in 2.3 (including 2.3.5) basicConfig did not accept the example's keyword arguments. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244683&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1244864 ] Segfault in Python interpreter 2.3.5
Bugs item #1244864, was opened at 2005-07-25 23:53 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=1244864&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: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Evil Mr Henry (evilmrhenry) Assigned to: Nobody/Anonymous (nobody) Summary: Segfault in Python interpreter 2.3.5 Initial Comment: Linux, Debian Testing, with Bash shell. If I type "python" at the bash prompt to start the interpreter, then hit the up arrow key (the previous command key), Python segfaults. This only occurs if there are no previous commands in the queue. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244864&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
