From: SourceForge.net <no...@so...> - 2010-09-17 18:10:49
|
Bugs item #3069278, was opened at 2010-09-17 11:04 Message generated for change (Comment added) made by hobbs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3069278&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: 37. File System Group: development: 8.6b1.1 Status: Open Resolution: None Priority: 8 Private: No Submitted By: Jeffrey Hobbs (hobbs) Assigned to: Jan Nijtmans (nijtmans) Summary: breakage on head Windows triggered by install-tzdata Initial Comment: Previously recorded at 3065455, we have found that there is a general issue newly introduced on head on Windows, I suspect related to the -DUNICODE work. You can trigger this bug with install-tzdata, but only when you use a prefix path of sufficient length. This one in particular worked for me: prefix = C:/Tcl-test/we-want-a-long-path/and-this-makes-it-longer/dont-you-know-longer-still/yes-this-will-be-long-enough exec_prefix = C:/Tcl-test/we-want-a-long-path/and-this-makes-it-longer/dont-you-know-longer-still/yes-this-will-be-long-enough bindir = ${exec_prefix}/bin libdir = C:/Tcl-test/we-want-a-long-path/and-this-makes-it-longer/dont-you-know-longer-still/yes-this-will-be-long-enough/lib aka --prefix=C:/Tcl-test/we-want-a-long-path/and-this-makes-it-longer/dont-you-know-longer-still/yes-this-will-be-long-enough when building. So what's happening here? I believe something in the switch from regular to -DUNICODE mode is now overflowing some aspect of a dstring (they have static space of 200b, and must grow otherwise). Or perhaps a buffer overrun where 1b was appended where 1*sizeof(WCHAR) is needed now. In any case, the crash symptoms indicate dstring related smashing, which is of course used all over Windows file handling. The -DUNICODE will have distinctly affected this behavior as well. ---------------------------------------------------------------------- >Comment By: Jeffrey Hobbs (hobbs) Date: 2010-09-17 11:10 Message: BTW, this is heisenbug like, and does need multiple runs to confirm. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2010-09-17 11:05 Message: One crash stack, which crashed in a mem debug build with "unable to alloc 306 bytes, z:/cvs/tcl/tcl8.6/win/tclWinFile.c line 3232". Of course I have enough mem, but some mem smashing must be occurring. tcl86g.dll!Tcl_DbCkalloc(unsigned int size=306, const char * file=0x1018425c, int line=3232) Line 393 + 0x16 bytes C > tcl86g.dll!TclNativeCreateNativeRep(Tcl_Obj * pathPtr=0x023d6310) Line 3232 + 0x13 bytes C tcl86g.dll!Tcl_FSGetInternalRep(Tcl_Obj * pathPtr=0x023d6310, const Tcl_Filesystem * fsPtr=0x10132c38) Line 2160 + 0x7 bytes C tcl86g.dll!Tcl_FSGetNativePath(Tcl_Obj * pathPtr=0x023d6310) Line 4571 + 0xe bytes C tcl86g.dll!TclpObjStat(Tcl_Obj * pathPtr=0x023d6310, _stat64 * statPtr=0x0017ebd4) Line 1985 + 0xf bytes C tcl86g.dll!Tcl_FSStat(Tcl_Obj * pathPtr=0x023d6310, _stat64 * buf=0x0017ebd4) Line 2034 + 0x10 bytes C tcl86g.dll!FileCopyRename(Tcl_Interp * interp=0x023004d8, int objc=5, Tcl_Obj * const * objv=0x023015e8, int copyFlag=1) Line 147 + 0xd bytes C ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3069278&group_id=10894 |