[Tcl-bugs] [ tcl-Bugs-1381436 ] threaded tcl crashes

[SourceForge.net <no...@so...>]

Bugs item #1381436, was opened at 2005-12-15 11:07
Message generated for change (Comment added) made by vasiljevic
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1381436&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: 48. Threading
Group: current: 8.4.12
Status: Open
Resolution: None
Priority: 8
Submitted By: yahalom emet (yahalom)
Assigned to: Zoran Vasiljevic (vasiljevic)
Summary: threaded tcl crashes

Initial Comment:
tcl:8.4.2.12
thread: 2.6.2
windows: server 2003
when using tcl many threads tcl crashes. 
0000: 41 70 70 6c 69 63 61 74   Applicat
0008: 69 6f 6e 20 46 61 69 6c   ion Fail
0010: 75 72 65 20 20 74 63 6c   ure  tcl
0018: 73 68 38 34 74 2e 65 78   sh84t.ex
0020: 65 20 38 2e 34 2e 32 2e   e 8.4.2.
0028: 31 32 20 69 6e 20 74 63   12 in tc
0030: 6c 38 34 74 2e 64 6c 6c   l84t.dll
0038: 20 38 2e 34 2e 32 2e 31    8.4.2.1
0040: 32 20 61 74 20 6f 66 66   2 at off
0048: 73 65 74 20 30 30 30 36   set 0006
0050: 62 33 64 63               b3dc    


this looks like the same phenomena I reported in the 
past on bug number 859820 submitted on 2003-12-14 
04:54.
locking the open/close pipe with tsv::lock stops the 
crash a thing which supports my assumption.
doesn't the patch that was created in the previous bug 
report inserted to the version?
I tried to apply the bug suggested on that bug but I 
still get the error. can a new patch be created?


 

----------------------------------------------------------------------

>Comment By: Zoran Vasiljevic (vasiljevic)
Date: 2006-01-15 10:30

Message:
Logged In: YES 
user_id=95086

Hey, no rush!
The file is: generic/tclIOUtil.c for core-8-4-branch

----------------------------------------------------------------------

Comment By: yahalom emet (yahalom)
Date: 2006-01-15 07:47

Message:
Logged In: YES 
user_id=130120

I have a bit of work pressure so it will take some time. 
what file should I checkout?

----------------------------------------------------------------------

Comment By: Zoran Vasiljevic (vasiljevic)
Date: 2006-01-14 20:28

Message:
Logged In: YES 
user_id=95086

I do not know if this applies here but I have commited a fix to core-8-4-branch
which closes a potential hole in TclVFS which MAY (not sure) be relevant to
the described problem.
Can you please checkout and try?


----------------------------------------------------------------------

Comment By: Zoran Vasiljevic (vasiljevic)
Date: 2006-01-11 15:52

Message:
Logged In: YES 
user_id=95086

Great. What a mess... 
Did you try compiling with VC6 but turning OFF compiler optimizations?

----------------------------------------------------------------------

Comment By: yahalom emet (yahalom)
Date: 2006-01-11 08:53

Message:
Logged In: YES 
user_id=130120

I compiled tcl with mingw and the crash does not happen. it 
seems that compiling threaded tcl with vc 6 does not work 
well on windows 2003. 

----------------------------------------------------------------------

Comment By: Zoran Vasiljevic (vasiljevic)
Date: 2005-12-20 15:45

Message:
Logged In: YES 
user_id=95086

Well, then it is pretty clear. The global "procList" is busted.
This is more difficult to trace as I'm not very familiar with 
the Windows sources. I will give it a try though.  

----------------------------------------------------------------------

Comment By: yahalom emet (yahalom)
Date: 2005-12-20 15:40

Message:
Logged In: YES 
user_id=130120

I still get an exception but this time in a different place.
   
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) {
		unsigned long processId = infoPtr-
>dwProcessId;
	    Tcl_MutexUnlock(&pipeMutex);
	    return processId;
	}
    }
    Tcl_MutexUnlock(&pipeMutex);
    return (unsigned long) -1;
}


----------------------------------------------------------------------

Comment By: Zoran Vasiljevic (vasiljevic)
Date: 2005-12-20 13:23

Message:
Logged In: YES 
user_id=95086

Hm.... this is bad. The mutex is released too early, referencing the 
infoPtr->dwProcessId w/o protection. I do not know if this is the
cause of the problem (have to examine that code more carefully)
but on the first glance I'd do:
	if (infoPtr->hProcess == (HANDLE) pid) {
            unsigned long processId = infoPtr->dwProcessId;
	    Tcl_MutexUnlock(&pipeMutex);
            return processId;
	}
   
If you do this in your copy, can you still reproduce the bug?


----------------------------------------------------------------------

Comment By: yahalom emet (yahalom)
Date: 2005-12-15 11:39

Message:
Logged In: YES 
user_id=130120

compiling with symbos this is what I get:
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;
}


the exception is on :return infoPtr->dwProcessId;


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1381436&group_id=10894