EPICS Home

Experimental Physics and Industrial Control System


 
2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017>  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017>  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>
Subject: Re: terminate called after throwing an instance of 'epicsMutex::invalidMutex'
From: Michael Davidsaver <[email protected]>
To: Marty Kraimer <[email protected]>, Heinz Junkes <[email protected]>, [email protected]
Date: Tue, 6 Jun 2017 11:05:08 +0200 
On 06/04/2017 09:16 PM, Marty Kraimer wrote:
> On 06/04/2017 01:32 PM, Heinz Junkes wrote:
>> I replaced pvaClientCPP and pvAccessCPP with the code you provide
>>
>> Now the tests runs without error:
> 
> Good news!!!
> 
> I did make some more changes to
> https://github.com/mrkraimer/pvAccessCPP/
> 
> The changes resulted from suggestions made by Michael Davidsaver.

Well, at least some of them.

FYI. this is what I'm doing

https://github.com/mdavidsaver/pvAccessCPP/commit/6926d911eeb1b8ccb4da14ed7717f381379a7434

This is only the first part though, dealing with the problems in
caProvider.cpp.

The larger issue I see is that the "conventional" implementations of
ChannelProviderFactory::sharedInstance() has the factory keep a strong
ChannelProvider reference.

For my work on P4P server side this was causing problems as all python
objects should be destroyed well before the global provider factory
map<> is destroyed.  This resulted in an attempt to take the GIL after
it had been free'd.  So if a removeProvider() is omitted, then the
process crashes on exit.

My first change is to turn this strong ref. into a weak ref.  This means
that destruction of the registry no longer has side-effects related to
provider destruction.

In clearing up some potential global ctor/dtor ordering issues, the
global registry (a la. getChannelProviderRegistry() ) is no longer
free'd.  As it hold only weak refs. there seemed to me no downside other
than a "reachable" leak.
Replies:
Re: terminate called after throwing an instance of 'epicsMutex::invalidMutex' Marty Kraimer
References:
terminate called after throwing an instance of 'epicsMutex::invalidMutex' Heinz Junkes
Re: terminate called after throwing an instance of 'epicsMutex::invalidMutex' Marty Kraimer
Re: terminate called after throwing an instance of 'epicsMutex::invalidMutex' Heinz Junkes
Re: terminate called after throwing an instance of 'epicsMutex::invalidMutex' Marty Kraimer
Navigate by Date:
Prev: RE: Build problem Mark Rivers
Next: Re: terminate called after throwing an instance of 'epicsMutex::invalidMutex' Marty Kraimer
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017>  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: terminate called after throwing an instance of 'epicsMutex::invalidMutex' Marty Kraimer
Next: Re: terminate called after throwing an instance of 'epicsMutex::invalidMutex' Marty Kraimer
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017>  2018  2019  2020  2021  2022  2023  2024