From: <no...@so...> - 2001-05-10 03:04:48
|
Bugs item #217982, was updated on 2000-10-25 17:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110894&aid=217982&group_id=10894 Category: Threading Group: 8.3.1 Status: Open Resolution: Fixed >Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Exception caused by NULL pointer Initial Comment: OriginalBugID: 5804 Bug Version: 8.3.1 SubmitDate: '2000-06-02' LastModified: '2000-09-01' Severity: CRIT Status: Closed Submitter: techsupp ChangedBy: davidg RelatedBugIDs: 5312 OS: Windows NT OSVersion: NT 4.0 SP5 and Windows 2000 Professional Machine: Pentium III 600Mhz with 128MB FixedDate: '2000-09-01' ClosedDate: '2000-10-25' Name: Hugh Vu Extensions: No extension ReproducibleScript: I am using embedded TCL in my application. I had no problem with 8.2.1 but when I imported 8.3.1 into my application, the following problem occurred: When I closed my application, Windows popped up an error message that reads "The instruction at 0x77f87808 referenced memory at 0x00000010. The memory could not be read." Using the Visual C++ debugger, I found that on closing, the TCL DLL detached by callling Tcl_Finalize() -> Tcl_FinalizeThread() -> TclFinalizeNotifier() -> Tcl_FinalizeNotifier(0). Since the parameter "clientData" passed to Tcl_FinalizeNotifier is 0, the function DeleteCriticalSection crashed with Access Violation (tsdPtr = NULL). I have no idea why "clientData" value is 0. Are you aware of any problem or issue resembling this problem I described above? I don't know if this is caused by my application or a bug in 8.3.1. Any comment from you will be greatly appreciated. *** win/tclWinNotify.c 1999/07/02 22:08:28 1.5 --- win/tclWinNotify.c 2000/06/05 00:50:37 *************** *** 150,155 **** --- 150,163 ---- { ThreadSpecificData *tsdPtr = (ThreadSpecificData *) clientData; + /* + * Should the operating system call DllMain with + * DLL_PROCESS_DETACH from any alternate thread path, such + * as Task Manager terminating the process, tsdPtr will + * be NULL and invalid. + */ + if (tsdPtr == NULL) return; + DeleteCriticalSection(&tsdPtr->crit); CloseHandle(tsdPtr->event); Try this. I noticed the same thing with a threaded build. -- 07/25/2000 davidg recent comments by email: To: su...@aj..., gl...@ci... Subject: RE: TR#5804 From: Gene Leache <gl...@ci...> Date: Thu, 03 Aug 2000 12:10:20 -0400 RE bug report TR#5804: Possibly you folks have done further analysis on this bug, possibly not. I've been wrestling with it since yesterday, and realized this morning that as NT Thread-Local-Storage (TLS) is used by tcllib, anytime that a thread other than the initiator causes tcllib to be deinitialized, the expected data in TLS will not be found, causing tcllib to initialize the TLS data to zero. The result (as described in the bug report) is that the clientData parameter passed to Tcl_FinalizeNotifier is zero, causing the access violation. Since the expected datum is just a pointer to an in-memory structure (whose contents appear to be correct), I was able to use Windbg to supply the expected datum to Tcl_FinalizeNotifier, and allow program execution to proceed -- tcllib was deinitizialized correctly after doing this experiment. Hope this helps, Gene Gene, thanks for the comment. -- 08/03/2000 davidg ---------------------------------------------------------------------- Comment By: David Gravereaux (davygrvy) Date: 2001-05-09 20:02 Message: Logged In: YES user_id=7549 The patch has not been applied to the core (yet). ---------------------------------------------------------------------- Comment By: David Gravereaux (davygrvy) Date: 2001-05-09 19:56 Message: Logged In: YES user_id=7549 This bug relates to 219355 as well. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110894&aid=217982&group_id=10894 |