Menu
▾
▴
[Tcl-bugs] [ tcl-Bugs-859820 ] tclsh84t crashes when opening pipe
|
From: SourceForge.net <no...@so...> - 2004-01-20 05:39:25
|
Bugs item #859820, was opened at 2003-12-14 04:54 Message generated for change (Comment added) made by davygrvy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=859820&group_id=10894 Category: 27. Channel Types Group: obsolete: 8.4.4 Status: Open Resolution: None Priority: 8 Submitted By: yahalom emet (yahalom) Assigned to: Andreas Kupries (andreas_kupries) Summary: tclsh84t crashes when opening pipe Initial Comment: tcl8.4.4 thread 2.5.2 win200 when I open a pipe to an exe and another thread closes a pipe to that exe tcl crashes. it does not happen all the time. it seems that this actions need to happen at the same time exactly. I made locking around the open and close points and it works fine. is the open/close pipe not thread safe? visual studio says: Application popup: tclsh84t.exe - Application Error : The instruction at "0x100682fc" referenced memory at "0x00000009". The memory could not be "read". unhandled exception in tclsh84t.exe (tcl84t.dll) 0xC0000005: Access Violation 100682E6 call 1006BC20 100682EB mov esi,dword ptr ds:[100896D4h] 100682F1 add esp,4 100682F4 test esi,esi 100682F6 je 10068307 100682F8 mov eax,dword ptr [esp+8] ->100682FC cmp dword ptr [esi],eax 100682FE je 10068319 10068300 mov esi,dword ptr [esi+8] 10068303 test esi,esi 10068305 jne 100682FC 10068307 push 100896CCh 1006830C call 1006BC70 10068311 add esp,4 10068314 or eax,0FFFFFFFFh 10068317 pop esi 10068318 ret 10068319 push 100896CCh 1006831E call 1006BC70 10068323 mov eax,dword ptr [esi+4] 10068326 add esp,4 10068329 pop esi ---------------------------------------------------------------------- >Comment By: David Gravereaux (davygrvy) Date: 2004-01-19 21:39 Message: Logged In: YES user_id=7549 anon access might be running a day behind. It's the same as the attachment here. ---------------------------------------------------------------------- Comment By: yahalom emet (yahalom) Date: 2004-01-19 21:32 Message: Logged In: YES user_id=130120 I do not see that tclWinPipe was changed in the cvs. how do I get it in order to test it. ---------------------------------------------------------------------- Comment By: David Gravereaux (davygrvy) Date: 2004-01-19 21:20 Message: Logged In: YES user_id=7549 Committed patch to HEAD. Please do a CVS update to test the fix. All tests pass as before. It looks right, to me. ---------------------------------------------------------------------- Comment By: David Gravereaux (davygrvy) Date: 2004-01-18 16:44 Message: Logged In: YES user_id=7549 Try this. Get the attachment and rebuild. I'd post a diff, but CVS is down today for maintenance. This should avoid the pointer going stale. ---------------------------------------------------------------------- Comment By: David Gravereaux (davygrvy) Date: 2004-01-18 14:52 Message: Logged In: YES user_id=7549 ack.. bad code.. I'll fix and repost. ---------------------------------------------------------------------- Comment By: David Gravereaux (davygrvy) Date: 2004-01-18 13:19 Message: Logged In: YES user_id=7549 This might work: diff -c -r1.39 tclWinPipe.c *** tclWinPipe.c 24 Dec 2003 04:18:23 -0000 1.39 --- tclWinPipe.c 18 Jan 2004 21:17:24 -0000 *************** *** 2485,2491 **** int *statPtr, int options) { ! ProcInfo *infoPtr, **prevPtrPtr; DWORD flags; Tcl_Pid result; DWORD ret, exitCode; --- 2485,2491 ---- int *statPtr, int options) { ! ProcInfo *infoPtr = NULL, **nextPtrPtr; DWORD flags; Tcl_Pid result; DWORD ret, exitCode; *************** *** 2506,2515 **** */ Tcl_MutexLock(&pipeMutex); ! prevPtrPtr = &procList; ! for (infoPtr = procList; infoPtr != NULL; ! prevPtrPtr = &infoPtr->nextPtr, infoPtr = infoPtr- >nextPtr) { ! if (infoPtr->hProcess == (HANDLE) pid) { break; } } --- 2506,2516 ---- */ Tcl_MutexLock(&pipeMutex); ! for (nextPtrPtr = &procList; (*nextPtrPtr) != NULL; ! nextPtrPtr = &((*nextPtrPtr)->nextPtr)) { ! if (((*nextPtrPtr)->nextPtr)->hProcess == (HANDLE) pid) { ! infoPtr = (*nextPtrPtr)->nextPtr; ! *nextPtrPtr = infoPtr->nextPtr; break; } } *************** *** 2539,2544 **** --- 2540,2552 ---- if (ret == WAIT_TIMEOUT) { *statPtr = 0; if (options & WNOHANG) { + /* + * Reinsert this ProcInfo* back on the linkedlist. + */ + Tcl_MutexLock(&pipeMutex); + infoPtr->nextPtr = procList; + procList = infoPtr; + Tcl_MutexUnlock(&pipeMutex); return 0; } else { result = 0; *************** *** 2605,2611 **** */ CloseHandle(infoPtr->hProcess); - *prevPtrPtr = infoPtr->nextPtr; ckfree((char*)infoPtr); return result; --- 2613,2618 ---- ---------------------------------------------------------------------- Comment By: David Gravereaux (davygrvy) Date: 2004-01-18 12:42 Message: Logged In: YES user_id=7549 infoPtr is in some sort of uninitialized state. It looks like the problem might be in Tcl_WaitPid at the end of the function. During the mutex protected search, prevPtrPtr was valid at that moment in time. But after the wait to get the exit code, is it still valid? I don't think so. What we could do is splice this ProcInfo off prior to the wait and during the list lock, then reinsert for when the wait timedout. yahalom, could you attach a script that reproduces this if possible. ---------------------------------------------------------------------- Comment By: yahalom emet (yahalom) Date: 2004-01-18 05:42 Message: Logged In: YES user_id=130120 with symbols I get the exception in tclWinPipe.c line : if (infoPtr->hProcess == (HANDLE) pid) { the code: unsigned long TclpGetPid( Tcl_Pid pid) /* The HANDLE of the child process. */ { ProcInfo *infoPtr; Tcl_MutexLock(&pipeMutex); for (infoPtr = procList; infoPtr != NULL; infoPtr = infoPtr- >nextPtr) { if (infoPtr->hProcess == (HANDLE) pid) { Tcl_MutexUnlock(&pipeMutex); return infoPtr->dwProcessId; } } Tcl_MutexUnlock(&pipeMutex); return (unsigned long) -1; } is there more info needed. ---------------------------------------------------------------------- Comment By: David Gravereaux (davygrvy) Date: 2004-01-18 00:34 Message: Logged In: YES user_id=7549 Could you build for symbols and reproduce it? The position of the crash with a symbols build can get us to where that is in the code itself. ---------------------------------------------------------------------- Comment By: yahalom emet (yahalom) Date: 2004-01-17 23:11 Message: Logged In: YES user_id=130120 I do not use thread::transfer in my app. two different threads are opening/closing a pipe to the same program. there should be no problem with this but there is a crash. ---------------------------------------------------------------------- Comment By: David Gravereaux (davygrvy) Date: 2004-01-15 01:25 Message: Logged In: YES user_id=7549 If so, a patch can be found here: https://sourceforge.net/tracker/index.php? func=detail&aid=875701&group_id=10894&atid=310894 ---------------------------------------------------------------------- Comment By: David Gravereaux (davygrvy) Date: 2004-01-15 01:01 Message: Logged In: YES user_id=7549 > is the open/close pipe not thread safe? Are you using thread::transfer? pipe channels do not support cut/splice operations yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=859820&group_id=10894 |