From: SourceForge.net <no...@so...> - 2012-07-23 11:49:11
|
Bugs item #3545365, was opened at 2012-07-18 04:52 Message generated for change (Comment added) made by twylite You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3545365&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: 24. Channel Commands Group: development: 8.6b3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Twylite (twylite) Assigned to: Andreas Kupries (andreas_kupries) Summary: Crash in io-29.33b (no implicit flush of nonblocking on exit Initial Comment: Hi, io-29.33b crashes on a trunk build from 2012/07/18 using MSVC10, 32-bit tclsh running on Windows 7 64-bit. Details: Build setup (32-bit): 'Setting environment for using Microsoft Visual Studio 2010 x86 tools' Testing platform: Windows 7 (64-bit), PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 30 Stepping 5, GenuineIntel C:\User\Tcl_BUILD\cmake-2012\tcl-trunk>fossil pull Server: http://core.tcl.tk/tcl C:\User\Tcl_BUILD\cmake-2012\tcl-trunk>fossil update updated-to: f0f8f508748b68a589768e9e7df3beea28279df9 2012-07-17 13:08:18 UTC tags: trunk Build commands: set BUILDENV=VC10 set VER=86b3 set INSTALLDIR=%CD%\Release_%VER%_%BUILDENV% set OPTS=threads set TCLSH=%INSTALLDIR%\bin\tclsh86t.exe mkdir %INSTALLDIR% pushd win nmake /f makefile.vc release tcltest OPTS=%OPTS% CFG_ENCODING=\\\"utf-8\\\" INSTALLDIR=%INSTALLDIR% nmake /f makefile.vc install OPTS=%OPTS% CFG_ENCODING=\\\"utf-8\\\" INSTALLDIR=%INSTALLDIR% nmake /f makefile.vc test FAILURE #1: io-29.33b crashes (probably unrelated) C:/User/Tcl_BUILD/cmake-2012/tcl-trunk/tests/io.test:2746: error: test failed: i o-29.33b TIP#398, no implicit flush of nonblocking on exit ==== io-29.33b TIP#398, no implicit flush of nonblocking on exit FAILED ==== Contents of test case: set f [open $path(script) w] puts $f { fconfigure stdout -blocking 0 puts -nonewline stdout [string repeat A 655360] flush stdout } close $f set f [open $path(script2) w] puts $f {after 2000} close $f set t1 [clock milliseconds] set ff [open "|[list [interpreter] $path(script2)]" w] catch {unset ::env(TCL_FLUSH_NONBLOCKING_ON_EXIT)} exec [interpreter] $path(script) >@ $ff set t2 [clock milliseconds] close $ff expr {($t2-$t1)/2000 ? $t2-$t1 : 0} ---- Test generated error; Return code was: 1 ---- Return code should have been one of: 0 2 ---- errorInfo: child killed: segmentation violation while executing "exec [interpreter] $path(script) >@ $ff" ("uplevel" body line 15) invoked from within "uplevel 1 $script" ---- errorCode: CHILDKILLED 9996 SIGSEGV {segmentation violation} ==== io-29.33b FAILED ---------------------------------------------------------------------- >Comment By: Twylite (twylite) Date: 2012-07-23 04:49 Message: I have to concur with Alexandre here -- checking that instanceData != NULL will prevent the crash, but there's still the question of when and why instanceData becomes NULL, given that PipeClose2Proc() may not be the only code that assumes instanceData is non-NULL. ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2012-07-23 04:46 Message: That would seem to work at a superficial level; however, that this can be happening at all (and not always, not on all OSes...) indicates a deeper flaw in the logic, like a subtle race condition. I'd like to understand it before wiping out the symptom ;) Andreas, are you available to have a look ? ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2012-07-23 04:32 Message: My suggestion would be to change the following line tclIO.c: if (chanPtr->typePtr->closeProc == TCL_CLOSE2PROC) { to: if (chanPtr->typePtr->closeProc == TCL_CLOSE2PROC && chanPtr->instanceData) { (in all Tcl 8.4, 8.5 and 8.6) Reasoning: If chanPtr->instanceData == NULL, close2Proc for sure will not be able to handle that. Would that solve the problem? ---------------------------------------------------------------------- Comment By: Twylite (twylite) Date: 2012-07-23 03:23 Message: The crash is in the exec'd process - a NULL pointer dereference in PipClose2Proc during the Tcl shutdown (Tcl_FinalizeIOSubsystem). tcl86.dll!PipeClose2Proc(void * instanceData, Tcl_Interp * interp, int flags) Line 1809 + 0x13 bytes C if ((!flags || flags == TCL_CLOSE_READ) && (pipePtr->readFile != NULL)) { instanceData 0x00000000 void * pipePtr 0x00000000 {nextPtr=??? channel=??? validMask=??? ...} PipeInfo * tcl86.dll!Tcl_Close(Tcl_Interp * interp, Tcl_Channel_ * chan) Line 3121 + 0x1a bytes C tcl86.dll!TclFinalizeIOSubsystem() Line 477 + 0xb bytes C tcl86.dll!Tcl_FinalizeThread() Line 1305 C tcl86.dll!Tcl_Exit(int status) Line 988 C tcl86.dll!Tcl_ExitObjCmd(void * dummy, Tcl_Interp * interp, int objc, Tcl_Obj * const * objv) Line 825 + 0x9 bytes C ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2012-07-18 06:02 Message: OK, to proceed and get a debugger stack, we need to work a bit ;) As you have seen, the test involves two subprocesses: $path(script) which does a big nonblocking write, and $path(script2) which just sits for two seconds. The test criterion is then, "is the life of the writer short or long". Here, the crash appears in the writer. So, you'll have to instrument it to be attachable by debugger: (1) arrange so that [interpreter] is the debug-compiled executable (2) add a long [after] at the beginning of the $path(script) (3) identify it in task manager and attach Then please come back with a stack trace ;) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3545365&group_id=10894 |