Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017 Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
<== Date ==> <== Thread ==>

Subject: Re: terminate called after throwing an instance of 'epicsMutex::invalidMutex'
From: Michael Davidsaver <mdavidsaver@gmail.com>
To: Marty Kraimer <mrkraimer@comcast.net>, Heinz Junkes <junkes@fhi-berlin.mpg.de>, core-talk@aps.anl.gov
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
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
ANJ, 06 Jun 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·