I use Delphi2010 development program, which USES the TMS6.9 TAdvTrackBar control in the package, in Windows 7, doing all operating normally, but will lead to process on Windows XP cannot end, leading to subsequent unable to start the program, what is? Did anyone come across?
Thank you very much!
CodePudding user response:
Feel really want to is used in the DLL TAdvTrackBar reasons, for use in EXE is normal, please master answer,CodePudding user response:
Don't even need to use TAdvTrackBar this control, only need to add 'Uses AdvTrackBar' this statement will lead to this problem! Please answer, feel is a DLL release resources problem,CodePudding user response:
Hard to say, the problem, can only look at the original code, to analysis,CodePudding user response:
Find the following answers online, but how can I modify? TMS component is no source code!
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
If you're in the Windows platform development dynamic link library, and library's internal threads, launched the link then you will probably find your DLL loading program when to exit a deadlock, sometimes even though the main program interface, but open the task manager, found that the process is still there,
Recently do player plug-in development, based on directshow, VLC, mplayer framework, each made a plug-in, all three plug-in DLL library USES another media (Mylib. DLL), and by dynamic loading (LoadLibrary), using the DLL is more complex, the internal use of thread; Other directshow, VLC plugin itself is also a DLL, mplayer doesn't support dynamic plug-in, is a built-in source code to compile,
Without process exits against doing processing, three players (based on the tested GraphEidt directshow Player, Windows Media Player cannot exit normally,
By looking at the call stack, thread is in the Mylib. DLL finally unload, a global object DLLS destructor, waiting for an Event (Event) object does not return, and this Event should be set to have before another thread exit signal, but the entire process in addition to the main thread, other threads are over, suggesting that the thread is forced over, the main thread call stack display has entered the _ExitProcess, should be the main thread before this killed all the child thread,
Three player framework didn't find the exit mechanism of the announcement, so can think method only using atexit, at the end of the program to invoke a Mylib. Stop interface DLL (Mylib_Stop), there is no effect, still can't normal exit,
But is different from the above situation, mplayer or hang dead in Mylib. DLL global object in the destructor; Directshow and VLC is directly died in Mylib_Stop function, the call stack display is waiting for another thread to exit, but the thread where _ExitThread stuck,
To solve the deadlock problem in global object destructor, need to let the thread exits normally, rather than being forced termination, so you need to in front of the _ExitProcess uninstall Mylib. DLL, we put this task to atexit process, because atexit function in the main exit the main function is invoked, after modified, mplayer can really normal withdrew,
For directshow and VLC, is all in a plug-in DLL startup Mylib. DLL, we found that atexit registered function, is in the plug-in DLL when unloading is called, with DllMain function in the call stack, lenovo to perform DllMain function of some of the details, feel is should be the same: system in the calling DllMain will there be a global lock, the main thread has entered the DllMain, all locks have been combined with another thread exits will call DllMain, also need the lock, thus caused the main thread waiting for another thread to exit, and the thread is waiting for the main thread of locks, formed a deadlock situation,
Also use atexit registered in the DLL function, not as we hoped for when the process exits calls, and in the corresponding DLL call when unloading, it did not say the MSDN but by tracking to atexit, found is indeed a DLL or EXE respectively according to the processing, is also found in EXE _imp___onexit function,
Try substituting _imp___onexit atexit, compiled without problems, but running will crash, because registered exits function code is actually in the plug-in DLL, the DLL has unloaded before process exits, code page fails,
At the end of the day, we can only modify Mylib. DLL, remove the wait for events in the global variable destructor deadlocks, and do not use atexit, such can adapt to three players; Price is Mylib. The DLL is not normal is terminated, the inside of the thread is forcibly terminated, there may be some aftermath was unable to complete,
Summarized as follows: 1, with internal threads DLL to normal, need to export a exit function interface, and ask the caller to call at the appropriate time,
2, pay attention to the DLL global variables before the destructor, thread may have been forcibly terminated, if in the destructor rely on a thread to finish some work, is to consider this possibility, but directly waiting thread handle no problem
3, use atexit register functions in the DLL code, should not expect when the process exits is called, and whether the DLL or EXE code, a function of other modules can not be registered to atexit,
CodePudding user response:
May be the problem of GDI + and GDI + a ShutDown exit function, the unit will make the host program, the DLL reference, finally quit because the ShutDown closed recycling GDI + resources have led to the process card dead, there is a way, is the packaging, the unit of TMS GDI + in package, and then the host exe is the project of the master file head first recover GDI + resource references have the ShutDown function unit, and then the host and DLL project should carry this bag with GDI + is ok,