When to free the memory, or another things?
Re: When to free the memory, or another things?
Thank you all for your answers, I will investigate a little more to see if I find a valid solution
Re: When to free the memory, or another things?
Nothing clear about it I'm afraid since Caronte3D has not indicated whether the dll has been compiled with the threadsafe switch and so this may not even be an issue. I'm not saying that there isn't a bug in the threadsafe lib, but not clear in this case whether this could be the root cause. Over to Caronte3D!Both.
It has nothing to do with calling conventions, but it's clearly a bug in the threadsave library.
I may look like a mule, but I'm not a complete ass.
Re: When to free the memory, or another things?
Indeed, I was only referring to my experiences.srod wrote:Nothing clear about it I'm afraid since Caronte3D has not indicated whether the dll has been compiled with the threadsafe switch and so this may not even be an issue. I'm not saying that there isn't a bug in the threadsafe lib, but not clear in this case whether this could be the root cause. Over to Caronte3D!Both.
It has nothing to do with calling conventions, but it's clearly a bug in the threadsave library.
Re: When to free the memory, or another things?
I experienced an x86 stdcall dll crash on calls to closelibrary() in detach().
The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
Re: When to free the memory, or another things?
If you mean that you call closelibrary in detach_process, then that's a no go.skywalk wrote:I experienced an x86 stdcall dll crash on calls to closelibrary() in detach().
See https://docs.microsoft.com/en-us/window ... t-function
The entry-point function should perform only simple initialization tasks. It must not call the LoadLibrary or LoadLibraryEx function (or a function that calls these functions), because this may create dependency loops in the DLL load order. This can result in a DLL being used before the system has executed its initialization code. Similarly, the entry-point function must not call the FreeLibrary function (or a function that calls FreeLibrary) during process termination, because this can result in a DLL being used after the system has executed its termination code.
Re: When to free the memory, or another things?
Yes, the dll has been compiled with the threadsafe switch because I create several threads from the dll.srod wrote:Nothing clear about it I'm afraid since Caronte3D has not indicated whether the dll has been compiled with the threadsafe switch and so this may not even be an issue.
Re: When to free the memory, or another things?
Thanks, I learned that the hard way. Dropped the closelibrary() calls and all good.sq4 wrote:If you mean that you call closelibrary in detach_process, then that's a no go.skywalk wrote:I experienced an x86 stdcall dll crash on calls to closelibrary() in detach().
See https://docs.microsoft.com/en-us/window ... t-function
But, the dll had to call load library Not sure what they mean by that.The entry-point function should perform only simple initialization tasks. It must not call the LoadLibrary or LoadLibraryEx function...
The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
-
- Always Here
- Posts: 6425
- Joined: Fri Oct 23, 2009 2:33 am
- Location: Wales, UK
- Contact:
Re: When to free the memory, or another things?
@skywalk
I think what MS are saying is that the DLL should not be loaded during the time the Program is started. It can be loaded later, on demand. Likewise, the DLL should not be closed or freed at the same time as the Program - so when the Program is closed, that needs careful management, it can't just be exited when WaitWindowEvent() = #PB_Event_CloseWindow for example. The snag is, most times you will only want to close the lib when the User wants to close the Program, so the Program needs to know if and when the DLL is fully released before closing itself.
I think what MS are saying is that the DLL should not be loaded during the time the Program is started. It can be loaded later, on demand. Likewise, the DLL should not be closed or freed at the same time as the Program - so when the Program is closed, that needs careful management, it can't just be exited when WaitWindowEvent() = #PB_Event_CloseWindow for example. The snag is, most times you will only want to close the lib when the User wants to close the Program, so the Program needs to know if and when the DLL is fully released before closing itself.
IdeasVacuum
If it sounds simple, you have not grasped the complexity.
If it sounds simple, you have not grasped the complexity.
Re: When to free the memory, or another things?
In which case it looks like you have probably run up against the same bug/issue that sq4 has mentioned. You might want to try and remove the threadsafe option and employ your own thread protection mechanisms (mutex, semaphore etc.) The biggest problem might be avoiding the use of PB's string library as this is not threadsafe without the threadsafe compiler switch. Try and avoid using strings in the dll threads (main dll process is fine) - perhaps use memory buffers/pointers instead. I'm sure sq4 can advise given his experience with this issue.Caronte3D wrote:Yes, the dll has been compiled with the threadsafe switch because I create several threads from the dll.srod wrote:Nothing clear about it I'm afraid since Caronte3D has not indicated whether the dll has been compiled with the threadsafe switch and so this may not even be an issue.
I may look like a mule, but I'm not a complete ass.
Re: When to free the memory, or another things?
I use too much strings at the moment and I'm in a hurry to finish I will take a look again when finish this project.
Thanks!
Thanks!