Topics

change openmama linux platform implementation to call dlopen with RTLD_LOCAl flag

Igor Kovalenko
 

Classification: Public

Hi openmama team,

 

I see that on linux platform openmama uses dlopen() with RTLD_GLOBAL flag to load bridge implementations.

What do you think about changing that dlopen() call to use RTLD_LOCAL instead?

Using dlopen() with RTLD_LOCAL naturally provides named symbol isolation behavior one would expect from a system which dynamically loads implementations.

 

I cannot post a patch here yet but otherwise it is a trivial change to src/common/c_cpp/src/c/linux/platform.c line 65

 

Using RTLD_GLOBAL creates a problem if any two bridge implementations provide the same global symbol name. If loaded simultaneously these will share the same underlying object resolved through the library loaded first.

For instance a crash can be reproduced with just loading tick42blp and tick42rmds bridges, and then closing mama. While mama is closing first bridge shutting down will destroy gTimerHeap object, and then last bridge shutting down will attempt to destroy the same gTimerHeap once again.

 

A workaround would be to carefully examine non-local symbols from each bridge implementation and fix accordingly if bridge sources are available.

We can amend either blp or rmds bridge implementation - but this is not always possible and is obviously very inconvenient.

 

Note that on windows platform implementation already is behaving as non-global due to the fact that you always need explicitly loaded library handle to resolve a symbol.

 

Thank you!

 

--

Kind regards,
Igor Kovalenko
____________________________________________________



Igor Kovalenko

OOO "Deutsche Bank TechCentre"
Global Technology
Business Center Aquamarine, Ozerkovskaya naberezhnaya 24, 115184 Moscow, Russia
Tel. +7 495 783-0313
Email igor.kovalenko@...

 



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

Frank Quinn
 

Hi Igor,

Yes I'm open to the suggestion I can't see any negative side effects of this.

As an aside, the new split-bridge changes will also fix your timerheap issue since each bridge will have its own distinct heap allocated object in each bridge if it's used and would be best practice overall since it isolates each bridge and doesn't depend on static externs.

Cheers,
Frank

On Jan 15 2019, at 10:03 am, Igor Kovalenko <igor.kovalenko@...> wrote:
 
Classification: Public

Hi openmama team,

 

I see that on linux platform openmama uses dlopen() with RTLD_GLOBAL flag to load bridge implementations.

What do you think about changing that dlopen() call to use RTLD_LOCAL instead?

Using dlopen() with RTLD_LOCAL naturally provides named symbol isolation behavior one would expect from a system which dynamically loads implementations.

 

I cannot post a patch here yet but otherwise it is a trivial change to src/common/c_cpp/src/c/linux/platform.c line 65

 

Using RTLD_GLOBAL creates a problem if any two bridge implementations provide the same global symbol name. If loaded simultaneously these will share the same underlying object resolved through the library loaded first.

For instance a crash can be reproduced with just loading tick42blp and tick42rmds bridges, and then closing mama. While mama is closing first bridge shutting down will destroy gTimerHeap object, and then last bridge shutting down will attempt to destroy the same gTimerHeap once again.

 

A workaround would be to carefully examine non-local symbols from each bridge implementation and fix accordingly if bridge sources are available.

We can amend either blp or rmds bridge implementation - but this is not always possible and is obviously very inconvenient.

 

Note that on windows platform implementation already is behaving as non-global due to the fact that you always need explicitly loaded library handle to resolve a symbol.

 

Thank you!

 

--

Kind regards,
Igor Kovalenko
____________________________________________________



Igor Kovalenko

OOO "Deutsche Bank TechCentre"
Global Technology
Business Center Aquamarine, Ozerkovskaya naberezhnaya 24, 115184 Moscow, Russia
Tel. +7 495 783-0313

 


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

Igor Kovalenko
 

Classification: Public

Thank you Frank,

 

I confirm changing the dlopen() call to use RTLD_LOCAL fixes the problem for us here, none of our tests are otherwise affected.

Have not looked at split-bridge changes yet but I’m sure that is a good thing to have.

 

--

Kind regards,
Igor Kovalenko
____________________________________________________



Igor Kovalenko

OOO "Deutsche Bank TechCentre"
Global Technology
Business Center Aquamarine, Ozerkovskaya naberezhnaya 24, 115184 Moscow, Russia
Tel. +7 495 783-0313
Email igor.kovalenko@...

 

From: Openmama-dev@... [mailto:Openmama-dev@...] On Behalf Of Frank Quinn
Sent: 15 января 2019 г. 13:11
To: Igor Kovalenko <igor.kovalenko@...>
Cc: openmama-dev@...
Subject: Re: [Openmama-dev] change openmama linux platform implementation to call dlopen with RTLD_LOCAl flag

 

Hi Igor,

 

Yes I'm open to the suggestion I can't see any negative side effects of this.

 

As an aside, the new split-bridge changes will also fix your timerheap issue since each bridge will have its own distinct heap allocated object in each bridge if it's used and would be best practice overall since it isolates each bridge and doesn't depend on static externs.

 

Cheers,

Frank

 

On Jan 15 2019, at 10:03 am, Igor Kovalenko <igor.kovalenko@...> wrote:

 

Classification: Public

 

Hi openmama team,

 

 

 

I see that on linux platform openmama uses dlopen() with RTLD_GLOBAL flag to load bridge implementations.

 

What do you think about changing that dlopen() call to use RTLD_LOCAL instead?

 

Using dlopen() with RTLD_LOCAL naturally provides named symbol isolation behavior one would expect from a system which dynamically loads implementations.

 

 

 

I cannot post a patch here yet but otherwise it is a trivial change to src/common/c_cpp/src/c/linux/platform.c line 65

 

 

 

Using RTLD_GLOBAL creates a problem if any two bridge implementations provide the same global symbol name. If loaded simultaneously these will share the same underlying object resolved through the library loaded first.

 

For instance a crash can be reproduced with just loading tick42blp and tick42rmds bridges, and then closing mama. While mama is closing first bridge shutting down will destroy gTimerHeap object, and then last bridge shutting down will attempt to destroy the same gTimerHeap once again.

 

 

 

A workaround would be to carefully examine non-local symbols from each bridge implementation and fix accordingly if bridge sources are available.

 

We can amend either blp or rmds bridge implementation - but this is not always possible and is obviously very inconvenient.

 

 

 

Note that on windows platform implementation already is behaving as non-global due to the fact that you always need explicitly loaded library handle to resolve a symbol.

 

 

 

Thank you!

 

 

 

--

 

Kind regards,

Igor Kovalenko

____________________________________________________

 

Igor Kovalenko

 

OOO "Deutsche Bank TechCentre"

Global Technology

Business Center Aquamarine, Ozerkovskaya naberezhnaya 24, 115184 Moscow, Russia

Tel. +7 495 783-0313

 

 

 

---

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.



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