garbage collection asserts failing

[munder12]

BPO	1241545
Nosy	@tim-one, @nascheme, @tiran

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2008-01-20.19:39:32.934>
created_at = <Date 2005-07-20.13:27:27.000>
labels = []
title = 'garbage collection asserts failing'
updated_at = <Date 2008-01-20.19:39:32.932>
user = 'https://bugs.python.org/munder12'

bugs.python.org fields:

activity = <Date 2008-01-20.19:39:32.932>
actor = 'christian.heimes'
assignee = 'none'
closed = True
closed_date = <Date 2008-01-20.19:39:32.934>
closer = 'christian.heimes'
components = ['None']
creation = <Date 2005-07-20.13:27:27.000>
creator = 'munder12'
dependencies = []
files = []
hgrepos = []
issue_num = 1241545
keywords = []
message_count = 11.0
messages = ['60777', '60778', '60779', '60780', '60781', '60782', '60783', '60784', '60785', '60786', '61352']
nosy_count = 5.0
nosy_names = ['tim.peters', 'nnorwitz', 'nascheme', 'munder12', 'christian.heimes']
pr_nums = []
priority = 'normal'
resolution = 'out of date'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1241545'
versions = ['Python 2.3']

[munder12]

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

[munder12]

Logged In: YES
user_id=1156202

This also fails in Python 2.4.1 on same system.

[nascheme]

Logged In: YES
user_id=35752

Usually this kind of error is caused by a bug in a 3rd party
extension module. Try to narrow down the test case as much
as possible. Can you provide a Python script that triggers
the assertion failure?

[tim-one]

Logged In: YES
user_id=31435

Well, this isn't enough info to go on. For example, what
program was Python running at the time? What were you
doing? How could anyone else try to reproduce this? It's
certainly not something Python normally does ;-)

FWIW, the most likely cause is bad C coding in a Python
extension (non-core) module. That the problem persists for
you across Python versions points even more at non-core C
code.

[munder12]

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 hoping someone familiar with the gc routines might
go "oh, yeah... -4 is valid now too.." or something similar.

In the meantime, I will be trying to continue to reduce the
number of imported modules where I can still get the problem
to happen There are 2 modules psyco and pyro that are non-
core and Tkinter.

But since the Google search turned up yum giving same error
(which I doubt uses psyco, pyro, or Tkinter), I thought I would
mention it here as I continued searching.

[tim-one]

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.

[munder12]

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

[tim-one]

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.

[munder12]

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.

[nnorwitz]

Logged In: YES
user_id=33168

munder, do you think this is still a bug or should it be closed?

[tiran]

No response from the OP in the last 2 years. I'm closing this bug.