Menu
▾
▴
[Tcl-bugs] [ tcl-Bugs-1379287 ] TclFSNormalizeAbsolutePath() fails on /tmp/..
|
From: SourceForge.net <no...@so...> - 2006-03-04 02:34:03
|
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: 36. File System Group: development: 8.5a4 Status: Pending Resolution: Fixed Priority: 9 Submitted By: George Peter Staplin (georgeps) Assigned to: Don Porter (dgp) Summary: TclFSNormalizeAbsolutePath() fails on /tmp/.. 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-03-03 21:34 Message: Logged In: YES user_id=80530 another attempt committed. Windows testers needed to check fileSystem.test ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2006-03-03 17:37 Message: Logged In: YES user_id=80530 still same failure on Windows. What a garbage routine this is to debug. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2006-03-03 15:10 Message: Logged In: YES user_id=80530 Here's an additional patch I'm committing to HEAD. Windows testers please? ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2006-03-03 14:16 Message: Logged In: YES user_id=80530 Test failure on Windows: ---- Result was: Paths should be equal: /bar , C:/bar ---- Result should have been (exact matching): ok ==== filesystem-1.45 FAILED ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2006-03-03 13:52 Message: Logged In: YES user_id=32170 Thanks dgp! I've just had a kid so will not have much time to examine this sort of thing for a while... Vince. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2006-03-02 23:32 Message: Logged In: YES user_id=80530 Revised patch now works on OSX and any other system where /tmp is a symlink. Tests broken if /xxx is a symlink, but that ought to be rare enough to not worry about. Committing so that someone will test on Windows. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2006-03-02 11:53 Message: Logged In: YES user_id=80530 I think the attached patch solves the problem, but review and testing is welcome. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2006-03-01 16:29 Message: Logged In: YES user_id=80530 revised subject. Note that the lexical processing of ".." by TclFSNormalizeAbsolutePath is already a point of controversy. See Bug 961646. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2006-03-01 16:22 Message: Logged In: YES user_id=80530 The problem is with TclFSNormalizeAbsolutePath(). In particular the call around line 1884. The "absolutePath" value passed in is "/tmp/.." and the resulting normalized form is "". ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2006-03-01 16:15 Message: Logged In: YES user_id=80530 hmmm.. ok, several lines later around lline 1849-1851, the TCL_PATH_RELATIVE case is handled, so this is just a bad var name. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2006-03-01 16:13 Message: Logged In: YES user_id=80530 Within Tcl_FSGetNormalizedPath() at line 1830 of tclPathObj.c: Tcl_Obj *absolutePath = fsPathPtr->translatedPathPtr; The variable name "absolutePath" suggests the code expects that path to have pathtype TCL_PATH_ABSOLUTE. In this example, that is not the case. The value is "..", which has pathtype TCL_PATH_RELATIVE. If the code does in fact depend on absolutePath being an absolutePath, then things are broken somewhere. If it does not depend on that, then the variable name choice is poor. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2006-03-01 00:49 Message: Logged In: YES user_id=80530 Finally, the next relevant revision: 2004-01-22 Vince Darley <vin...@us...> * tests/fileSystem.test: 3 new tests * generic/tclPathObj.c: fix to [Bug 879555] in file normalization. * doc/filename.n: small clarification to Windows behaviour with filenames like '.....', 'a.....', '.....a'. left things in their current buggy state: % cd /tmp % pwd /tmp % cd .. % pwd % cd .. % pwd .. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2006-03-01 00:30 Message: Logged In: YES user_id=80530 Next relevant revision, 2004-01-21 Vince Darley <vin...@us...> gets us closer to what we see now: % cd /tmp % pwd /tmp % cd .. % pwd % cd .. % pwd <CRASH> ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2006-02-28 23:46 Message: Logged In: YES user_id=80530 The next relevant changes: 2003-12-17 Vince Darley <vin...@us...> * generic/tclCmdAH.c: * unix/tclUnixFile.c: * win/tclWinFCmd.c: * tests/fCmd.test: * tests/fileSystem.test: * doc/file.n: final fix to support for relative links and its implications on normalization and other parts of the filesystem code. Fixes [Bug 859251] and some Windows problems with recursive file delete/copy and symbolic links. 2003-12-17 Vince Darley <vin...@us...> * generic/tclPathObj.c: * tests/fileSystem.test: fix and tests for [Bug 860402] in new file normalization code. ...left things buggy in a different way: % cd /tmp % pwd /tmp % cd .. couldn't change working directory to "..": no such file or directory ---------------------------------------------------------------------- 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 |