Anonymous | Login | Signup for a new account | 2019-02-16 21:45 CET |
Main | My View | View Issues | Change Log | Roadmap | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | ||||||
ID | Category | Severity | Reproducibility | Date Submitted | Last Update | ||
0003301 | [JEDI VCL] 00 JVCL Components | major | always | 2005-11-04 06:29 | 2005-11-27 03:43 | ||
Reporter | Kiriakos | View Status | public | ||||
Assigned To | AHUser | ||||||
Priority | normal | Resolution | fixed | ||||
Status | resolved | Product Version | 3.00 | ||||
Summary | 0003301: Memory loss and crashes in JvChangeNotify | ||||||
Description |
I discovered the following problem with FastMM4: When the property FreeOnTerminate is True the JvChangeThread is not freed and crashes can occur. Analysis: Assume that in your program you so somewhere: JvChangeNotify.Active := False; // do something JvChangeNotify.Active := True; Setting Active to False will trigger the following code in TJvChangeNotify.SetActive: if FThread <> nil then begin FThread.Terminate; if FreeOnTerminate then FThread := nil else begin FThread.WaitFor; FreeAndNil(FThread); end; end; Whereas Seting Active to True will create a JvChangeThread and assign it to FThread; At the same time when the original JvChangeThread gets destroyed DoThreadTerminate is called which sets FThread to nil; This may well happen after the new JvChangeThread has been created. So FThread will be nil when the JvThread is actually alive and active. Next time you set the Active property to False the JvActiveThread will not be destoyed with the result of having multiple JvChangeThreads active. Solution: Remove DoThreadTerminate and all references to it. Further problems: When the JvChangeNotify gets destroyed is sets its Active property to false which will eventually destroy the JvChangeThread. However the destruction of the thread will happen after JvChangeNotify will have been destroyed. The Execute method of the thread will call its FNotify method which in turn calls the FNotify of the JvChangeNotify which will be an invalid pointer. Suggestion: In SetActive add the following line before calling FThread.Terminate; (2 places): FThread.OnChangeNotify := nil; For futher safety, in procedure TJvChangeThread.Execute modify the 5th line to if (I >= 0) and (I < FCount) and not Terminated then Even with the above suggestions there is still a chance when the Interval is long enough that TJvChangeThread.Execute will get stuck in WaitForMultipleObjects for too long and the main thread will have finished before this thread is finished. |
||||||
Additional Information | |||||||
Tags | No tags attached. | ||||||
Attached Files | |||||||
|
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |