Date   

Re: Finalizers are dangerous

Bill Torpey
 

See comments inline …

On Dec 28, 2017, at 11:07 AM, Frank Quinn <frank@...> wrote:

Hi Bill,

We close the bridges because we leak memory if we dont.

No, we shut down the bridges to prevent events from firing.  In some cases (and certainly *not* all) that also releases resources acquired when the bridges were opened, which is a Good Thing.


Imho leaking memory should be avoided where possible. In this case, its avoidable, so I don't think we should do it.

It’s not up to you.  As I said before, it’s my application, and I get to decide what leaks are worth worrying about.  One-time leaks that don’t grow over time don’t concern me, and the cost of eliminating them is not worth it in almost all cases.  (Again, that’s my choice — “Perfect is the enemy of good enough”).


If you really want control and are happy to leak memory, just don't call mama_close(),

As you are well aware, that is not a solution — it doesn’t stop events from firing, which is the real reason for shutting down the transport.

or we can look at that configuration option I suggested (though it will need to avoid freeing the bridges too - not just avoid dlclosing).

What configuration option is that?  How would it work?  


In terms of the actual fix, as I said, I haven't gotten around to it yet. I know how to fix it, I just haven't had the chance, nor have any volunteers come forward to pick it up.

I would be happy to submit a PR, but it doesn’t sound like it would be accepted.  If we can agree on an approach I’ll see what I can come up with.

In the meantime I gave up and forked the code.  As project maintainer I don’t imagine that’s what you want, but you’re not giving me a choice.


Cheers,
Frank


On 28 Dec 2017 15:49, "Bill Torpey" <wallstprog@...> wrote:
HI Frank:

And Happy Holidays to you too!

A couple of points:

  • I’m not aware of any changes to OpenMAMA that affect the issue, so if there are some please point me in the proper direction.  The last reply from you was back in May.
  • As the application developer I get to decide which leaks are acceptable to me, and which are not.  Taking that choice away from me is not OK.
  • You’re confusing and/or conflating the shutdown of the bridge libraries with the unloading of those libraries from memory.  
    • It is not necessary to unload the libraries in order to shut them down:
      • The transport library can be shut down without being unloaded from memory.
      • The payload library doesn’t need to be shut down at all, since it never fires any events.
    • The only reason I can think of for dynamically unloading the libraries is to support some kind of dynamic switching of transports and/or payloads.  I suspect that this feature is an example of YAGNI, but even there is a reasonable use for this feature, forcing the vast majority of applications that don’t need it to pay the price for it is a bad design decision.

Short version, it’s my application, and I get to decide how I want it to behave. 

Best Regards,

Bill 

On Dec 28, 2017, at 10:33 AM, Frank Quinn <frank@...> wrote:

Happy holidays folks!

First of all (with respect to the C++ concerns), that ticket is still open - I plan on actioning it I just haven't had time yet.

My suggestions were far from "don't solve it" and was instead was more like "let's not annoy every developer of OpenMAMA by leaking memory every single time they close their application" which is what was suggested. My opinion was that if there was an alternative, we should do that. If there was no alternative, we can reassess. Fortunately in this case there is an alternative since it's possible (thanks to last year's bridge changes) to programatically check if a specific bridge is still open in the finalizer / destructor and therefore not attempt to access the bridge if it has been unloaded. This is clean, unobtrusive and lightweight.

I also suggested a configuration option to optionally leave the payload bridge open (though as mentioned in the ticket if its memory is tied to the middleware bridge, it could crash anyway).

I would suggest a similar approach in Java - let the language specific layer deal with the language specific nuances. We can avoid crashes with code changes in OpenMAMA here fairly easily.

Cheers,
Frank


On Thu, Dec 28, 2017 at 3:17 PM, 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
        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@...nmama.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@...rg>
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@...g
> https://lists.openmama.org/mailman/listinfo/openmama-dev

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

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





Re: Finalizers are dangerous

Frank Quinn
 

@Yury: The short answer is that we can't, but we can check if a bridge is still open before attempting to access bridge dependant methods in finalisers / destructors which was my suggestion.

On 28 Dec 2017 15:56, "Yury Batrakov" <yury.batrakov@...> wrote:

Classification: Public

Hi Frank,

 

> I would suggest a similar approach in Java - let the language specific layer deal with the language specific nuances.

 

What is the idea on how to avoid this in Java? How can we make sure that no Mama.close() calls were made before GC comes to finalize an object?

 

 

From: Frank Quinn [mailto:frank@...]
Sent: Thursday, December 28, 2017 6:33 PM
To: Sanjeev Wahi <sawahi@...>
Cc: Bill Torpey <wallstprog@...>; Yury Batrakov <yury.batrakov@...>; openmama-dev <openmama-dev@....org>


Subject: Re: [Openmama-dev] Finalizers are dangerous

 

Happy holidays folks!

 

First of all (with respect to the C++ concerns), that ticket is still open - I plan on actioning it I just haven't had time yet.

 

My suggestions were far from "don't solve it" and was instead was more like "let's not annoy every developer of OpenMAMA by leaking memory every single time they close their application" which is what was suggested. My opinion was that if there was an alternative, we should do that. If there was no alternative, we can reassess. Fortunately in this case there is an alternative since it's possible (thanks to last year's bridge changes) to programatically check if a specific bridge is still open in the finalizer / destructor and therefore not attempt to access the bridge if it has been unloaded. This is clean, unobtrusive and lightweight.

 

I also suggested a configuration option to optionally leave the payload bridge open (though as mentioned in the ticket if its memory is tied to the middleware bridge, it could crash anyway).

 

I would suggest a similar approach in Java - let the language specific layer deal with the language specific nuances. We can avoid crashes with code changes in OpenMAMA here fairly easily.

 

Cheers,

Frank

 

 

On Thu, Dec 28, 2017 at 3:17 PM, 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
        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

 



---
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.


Re: Finalizers are dangerous

Frank Quinn
 

Hi Bill,

We close the bridges because we leak memory if we dont. Imho leaking memory should be avoided where possible. In this case, its avoidable, so I don't think we should do it.

If you really want control and are happy to leak memory, just don't call mama_close(), or we can look at that configuration option I suggested (though it will need to avoid freeing the bridges too - not just avoid dlclosing).

In terms of the actual fix, as I said, I haven't gotten around to it yet. I know how to fix it, I just haven't had the chance, nor have any volunteers come forward to pick it up.

Cheers,
Frank


On 28 Dec 2017 15:49, "Bill Torpey" <wallstprog@...> wrote:
HI Frank:

And Happy Holidays to you too!

A couple of points:

  • I’m not aware of any changes to OpenMAMA that affect the issue, so if there are some please point me in the proper direction.  The last reply from you was back in May.
  • As the application developer I get to decide which leaks are acceptable to me, and which are not.  Taking that choice away from me is not OK.
  • You’re confusing and/or conflating the shutdown of the bridge libraries with the unloading of those libraries from memory.  
    • It is not necessary to unload the libraries in order to shut them down:
      • The transport library can be shut down without being unloaded from memory.
      • The payload library doesn’t need to be shut down at all, since it never fires any events.
    • The only reason I can think of for dynamically unloading the libraries is to support some kind of dynamic switching of transports and/or payloads.  I suspect that this feature is an example of YAGNI, but even there is a reasonable use for this feature, forcing the vast majority of applications that don’t need it to pay the price for it is a bad design decision.

Short version, it’s my application, and I get to decide how I want it to behave. 

Best Regards,

Bill 

On Dec 28, 2017, at 10:33 AM, Frank Quinn <frank@...> wrote:

Happy holidays folks!

First of all (with respect to the C++ concerns), that ticket is still open - I plan on actioning it I just haven't had time yet.

My suggestions were far from "don't solve it" and was instead was more like "let's not annoy every developer of OpenMAMA by leaking memory every single time they close their application" which is what was suggested. My opinion was that if there was an alternative, we should do that. If there was no alternative, we can reassess. Fortunately in this case there is an alternative since it's possible (thanks to last year's bridge changes) to programatically check if a specific bridge is still open in the finalizer / destructor and therefore not attempt to access the bridge if it has been unloaded. This is clean, unobtrusive and lightweight.

I also suggested a configuration option to optionally leave the payload bridge open (though as mentioned in the ticket if its memory is tied to the middleware bridge, it could crash anyway).

I would suggest a similar approach in Java - let the language specific layer deal with the language specific nuances. We can avoid crashes with code changes in OpenMAMA here fairly easily.

Cheers,
Frank


On Thu, Dec 28, 2017 at 3:17 PM, 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
        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@...nmama.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@...rg>
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@...g
> https://lists.openmama.org/mailman/listinfo/openmama-dev

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

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




Re: Finalizers are dangerous

Yury Batrakov
 

Classification: Public

Hi Frank,

 

> I would suggest a similar approach in Java - let the language specific layer deal with the language specific nuances.

 

What is the idea on how to avoid this in Java? How can we make sure that no Mama.close() calls were made before GC comes to finalize an object?

 

 

From: Frank Quinn [mailto:frank@...]
Sent: Thursday, December 28, 2017 6:33 PM
To: Sanjeev Wahi <sawahi@...>
Cc: Bill Torpey <wallstprog@...>; Yury Batrakov <yury.batrakov@...>; openmama-dev <openmama-dev@...>
Subject: Re: [Openmama-dev] Finalizers are dangerous

 

Happy holidays folks!

 

First of all (with respect to the C++ concerns), that ticket is still open - I plan on actioning it I just haven't had time yet.

 

My suggestions were far from "don't solve it" and was instead was more like "let's not annoy every developer of OpenMAMA by leaking memory every single time they close their application" which is what was suggested. My opinion was that if there was an alternative, we should do that. If there was no alternative, we can reassess. Fortunately in this case there is an alternative since it's possible (thanks to last year's bridge changes) to programatically check if a specific bridge is still open in the finalizer / destructor and therefore not attempt to access the bridge if it has been unloaded. This is clean, unobtrusive and lightweight.

 

I also suggested a configuration option to optionally leave the payload bridge open (though as mentioned in the ticket if its memory is tied to the middleware bridge, it could crash anyway).

 

I would suggest a similar approach in Java - let the language specific layer deal with the language specific nuances. We can avoid crashes with code changes in OpenMAMA here fairly easily.

 

Cheers,

Frank

 

 

On Thu, Dec 28, 2017 at 3:17 PM, 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
        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@... [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:  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@...
> https://lists.openmama.org/mailman/listinfo/openmama-dev

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

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

 



---
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.


Re: Finalizers are dangerous

Bill Torpey
 

HI Frank:

And Happy Holidays to you too!

A couple of points:

  • I’m not aware of any changes to OpenMAMA that affect the issue, so if there are some please point me in the proper direction.  The last reply from you was back in May.
  • As the application developer I get to decide which leaks are acceptable to me, and which are not.  Taking that choice away from me is not OK.
  • You’re confusing and/or conflating the shutdown of the bridge libraries with the unloading of those libraries from memory.  
    • It is not necessary to unload the libraries in order to shut them down:
      • The transport library can be shut down without being unloaded from memory.
      • The payload library doesn’t need to be shut down at all, since it never fires any events.
    • The only reason I can think of for dynamically unloading the libraries is to support some kind of dynamic switching of transports and/or payloads.  I suspect that this feature is an example of YAGNI, but even there is a reasonable use for this feature, forcing the vast majority of applications that don’t need it to pay the price for it is a bad design decision.

Short version, it’s my application, and I get to decide how I want it to behave. 

Best Regards,

Bill 

On Dec 28, 2017, at 10:33 AM, Frank Quinn <frank@...> wrote:

Happy holidays folks!

First of all (with respect to the C++ concerns), that ticket is still open - I plan on actioning it I just haven't had time yet.

My suggestions were far from "don't solve it" and was instead was more like "let's not annoy every developer of OpenMAMA by leaking memory every single time they close their application" which is what was suggested. My opinion was that if there was an alternative, we should do that. If there was no alternative, we can reassess. Fortunately in this case there is an alternative since it's possible (thanks to last year's bridge changes) to programatically check if a specific bridge is still open in the finalizer / destructor and therefore not attempt to access the bridge if it has been unloaded. This is clean, unobtrusive and lightweight.

I also suggested a configuration option to optionally leave the payload bridge open (though as mentioned in the ticket if its memory is tied to the middleware bridge, it could crash anyway).

I would suggest a similar approach in Java - let the language specific layer deal with the language specific nuances. We can avoid crashes with code changes in OpenMAMA here fairly easily.

Cheers,
Frank


On Thu, Dec 28, 2017 at 3:17 PM, 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
        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



Re: Finalizers are dangerous

Yury Batrakov
 

Classification: Public
It is possible to group all mama objects (transports, subscriptions...) in one class and let it's destructor to delete them in required order. Obviously this class shouldn't let others to access any them. Something like:

class MamaHolder
{
// public interface
private:
MamaOpenCloseHolder openclose;
MamaTransport transport;
MamaSubscription subscription;
...
};

class MamaOpenCloseHolder {
...
~ MamaOpenCloseHolder() {
Mama.close();
}
};

When MamaHolder is deleted, first object to delete will be subscription, then transport, then openclose which will call Mama.close

Unfortunately this is impossible for Java when Mama objects are shared with Finalizer thread which may destroy objects at any moment.

-----Original Message-----
From: Bill Torpey [mailto:wallstprog@gmail.com]
Sent: Thursday, December 28, 2017 6:23 PM
To: Sanjeev Wahi <sawahi@gmail.com>
Cc: Yury Batrakov <yury.batrakov@db.com>; openmama-dev <openmama-dev@lists.openmama.org>
Subject: Re: [Openmama-dev] Finalizers are dangerous

Sanjeev:

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.

Regards,

Bill


On Dec 28, 2017, at 10:17 AM, Sanjeev Wahi <sawahi@gmail.com> 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
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@db.com>
Cc: openmama-dev <openmama-dev@lists.openmama.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@db.com> 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@lists.openmama.org
https://lists.openmama.org/mailman/listinfo/openmama-dev
_______________________________________________
Openmama-dev mailing list
Openmama-dev@lists.openmama.org
https://lists.openmama.org/mailman/listinfo/openmama-dev


---
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.


Re: Finalizers are dangerous

Sanjeev Wahi
 

Not sure about the other alternative?
Are you expecting OpenMAMA C-API to keep track of all GC objects like shared_ptr ?
*(Keeping a table of active objects for clean-up at Mama.close() may also add overhead, which can be debated from performance point of view ?)

-Regards,
Sanjeev

-----Original Message-----
From: Bill Torpey [mailto:wallstprog@gmail.com]
Sent: Thursday, December 28, 2017 10:23 AM
To: Sanjeev Wahi <sawahi@gmail.com>
Cc: Yury Batrakov <yury.batrakov@db.com>; openmama-dev <openmama-dev@lists.openmama.org>
Subject: Re: [Openmama-dev] Finalizers are dangerous

Sanjeev:

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.

Regards,

Bill


On Dec 28, 2017, at 10:17 AM, Sanjeev Wahi <sawahi@gmail.com> 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
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@db.com>
Cc: openmama-dev <openmama-dev@lists.openmama.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@db.com> 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@lists.openmama.org
https://lists.openmama.org/mailman/listinfo/openmama-dev
_______________________________________________
Openmama-dev mailing list
Openmama-dev@lists.openmama.org
https://lists.openmama.org/mailman/listinfo/openmama-dev


Re: Finalizers are dangerous

Frank Quinn
 

Happy holidays folks!

First of all (with respect to the C++ concerns), that ticket is still open - I plan on actioning it I just haven't had time yet.

My suggestions were far from "don't solve it" and was instead was more like "let's not annoy every developer of OpenMAMA by leaking memory every single time they close their application" which is what was suggested. My opinion was that if there was an alternative, we should do that. If there was no alternative, we can reassess. Fortunately in this case there is an alternative since it's possible (thanks to last year's bridge changes) to programatically check if a specific bridge is still open in the finalizer / destructor and therefore not attempt to access the bridge if it has been unloaded. This is clean, unobtrusive and lightweight.

I also suggested a configuration option to optionally leave the payload bridge open (though as mentioned in the ticket if its memory is tied to the middleware bridge, it could crash anyway).

I would suggest a similar approach in Java - let the language specific layer deal with the language specific nuances. We can avoid crashes with code changes in OpenMAMA here fairly easily.

Cheers,
Frank


On Thu, Dec 28, 2017 at 3:17 PM, 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
        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


Re: Finalizers are dangerous

Bill Torpey
 

Sanjeev:

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.

Regards,

Bill

On Dec 28, 2017, at 10:17 AM, Sanjeev Wahi <sawahi@gmail.com> 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
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@db.com>
Cc: openmama-dev <openmama-dev@lists.openmama.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@db.com> 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@lists.openmama.org
https://lists.openmama.org/mailman/listinfo/openmama-dev
_______________________________________________
Openmama-dev mailing list
Openmama-dev@lists.openmama.org
https://lists.openmama.org/mailman/listinfo/openmama-dev


Re: Finalizers are dangerous

Sanjeev Wahi
 

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@db.com>
Cc: openmama-dev <openmama-dev@lists.openmama.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@db.com> 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@lists.openmama.org
https://lists.openmama.org/mailman/listinfo/openmama-dev
_______________________________________________
Openmama-dev mailing list
Openmama-dev@lists.openmama.org
https://lists.openmama.org/mailman/listinfo/openmama-dev


Re: Finalizers are dangerous

Bill Torpey
 

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@db.com> 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@lists.openmama.org
https://lists.openmama.org/mailman/listinfo/openmama-dev


Finalizers are dangerous

Yury Batrakov
 

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.


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[noreply] Added vcpkg_build option for use with vcpkg (#340)
	site_scons/community/command_line.py
	site_scons/community/windows.py
	mama/c_cpp/src/c/SConscript.win
	mama/c_cpp/src/c/bridge/qpid/SConscript.win


Results for OpenMAMA_Snapshot_Linux CI run with latest changes:

  • CI Project Name: OpenMAMA_Snapshot_Linux
  • Build Number: #196
  • Build Status: Successful
  • Build Warnings: 0
  • Total Amount of Tests: 1829
  • Passed: 1829
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[fquinn.ni] Added new option for disabling runtime install
	mama/c_cpp/src/c/bridge/qpid/SConscript
	mama/c_cpp/src/c/SConscript.win
	mama/c_cpp/src/c/SConscript
	mama/c_cpp/src/c/payload/qpidmsg/SConscript.win
	mama/c_cpp/src/c/bridge/qpid/SConscript.win
	site_scons/community/command_line.py


Results for OpenMAMA_Snapshot_Linux CI run with latest changes:

  • CI Project Name: OpenMAMA_Snapshot_Linux
  • Build Number: #195
  • Build Status: Successful
  • Build Warnings: 0
  • Total Amount of Tests: 1829
  • Passed: 1829
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[noreply] Added visual studio 14.1 as build option
	site_scons/community/command_line.py


Results for OpenMAMA_Snapshot_Linux CI run with latest changes:

  • CI Project Name: OpenMAMA_Snapshot_Linux
  • Build Number: #194
  • Build Status: Successful
  • Build Warnings: 0
  • Total Amount of Tests: 1829
  • Passed: 1829
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[fquinn.ni] [MAMDA] Removing duplicated FieldUpdate structs
	mamda/c_cpp/src/cpp/MamdaTradeListener.cpp


Results for OpenMAMA_Snapshot_Linux CI run with latest changes:

  • CI Project Name: OpenMAMA_Snapshot_Linux
  • Build Number: #193
  • Build Status: Successful
  • Build Warnings: 0
  • Total Amount of Tests: 1829
  • Passed: 1829
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[fquinn.ni] Added lex option to allow optional tool path
	common/c_cpp/SConscript.win
	site_scons/community/command_line.py
	site_scons/community/windows.py
	common/c_cpp/src/c/SConscript.win

[fquinn.ni] Added lex to tools list
	site_scons/community/windows.py


Results for OpenMAMA_Snapshot_Linux CI run with latest changes:

  • CI Project Name: OpenMAMA_Snapshot_Linux
  • Build Number: #192
  • Build Status: Successful
  • Build Warnings: 0
  • Total Amount of Tests: 1829
  • Passed: 1829
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[fquinn.ni] [COMMON] Enhancements to support Darwin.
	common/c_cpp/src/c/darwin/port.h
	common/c_cpp/src/c/darwin/clock.c
	common/c_cpp/src/c/SConscript
	common/c_cpp/src/c/darwin/port.c
	site_scons/community/command_line.py

[fquinn.ni] [COMMON] Fixing compiler error with wUuid_clear
	common/c_cpp/src/c/linux/wUuid.h


Results for OpenMAMA_Snapshot_Linux CI run with latest changes:

  • CI Project Name: OpenMAMA_Snapshot_Linux
  • Build Number: #191
  • Build Status: Successful
  • Build Warnings: 0
  • Total Amount of Tests: 1829
  • Passed: 1829
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Re: Fixed some crashes in JNI code

Frank Quinn <fquinn.ni@...>
 

Huzzah! The first of many I hope! :)

Good hunting!

Cheers,
Frank


On Fri, 17 Nov 2017, 18:22 Victor Maleyev, <imnotmindlin@...> wrote:
Thank you, Frank.
My first commit to OpenMAMA hooray! :)

16.11.2017, 21:57, "Frank Quinn" <fquinn.ni@...>:
Thanks Victor - just merged those changes into next.

Comprehensive detail in there too - it was much appreciated.

Cheers,
Frank

On Tue, 14 Nov 2017, 20:13 Victor Maleyev, <imnotmindlin@...> wrote:
Hey guys,

I've fixed few JVM crashes in mamajni and have created a pull request: https://github.com/OpenMAMA/OpenMAMA/pull/333
Could someone have a look?
_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev




Re: Fixed some crashes in JNI code

Victor Maleyev
 

Thank you, Frank.
My first commit to OpenMAMA hooray! :)

16.11.2017, 21:57, "Frank Quinn" <fquinn.ni@...>:

Thanks Victor - just merged those changes into next.

Comprehensive detail in there too - it was much appreciated.

Cheers,
Frank

On Tue, 14 Nov 2017, 20:13 Victor Maleyev, <imnotmindlin@...> wrote:
Hey guys,

I've fixed few JVM crashes in mamajni and have created a pull request: https://github.com/OpenMAMA/OpenMAMA/pull/333
Could someone have a look?
_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev



161 - 180 of 2295