I have narrowed it down as far as I can by continuing
to make the problem simpler and simpler but where it
still core dumps.

The way this is set up is the following:

pytest2.py and pytest.py are in the same directory.

pytest3.py is in PYTHONPATH where PYTHONPATH is
<abs_path>/BASE:<abs_path>/SUP  (pytest3.py is in BASE).


Run ./pytest2.py several times.
This current problem core dumps on average about 2
times every 5 runs.

I have attached a file that has the Python listings as
well as the gdb traceback.

This is running under Fedora Core 1 with:

Python 2.2.3 (#1, Oct 15 2003, 23:33:35)
[GCC 3.3.1 20030930 (Red Hat Linux 3.3.1-6)] on linux2

Thank you,
Mark

PS  Strangely enough the comments in pytest.py seem to
actually increase the frequency of core dumps.

Logged In: YES 
user_id=6656

Have you tried a more recent Python?

I'm finding decoding your report (attempting to reproduce) a
little challenging.  Could you upload a tarball containing a
shell script driver or something?

Logged In: YES 
user_id=1156202

I have played some more with the setup.  Now only pytest2.py
and pytest.py need to be present in same directory.

Running pytest2.py will randomly cause core dumps coming
from pytest.py.

If you run pytest.py enough times directly it also will
randomly core.

I have attached pytest.py and pytest2.py.

I have not tried with any other version of Python yet.

Logged In: YES 
user_id=6656

Uh, if that tiny thing cores, I'm very much inclined to
believe there's something flaky in your setup.

Logged In: YES 
user_id=1156202

I have checked out and built Python 2.4b2.  It still core
dumps on these same files but it now takes on average about
8 runs to get 2 cores.

I will attach the 2.4b2 core traceback.

Logged In: YES 
user_id=6656

Hmm.  The traceback shows that it's dumping core while loading 
the site.pyc file from the disk.  This happens before Python begins 
executing whatever code you've asked it to.  You could try 
deleting the site.pyc file and see if that makes any difference, or 
running python -S.

I still think there must be something odd about your setup.  If 
Python 2.4b2 cored 25% of the time it was launched, someone 
else would have noticed by now :)

Logged In: YES 
user_id=1156202

It is 2 times out of 8 runs of the main script.  Actually, that is 
2 cores out of 1600 runs of the script that really cores.  It 
does seem to be localized to Fedora Core 1.  Fedora Core 2, 
Win 2000, Win XP, and Mandrake 9 on similar hardware do not 
have the problem with these scripts.

The Python 2.4b2 is straight out of the tarball (compiled and 
installed cleanly).  The core dumps occur randomly with 
posixpath.py, site.py, etc. and at different stages (robject() 
and within fstat() (from /usr/include/sys/stat.h)).

Logged In: YES 
user_id=31435

At this point, it would be prudent to write the same kind of 
program in straight C, and test that.  The more you find out, 
the less it appears that Python has something to do with 
what you're seeing.  Note that it's not unusual to discover 
OS, compiler, and platform C library bugs by running Python 
programs, simply because Python builds on all of them.

Logged In: YES 
user_id=1156202

I have written a program in C that just opens and closes a
file repeatedly.  It appears to work fine.  But, there
appears to be much more that Python is doing behind the
scenes than what my script is explicitly directing (open and
close the file).  Since I'm not sure what all OS related
calls Python is making when opening, say, "site.py," I'm not
quite sure how I can write a C code that mimics what Python
is doing.

It may well be that the OS is the culprit.  However, it also
could be that, in the Python code itself, some error
checking is not being performed on all OS calls as they
should be since they so rarely fail on a mjority of OS's. 
Or, extra try...catch blocks maybe could be added to retry
the OS call(s) that is "incorrectly" failing on Fedora Core
1 so that Python maintains its portability with (hopefully)
minimal speed impact.

Logged In: YES 
user_id=1038590

I'm not sure it's relevant, but I once had a similar problem
with Python flakiness that turned out to be due to some old
.pyc files lying around (this was Fedora Core 3-test 1, and
the offending files were in my Python CVS build directory).

For whatever reason, Python wasn't picking up the version
mismatch and was trying to use the old .pyc files. Seg
faults abounded as a result.

One thought: could root ownership of pre-generated .pyc's
have that effect? (I don't know how Python reacts if it
can't delete the .pyc's)

Logged In: YES 
user_id=33168

I can't reproduce on current CVS (2.5).  Can anyone
reproduce this now?  Should this be closed?

Logged In: YES 
user_id=1188172

I'd say that it can be closed. As mwh says: "If Python 2.4b2
cored 25% of the time it was launched, someone else would
have noticed by now :)"

Logged In: YES 
user_id=33168

munder12, if you are still having problems let us know.  I'm
closing this as not reproducible.

Logged In: YES 
user_id=1156202

I'm no longer on Fedora Core 1 and cannot tell if this has 
been fixed on that system or not.  I do not have the 
problem on Fedora Core 3.