quickfix-developers

RE: [Quickfix-developers] MS VC++ release builds

[Timothy Y. <Tim...@pa...>]

The callstack is not enabled.

Tim.

-----Original Message-----
From: Oren Miller [mailto:or...@qu...]
Sent: Monday, June 14, 2004 9:32 AM
To: Timothy Yates
Cc: qui...@li...
Subject: Re: [Quickfix-developers] MS VC++ release builds


Do you have the callstack enabled?

--oren

On Jun 14, 2004, at 8:39 AM, Timothy Yates wrote:

> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: http://www.quickfixengine.org/quickfix/doc/html/FAQ.html
>
> Has anyone else had problems with apparently random crashes and memory
> corruptions in quickfix when using MS VC++, specifically using the 
> default
> release build options?
>
> We have a C++ production application that uses quickfix.  We have had 
> to
> build quickfix with all optimizations turned off.  We were unable to 
> track
> down the memory corruptions that occurred with a release build.
>
> Recently, I have been using the Java version of quickfix.  I have a 
> test
> application that generates MarketDataSnapshotFullRefresh messages  and
> populates them with essentially random price data.  The receiving
> application sends a subscribe message and the test application starts
> sending refresh messages at a rate of about 20 per second.  When using 
> a
> release build of quickfix_jni.dll, the receiving application often 
> crashes
> after several hundred messages due to an access violation.  This 
> typically
> occurs in the destructor call from Message.finalize(), other times in
> Group.finalize(), and othertime some place else.   I do a session reset
> between test runs.  Sometimes the application does not crash at all.   
> I
> have tried disabling all processing of refresh messages by the 
> receiving
> application (so it just returns from fromApp without doing anything), 
> and
> the crashes still happen.
>
> The random nature of the crashes leads me to suspect a threading issue.
>
> When I use a debug build of quickfix_jni.dll, I can never get it to 
> crash.
> This might just be luck, or it might indicate a problem with compiler
> optimizations.
>
> I think this problem may have something to do with repeating groups as 
> I
> have only started noticing it since implementing market data support.
> However, it could just be that I have started stressing quickfix more 
> than
> before.
>
> Interestingly, the corruptions we were experiencing in our production 
> C++
> application also occurred when there was a large amount of market data
> traffic.
>
> I am using quickfix 1.7.0.
>
> Tim Yates
> Lead Developer
> Patsystems (US) LLC
> 141 West Jackson Boulevard
> Chicago 60604, USA
> Tel +1 (312) 542-1336
> www.patsystems.com
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> From Windows to Linux, servers to mobile, InstallShield X is the
> one installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

RE: [Quickfix-developers] MS VC++ release builds

[Timothy Y. <Tim...@pa...>]

Hi Antonio,

I mentioned two distinct problems in my original email.

The first of these related to random corruptions of field data in FIX
messages, especially during periods of heavy traffic.  These problems
occurred in an MS VC++ quickfix application.  Once or twice, we saw the same
CompID error you refer to. Typically, the corrupted field data contained
parts of other FIX fields from the same message.

We were never able to track down the cause of these corruptions -- we found
the problem very hard to reproduce. However, turning off compiler
optimizations did seem to improve the situation considerably.  If you can
find out the cause of this probem, I would be very interested.

The second problem related to the Java version of QuickFIX on Windows XP.
This problem seems to be related to hyperthreading (possibly in combination
with hot-spot compilation).  When I disabled hyperthreading on the host
machine, this problem went away -- it doesn't seem to be related to the
first problem as I initially thought.

Tim

-----Original Message-----
From: Antonio Caroselli [mailto:ant...@ga...]
Sent: Friday, August 20, 2004 3:53 AM
To: Timothy Yates
Cc: 'Oren Miller'; qui...@li...
Subject: Re: [Quickfix-developers] MS VC++ release builds


Dear Tim,

We are experiencing the same problems described in your email dated June
14/2004.

We are using MS VC++ 6 SP5 with default compilation and link options and
QuickFix 1.7.1. The target application is being run under Windows Server
2000 SP4.

In most cases we detected memory errors on incoming messages: we often get
the error "Message nn rejected: CompID problem" even if the FIX message
logged in our log file via the QuickFix log function shows correct tags and
values. It may happen that we have such a problem once or twice in a day
under heavy traffic conditions, mostly on incoming messages. In few cases
this possible memory problem also caused outgoing messages to be truncated.

At times (not always) this problem is followed by an application crash: we
do not get any application fault window since the application simply
disappears from the Task Manager.

I have seen Oren's suggestion about the callstack. Did that help you solve
your problem ? We might try and use QuickFix 1.8.0, but the release notes do
not seem to address this problem.

Any help will be greatly appreciated

Bye,

Antonio Caroselli
GATE T.I.
www.gatelab.com



----- Original Message -----
From: "Timothy Yates" <Tim...@pa...>
To: "'Oren Miller'" <or...@qu...>
Cc: <qui...@li...>
Sent: Monday, June 14, 2004 5:30 PM
Subject: RE: [Quickfix-developers] MS VC++ release builds


> QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: http://www.quickfixengine.org/quickfix/doc/html/FAQ.html
>
> The callstack is not enabled.
>
> Tim.
>
> -----Original Message-----
> From: Oren Miller [mailto:or...@qu...]
> Sent: Monday, June 14, 2004 9:32 AM
> To: Timothy Yates
> Cc: qui...@li...
> Subject: Re: [Quickfix-developers] MS VC++ release builds
>
>
> Do you have the callstack enabled?
>
> --oren
>
> On Jun 14, 2004, at 8:39 AM, Timothy Yates wrote:
>
> > QuickFIX Documentation:
> > http://www.quickfixengine.org/quickfix/doc/html/index.html
> > QuickFIX FAQ: http://www.quickfixengine.org/quickfix/doc/html/FAQ.html
> >
> > Has anyone else had problems with apparently random crashes and memory
> > corruptions in quickfix when using MS VC++, specifically using the
> > default
> > release build options?
> >
> > We have a C++ production application that uses quickfix.  We have had
> > to
> > build quickfix with all optimizations turned off.  We were unable to
> > track
> > down the memory corruptions that occurred with a release build.
> >
> > Recently, I have been using the Java version of quickfix.  I have a
> > test
> > application that generates MarketDataSnapshotFullRefresh messages  and
> > populates them with essentially random price data.  The receiving
> > application sends a subscribe message and the test application starts
> > sending refresh messages at a rate of about 20 per second.  When using
> > a
> > release build of quickfix_jni.dll, the receiving application often
> > crashes
> > after several hundred messages due to an access violation.  This
> > typically
> > occurs in the destructor call from Message.finalize(), other times in
> > Group.finalize(), and othertime some place else.   I do a session reset
> > between test runs.  Sometimes the application does not crash at all.
> > I
> > have tried disabling all processing of refresh messages by the
> > receiving
> > application (so it just returns from fromApp without doing anything),
> > and
> > the crashes still happen.
> >
> > The random nature of the crashes leads me to suspect a threading issue.
> >
> > When I use a debug build of quickfix_jni.dll, I can never get it to
> > crash.
> > This might just be luck, or it might indicate a problem with compiler
> > optimizations.
> >
> > I think this problem may have something to do with repeating groups as
> > I
> > have only started noticing it since implementing market data support.
> > However, it could just be that I have started stressing quickfix more
> > than
> > before.
> >
> > Interestingly, the corruptions we were experiencing in our production
> > C++
> > application also occurred when there was a large amount of market data
> > traffic.
> >
> > I am using quickfix 1.7.0.
> >
> > Tim Yates
> > Lead Developer
> > Patsystems (US) LLC
> > 141 West Jackson Boulevard
> > Chicago 60604, USA
> > Tel +1 (312) 542-1336
> > www.patsystems.com
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by the new InstallShield X.
> > From Windows to Linux, servers to mobile, InstallShield X is the
> > one installation-authoring solution that does it all. Learn more and
> > evaluate today! http://www.installshield.com/Dev2Dev/0504
> > _______________________________________________
> > Quickfix-developers mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> >
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> >From Windows to Linux, servers to mobile, InstallShield X is the
> one installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] MS VC++ release builds

[Antonio C. <ant...@ga...>]

Dear Tim,

Thank you for your contribution. Even if you mentioned hyperthreading  for
the second problem only [related to the Java version of QuickFix], we
experienced the first problem under Windows 2000 SP4 on a computer with two
XEON processors plus hyperthreading (actually we see 4 processor performance
sub-windows when the Task Manager window is opened). We shall use your
suggestion about compiler optimizations, and also we shall run more tests on
different HW (both mono and dual processors) even if slower processors might
reduce the risk of concurrent access to memory.

Bye,

Antonio Caroselli
GATE T.I.
www.gatelab.com



----- Original Message -----
From: "Timothy Yates" <Tim...@pa...>
To: "'Antonio Caroselli'" <ant...@ga...>
Cc: "'Oren Miller'" <or...@qu...>;
<qui...@li...>
Sent: Friday, August 20, 2004 3:20 PM
Subject: RE: [Quickfix-developers] MS VC++ release builds


> QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi Antonio,
>
> I mentioned two distinct problems in my original email.
>
> The first of these related to random corruptions of field data in FIX
> messages, especially during periods of heavy traffic.  These problems
> occurred in an MS VC++ quickfix application.  Once or twice, we saw the
same
> CompID error you refer to. Typically, the corrupted field data contained
> parts of other FIX fields from the same message.
>
> We were never able to track down the cause of these corruptions -- we
found
> the problem very hard to reproduce. However, turning off compiler
> optimizations did seem to improve the situation considerably.  If you can
> find out the cause of this probem, I would be very interested.
>
> The second problem related to the Java version of QuickFIX on Windows XP.
> This problem seems to be related to hyperthreading (possibly in
combination
> with hot-spot compilation).  When I disabled hyperthreading on the host
> machine, this problem went away -- it doesn't seem to be related to the
> first problem as I initially thought.
>
> Tim
>
> -----Original Message-----
> From: Antonio Caroselli [mailto:ant...@ga...]
> Sent: Friday, August 20, 2004 3:53 AM
> To: Timothy Yates
> Cc: 'Oren Miller'; qui...@li...
> Subject: Re: [Quickfix-developers] MS VC++ release builds
>
>
> Dear Tim,
>
> We are experiencing the same problems described in your email dated June
> 14/2004.
>
> We are using MS VC++ 6 SP5 with default compilation and link options and
> QuickFix 1.7.1. The target application is being run under Windows Server
> 2000 SP4.
>
> In most cases we detected memory errors on incoming messages: we often get
> the error "Message nn rejected: CompID problem" even if the FIX message
> logged in our log file via the QuickFix log function shows correct tags
and
> values. It may happen that we have such a problem once or twice in a day
> under heavy traffic conditions, mostly on incoming messages. In few cases
> this possible memory problem also caused outgoing messages to be
truncated.
>
> At times (not always) this problem is followed by an application crash: we
> do not get any application fault window since the application simply
> disappears from the Task Manager.
>
> I have seen Oren's suggestion about the callstack. Did that help you solve
> your problem ? We might try and use QuickFix 1.8.0, but the release notes
do
> not seem to address this problem.
>
> Any help will be greatly appreciated
>
> Bye,
>
> Antonio Caroselli
> GATE T.I.
> www.gatelab.com
>
>
>
> ----- Original Message -----
> From: "Timothy Yates" <Tim...@pa...>
> To: "'Oren Miller'" <or...@qu...>
> Cc: <qui...@li...>
> Sent: Monday, June 14, 2004 5:30 PM
> Subject: RE: [Quickfix-developers] MS VC++ release builds
>
>
> > QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> > QuickFIX FAQ: http://www.quickfixengine.org/quickfix/doc/html/FAQ.html
> >
> > The callstack is not enabled.
> >
> > Tim.
> >
> > -----Original Message-----
> > From: Oren Miller [mailto:or...@qu...]
> > Sent: Monday, June 14, 2004 9:32 AM
> > To: Timothy Yates
> > Cc: qui...@li...
> > Subject: Re: [Quickfix-developers] MS VC++ release builds
> >
> >
> > Do you have the callstack enabled?
> >
> > --oren
> >
> > On Jun 14, 2004, at 8:39 AM, Timothy Yates wrote:
> >
> > > QuickFIX Documentation:
> > > http://www.quickfixengine.org/quickfix/doc/html/index.html
> > > QuickFIX FAQ: http://www.quickfixengine.org/quickfix/doc/html/FAQ.html
> > >
> > > Has anyone else had problems with apparently random crashes and memory
> > > corruptions in quickfix when using MS VC++, specifically using the
> > > default
> > > release build options?
> > >
> > > We have a C++ production application that uses quickfix.  We have had
> > > to
> > > build quickfix with all optimizations turned off.  We were unable to
> > > track
> > > down the memory corruptions that occurred with a release build.
> > >
> > > Recently, I have been using the Java version of quickfix.  I have a
> > > test
> > > application that generates MarketDataSnapshotFullRefresh messages  and
> > > populates them with essentially random price data.  The receiving
> > > application sends a subscribe message and the test application starts
> > > sending refresh messages at a rate of about 20 per second.  When using
> > > a
> > > release build of quickfix_jni.dll, the receiving application often
> > > crashes
> > > after several hundred messages due to an access violation.  This
> > > typically
> > > occurs in the destructor call from Message.finalize(), other times in
> > > Group.finalize(), and othertime some place else.   I do a session
reset
> > > between test runs.  Sometimes the application does not crash at all.
> > > I
> > > have tried disabling all processing of refresh messages by the
> > > receiving
> > > application (so it just returns from fromApp without doing anything),
> > > and
> > > the crashes still happen.
> > >
> > > The random nature of the crashes leads me to suspect a threading
issue.
> > >
> > > When I use a debug build of quickfix_jni.dll, I can never get it to
> > > crash.
> > > This might just be luck, or it might indicate a problem with compiler
> > > optimizations.
> > >
> > > I think this problem may have something to do with repeating groups as
> > > I
> > > have only started noticing it since implementing market data support.
> > > However, it could just be that I have started stressing quickfix more
> > > than
> > > before.
> > >
> > > Interestingly, the corruptions we were experiencing in our production
> > > C++
> > > application also occurred when there was a large amount of market data
> > > traffic.
> > >
> > > I am using quickfix 1.7.0.
> > >
> > > Tim Yates
> > > Lead Developer
> > > Patsystems (US) LLC
> > > 141 West Jackson Boulevard
> > > Chicago 60604, USA
> > > Tel +1 (312) 542-1336
> > > www.patsystems.com
> > >
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by the new InstallShield X.
> > > From Windows to Linux, servers to mobile, InstallShield X is the
> > > one installation-authoring solution that does it all. Learn more and
> > > evaluate today! http://www.installshield.com/Dev2Dev/0504
> > > _______________________________________________
> > > Quickfix-developers mailing list
> > > Qui...@li...
> > > https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> > >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by the new InstallShield X.
> > >From Windows to Linux, servers to mobile, InstallShield X is the
> > one installation-authoring solution that does it all. Learn more and
> > evaluate today! http://www.installshield.com/Dev2Dev/0504
> > _______________________________________________
> > Quickfix-developers mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> >
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

RE: [Quickfix-developers] MS VC++ release builds

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

Hi Antonio and Tim,

It would be interesting to see what the real cause of the problems.

We have been using MS VC7 compiler (Visual Studio .NET 2003) on Windows
2003 and XP and did not see the corrupted fields and reject messages.
Maybe we should examine them more carefully.

A few questions: (1) if the QuickFIX log shows correct FIX messages
while the application shows error and rejects message, does it imply
something wrong in the implementation of the application? (2) Is the
application using the same compiler options as the QuickFIX library,
e.g. multiplethread dll settings etc? (3) Is there any memory leak seen
in the application after a long period of time?

Thanks.

-Yihu

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Timothy Yates
Sent: Friday, August 20, 2004 9:21 AM
To: 'Antonio Caroselli'
Cc: 'Oren Miller'; qui...@li...
Subject: RE: [Quickfix-developers] MS VC++ release builds

QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX FAQ:
http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
QuickFIX Support: http://www.quickfixengine.org/services.html

Hi Antonio,

I mentioned two distinct problems in my original email.

The first of these related to random corruptions of field data in FIX
messages, especially during periods of heavy traffic.  These problems
occurred in an MS VC++ quickfix application.  Once or twice, we saw the
same
CompID error you refer to. Typically, the corrupted field data contained
parts of other FIX fields from the same message.

We were never able to track down the cause of these corruptions -- we
found
the problem very hard to reproduce. However, turning off compiler
optimizations did seem to improve the situation considerably.  If you
can
find out the cause of this probem, I would be very interested.

The second problem related to the Java version of QuickFIX on Windows
XP.
This problem seems to be related to hyperthreading (possibly in
combination
with hot-spot compilation).  When I disabled hyperthreading on the host
machine, this problem went away -- it doesn't seem to be related to the
first problem as I initially thought.

Tim

-----Original Message-----
From: Antonio Caroselli [mailto:ant...@ga...]
Sent: Friday, August 20, 2004 3:53 AM
To: Timothy Yates
Cc: 'Oren Miller'; qui...@li...
Subject: Re: [Quickfix-developers] MS VC++ release builds


Dear Tim,

We are experiencing the same problems described in your email dated June
14/2004.

We are using MS VC++ 6 SP5 with default compilation and link options and
QuickFix 1.7.1. The target application is being run under Windows Server
2000 SP4.

In most cases we detected memory errors on incoming messages: we often
get
the error "Message nn rejected: CompID problem" even if the FIX message
logged in our log file via the QuickFix log function shows correct tags
and
values. It may happen that we have such a problem once or twice in a day
under heavy traffic conditions, mostly on incoming messages. In few
cases
this possible memory problem also caused outgoing messages to be
truncated.

At times (not always) this problem is followed by an application crash:
we
do not get any application fault window since the application simply
disappears from the Task Manager.

I have seen Oren's suggestion about the callstack. Did that help you
solve
your problem ? We might try and use QuickFix 1.8.0, but the release
notes do
not seem to address this problem.

Any help will be greatly appreciated

Bye,

Antonio Caroselli
GATE T.I.
www.gatelab.com



----- Original Message -----
From: "Timothy Yates" <Tim...@pa...>
To: "'Oren Miller'" <or...@qu...>
Cc: <qui...@li...>
Sent: Monday, June 14, 2004 5:30 PM
Subject: RE: [Quickfix-developers] MS VC++ release builds


> QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: http://www.quickfixengine.org/quickfix/doc/html/FAQ.html
>
> The callstack is not enabled.
>
> Tim.
>
> -----Original Message-----
> From: Oren Miller [mailto:or...@qu...]
> Sent: Monday, June 14, 2004 9:32 AM
> To: Timothy Yates
> Cc: qui...@li...
> Subject: Re: [Quickfix-developers] MS VC++ release builds
>
>
> Do you have the callstack enabled?
>
> --oren
>
> On Jun 14, 2004, at 8:39 AM, Timothy Yates wrote:
>
> > QuickFIX Documentation:
> > http://www.quickfixengine.org/quickfix/doc/html/index.html
> > QuickFIX FAQ:
http://www.quickfixengine.org/quickfix/doc/html/FAQ.html
> >
> > Has anyone else had problems with apparently random crashes and
memory
> > corruptions in quickfix when using MS VC++, specifically using the
> > default
> > release build options?
> >
> > We have a C++ production application that uses quickfix.  We have
had
> > to
> > build quickfix with all optimizations turned off.  We were unable to
> > track
> > down the memory corruptions that occurred with a release build.
> >
> > Recently, I have been using the Java version of quickfix.  I have a
> > test
> > application that generates MarketDataSnapshotFullRefresh messages
and
> > populates them with essentially random price data.  The receiving
> > application sends a subscribe message and the test application
starts
> > sending refresh messages at a rate of about 20 per second.  When
using
> > a
> > release build of quickfix_jni.dll, the receiving application often
> > crashes
> > after several hundred messages due to an access violation.  This
> > typically
> > occurs in the destructor call from Message.finalize(), other times
in
> > Group.finalize(), and othertime some place else.   I do a session
reset
> > between test runs.  Sometimes the application does not crash at all.
> > I
> > have tried disabling all processing of refresh messages by the
> > receiving
> > application (so it just returns from fromApp without doing
anything),
> > and
> > the crashes still happen.
> >
> > The random nature of the crashes leads me to suspect a threading
issue.
> >
> > When I use a debug build of quickfix_jni.dll, I can never get it to
> > crash.
> > This might just be luck, or it might indicate a problem with
compiler
> > optimizations.
> >
> > I think this problem may have something to do with repeating groups
as
> > I
> > have only started noticing it since implementing market data
support.
> > However, it could just be that I have started stressing quickfix
more
> > than
> > before.
> >
> > Interestingly, the corruptions we were experiencing in our
production
> > C++
> > application also occurred when there was a large amount of market
data
> > traffic.
> >
> > I am using quickfix 1.7.0.
> >
> > Tim Yates
> > Lead Developer
> > Patsystems (US) LLC
> > 141 West Jackson Boulevard
> > Chicago 60604, USA
> > Tel +1 (312) 542-1336
> > www.patsystems.com
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by the new InstallShield X.
> > From Windows to Linux, servers to mobile, InstallShield X is the
> > one installation-authoring solution that does it all. Learn more and
> > evaluate today! http://www.installshield.com/Dev2Dev/0504
> > _______________________________________________
> > Quickfix-developers mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> >
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> >From Windows to Linux, servers to mobile, InstallShield X is the
> one installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers



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

Re: [Quickfix-developers] MS VC++ release builds

[Antonio C. <ant...@ga...>]

Hi, Yihu and Tim.

As you might have seen from my colleage's email to this newsgroup: "****
VERY IMPORTANT ***** Crashes in QuickFIX compiled with MS VC++ 6.0" sent out
yesterday, the reason for memory corruption and random crashes is the use of
STL strings in the QuickFix library when running our application in a
multithreading environment (see
http://support.microsoft.com/default.aspx?scid=kb;en-us;813810 ).

We have been using MS VC++ 6 - SP5 to compile and link our application,
which has been deployed under Windows 2000 SP4 on a computer with two XEON
processors plus hyperthreading enabled.

Both Oren and Microsoft suggest to try a different STL from different
suppliers (www.stlport.org [FREE] and www.dinkumware.com [NOT FREE]), which
might be a good choice if we want to keep using MS VC++ 6. On the contrary,
we might compile our application with Visual Studio .NET which seems to have
a thread-safe STL. Probably we shall try both options and go through a new
set of stress tests before taking a final decision.

Anyway, we would avoid those code manipulations suggested by Microsoft since
that might unearth new problems in other areas.

Bye,

Antonio Caroselli
GATE T.I.
www.gatelab.com



----- Original Message -----
From: "Yihu Fang" <Yih...@re...>
To: "Timothy Yates" <Tim...@pa...>; "Antonio Caroselli"
<ant...@ga...>
Cc: "Oren Miller" <or...@qu...>;
<qui...@li...>
Sent: Friday, August 20, 2004 9:10 PM
Subject: RE: [Quickfix-developers] MS VC++ release builds


QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
QuickFIX Support: http://www.quickfixengine.org/services.html

Hi Antonio and Tim,

It would be interesting to see what the real cause of the problems.

We have been using MS VC7 compiler (Visual Studio .NET 2003) on Windows
2003 and XP and did not see the corrupted fields and reject messages.
Maybe we should examine them more carefully.

A few questions: (1) if the QuickFIX log shows correct FIX messages
while the application shows error and rejects message, does it imply
something wrong in the implementation of the application? (2) Is the
application using the same compiler options as the QuickFIX library,
e.g. multiplethread dll settings etc? (3) Is there any memory leak seen
in the application after a long period of time?

Thanks.

-Yihu

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Timothy Yates
Sent: Friday, August 20, 2004 9:21 AM
To: 'Antonio Caroselli'
Cc: 'Oren Miller'; qui...@li...
Subject: RE: [Quickfix-developers] MS VC++ release builds

QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX FAQ:
http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
QuickFIX Support: http://www.quickfixengine.org/services.html

Hi Antonio,

I mentioned two distinct problems in my original email.

The first of these related to random corruptions of field data in FIX
messages, especially during periods of heavy traffic.  These problems
occurred in an MS VC++ quickfix application.  Once or twice, we saw the
same
CompID error you refer to. Typically, the corrupted field data contained
parts of other FIX fields from the same message.

We were never able to track down the cause of these corruptions -- we
found
the problem very hard to reproduce. However, turning off compiler
optimizations did seem to improve the situation considerably.  If you
can
find out the cause of this probem, I would be very interested.

The second problem related to the Java version of QuickFIX on Windows
XP.
This problem seems to be related to hyperthreading (possibly in
combination
with hot-spot compilation).  When I disabled hyperthreading on the host
machine, this problem went away -- it doesn't seem to be related to the
first problem as I initially thought.

Tim

-----Original Message-----
From: Antonio Caroselli [mailto:ant...@ga...]
Sent: Friday, August 20, 2004 3:53 AM
To: Timothy Yates
Cc: 'Oren Miller'; qui...@li...
Subject: Re: [Quickfix-developers] MS VC++ release builds


Dear Tim,

We are experiencing the same problems described in your email dated June
14/2004.

We are using MS VC++ 6 SP5 with default compilation and link options and
QuickFix 1.7.1. The target application is being run under Windows Server
2000 SP4.

In most cases we detected memory errors on incoming messages: we often
get
the error "Message nn rejected: CompID problem" even if the FIX message
logged in our log file via the QuickFix log function shows correct tags
and
values. It may happen that we have such a problem once or twice in a day
under heavy traffic conditions, mostly on incoming messages. In few
cases
this possible memory problem also caused outgoing messages to be
truncated.

At times (not always) this problem is followed by an application crash:
we
do not get any application fault window since the application simply
disappears from the Task Manager.

I have seen Oren's suggestion about the callstack. Did that help you
solve
your problem ? We might try and use QuickFix 1.8.0, but the release
notes do
not seem to address this problem.

Any help will be greatly appreciated

Bye,

Antonio Caroselli
GATE T.I.
www.gatelab.com



----- Original Message -----
From: "Timothy Yates" <Tim...@pa...>
To: "'Oren Miller'" <or...@qu...>
Cc: <qui...@li...>
Sent: Monday, June 14, 2004 5:30 PM
Subject: RE: [Quickfix-developers] MS VC++ release builds


> QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: http://www.quickfixengine.org/quickfix/doc/html/FAQ.html
>
> The callstack is not enabled.
>
> Tim.
>
> -----Original Message-----
> From: Oren Miller [mailto:or...@qu...]
> Sent: Monday, June 14, 2004 9:32 AM
> To: Timothy Yates
> Cc: qui...@li...
> Subject: Re: [Quickfix-developers] MS VC++ release builds
>
>
> Do you have the callstack enabled?
>
> --oren
>
> On Jun 14, 2004, at 8:39 AM, Timothy Yates wrote:
>
> > QuickFIX Documentation:
> > http://www.quickfixengine.org/quickfix/doc/html/index.html
> > QuickFIX FAQ:
http://www.quickfixengine.org/quickfix/doc/html/FAQ.html
> >
> > Has anyone else had problems with apparently random crashes and
memory
> > corruptions in quickfix when using MS VC++, specifically using the
> > default
> > release build options?
> >
> > We have a C++ production application that uses quickfix.  We have
had
> > to
> > build quickfix with all optimizations turned off.  We were unable to
> > track
> > down the memory corruptions that occurred with a release build.
> >
> > Recently, I have been using the Java version of quickfix.  I have a
> > test
> > application that generates MarketDataSnapshotFullRefresh messages
and
> > populates them with essentially random price data.  The receiving
> > application sends a subscribe message and the test application
starts
> > sending refresh messages at a rate of about 20 per second.  When
using
> > a
> > release build of quickfix_jni.dll, the receiving application often
> > crashes
> > after several hundred messages due to an access violation.  This
> > typically
> > occurs in the destructor call from Message.finalize(), other times
in
> > Group.finalize(), and othertime some place else.   I do a session
reset
> > between test runs.  Sometimes the application does not crash at all.
> > I
> > have tried disabling all processing of refresh messages by the
> > receiving
> > application (so it just returns from fromApp without doing
anything),
> > and
> > the crashes still happen.
> >
> > The random nature of the crashes leads me to suspect a threading
issue.
> >
> > When I use a debug build of quickfix_jni.dll, I can never get it to
> > crash.
> > This might just be luck, or it might indicate a problem with
compiler
> > optimizations.
> >
> > I think this problem may have something to do with repeating groups
as
> > I
> > have only started noticing it since implementing market data
support.
> > However, it could just be that I have started stressing quickfix
more
> > than
> > before.
> >
> > Interestingly, the corruptions we were experiencing in our
production
> > C++
> > application also occurred when there was a large amount of market
data
> > traffic.
> >
> > I am using quickfix 1.7.0.
> >
> > Tim Yates
> > Lead Developer
> > Patsystems (US) LLC
> > 141 West Jackson Boulevard
> > Chicago 60604, USA
> > Tel +1 (312) 542-1336
> > www.patsystems.com
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by the new InstallShield X.
> > From Windows to Linux, servers to mobile, InstallShield X is the
> > one installation-authoring solution that does it all. Learn more and
> > evaluate today! http://www.installshield.com/Dev2Dev/0504
> > _______________________________________________
> > Quickfix-developers mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> >
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> >From Windows to Linux, servers to mobile, InstallShield X is the
> one installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers



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



-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

Re: [Quickfix-developers] MS VC++ release builds

[Oren M. <or...@qu...>]

Also, at the Dinkumware page on VC fixes (VC6 uses an old version of 
dinkumware), they give a couple of suggestions for circumventing the 
problem, one of which is to disable reference counting: 
http://www.dinkumware.com/vc_fixes.html

See the section on Fixes to <xstring>.  This will of course likely 
affect performance.

--oren

On Aug 24, 2004, at 4:52 AM, Antonio Caroselli wrote:

> Hi, Yihu and Tim.
>
> As you might have seen from my colleage's email to this newsgroup: 
> "****
> VERY IMPORTANT ***** Crashes in QuickFIX compiled with MS VC++ 6.0" 
> sent out
> yesterday, the reason for memory corruption and random crashes is the 
> use of
> STL strings in the QuickFix library when running our application in a
> multithreading environment (see
> http://support.microsoft.com/default.aspx?scid=kb;en-us;813810 ).
>
> We have been using MS VC++ 6 - SP5 to compile and link our application,
> which has been deployed under Windows 2000 SP4 on a computer with two 
> XEON
> processors plus hyperthreading enabled.
>
> Both Oren and Microsoft suggest to try a different STL from different
> suppliers (www.stlport.org [FREE] and www.dinkumware.com [NOT FREE]), 
> which
> might be a good choice if we want to keep using MS VC++ 6. On the 
> contrary,
> we might compile our application with Visual Studio .NET which seems 
> to have
> a thread-safe STL. Probably we shall try both options and go through a 
> new
> set of stress tests before taking a final decision.
>
> Anyway, we would avoid those code manipulations suggested by Microsoft 
> since
> that might unearth new problems in other areas.
>
> Bye,
>
> Antonio Caroselli
> GATE T.I.
> www.gatelab.com
>
>
>
> ----- Original Message -----
> From: "Yihu Fang" <Yih...@re...>
> To: "Timothy Yates" <Tim...@pa...>; "Antonio Caroselli"
> <ant...@ga...>
> Cc: "Oren Miller" <or...@qu...>;
> <qui...@li...>
> Sent: Friday, August 20, 2004 9:10 PM
> Subject: RE: [Quickfix-developers] MS VC++ release builds
>
>
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: 
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi Antonio and Tim,
>
> It would be interesting to see what the real cause of the problems.
>
> We have been using MS VC7 compiler (Visual Studio .NET 2003) on Windows
> 2003 and XP and did not see the corrupted fields and reject messages.
> Maybe we should examine them more carefully.
>
> A few questions: (1) if the QuickFIX log shows correct FIX messages
> while the application shows error and rejects message, does it imply
> something wrong in the implementation of the application? (2) Is the
> application using the same compiler options as the QuickFIX library,
> e.g. multiplethread dll settings etc? (3) Is there any memory leak seen
> in the application after a long period of time?
>
> Thanks.
>
> -Yihu
>
> -----Original Message-----
> From: qui...@li...
> [mailto:qui...@li...] On Behalf Of
> Timothy Yates
> Sent: Friday, August 20, 2004 9:21 AM
> To: 'Antonio Caroselli'
> Cc: 'Oren Miller'; qui...@li...
> Subject: RE: [Quickfix-developers] MS VC++ release builds
>
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ:
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi Antonio,
>
> I mentioned two distinct problems in my original email.
>
> The first of these related to random corruptions of field data in FIX
> messages, especially during periods of heavy traffic.  These problems
> occurred in an MS VC++ quickfix application.  Once or twice, we saw the
> same
> CompID error you refer to. Typically, the corrupted field data 
> contained
> parts of other FIX fields from the same message.
>
> We were never able to track down the cause of these corruptions -- we
> found
> the problem very hard to reproduce. However, turning off compiler
> optimizations did seem to improve the situation considerably.  If you
> can
> find out the cause of this probem, I would be very interested.
>
> The second problem related to the Java version of QuickFIX on Windows
> XP.
> This problem seems to be related to hyperthreading (possibly in
> combination
> with hot-spot compilation).  When I disabled hyperthreading on the host
> machine, this problem went away -- it doesn't seem to be related to the
> first problem as I initially thought.
>
> Tim
>
> -----Original Message-----
> From: Antonio Caroselli [mailto:ant...@ga...]
> Sent: Friday, August 20, 2004 3:53 AM
> To: Timothy Yates
> Cc: 'Oren Miller'; qui...@li...
> Subject: Re: [Quickfix-developers] MS VC++ release builds
>
>
> Dear Tim,
>
> We are experiencing the same problems described in your email dated 
> June
> 14/2004.
>
> We are using MS VC++ 6 SP5 with default compilation and link options 
> and
> QuickFix 1.7.1. The target application is being run under Windows 
> Server
> 2000 SP4.
>
> In most cases we detected memory errors on incoming messages: we often
> get
> the error "Message nn rejected: CompID problem" even if the FIX message
> logged in our log file via the QuickFix log function shows correct tags
> and
> values. It may happen that we have such a problem once or twice in a 
> day
> under heavy traffic conditions, mostly on incoming messages. In few
> cases
> this possible memory problem also caused outgoing messages to be
> truncated.
>
> At times (not always) this problem is followed by an application crash:
> we
> do not get any application fault window since the application simply
> disappears from the Task Manager.
>
> I have seen Oren's suggestion about the callstack. Did that help you
> solve
> your problem ? We might try and use QuickFix 1.8.0, but the release
> notes do
> not seem to address this problem.
>
> Any help will be greatly appreciated
>
> Bye,
>
> Antonio Caroselli
> GATE T.I.
> www.gatelab.com
>
>
>
> ----- Original Message -----
> From: "Timothy Yates" <Tim...@pa...>
> To: "'Oren Miller'" <or...@qu...>
> Cc: <qui...@li...>
> Sent: Monday, June 14, 2004 5:30 PM
> Subject: RE: [Quickfix-developers] MS VC++ release builds
>
>
>> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
>> QuickFIX FAQ: http://www.quickfixengine.org/quickfix/doc/html/FAQ.html
>>
>> The callstack is not enabled.
>>
>> Tim.
>>
>> -----Original Message-----
>> From: Oren Miller [mailto:or...@qu...]
>> Sent: Monday, June 14, 2004 9:32 AM
>> To: Timothy Yates
>> Cc: qui...@li...
>> Subject: Re: [Quickfix-developers] MS VC++ release builds
>>
>>
>> Do you have the callstack enabled?
>>
>> --oren
>>
>> On Jun 14, 2004, at 8:39 AM, Timothy Yates wrote:
>>
>>> QuickFIX Documentation:
>>> http://www.quickfixengine.org/quickfix/doc/html/index.html
>>> QuickFIX FAQ:
> http://www.quickfixengine.org/quickfix/doc/html/FAQ.html
>>>
>>> Has anyone else had problems with apparently random crashes and
> memory
>>> corruptions in quickfix when using MS VC++, specifically using the
>>> default
>>> release build options?
>>>
>>> We have a C++ production application that uses quickfix.  We have
> had
>>> to
>>> build quickfix with all optimizations turned off.  We were unable to
>>> track
>>> down the memory corruptions that occurred with a release build.
>>>
>>> Recently, I have been using the Java version of quickfix.  I have a
>>> test
>>> application that generates MarketDataSnapshotFullRefresh messages
> and
>>> populates them with essentially random price data.  The receiving
>>> application sends a subscribe message and the test application
> starts
>>> sending refresh messages at a rate of about 20 per second.  When
> using
>>> a
>>> release build of quickfix_jni.dll, the receiving application often
>>> crashes
>>> after several hundred messages due to an access violation.  This
>>> typically
>>> occurs in the destructor call from Message.finalize(), other times
> in
>>> Group.finalize(), and othertime some place else.   I do a session
> reset
>>> between test runs.  Sometimes the application does not crash at all.
>>> I
>>> have tried disabling all processing of refresh messages by the
>>> receiving
>>> application (so it just returns from fromApp without doing
> anything),
>>> and
>>> the crashes still happen.
>>>
>>> The random nature of the crashes leads me to suspect a threading
> issue.
>>>
>>> When I use a debug build of quickfix_jni.dll, I can never get it to
>>> crash.
>>> This might just be luck, or it might indicate a problem with
> compiler
>>> optimizations.
>>>
>>> I think this problem may have something to do with repeating groups
> as
>>> I
>>> have only started noticing it since implementing market data
> support.
>>> However, it could just be that I have started stressing quickfix
> more
>>> than
>>> before.
>>>
>>> Interestingly, the corruptions we were experiencing in our
> production
>>> C++
>>> application also occurred when there was a large amount of market
> data
>>> traffic.
>>>
>>> I am using quickfix 1.7.0.
>>>
>>> Tim Yates
>>> Lead Developer
>>> Patsystems (US) LLC
>>> 141 West Jackson Boulevard
>>> Chicago 60604, USA
>>> Tel +1 (312) 542-1336
>>> www.patsystems.com
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by the new InstallShield X.
>>> From Windows to Linux, servers to mobile, InstallShield X is the
>>> one installation-authoring solution that does it all. Learn more and
>>> evaluate today! http://www.installshield.com/Dev2Dev/0504
>>> _______________________________________________
>>> Quickfix-developers mailing list
>>> Qui...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by the new InstallShield X.
>>> From Windows to Linux, servers to mobile, InstallShield X is the
>> one installation-authoring solution that does it all. Learn more and
>> evaluate today! http://www.installshield.com/Dev2Dev/0504
>> _______________________________________________
>> Quickfix-developers mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
>
> -----------------------------------------------------------------
>         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.
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
>

Re: [Quickfix-developers] MS VC++ release builds

[Antonio C. <ant...@ga...>]

Dear Tim,

We are experiencing the same problems described in your email dated June
14/2004.

We are using MS VC++ 6 SP5 with default compilation and link options and
QuickFix 1.7.1. The target application is being run under Windows Server
2000 SP4.

In most cases we detected memory errors on incoming messages: we often get
the error "Message nn rejected: CompID problem" even if the FIX message
logged in our log file via the QuickFix log function shows correct tags and
values. It may happen that we have such a problem once or twice in a day
under heavy traffic conditions, mostly on incoming messages. In few cases
this possible memory problem also caused outgoing messages to be truncated.

At times (not always) this problem is followed by an application crash: we
do not get any application fault window since the application simply
disappears from the Task Manager.

I have seen Oren's suggestion about the callstack. Did that help you solve
your problem ? We might try and use QuickFix 1.8.0, but the release notes do
not seem to address this problem.

Any help will be greatly appreciated

Bye,

Antonio Caroselli
GATE T.I.
www.gatelab.com



----- Original Message -----
From: "Timothy Yates" <Tim...@pa...>
To: "'Oren Miller'" <or...@qu...>
Cc: <qui...@li...>
Sent: Monday, June 14, 2004 5:30 PM
Subject: RE: [Quickfix-developers] MS VC++ release builds


> QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: http://www.quickfixengine.org/quickfix/doc/html/FAQ.html
>
> The callstack is not enabled.
>
> Tim.
>
> -----Original Message-----
> From: Oren Miller [mailto:or...@qu...]
> Sent: Monday, June 14, 2004 9:32 AM
> To: Timothy Yates
> Cc: qui...@li...
> Subject: Re: [Quickfix-developers] MS VC++ release builds
>
>
> Do you have the callstack enabled?
>
> --oren
>
> On Jun 14, 2004, at 8:39 AM, Timothy Yates wrote:
>
> > QuickFIX Documentation:
> > http://www.quickfixengine.org/quickfix/doc/html/index.html
> > QuickFIX FAQ: http://www.quickfixengine.org/quickfix/doc/html/FAQ.html
> >
> > Has anyone else had problems with apparently random crashes and memory
> > corruptions in quickfix when using MS VC++, specifically using the
> > default
> > release build options?
> >
> > We have a C++ production application that uses quickfix.  We have had
> > to
> > build quickfix with all optimizations turned off.  We were unable to
> > track
> > down the memory corruptions that occurred with a release build.
> >
> > Recently, I have been using the Java version of quickfix.  I have a
> > test
> > application that generates MarketDataSnapshotFullRefresh messages  and
> > populates them with essentially random price data.  The receiving
> > application sends a subscribe message and the test application starts
> > sending refresh messages at a rate of about 20 per second.  When using
> > a
> > release build of quickfix_jni.dll, the receiving application often
> > crashes
> > after several hundred messages due to an access violation.  This
> > typically
> > occurs in the destructor call from Message.finalize(), other times in
> > Group.finalize(), and othertime some place else.   I do a session reset
> > between test runs.  Sometimes the application does not crash at all.
> > I
> > have tried disabling all processing of refresh messages by the
> > receiving
> > application (so it just returns from fromApp without doing anything),
> > and
> > the crashes still happen.
> >
> > The random nature of the crashes leads me to suspect a threading issue.
> >
> > When I use a debug build of quickfix_jni.dll, I can never get it to
> > crash.
> > This might just be luck, or it might indicate a problem with compiler
> > optimizations.
> >
> > I think this problem may have something to do with repeating groups as
> > I
> > have only started noticing it since implementing market data support.
> > However, it could just be that I have started stressing quickfix more
> > than
> > before.
> >
> > Interestingly, the corruptions we were experiencing in our production
> > C++
> > application also occurred when there was a large amount of market data
> > traffic.
> >
> > I am using quickfix 1.7.0.
> >
> > Tim Yates
> > Lead Developer
> > Patsystems (US) LLC
> > 141 West Jackson Boulevard
> > Chicago 60604, USA
> > Tel +1 (312) 542-1336
> > www.patsystems.com
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by the new InstallShield X.
> > From Windows to Linux, servers to mobile, InstallShield X is the
> > one installation-authoring solution that does it all. Learn more and
> > evaluate today! http://www.installshield.com/Dev2Dev/0504
> > _______________________________________________
> > Quickfix-developers mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> >
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> >From Windows to Linux, servers to mobile, InstallShield X is the
> one installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>