[Tcl-bugs] [ tcl-Bugs-1379287 ] cd .. pwd segfault in NetBSD and Linux (in some cases)

[SourceForge.net <no...@so...>]

Bugs item #1379287, was opened at 2005-12-13 02:04
Message generated for change (Comment added) made by dgp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1379287&group_id=10894

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: 35. Pathname Management
Group: development: 8.5a4
Status: Open
Resolution: None
Priority: 9
Submitted By: George Peter Staplin (georgeps)
Assigned to: Vince Darley (vincentdarley)
Summary: cd .. pwd segfault in NetBSD and Linux (in some cases)

Initial Comment:
I found this odd behavior first in an old tclkit.  In
that case it was an 8.5a4-based version (sometime
before the BigNum code was integrated) and it caused a
segfault.

I just tried today with the HEAD and it's broken, but
doesn't segfault for me.  Steve Redler IV confirmed
that it's broken in Slackware Linux.  Steve was able to
get a segfault with a tclkit built with the Tcl HEAD as
of about 2 weeks ago -- using the patterns I list below.

I haven't yet tried todays HEAD with a tclkit, but it
could be that tclkit introduces a segfault rather than
just the strange behavior.

In the tclkit the pattern is:
# cd /tmp
# tclkit8.5 
% cd ..
% pwd
% cd ..
% pwd
Memory fault (core dumped) 

Note: I had to be root to get the /tclkit8.5.core created.

The backtrace on the core indicates a loop of patterns
that goes on for quite a while (endless recursion? or
possibly the debugger is confused).
#0  0x080811bf in TclDefaultBgErrorHandlerObjCmd ()
[this is where it repeats for thousands of times]
#1  0x08094ca7 in Tcl_FSLstat ()
#2  0x080a593e in Tcl_FSLstat ()
#3  0x080a58dc in Tcl_FSLstat ()
#4  0x080a7bfb in Tcl_FSLstat ()
#5  0x080d220f in TclpUnloadFile ()
#6  0x080952a9 in Tcl_FSLstat ()
#7  0x08094248 in Tcl_FSLstat ()
#8  0x080a7c0e in Tcl_FSLstat ()
#9  0x080d220f in TclpUnloadFile ()
#10 0x080952a9 in Tcl_FSLstat ()
#11 0x08094248 in Tcl_FSLstat ()
#12 0x080a7c0e in Tcl_FSLstat ()
#13 0x080d220f in TclpUnloadFile ()
...


This demonstrates the broken behavior with today's HEAD:
$ make shell
LD_LIBRARY_PATH=`pwd`:${LD_LIBRARY_PATH}; export
LD_LIBRARY_PATH;  TCL_LIBRARY="
/gps/src/cvs/HEAD/tcl/library"; export TCL_LIBRARY; 
./tclsh 
% cd /gps
% cd ..
% pwd
% cd ..
% pwd
..
% cd ..
% pwd
..
% cd ..
% pwd
..
% cd ..
% pwd
..
% cd /
% pwd
/
% cd ..
% pwd
% cd ..
% pwd
..

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

>Comment By: Don Porter (dgp)
Date: 2006-02-28 23:19

Message:
Logged In: YES 
user_id=80530

This test case worked correctly
until:

2003-12-14  Vince Darley  <vin...@us...>

        * generic/tclPathObj.c: complete rewrite of generic file
        normalization code to cope with links followed by '..'.
        [Bug 849514], and parts of [859251]


That change made things buggy in this way:

% cd /tmp
% pwd
/tmp
% cd ..
% pwd
/tmp


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

Comment By: Don Porter (dgp)
Date: 2006-02-28 16:14

Message:
Logged In: YES 
user_id=80530


Ditto 8.5a1.

Working theory is this bug
arose with the 2003-04-11
refactorization that produced
tclPathObj.c.

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

Comment By: Don Porter (dgp)
Date: 2006-02-28 16:01

Message:
Logged In: YES 
user_id=80530


This bug is present in
Tcl 8.5a3 and 8.5a2 releases.

Still testing...

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

Comment By: George Peter Staplin (georgeps)
Date: 2006-02-27 18:02

Message:
Logged In: YES 
user_id=585068

from CdObjCmd -> FSChdir -> Tcl_FSGetNormalizedPath we find
the failure I think.  pathPtr->bytes is ".." at the start.

None of the code in Tcl_FSGetNormalizedPath that updates the
->normPathPtr used at the end is executed.  There is only
one branch that is entered and that is this:

 if (fsPathPtr->cwdPtr != NULL) {
  ...
  if (...) { 
   [not executed]
  } else if (...) {
   [not executed]
  }
 }
 
We then reach:
 return fsPathPtr->normPathPtr

I added this before the return:
printf ("fsPathPtr->normPathPtr '%s'\n",
fsPathPtr->normPathPtr);

which output this:
fsPathPtr->normPathPtr ''

So the normPathPtr should be updated by some code in
Tcl_FSGetNormalizedPath based on my interpretation of the
code and output.

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

Comment By: miguel sofer (msofer)
Date: 2006-02-25 12:46

Message:
Logged In: YES 
user_id=148712

Still occurs on current HEAD. Any progress?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1379287&group_id=10894