Date   

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




Re: Java publishing is broken in 6.2.1

Frank Quinn <fquinn.ni@...>
 

Hi Yury,

This was actually part of why I recently introduced CI for jni - we didn't spot this until it was too late.

The short answer is that since its usually a compile time dependency, its so easily fixed, and its unavoidable if publisher events were to work without significant changes, I was letting this one slide. In the maven world this would be a common enough occurrence when bumping version numbers too (I want to add proper maven support soon too) so it was less of a concern.

Going forward though, we will be a little more pro-active about this sort of thing.

Cheers,
Frank


On Tue, 14 Nov 2017, 16:19 Yury Batrakov, <yury.batrakov@...> wrote:
Classification: Public
Hi team,

We found that Java publishing was broken when onSuccess event was introduced. The problem is here - mamapublisherjni.c, function Java_com_wombat_mama_MamaPublisher_initIDs:
    publisherCallbackMethoOnSuccess_g = (*env)->GetMethodID(env, publisherCallbackClass,
        "onSuccess", "(Lcom/wombat/mama/MamaPublisher;SLjava/lang/String;)V");

But com.wombat.mama. MamaPublisherCallback doesn't have this method and we get exception when trying to create MamaPublisher object (reproduced with MamaPublisherJava example):
Exception in thread "main" java.lang.NoSuchMethodError: onSuccess
        at com.wombat.mama.MamaPublisher.initIDs(Native Method)
        at com.wombat.mama.MamaPublisher.<clinit>(MamaPublisher.java:31)
        at com.wombat.mama.examples.MamaPublisherJava.createPublisher(MamaPublisherJava.java:103)
        at com.wombat.mama.examples.MamaPublisherJava.run(MamaPublisherJava.java:313)
        at com.wombat.mama.examples.MamaPublisherJava.main(MamaPublisherJava.java:301)

Obvious fix is to add new method to MamaPublisherCallback but it will break the code for those clients who were using publisher events before. What do you think should be the fix for this?


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


Re: Fixed some crashes in JNI code

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


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

jenkins@...
 

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

[fquinn.ni] Fixed few crashes when calling Mama.loadPayloadBridge of Java API
	mama/jni/src/c/mamajni.c
	mama/jni/src/c/mamapayloadbridgejni.c
	mama/c_cpp/src/c/mama.c
	mama/c_cpp/src/cpp/mamacpp.cpp

[fquinn.ni] Fixed crash when calling MamaMsg(payloadBridge) of Java API
	mama/jni/src/c/mamamsgjni.c

[fquinn.ni] Fix for MamaMsg.setNewBuffer of Java API
	mama/jni/src/c/mamamsgjni.c


Results for OpenMAMA_Snapshot_Linux CI run with latest changes:

  • CI Project Name: OpenMAMA_Snapshot_Linux
  • Build Number: #190
  • 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.


Fixed some crashes in JNI code

Victor Maleyev
 

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?


Java publishing is broken in 6.2.1

Yury Batrakov
 

Classification: Public
Hi team,

We found that Java publishing was broken when onSuccess event was introduced. The problem is here - mamapublisherjni.c, function Java_com_wombat_mama_MamaPublisher_initIDs:
publisherCallbackMethoOnSuccess_g = (*env)->GetMethodID(env, publisherCallbackClass,
"onSuccess", "(Lcom/wombat/mama/MamaPublisher;SLjava/lang/String;)V");

But com.wombat.mama. MamaPublisherCallback doesn't have this method and we get exception when trying to create MamaPublisher object (reproduced with MamaPublisherJava example):
Exception in thread "main" java.lang.NoSuchMethodError: onSuccess
at com.wombat.mama.MamaPublisher.initIDs(Native Method)
at com.wombat.mama.MamaPublisher.<clinit>(MamaPublisher.java:31)
at com.wombat.mama.examples.MamaPublisherJava.createPublisher(MamaPublisherJava.java:103)
at com.wombat.mama.examples.MamaPublisherJava.run(MamaPublisherJava.java:313)
at com.wombat.mama.examples.MamaPublisherJava.main(MamaPublisherJava.java:301)

Obvious fix is to add new method to MamaPublisherCallback but it will break the code for those clients who were using publisher events before. What do you think should be the fix for this?


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


Operation Windows Love Concludes

Frank Quinn <fquinn.ni@...>
 

Hi Folks,

As part of the last round of integration testing prior to the last release, we noticed that Java and C# builds were actually broken and had to be fixed fairly last-minute.

To prevent this going forward, I have just merged some changes which:

 - Removes broken unit tests
 - Fixes working unit tests (including an actual bugfix spotted by some tests)
 - Adds running unit tests to ci script

This is for both Java and C# builds. Travis builds have also been updated so they will automatically be tested now on each PR raised.

This concludes "Operation Windows Love" which has been trickling in changes for over a year now to:

 - Improve the build experience on windows
 - Get unit tests running on windows
 - Get nunit tests running on windows
 - Get junit tests running on windows
 - Remove compiler warnings on windows
 - Modify CI to take advantage of the above

Don't get me wrong - there are still a *lot* of things we could still improve upon, but at least we have a decent minimum set to work from now.

Cheers,
Frank


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

jenkins@...
 

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

[Frank Quinn] Set build product to mamdaall
	release_scripts/ci-run.py

[Frank Quinn] Fixed bug in java deserialization methods
	mama/jni/src/junittests/MamaTimerCallbacks.java
	mama/jni/src/junittests/MamaMsgAddArrayMsgWithLength.java
	mama/jni/src/junittests/MamaMsgGetStringAsCharBuffer.java
	mama/jni/src/junittests/MamaMsgVectorFields.java
	mama/jni/src/junittests/MamaPublisherTest.java
	mama/jni/src/c/mamamsgjni.c
	mama/jni/src/junittests/MamaMsgTryMethods.java
	mama/jni/src/junittests/MamaInboxCallbacks.java
	mama/jni/src/junittests/Main.java

[Frank Quinn] Fixed a few jni compiler warnings
	mama/jni/src/c/mamaconnectionjni.c
	mama/jni/src/c/mamabasicsubscriptionjni.c
	mama/jni/src/c/mamajni.vcxproj

[Frank Quinn] Added junit unit tests to ci run
	release_scripts/ci-run.py

[Frank Quinn] Set nunit to x86 directory by default
	site_scons/community/windows.py

[Frank Quinn] Added setting of PATH for unit test run
	release_scripts/ci-run.py

[Frank Quinn] Fixes for c# unit tests
	mama/c_cpp/src/c/mama/log.h
	mama/dotnet/src/nunittest/MamaSetLogSizeTest.cs
	mama/dotnet/src/nunittest/MamaPublisherTest.cs
	mama/dotnet/src/cs/MamaVersion.cs
	mama/dotnet/src/nunittest/MamaLogMessageTest.cs
	mama/dotnet/src/nunittest/MamaMsgVectorStringTest.cs
	release_scripts/ci-run.py
	mama/dotnet/src/nunittest/NUnitTest.csproj
	mama/dotnet/src/cs/MAMA.cs
	mama/dotnet/src/nunittest/SConscript.win
	mamda/dotnet/SConscript.win
	mama/dotnet/src/nunittest/MamaSetLogFilePolicyTest.cs
	mama/dotnet/SConscript.win
	mama/dotnet/src/cs/AssemblyInfo.cs
	mama/dotnet/src/nunittest/MamaMsgVectorPriceTest.cs
	mama/dotnet/src/nunittest/MamaLogTest.cs
	mama/dotnet/src/nunittest/MamaLogToFileTest.cs

[Frank Quinn] Added nunit path for unit test runner
	release_scripts/ci-run.py

[Frank Quinn] Escaped clashes in nunit
	release_scripts/ci-run.py

[Frank Quinn] Fixed jni warnings on win and enabled for linux
	mama/jni/src/c/mamasubscriptionjni.c
	mama/jni/src/c/mamajni.c
	mama/jni/src/c/mamamsgjni.c
	release_scripts/ci-run.py
	mama/jni/src/c/mamapublisherjni.c

[Frank Quinn] Added setting of JAVA_HOME for travis
	.travis.yml

[Frank Quinn] Added consideration of JAVA_HOME to ci script
	release_scripts/ci-run.py

[Frank Quinn] Updated JAVA_HOME path for travis
	.travis.yml

[Frank Quinn] Fixed some compiler warnings for jni and removed dead code
	mama/jni/src/com/wombat/mama/Mama.java
	mama/jni/src/c/SConscript
	mama/jni/src/c/mamadqpublisherjni.c
	mama/jni/src/c/mamajni.c
	mamda/java/com/wombat/mamda/options/MamdaOptionChainListener.java
	mama/jni/src/c/mamadqpublishermanagerjni.c
	mama/c_cpp/src/testtools/load/cpp/mamachurncpp.cpp
	mama/jni/src/c/mamapricejni.c
	mamda/java/com/wombat/mamda/MamdaSecurityStatusListener.java
	mama/jni/src/com/wombat/mama/MamaTransport.java
	mamda/java/com/wombat/mamda/examples/MamdaOptionChainExample.java
	mama/jni/src/c/mamapublisherjni.c
	mama/jni/src/c/mamasourcejni.c
	mama/jni/src/c/mamaconnectionjni.c
	mamda/java/com/wombat/mamda/examples/MamdaOptionChainViewExample.java
	mama/jni/src/junittests/MamaMsgTryMethods.java
	mama/jni/src/c/mamasubscriptionjni.c
	mama/jni/src/c/mamamsgjni.c


Results for OpenMAMA_Snapshot_Linux CI run with latest changes:

  • CI Project Name: OpenMAMA_Snapshot_Linux
  • Build Number: #189
  • 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] Fixed memory leak in MamaMsgField (#331)
	mama/c_cpp/src/cpp/mama/MamaMsgField.h
	mama/c_cpp/src/cpp/MamaMsgField.cpp


Results for OpenMAMA_Snapshot_Linux CI run with latest changes:

  • CI Project Name: OpenMAMA_Snapshot_Linux
  • Build Number: #188
  • 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: ​[PATCH 6.2.1] MAMA C++: Fixed memory leak in MamaMsgField

Frank Quinn <fquinn.ni@...>
 

Hi Victor,

Apologies - yes the website is out of date - I'll update it.


I did raise the PR on your request though:


And just merged into next so it will be included in the next release.

Cheers,
Frank


On Wed, Nov 8, 2017 at 1:39 PM, Victor Maleyev <imnotmindlin@...> wrote:
Hey Damian,

Could you apply the patch? I thought it's official way to contribute changes - it is documented on openmama.org -> Contribute.

08.11.2017, 14:51, "Damian Maguire" <dmaguire@...>:

Hey Victor,


In Github projects, forking is generally the best way to work with the project, and is the recommended approach for raising patches for OpenMAMA - you can actually see the forks used by the likes of myself, Frank and other contributors if you go looking.


Regarding some documentation, you can find a bunch in the 'Contributor Guides' section of the OpenMAMA GitHub page, with the 'Submission Process' page probably the most interesting for you: https://openmama.github.io/openmama_submission_process.html


If you still aren't comfortable with the approach once you've given it a try, or if you hit some difficulties, we can apply the patch for you, but I'd recommend you give it a go - it's a much nicer way of working with the project than sending patches around, and should let you use a bunch of GitHub's other functionality as well.


Any questions feel free to reach out to me.


Thanks,


Damian



DAMIAN MAGUIRE 

Senior Sales Engineer 

 

M. +44 783 584 4770 

 

Adelaide Exchange Building2nd Floor, 24-26 Adelaide StreetBelfast, BT2 8GD  

velatradingtech.com | @vela_tt





From: Victor Maleyev <imnotmindlin@...>
Sent: 08 November 2017 11:01
To: Frank Quinn
Cc: openmama-dev; Damian Maguire; frank@...
Subject: Re: [Openmama-dev] [PATCH 6.2.1] MAMA C++: Fixed memory leak in MamaMsgField
 
Hi Frank,

I don't know how to make pull requests without forking the project, that's why I sent the patch. Is it possible for you to apply it? Or is it any instruction on how to do pull requests?

08.11.2017, 02:41, "Frank Quinn" <fquinn.ni@...>:

Thanks Victor,

Yes I can see how that wouldn't have behaved as expected and fix looks sound. Are you going to raise a pull request against the "next" branch for this or do you want me to take it from here?

Cheers,
Frank


On Mon, 6 Nov 2017, 09:55 Victor Maleyev, <imnotmindlin@...> wrote:
Not sure if my previous mail reached the maillist. Adding list admins, sorry if this is inapropriate.
---
It is possible to reproduce memory leak using the following:

MamaMsgIterator i;
for(MamaMsgField field = msg.begin(i); ...; field =  *++i) {
    field.getVectorMsg(...);
}

Note that field is not reference but object.

When calling getVectorMsg() the array of pointers (mLastVectorMsg) is allocated by malloc but when we assign a new value to the field (field = *++i) the allocated array becomes unreachable and can't be deleted. Overloaded assignment operator calling clear before assignment can solve this.
Signed-off-by: Victor Maleyev <imnotmindlin@...>

From c036b0726464916b2e49d6b1297a2a82404c0359 Mon Sep 17 00:00:00 2001
From: Victor Maleyev <imnotmindlin@...>
Date: Fri, 3 Nov 2017 00:14:05 +0300
Subject: [PATCH] Fixed memory leak in MamaMsgField

Signed-off-by: Victor Maleyev <imnotmindlin@...>
---
 mama/c_cpp/src/cpp/MamaMsgField.cpp | 15 +++++++++++++++
 mama/c_cpp/src/cpp/mama/MamaMsgField.h | 6 ++++++
 2 files changed, 21 insertions(+)

diff --git a/mama/c_cpp/src/cpp/MamaMsgField.cpp b/mama/c_cpp/src/cpp/MamaMsgField.cpp
index f2f287c..2cf1270 100644
--- a/mama/c_cpp/src/cpp/MamaMsgField.cpp
+++ b/mama/c_cpp/src/cpp/MamaMsgField.cpp
@@ -47,6 +47,21 @@ namespace Wombat
     {
     }

+ MamaMsgField::MamaMsgField (const MamaMsgField& field)
+ : mField (field.mField)
+ , mFieldDesc (NULL)
+ , mLastVectorMsg (NULL)
+ , mLastVectorMsgLen (0)
+ {
+ }
+
+ MamaMsgField& MamaMsgField::operator= (const MamaMsgField& field)
+ {
+ clear();
+ mField = field.mField;
+ return *this;
+ }
+
     void MamaMsgField::clear ()
     {
         if (mFieldDesc)
diff --git a/mama/c_cpp/src/cpp/mama/MamaMsgField.h b/mama/c_cpp/src/cpp/mama/MamaMsgField.h
index b9b9e73..d8f45b1 100644
--- a/mama/c_cpp/src/cpp/mama/MamaMsgField.h
+++ b/mama/c_cpp/src/cpp/mama/MamaMsgField.h
@@ -50,6 +50,12 @@ namespace Wombat
         MamaMsgField (
             mamaMsgField field);

+ MamaMsgField (
+ const MamaMsgField& field);
+
+ MamaMsgField& operator= (
+ const MamaMsgField& field);
+
         /**
          * Clear the field.
          */
--
2.13.3
-------- Конец пересылаемого сообщения --------_______________________________________________
Openmama-dev mailing list
Openmama-dev@....org
https://lists.openmama.org/mailman/listinfo/openmama-dev




The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. Vela Trading Technologies LLC





Re: ​[PATCH 6.2.1] MAMA C++: Fixed memory leak in MamaMsgField

Victor Maleyev
 

Hey Damian,

Could you apply the patch? I thought it's official way to contribute changes - it is documented on openmama.org -> Contribute.

08.11.2017, 14:51, "Damian Maguire" <dmaguire@...>:

Hey Victor,


In Github projects, forking is generally the best way to work with the project, and is the recommended approach for raising patches for OpenMAMA - you can actually see the forks used by the likes of myself, Frank and other contributors if you go looking.


Regarding some documentation, you can find a bunch in the 'Contributor Guides' section of the OpenMAMA GitHub page, with the 'Submission Process' page probably the most interesting for you: https://openmama.github.io/openmama_submission_process.html


If you still aren't comfortable with the approach once you've given it a try, or if you hit some difficulties, we can apply the patch for you, but I'd recommend you give it a go - it's a much nicer way of working with the project than sending patches around, and should let you use a bunch of GitHub's other functionality as well.


Any questions feel free to reach out to me.


Thanks,


Damian



DAMIAN MAGUIRE 

Senior Sales Engineer 

 

O. +44 289 568 0298  

M. +44 783 584 4770 

 

Adelaide Exchange Building2nd Floor, 24-26 Adelaide StreetBelfast, BT2 8GD  

velatradingtech.com | @vela_tt





From: Victor Maleyev <imnotmindlin@...>
Sent: 08 November 2017 11:01
To: Frank Quinn
Cc: openmama-dev; Damian Maguire; frank@...
Subject: Re: [Openmama-dev] [PATCH 6.2.1] MAMA C++: Fixed memory leak in MamaMsgField
 
Hi Frank,

I don't know how to make pull requests without forking the project, that's why I sent the patch. Is it possible for you to apply it? Or is it any instruction on how to do pull requests?

08.11.2017, 02:41, "Frank Quinn" <fquinn.ni@...>:

Thanks Victor,

Yes I can see how that wouldn't have behaved as expected and fix looks sound. Are you going to raise a pull request against the "next" branch for this or do you want me to take it from here?

Cheers,
Frank


On Mon, 6 Nov 2017, 09:55 Victor Maleyev, <imnotmindlin@...> wrote:
Not sure if my previous mail reached the maillist. Adding list admins, sorry if this is inapropriate.
---
It is possible to reproduce memory leak using the following:

MamaMsgIterator i;
for(MamaMsgField field = msg.begin(i); ...; field =  *++i) {
    field.getVectorMsg(...);
}

Note that field is not reference but object.

When calling getVectorMsg() the array of pointers (mLastVectorMsg) is allocated by malloc but when we assign a new value to the field (field = *++i) the allocated array becomes unreachable and can't be deleted. Overloaded assignment operator calling clear before assignment can solve this.
Signed-off-by: Victor Maleyev <imnotmindlin@...>

From c036b0726464916b2e49d6b1297a2a82404c0359 Mon Sep 17 00:00:00 2001
From: Victor Maleyev <imnotmindlin@...>
Date: Fri, 3 Nov 2017 00:14:05 +0300
Subject: [PATCH] Fixed memory leak in MamaMsgField

Signed-off-by: Victor Maleyev <imnotmindlin@...>
---
 mama/c_cpp/src/cpp/MamaMsgField.cpp | 15 +++++++++++++++
 mama/c_cpp/src/cpp/mama/MamaMsgField.h | 6 ++++++
 2 files changed, 21 insertions(+)

diff --git a/mama/c_cpp/src/cpp/MamaMsgField.cpp b/mama/c_cpp/src/cpp/MamaMsgField.cpp
index f2f287c..2cf1270 100644
--- a/mama/c_cpp/src/cpp/MamaMsgField.cpp
+++ b/mama/c_cpp/src/cpp/MamaMsgField.cpp
@@ -47,6 +47,21 @@ namespace Wombat
     {
     }

+ MamaMsgField::MamaMsgField (const MamaMsgField& field)
+ : mField (field.mField)
+ , mFieldDesc (NULL)
+ , mLastVectorMsg (NULL)
+ , mLastVectorMsgLen (0)
+ {
+ }
+
+ MamaMsgField& MamaMsgField::operator= (const MamaMsgField& field)
+ {
+ clear();
+ mField = field.mField;
+ return *this;
+ }
+
     void MamaMsgField::clear ()
     {
         if (mFieldDesc)
diff --git a/mama/c_cpp/src/cpp/mama/MamaMsgField.h b/mama/c_cpp/src/cpp/mama/MamaMsgField.h
index b9b9e73..d8f45b1 100644
--- a/mama/c_cpp/src/cpp/mama/MamaMsgField.h
+++ b/mama/c_cpp/src/cpp/mama/MamaMsgField.h
@@ -50,6 +50,12 @@ namespace Wombat
         MamaMsgField (
             mamaMsgField field);

+ MamaMsgField (
+ const MamaMsgField& field);
+
+ MamaMsgField& operator= (
+ const MamaMsgField& field);
+
         /**
          * Clear the field.
          */
--
2.13.3
-------- Конец пересылаемого сообщения --------_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev




The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. Vela Trading Technologies LLC




Re: ​[PATCH 6.2.1] MAMA C++: Fixed memory leak in MamaMsgField

Damian Maguire <dmaguire@...>
 

Hey Victor,


In Github projects, forking is generally the best way to work with the project, and is the recommended approach for raising patches for OpenMAMA - you can actually see the forks used by the likes of myself, Frank and other contributors if you go looking.


Regarding some documentation, you can find a bunch in the 'Contributor Guides' section of the OpenMAMA GitHub page, with the 'Submission Process' page probably the most interesting for you: https://openmama.github.io/openmama_submission_process.html


If you still aren't comfortable with the approach once you've given it a try, or if you hit some difficulties, we can apply the patch for you, but I'd recommend you give it a go - it's a much nicer way of working with the project than sending patches around, and should let you use a bunch of GitHub's other functionality as well.


Any questions feel free to reach out to me.


Thanks,


Damian



DAMIAN MAGUIRE 

Senior Sales Engineer 

 

O. +44 289 568 0298  

M. +44 783 584 4770 

dmaguire@... 

 

Adelaide Exchange Building2nd Floor, 24-26 Adelaide StreetBelfast, BT2 8GD  

velatradingtech.com | @vela_tt





From: Victor Maleyev <imnotmindlin@...>
Sent: 08 November 2017 11:01
To: Frank Quinn
Cc: openmama-dev; Damian Maguire; frank@...
Subject: Re: [Openmama-dev] [PATCH 6.2.1] MAMA C++: Fixed memory leak in MamaMsgField
 
Hi Frank,

I don't know how to make pull requests without forking the project, that's why I sent the patch. Is it possible for you to apply it? Or is it any instruction on how to do pull requests?

08.11.2017, 02:41, "Frank Quinn" <fquinn.ni@...>:

Thanks Victor,

Yes I can see how that wouldn't have behaved as expected and fix looks sound. Are you going to raise a pull request against the "next" branch for this or do you want me to take it from here?

Cheers,
Frank


On Mon, 6 Nov 2017, 09:55 Victor Maleyev, <imnotmindlin@...> wrote:
Not sure if my previous mail reached the maillist. Adding list admins, sorry if this is inapropriate.
---
It is possible to reproduce memory leak using the following:

MamaMsgIterator i;
for(MamaMsgField field = msg.begin(i); ...; field =  *++i) {
    field.getVectorMsg(...);
}

Note that field is not reference but object.

When calling getVectorMsg() the array of pointers (mLastVectorMsg) is allocated by malloc but when we assign a new value to the field (field = *++i) the allocated array becomes unreachable and can't be deleted. Overloaded assignment operator calling clear before assignment can solve this.
Signed-off-by: Victor Maleyev <imnotmindlin@...>

From c036b0726464916b2e49d6b1297a2a82404c0359 Mon Sep 17 00:00:00 2001
From: Victor Maleyev <imnotmindlin@...>
Date: Fri, 3 Nov 2017 00:14:05 +0300
Subject: [PATCH] Fixed memory leak in MamaMsgField

Signed-off-by: Victor Maleyev <imnotmindlin@...>
---
 mama/c_cpp/src/cpp/MamaMsgField.cpp | 15 +++++++++++++++
 mama/c_cpp/src/cpp/mama/MamaMsgField.h | 6 ++++++
 2 files changed, 21 insertions(+)

diff --git a/mama/c_cpp/src/cpp/MamaMsgField.cpp b/mama/c_cpp/src/cpp/MamaMsgField.cpp
index f2f287c..2cf1270 100644
--- a/mama/c_cpp/src/cpp/MamaMsgField.cpp
+++ b/mama/c_cpp/src/cpp/MamaMsgField.cpp
@@ -47,6 +47,21 @@ namespace Wombat
     {
     }

+ MamaMsgField::MamaMsgField (const MamaMsgField& field)
+ : mField (field.mField)
+ , mFieldDesc (NULL)
+ , mLastVectorMsg (NULL)
+ , mLastVectorMsgLen (0)
+ {
+ }
+
+ MamaMsgField& MamaMsgField::operator= (const MamaMsgField& field)
+ {
+ clear();
+ mField = field.mField;
+ return *this;
+ }
+
     void MamaMsgField::clear ()
     {
         if (mFieldDesc)
diff --git a/mama/c_cpp/src/cpp/mama/MamaMsgField.h b/mama/c_cpp/src/cpp/mama/MamaMsgField.h
index b9b9e73..d8f45b1 100644
--- a/mama/c_cpp/src/cpp/mama/MamaMsgField.h
+++ b/mama/c_cpp/src/cpp/mama/MamaMsgField.h
@@ -50,6 +50,12 @@ namespace Wombat
         MamaMsgField (
             mamaMsgField field);

+ MamaMsgField (
+ const MamaMsgField& field);
+
+ MamaMsgField& operator= (
+ const MamaMsgField& field);
+
         /**
          * Clear the field.
          */
--
2.13.3
-------- Конец пересылаемого сообщения --------_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev




The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. Vela Trading Technologies LLC


Re: ​[PATCH 6.2.1] MAMA C++: Fixed memory leak in MamaMsgField

Victor Maleyev
 

Hi Frank,

I don't know how to make pull requests without forking the project, that's why I sent the patch. Is it possible for you to apply it? Or is it any instruction on how to do pull requests?

08.11.2017, 02:41, "Frank Quinn" <fquinn.ni@...>:

Thanks Victor,

Yes I can see how that wouldn't have behaved as expected and fix looks sound. Are you going to raise a pull request against the "next" branch for this or do you want me to take it from here?

Cheers,
Frank


On Mon, 6 Nov 2017, 09:55 Victor Maleyev, <imnotmindlin@...> wrote:
Not sure if my previous mail reached the maillist. Adding list admins, sorry if this is inapropriate.
---
It is possible to reproduce memory leak using the following:

MamaMsgIterator i;
for(MamaMsgField field = msg.begin(i); ...; field =  *++i) {
    field.getVectorMsg(...);
}

Note that field is not reference but object.

When calling getVectorMsg() the array of pointers (mLastVectorMsg) is allocated by malloc but when we assign a new value to the field (field = *++i) the allocated array becomes unreachable and can't be deleted. Overloaded assignment operator calling clear before assignment can solve this.
Signed-off-by: Victor Maleyev <imnotmindlin@...>

From c036b0726464916b2e49d6b1297a2a82404c0359 Mon Sep 17 00:00:00 2001
From: Victor Maleyev <imnotmindlin@...>
Date: Fri, 3 Nov 2017 00:14:05 +0300
Subject: [PATCH] Fixed memory leak in MamaMsgField

Signed-off-by: Victor Maleyev <imnotmindlin@...>
---
 mama/c_cpp/src/cpp/MamaMsgField.cpp | 15 +++++++++++++++
 mama/c_cpp/src/cpp/mama/MamaMsgField.h | 6 ++++++
 2 files changed, 21 insertions(+)

diff --git a/mama/c_cpp/src/cpp/MamaMsgField.cpp b/mama/c_cpp/src/cpp/MamaMsgField.cpp
index f2f287c..2cf1270 100644
--- a/mama/c_cpp/src/cpp/MamaMsgField.cpp
+++ b/mama/c_cpp/src/cpp/MamaMsgField.cpp
@@ -47,6 +47,21 @@ namespace Wombat
     {
     }

+ MamaMsgField::MamaMsgField (const MamaMsgField& field)
+ : mField (field.mField)
+ , mFieldDesc (NULL)
+ , mLastVectorMsg (NULL)
+ , mLastVectorMsgLen (0)
+ {
+ }
+
+ MamaMsgField& MamaMsgField::operator= (const MamaMsgField& field)
+ {
+ clear();
+ mField = field.mField;
+ return *this;
+ }
+
     void MamaMsgField::clear ()
     {
         if (mFieldDesc)
diff --git a/mama/c_cpp/src/cpp/mama/MamaMsgField.h b/mama/c_cpp/src/cpp/mama/MamaMsgField.h
index b9b9e73..d8f45b1 100644
--- a/mama/c_cpp/src/cpp/mama/MamaMsgField.h
+++ b/mama/c_cpp/src/cpp/mama/MamaMsgField.h
@@ -50,6 +50,12 @@ namespace Wombat
         MamaMsgField (
             mamaMsgField field);

+ MamaMsgField (
+ const MamaMsgField& field);
+
+ MamaMsgField& operator= (
+ const MamaMsgField& field);
+
         /**
          * Clear the field.
          */
--
2.13.3
-------- Конец пересылаемого сообщения --------_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev




Re: ​[PATCH 6.2.1] MAMA C++: Fixed memory leak in MamaMsgField

Frank Quinn <fquinn.ni@...>
 

Thanks Victor,

Yes I can see how that wouldn't have behaved as expected and fix looks sound. Are you going to raise a pull request against the "next" branch for this or do you want me to take it from here?

Cheers,
Frank


On Mon, 6 Nov 2017, 09:55 Victor Maleyev, <imnotmindlin@...> wrote:
Not sure if my previous mail reached the maillist. Adding list admins, sorry if this is inapropriate.
---
It is possible to reproduce memory leak using the following:

MamaMsgIterator i;
for(MamaMsgField field = msg.begin(i); ...; field =  *++i) {
    field.getVectorMsg(...);
}

Note that field is not reference but object.

When calling getVectorMsg() the array of pointers (mLastVectorMsg) is allocated by malloc but when we assign a new value to the field (field = *++i) the allocated array becomes unreachable and can't be deleted. Overloaded assignment operator calling clear before assignment can solve this.
Signed-off-by: Victor Maleyev <imnotmindlin@...>

From c036b0726464916b2e49d6b1297a2a82404c0359 Mon Sep 17 00:00:00 2001
From: Victor Maleyev <imnotmindlin@...>
Date: Fri, 3 Nov 2017 00:14:05 +0300
Subject: [PATCH] Fixed memory leak in MamaMsgField

Signed-off-by: Victor Maleyev <imnotmindlin@...>
---
 mama/c_cpp/src/cpp/MamaMsgField.cpp | 15 +++++++++++++++
 mama/c_cpp/src/cpp/mama/MamaMsgField.h | 6 ++++++
 2 files changed, 21 insertions(+)

diff --git a/mama/c_cpp/src/cpp/MamaMsgField.cpp b/mama/c_cpp/src/cpp/MamaMsgField.cpp
index f2f287c..2cf1270 100644
--- a/mama/c_cpp/src/cpp/MamaMsgField.cpp
+++ b/mama/c_cpp/src/cpp/MamaMsgField.cpp
@@ -47,6 +47,21 @@ namespace Wombat
     {
     }

+ MamaMsgField::MamaMsgField (const MamaMsgField& field)
+ : mField (field.mField)
+ , mFieldDesc (NULL)
+ , mLastVectorMsg (NULL)
+ , mLastVectorMsgLen (0)
+ {
+ }
+
+ MamaMsgField& MamaMsgField::operator= (const MamaMsgField& field)
+ {
+ clear();
+ mField = field.mField;
+ return *this;
+ }
+
     void MamaMsgField::clear ()
     {
         if (mFieldDesc)
diff --git a/mama/c_cpp/src/cpp/mama/MamaMsgField.h b/mama/c_cpp/src/cpp/mama/MamaMsgField.h
index b9b9e73..d8f45b1 100644
--- a/mama/c_cpp/src/cpp/mama/MamaMsgField.h
+++ b/mama/c_cpp/src/cpp/mama/MamaMsgField.h
@@ -50,6 +50,12 @@ namespace Wombat
         MamaMsgField (
             mamaMsgField field);

+ MamaMsgField (
+ const MamaMsgField& field);
+
+ MamaMsgField& operator= (
+ const MamaMsgField& field);
+
         /**
          * Clear the field.
          */
--
2.13.3
-------- Конец пересылаемого сообщения --------_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev


​[PATCH 6.2.1] MAMA C++: Fixed memory leak in MamaMsgField

Victor Maleyev
 

Not sure if my previous mail reached the maillist. Adding list admins, sorry if this is inapropriate.
---
It is possible to reproduce memory leak using the following:

MamaMsgIterator i;
for(MamaMsgField field = msg.begin(i); ...; field =  *++i) {
    field.getVectorMsg(...);
}

Note that field is not reference but object.

When calling getVectorMsg() the array of pointers (mLastVectorMsg) is allocated by malloc but when we assign a new value to the field (field = *++i) the allocated array becomes unreachable and can't be deleted. Overloaded assignment operator calling clear before assignment can solve this.
Signed-off-by: Victor Maleyev <imnotmindlin@yandex.ru>

From c036b0726464916b2e49d6b1297a2a82404c0359 Mon Sep 17 00:00:00 2001
From: Victor Maleyev <imnotmindlin@yandex.ru>
Date: Fri, 3 Nov 2017 00:14:05 +0300
Subject: [PATCH] Fixed memory leak in MamaMsgField

Signed-off-by: Victor Maleyev <imnotmindlin@yandex.ru>
---
 mama/c_cpp/src/cpp/MamaMsgField.cpp | 15 +++++++++++++++
 mama/c_cpp/src/cpp/mama/MamaMsgField.h | 6 ++++++
 2 files changed, 21 insertions(+)

diff --git a/mama/c_cpp/src/cpp/MamaMsgField.cpp b/mama/c_cpp/src/cpp/MamaMsgField.cpp
index f2f287c..2cf1270 100644
--- a/mama/c_cpp/src/cpp/MamaMsgField.cpp
+++ b/mama/c_cpp/src/cpp/MamaMsgField.cpp
@@ -47,6 +47,21 @@ namespace Wombat
     {
     }

+ MamaMsgField::MamaMsgField (const MamaMsgField& field)
+ : mField (field.mField)
+ , mFieldDesc (NULL)
+ , mLastVectorMsg (NULL)
+ , mLastVectorMsgLen (0)
+ {
+ }
+
+ MamaMsgField& MamaMsgField::operator= (const MamaMsgField& field)
+ {
+ clear();
+ mField = field.mField;
+ return *this;
+ }
+
     void MamaMsgField::clear ()
     {
         if (mFieldDesc)
diff --git a/mama/c_cpp/src/cpp/mama/MamaMsgField.h b/mama/c_cpp/src/cpp/mama/MamaMsgField.h
index b9b9e73..d8f45b1 100644
--- a/mama/c_cpp/src/cpp/mama/MamaMsgField.h
+++ b/mama/c_cpp/src/cpp/mama/MamaMsgField.h
@@ -50,6 +50,12 @@ namespace Wombat
         MamaMsgField (
             mamaMsgField field);

+ MamaMsgField (
+ const MamaMsgField& field);
+
+ MamaMsgField& operator= (
+ const MamaMsgField& field);
+
         /**
          * Clear the field.
          */
--
2.13.3
-------- Конец пересылаемого сообщения --------


Re: Did MAMAIgnoreDeprecatedOpen ever work on Linux? [I]

Yury Batrakov
 

Classification: Public

Thanks for the details guys!

 

From: Frank Quinn [mailto:fquinn.ni@...]
Sent: Tuesday, October 03, 2017 8:53 PM
To: Yury Batrakov <yury.batrakov@...>
Cc: Damian Maguire <dmaguire@...>; openmama-users <openmama-users@...>; openmama-dev <openmama-dev@...>
Subject: Re: [Openmama-dev] Did MAMAIgnoreDeprecatedOpen ever work on Linux? [I]

 

Hi Yury,

 

Yes that method is deprecated because OpenMAMA prefers dynamic loading methods now (so that payloads don't need to be registered in OpenMAMA's core code to load or depend on magic characters).

 

Have you looked at mamaMsg_createForPayloadBridge? It should do the same thing, but accepts a payload bridge rather than a char identifier and is not deprecated.

 

Damian also provided some helper functions included 6.2.1 to help look up bridges by name which might be helpful for lookup and cache, including mama_getPayloadBridge.

 

Cheers,

Frank

 

On Tue, Oct 3, 2017 at 10:07 AM, Yury Batrakov <yury.batrakov@...> wrote:

Classification: For internal use only

Hey Damian,

 

OK, thank you for clarification. The reason why I thought that deprecation warnings should be deleted automatically (after defining MAMA_DLL and BRIDGE preprocessor variables) is the following declaration of mamaMsg_createForPayload

MAMAIgnoreDeprecatedOpen

MAMAExpDeprecatedDLL(

        "mamaMsg_createForPayload has been deprecated, use dynamic loading instead!")

extern mama_status

mamaMsg_createForPayload (mamaMsg* msg, const char id);

MAMAIgnoreDeprecatedClose

 

The background of this question is: I’m writing a middleware bridge which always has to create messages for specific payload - it’s a problem because mamaMsg_createForPayload is deprecated and mamaMsg_create creates messages for “default” payload - the payload initialized by a first bridge created by OpenMAMA. This will be a problem when two or more bridges are loaded to a process.

 

 

From: Damian Maguire [mailto:dmaguire@...]
Sent: Tuesday, October 03, 2017 10:27 AM
To: Yury Batrakov <yury.batrakov@...>; openmama-users <openmama-users@...>; openmama-dev <openmama-dev@...>
Subject: Re: Did MAMAIgnoreDeprecatedOpen ever work on Linux?

 

Hey Yury,

 

I'm not sure the behaviour you're describing is an issue - the purpose of the pragma's is to allow you to use 'deprecated' features of the API without generating warnings, rather than disable the deprecation completely. For example, when we implemented dynamic loading, we deprecated the 'mamaPayloadType' here. However, in order to support legacy clients, we continue to use the type within the MAMA codebase. We generally aim to be 'warning free' in the code, and understand the risks associated with using the type, so where we make use of mamaPayloadType we mark them with MamaIgnoreDeprecatedOpen and MamaIgnoreDeprecatedClose pragma's. This disables the deprecation specific warnings at those sites - for example, here.

 

Using your code, the equivalent would be:

 

int __attribute__((deprecated)) b() {

   return 0;

}

 

int main() {

        printf("GCC %d %d\n" , __GNUC__, __GNUC_MINOR__);

MamaIgnoreDeprecatedOpen

        b();

MamaIgnoreDeprecatedClose

        return 0;

}

 

Which shouldn't warn about the use of b();.

 

Let me know if that makes sense, or if you have further questions around this.

 

Thanks,

 

Damian

 

 

DAMIAN MAGUIRE 

Senior Sales Engineer 

 

 

Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD  

velatradingtech.com | @vela_tt

 

 


From: openmama-dev-bounces@... <openmama-dev-bounces@...> on behalf of Yury Batrakov <yury.batrakov@...>
Sent: 02 October 2017 17:16
To: openmama-users; openmama-dev
Subject: [Openmama-dev] Did MAMAIgnoreDeprecatedOpen ever work on Linux?

 

Classification: Public

Hi team,

 

Is MAMAIgnoreDeprecatedOpen supposed to work for Linux with gcc > 4.6?

See the following example:

 

// Next 3 lines were copied from wombat/…/linux/port.h

_Pragma ("GCC diagnostic push")

_Pragma ("GCC diagnostic ignored \"-Wdeprecated\"")

_Pragma ("GCC diagnostic ignored \"-Wdeprecated-declarations\"")

 

int __attribute__((deprecated)) b() {

   return 0;

}

 

_Pragma ("GCC diagnostic pop")

 

int main() {

        printf("GCC %d %d\n" , __GNUC__, __GNUC_MINOR__);

        b();

        return 0;

}

 

When compiling with 4.8 it shows the following warnings anyway:

/opt/gcc/gcc-4.8.1/bin/g++ -Wall -Wextra 123.c

123.c: In function ‘int main()’:

123.c:15:9: warning: ‘int b()’ is deprecated (declared at 123.c:7) [-Wdeprecated-declarations]

         b();

         ^

123.c:15:11: warning: ‘int b()’ is deprecated (declared at 123.c:7) [-Wdeprecated-declarations]

         b();

           ^

 

But if we place those pragmas around invocation of b() (not around the definition) all warnings go away



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


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. Vela Trading Technologies LLC



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

 



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

181 - 200 of 2300