[Quickfix-users] Memory leak?

[Monheit, D. <Dav...@ci...>]

Hi

 

I am experiencing SEVERE memory leakage.  Our app handles 12,000,000 fix
messages from 8:00 till 4:30PM.  It cores at around 3:00 - 3:30 with a
memory footprint of > 2.5 gb !!!!

 

Here are some simple ways to duplicate this (I tested this on version
1.12.2, 1.12.3 and 1.12.4 (this morning)).

 

NO LEAK: Instantiating a FIX::Message from a string.

 

while (getline(infile, line, '\n'))

{

linecount++;

FIX::Message fixmsg(line, false); 

Parse(&fixmsg); 

            }

 

LEAK 1: Instantiating a FIX::Message from another FIX::Message.  This
leaks even if no data dictionaries are being used.

 

void Application::fromApp( const FIX::Message& message, const
FIX::SessionID& sessionID )

throw( FIX::FieldNotFound, FIX::IncorrectDataFormat,
FIX::IncorrectTagValue, FIX::UnsupportedMessageType )

{

            FIX::Message *p = new FIX::Message( message );

delete p;

}

 

NO LEAK - Amazing - same as above but instantiate the message from a
string again.  Double parsing but no leak

 

void Application::fromApp( const FIX::Message& message, const
FIX::SessionID& sessionID )

throw( FIX::FieldNotFound, FIX::IncorrectDataFormat,
FIX::IncorrectTagValue, FIX::UnsupportedMessageType )

{

            FIX::Message *p = new FIX::Message( message.toString() );

delete p;

}

 

No LEAK - when using data dictionary to instantiate a fix message

 

            DataDictionary dd is a member of the Application class.

 

            Application::Application()

{

FIX::DataDictionary dd2;

            dd2.addField( 134 );

            dd2.addField( 9167 );

            dd2.addField( 132 );

            dd2.addField( 135 );

            dd2.addField( 9168 );

            dd2.addField( 133 );

            dd2.checkFieldsHaveValues(false);

            dd2.checkFieldsOutOfOrder(false);

            dd2.checkUserDefinedFields(false);

 

            dd.addGroup( "U0004", 9917, 134, dd2);

            dd.checkFieldsHaveValues(false);

            dd.checkFieldsOutOfOrder(false);

            dd.checkUserDefinedFields(false);

}

 

void Application::fromApp( const FIX::Message& message, const
FIX::SessionID& sessionID )

throw( FIX::FieldNotFound, FIX::IncorrectDataFormat,
FIX::IncorrectTagValue, FIX::UnsupportedMessageType )

{

FIX::Message *p = new FIX::Message( message.toString(), dd );

delete p;

            }

 

LEAK LEAK LEAK - This is really amazing in how much it leaks

 

void Application::fromApp( const FIX::Message& message, const
FIX::SessionID& sessionID )

throw( FIX::FieldNotFound, FIX::IncorrectDataFormat,
FIX::IncorrectTagValue, FIX::UnsupportedMessageType )

{

FIX::Message *p = new FIX::Message( message.toString(), dd );

 

            if(p->getHeader().getField(35) == "U0004")

            {

                        FIX::Group g( 9917, 134,
FIX::message_order(134,9167,132,135,9168,133,0) );  // IF NOT STATIC,
THIS LEAKS

                        int numLimits = atoi(p->getField(9917).c_str());
for ( int i=0; i < 5; i++ )

                        {

                                    p->getGroup( i+1, g  );  // THIS
CAUSES THE LEAK

                        }

}           

delete p;

            }

 

Some additional observations:

 

*	The creation of FIX::Group g on the stack causes a leak.  If I
change that to a static it does not leak anymore.
*	The call to getGroup leaks galore :-)

 

Am I using the library incorrectly?  Any ideas or clues will be much
appreciated.

 

Regards

David

 

-------------------------------------------------------

David Monheit

Citadel Investment Group (Europe) Ltd

Tel   +44 (0) 20 7645 9715

Mob +44 (0) 7968 988 218

 


------------------------------------------------------------------------
------------------------------------------------------------------------
--

The contents of this message and any attachments may be privileged,
confidential and proprietary. If you are not an intended recipient,
please inform the sender of the transmission error and delete this
message immediately without reading, disseminating, distributing or
copying the contents. Citadel makes no assurances that this e-mail and
any attachments are free of viruses and other harmful code. 

Citadel Investment Group (Europe) Ltd is authorized and regulated by the
Financial Services Authority (FSA Firm Ref No 190260). 
Registered in England and Wales. Registration No. 3666898. 
Registered Office: 10th Floor, 2 George Yard, Lombard Street, London
EC3V 9DH.