[ python-Bugs-1309567 ] linecache module returns wrong results

[SourceForge.net]

Bugs item #1309567, was opened at 2005-09-30 10:57
Message generated for change (Settings changed) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1309567&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
>Summary: linecache module returns wrong results

Initial Comment:
On several occasions I have seen tracebacks in my code
pointing to PIL's __init__.py file. That is strange,
because I have installed PIL but it is used nowhere.

Finally I traced it down to a problem in the linecache
code, which tries to be smart in up updatecache
function.  When os.stat() on the filename fails with
os.error, it walks along sys.path and returns the first
file with a matching basename. This *may* make sense
for toplevel modules, but never for modules in packages.

So, if the traceback's stack contains an entry for a
non-existing file (for example because the .py file for
a .pyc file is no longer present), linecache returns
absolute garbage.

Example, on my system (the \a\b\c\__init__.py file
doesn't exist):

C:\>python -c "import linecache; print
linecache.getlines(r'\a\b\c\__init__.py')"
['#\n', '# The Python Imaging Library.\n',
'# $Id: //modules/pil/PIL/__init__.py#2 $\n', '#\n',
'# package placeholder\n', '#\n', '# Copyright (c) 1999
by Secret Labs AB.\n',
'#\n', '# See the README file for information on usage
and redistribution.\n',
'#\n', '\n', '# ;-)\n']
C:\>

The bug is present in 2.3, 2.4, and current CVS.


----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2005-09-30 13:12

Message:
Logged In: YES 
user_id=11105

> But what about the use case of modules compiled on one system
> and moved to a different system? Is that use case important
> enough?

Maybe.  Couldn't the code be made more robust, so that it
works as intended with packages?  Unfortunately the code
objects don't have a reference to the module where they live
(probably because they are created before the module is
created).

BTW: The bug sometimes also is responsible for tracebacks in
pydoc, because it cannot locate the sourceline in the file.
 So, wrong sourec in tracebacks aren't the only problem.

It seems it would work better with relative pathnames, but
it's too late for that.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2005-09-30 12:24

Message:
Logged In: YES 
user_id=6380

Radical indeed. But what about the use case of modules
compiled on one system and moved to a different system? Is
that use case important enough?

There used to be a different use case, because bytecode
files used to contain relative path names. I believe that's
been fixed, if only by code in site.py that absolutizes
sys.path. (Except the initial '' -- is that important?)

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2005-09-30 11:08

Message:
Logged In: YES 
user_id=11105

The attached patch is a radical way to fix this problem - it
refuses to guess if the file is not found.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1309567&group_id=5470