Re: Finalizers are dangerous

Bill Torpey


Thanks for the suggestion, but that is basically doing C-style manual memory management. That’s not a direction I’m interested in going — it’s the 21st century, and OpenMAMA needs to get with the program if it wants to be a viable platform for modern systems.



On Dec 28, 2017, at 10:17 AM, Sanjeev Wahi <sawahi@...> wrote:

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
sp->defrangulate(); // tell the Thing to do something
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@... [mailto:openmama-dev-bounces@...] On Behalf Of Bill Torpey
Sent: Thursday, December 28, 2017 9:39 AM
To: Yury Batrakov <yury.batrakov@...>
Cc: openmama-dev <openmama-dev@...>
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:

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) {

getMessage(); // Creating MamaMsg object without reference

Mama.close(); // Payload bridge is destroyed here
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 for additional EU corporate and regulatory disclosures and to for information about privacy.
Openmama-dev mailing list
Openmama-dev mailing list

Join to automatically receive all group messages.