[VSDK] Semaphore freeze after a crash

[Eric Forget]

Hi Ruslan,
Hi Totte,

>> #0    0x90017048 in semaphore_wait_signal_trap
>> #1    0x90002300 in pthread_mutex_lock
>> #2    0xb0041028 in FBL_IndexerTask::Run()
> 
> 1) You both use VSDK.framework made with xCode.

...And we both build with __MACH__ defined
 
> 2) This framework is built with FBL_SyncObjectsMac.cpp file.

...And with FBL_SyncObjectsMac.h inlined functions
 
> 3) you can see sources of all my Thread classes in the VSDK_MAC archive.

Yes and No. We do not have FBL_IndexerTask::Run() which cause the problem!!!
 
> 4) you can see that in file FBL_SyncObjectsMac.cpp I do not use pthreads
>   directly. 
>  
>   I call CARBON thread API as ::YieldToAnyThread();

That's true. However, in FBL_SyncObjectsMac.h you make use of it.
 
> 5) in the crash log we see call to pthread_mutex_lock
>   
>   I assume Apple call it in background.
> 
> This is why, Totte, I cannot add that parameter
> to mutex to make it REENTRANT.
> This is NOT MY mutex.

This is your mutex. Check 4)
 
> 6) Totte, I did offer you one way to solve this:
>   
> -- framework include already compiled file FBL_SyncObjectsMac.cpp
> 
> -- but at least in Visual C++, it is possible to include cpp file again into
> project, even it is already compiled into some DLL. May be xCode also allow
> such trick.
> 
> So you need to try include FBL_SyncObjectsMac.cpp file into YOUR project.
> Visual in this case simply say:
>   2 definitions of function found. Second is ignored.
> 
> 
> IF this trick works you can
> A) DEBUG when and how my functions are called.
> B) may be you can simply comment out call ::YieldToAnyThread();
>   for YOUR project and may be this will make a trick.

I don't know if xCode support that but it will be useless in our case since
the call is inlined. We will need all the code source that use FBL_MutexMac.
 
> 7) I really do not want spend time on this now, if above workaround will
> work. In 2.0 we will have pthreads for OS X Valentina engine.

For me it is now a show stopper. I have 2 different cases where my
application freeze. Maybe it is becoming more apparent with 10.3.2, I don't
know.

BTW, I found 2 problems with your code by just compiling it:

1) In FBL_MutexMac::Lock():
FBL_SyncObjectsMac.h:54: control reaches end of non-void function
FBL_SyncObjectsMac.h:54: no return statement in function returning non-void

2) In FBL_SemaphoreMac::Lock():
FBL_SyncObjectsMac.cpp:182: comparison between signed and unsigned integer
expressions

Maybe you should enable more warnings when you compiles...

I hope you will be able to solve that...

Éric


___________________________________________________________________

 Eric Forget                       Cafederic
 ForgetE at cafederic.com             <http://www.cafederic.com/>

 Fingerprint <86D5 38F5 E1FD 5D9C 71C3  BAA3 797E 70A4 6210 C684>