[Quickfix-developers] RE: Infinite loop when receiving bad message in threaded acceptor

[Yihu F. <Yih...@re...>]

Hi,

=20

To stop the infinite loop, in catch(MessageParseError &e) of
Parser::readFixMessage(), the m_buffer should be emptied. Because pos
and length are zero, the bad message in m_buffer is reused which causes
the infinite loop.

=20

QuickFIX 1.9.4

117,118c117

<     // m_buffer.erase( 0, pos + length );

<         m_buffer.erase();

---

>     m_buffer.erase( 0, pos + length );

=20

Whether QF is going to decide to terminate the session or not should be
done in the ThreadedSocketConnection.

=20

Thanks,

=20

-Yihu

=20

  _____ =20

From: Yihu Fang=20
Sent: Tuesday, February 22, 2005 2:09 PM
To: 'Oren Miller'; qui...@li...
Subject: Infinite loop when receiving bad message in threaded acceptor

=20

Oren,

=20

When a threaded acceptor receives a garbled message, e.g. invalid length
field, during an established FIX session, the QuickFIX engine runs into
an infinite loop.

=20

An example garbles message is like this,
8=3DTEST9=3DTEST35=3DTEST49=3DSS156=3DRORE34=3D352=3D20050222-16:45:5310=3D=
TEST

=20

Parser::extractLength() throws a MessageParserError exception because of
field 9=3DTEST.

=20

ThreadSocketConnection::readMessage() catches the exception but it does
nothing and returns true.

=20

This causes an infinite loop in the
ThreadedSocketConnection::readQueue(). An empty string is passed to
Session::next(), an InvalidMessage exception is thrown. However, because
the session is in a logon on state, the session is not disconnected, but
keeps going.

=20

The session should be disconnected in the exception catch of either
MessageParserError or InvalidMessage.

=20

Thank you,

=20

-Yihu



-----------------------------------------------------------------
        Visit our Internet site at http://www.reuters.com

Get closer to the financial markets with Reuters Messaging - for more
information and to register, visit http://www.reuters.com/messaging

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.