I can suggest a possible fix (by adding extra weak_ptr check) while calling Mama.close()  that can avoid this problem in C11/C11++ when using shared_ptr.
*(assumption is Mama.close() is not called by many threads same time, in that case also use C11 atomic integer counter with this code)

*( I do not know much Java but something similar would work).



1st Approach:
Gat a new shared_ptr, but test for whether it is empty or pointing to something by testing
it for true/false, analogous to what we would do with a built-in pointer that might be zero:

void do_it(weak_ptr<Thing> wp){
        shared_ptr<Thing> sp = wp.lock(); // get shared_ptr from weak_ptr
        if(sp)
                sp->defrangulate(); // tell the Thing to do something
        else
                cout << "The Thing is gone!" << endl;
}



2nd Approach:
We can ask the weak_ptr if it has "expired":

bool is_it_there(weak_ptr<Thing> wp) {
        if(wp.expired()) {
                cout << "The Thing is gone!" << endl;
                return false;
        }
return true;
}





-Sanjeev Wahi

-----Original Message-----
From: openmama-dev-bounces@lists.openmama.org [mailto:openmama-dev-bounces@lists.openmama.org] On Behalf Of Bill Torpey
Sent: Thursday, December 28, 2017 9:39 AM
To: Yury Batrakov <yury.batrakov@...>
Cc: openmama-dev <openmama-dev@....org>
Subject: Re: [Openmama-dev] Finalizers are dangerous

Unfortunately, that is not a bug, but a “feature”.

The problem is that mama_close unloads both the transport and payload libraries (via dlclose on Linux).  So, any access to any objects related to either library following mama_close is guaranteed to crash.

This makes OpenMAMA completely unusable for GC languages like Java, and presumably .Net, as well as for reference-counted implementations in other languages (e.g., shared_ptr in C++).

I’ve argued this point with Frank, but so far to no avail:  https://github.com/OpenMAMA/OpenMAMA/issues/264

Perhaps if enough people chime in, we can change Frank’s mind.  Until that time, the only solution I can think of is to fork OpenMAMA and remove or replace the offending code.  That is not a great solution, but as I mention in the bug report, this behavior is a total non-starter for me (and presumably for others as well).


> On Dec 28, 2017, at 6:08 AM, Yury Batrakov <yury.batrakov@...> wrote:
>
> Classification: Public
> Hi team,
>
> Sorry for telling bad news in holidays but I have found a major issue with Java API - JVM may crash if GC comes after Mama.close() method. Here's code sample to reproduce it:
>
> import com.wombat.mama.Mama;
> import com.wombat.mama.MamaMsg;
>
> public class Test {
>    private static MamaMsg getMessage() {
>        return new MamaMsg();
>    }
>
>    public static void main(String[] args) {
>        Mama.loadBridge("...");
>        Mama.open();
>
>        getMessage(); // Creating MamaMsg object without reference
>
>        Mama.close(); // Payload bridge is destroyed here
>        System.gc();
>        System.runFinalization(); // Calling MamaMsg.destroy() which delegates the destruction to deleted payload bridge
>    }
> }
>
> Stack trace:
> #12 0x00007fc494a095f0 in ?? ()
> #13 0x00007fc496ac1cf4 in mamaMsg_destroy (msg=0x7fc4900c90a0) at mama/c_cpp/src/c/msg.c:127
> #14 0x00007fc496d70b7f in Java_com_wombat_mama_MamaMsg__1destroy (env=0x7fc4b00039f8, this=0x7fc49779d710) at mama/jni/src/c/mamamsgjni.c:3882
> #15 0x00007fc4bae7e494 in ?? ()
>
> Problematic frame:
> #13 0x00007fc496ac1cf4 in mamaMsg_destroy (msg=0x7fc4900c90a0) at mama/c_cpp/src/c/msg.c:127
> 127             if (MAMA_STATUS_OK != impl->mPayloadBridge->msgPayloadDestroy (impl->mPayload))
>
> impl->mPayloadBridge is destroyed here.
>
> Similar crash occurs when finalizing subscriptions - they also need entitlements bridge to be available but Mama.close() deletes it too.
>
> The workaround is to call destroy() method for each message/subscription created but this actually nullifies the need for finalize() methods. I would delete all them from MAMA code.
>
>
> ---
> This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
>
> Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.
> _______________________________________________
> Openmama-dev mailing list
> Openmama-dev@....org
> https://lists.openmama.org/mailman/listinfo/openmama-dev

_______________________________________________
Openmama-dev mailing list
Openmama-dev@....org
https://lists.openmama.org/mailman/listinfo/openmama-dev

_______________________________________________
Openmama-dev mailing list
Openmama-dev@....org
https://lists.openmama.org/mailman/listinfo/openmama-dev