Instabilities in dotnet wrapper?

[GoogleCodeExporter]

When running InterpretFastDotnet on data from EBS, a number of problems occur:

1. "Decoder error: Field set full [0-1)" errors are frequent

2. "Decoder error: Field set full [0-6)" error are less frequent but still 
present, immediately followed by a "Decoder error: bad allocation"

3. After about 3 million messages have been processed, the last field set full 
is followed by a "system .accessviolationexception: Attempted to read or write 
protected memory".

VC9.0, Xerces 3.0.1, Boost 1.40

Exception detail:

System.AccessViolationException was unhandled
  Message="Attempted to read or write protected memory. This is often an indication that other memory is corrupt."
  Source="QuickFASTDotNetd"
  StackTrace:
       at QuickFAST.DotNet.DNMessageDeliverer.release()
       at QuickFAST.DotNet.DNMessageDeliverer.!DNMessageDeliverer()
       at QuickFAST.DotNet.DNMessageDeliverer.Dispose(Boolean )
       at QuickFAST.DotNet.DNMessageDeliverer.Finalize()
  InnerException: 

Original issue reported on code.google.com by p...@frejvall.se on 1 Sep 2010 at 11:17

Attachments:

• exc.tiff

[GoogleCodeExporter]

The "Field Set full" message indicates that the template parser came up with an 
incorrect count for the number of fields in a message or group or sequence 
entry.  Can you attach the EBS xml template file you are using without 
violating the terms of their agreement?

Original comment by dale.wil...@gmail.com on 1 Sep 2010 at 3:23

• Changed state: Acknowledged

[GoogleCodeExporter]

Ah! That is actually positive news. The XML we are currently using was actually 
pasted from their EBS documentation, so it may not be 100 percent correct. I 
have asked them for a "better" one. Attached is the one we're using now.
/per

Original comment by p...@frejvall.se on 1 Sep 2010 at 3:43

Attachments:

• EBS.xml

[GoogleCodeExporter]

OK, I have a file for you to test with and an XML to go with it. The data file 
is 36MB... Can we get in touch via e-mail and I'll let you run it for yourself. 
InterpretFastDotnet will catch a fieldset full error on record 181121. I do not 
posess the C++ knowledge to pursue a debug... From what I can see, the 
non-dotnet versions of the software will process the file without error.

I beleive that follow-up errors may be irrelevant due to data alignment errors 
in the stream following the full fieldset.(?)

I'm at per at frejvall.com

Original comment by p...@frejvall.se on 2 Sep 2010 at 4:16

[GoogleCodeExporter]

The problem was in the finalize stage of XML template parsing.  It has been 
corrected in R446.

Thanks for finding the problem and providing test data.

Original comment by dale.wil...@gmail.com on 5 Oct 2010 at 4:05

• Changed state: Fixed