From: SourceForge.net <no...@so...> - 2006-03-01 04:19:33
|
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 |