[PB 4.60] Thread safe crash my DLL (fred please read ^^)

PMV · **Posted:** Wed May 09, 2012 11:21 pm

Str(0) !

PB-Strings are Null-Terminated and if you are writing a
NULL into a string ... of course it will result in something wired
when PB is freeing this string. :lol:

If you search the forum a little bit of this topic, maybe you will
find more people having a wired crash because of a null-byte
plus threadsafe. :wink:

MFG PMV

srod · **Posted:** Wed May 09, 2012 11:43 pm

He is not writing a null. I think you are confusing Str(0) with Chr(0).

Danilo · **Joined:** Sat Apr 26, 2003 8:26 am **Posts:** 1290

Microsoft: Best Practices for Creating DLLs

Quote:

You should never perform the following tasks from within DllMain:

...
Call CreateThread. Creating a thread can work if you do not synchronize with other threads, but it is risky.
...
Use the memory management function from the dynamic C Run-Time (CRT). If the CRT DLL is not initialized,
calls to these functions can cause the process to crash.

AFAIK Str() relies on the MS Visual C Runtime (MSVCRT.dll), and it is possible this DLL is not initialized
for this new thread/DLL yet.

I think the same can happen on process detach, if some other DLLs are already unloaded. That's why
MSDN says for DllMain entry point:

Quote:

Because Kernel32.dll is guaranteed to be loaded in the process address space when the entry-point function is called,
calling functions in Kernel32.dll does not result in the DLL being used before its initialization code has been executed.
Therefore, the entry-point function can call functions in Kernel32.dll that do not load other DLLs.
For example, DllMain can create synchronization objects such as critical sections and mutexes, and use TLS.
Unfortunately, there is not a comprehensive list of safe functions in Kernel32.dll.

Calling functions that require DLLs other than Kernel32.dll may result in problems that are difficult to diagnose.
For example, calling User, Shell, and COM functions can cause access violation errors, because some functions
load other system components.
Conversely, calling functions such as these during termination can cause access violation errors because the
corresponding component may already have been unloaded or uninitialized.

Because DLL notifications are serialized, entry-point functions should not attempt to communicate with other threads or processes.
Deadlocks may occur as a result.

Maybe Fred wants to check if this is 100% correct with the internal PB management code for
threads and thread-safe string handling etc.

srod · **Posted:** Thu May 10, 2012 8:54 am

You just knew that creating a thread in the dll entry function would be, at best, risky!

Actually I recall now coming across this information (that posted by Danilo) before - perhaps in these forums? Funny the things you forget.

Thorium · **Joined:** Sat Aug 15, 2009 6:59 pm **Posts:** 1024

Danilo wrote:

AFAIK Str() relies on the MS Visual C Runtime (MSVCRT.dll), and it is possible this DLL is not initialized
for this new thread/DLL yet.

Thats not the problem. Even if you wait for the initialization to finish it crashes. And it crashes on unload, not on Str(). Str() works just fine.

I think srod was right, the problem is creating a thread before the TLS is initialized.
Without threadsafe activated it works without problems to create a thread and let it wait for the initialization to finish before it does anything else. I did that in GameFixer and all works fine. Even DirectDraw initialization works fine.
However, if i activate threadsafe it also gets unstable, just tested it.

So the rule is: Don't create threads in the AttachProcess procedure if you are using threadsafe.

I may change the way the thread in GameFixer is created, who knows what problems are still lurking related to that. ^^
I did it because it was the easiest way. Because the DLL is injected it's much more complicated to create the thread from the injector. Need to get the procedure address inside the games process and create another remote thread.

Thats how i wait for the initialization to finish:

Code:

Procedure InitCore(hAttachProcessThread.i)

  ;wait for AttachProcess thread to finish
  WaitForSingleObject_(hAttachProcessThread, #INFINITE)

EndProcedure

ProcedureDLL AttachProcess(Instance.i)

  Protected hAttachProcessThread.i
  Protected hProcess.i
  
  ;get the handle to the thread to enable the init procedure to wait for it's termination
  
  hProcess = GetCurrentProcess_()
  DuplicateHandle_(hProcess, GetCurrentThread_(), hProcess, @hAttachProcessThread, 0, #False, #DUPLICATE_SAME_ACCESS)

  CreateThread(@InitCore(), hAttachProcessThread)
  
EndProcedure

Phlos · **Joined:** Fri May 16, 2003 7:17 pm **Posts:** 67

Any news from fred ? :cry:

Zach · **Posted:** Sun May 20, 2012 11:08 pm

Perhaps should have posted in the Bug reports section, where he is more likely to see it, if this truly is a bug.

cas · **Joined:** Mon Nov 03, 2008 9:56 pm **Posts:** 444

Any news on this? Dll with threadsafe enabled causes crash when i exit application that loads that dll and i get error message from windows that says "Application has stopped working" and fault module name is mythreadsafelibrary.dll_unloaded. I dont get it always, its random - sometimes it crashes and sometimes it closes gracefully without error.
If i compile dll without threadsafe then it doesn't crash.
Dll is simple - i only set up some global fixed strings and there are 2 exported functions that return pointers to that strings.

RichAlgeni · **Posted:** Thu Jan 17, 2013 3:36 am

Post your code CAS. I remember this initial post, but wasn't sure about the code. Now that I have used dll's and threads extensively, I have to disagree with creating a thread in AttachProcess, IMHO. The only code I place in AttachProcess are initialization processes. I never create threads inside the dll, but constantly create threads that call dll procedures.

We may be able to help you with this issue.

PureBasic Forum

[PB 4.60] Thread safe crash my DLL (fred please read ^^)

Who is online