RE: "DECODE_BUF_NOFAIL" failure

["Nord, John D Contractor/NCCIM" <john.nord@xxxxxxxxxxxxxxxxx>]

Bob,
	I checked my project configurations, and the debug multithreaded library
is set correctly on all the projects.  I did some more investigation, and I
guess I made too early an assumption without debugging far enough into the code.
I did assume there was a memory overrun error.  
	I determined that the bomb I am getting is that a pointer is being freed
that has already been freed elsewhere.  In the code for the DECODE_BUF_NOFAIL
macro below, the last line is "free(pchBuffer);".  In the case that the macro is
called with a buffer larger than 100K, the AsnBuf internal buffer is reallocated
(with calloc) as you said to a larger size, and the buffer that was passed in
initially to the AsnBuff::Init function (in the "outputBuf.Init(pchBuffer,
(blob)->Length());" line of the macro) gets freed (in the AsnBuf::AddBuffer
function)--this pointer is the same pointer that the macro tries to free again
in the last line.

John

-----Original Message-----
From: Colestock, Robert [mailto:Robert.Colestock@xxxxxxxx]
Sent: Friday, September 15, 2000 8:30 AM
To: 'Nord, John D Contractor/NCCIM'; 'imc-sfl@xxxxxxx'
Subject: RE: "DECODE_BUF_NOFAIL" failure


John:

I investigated this error; the SNACC library handles bigger buffers, but my
test program failed in a similar manner due to a mis-alignment of the DLL
libraries.  Once I fixed this, the test of 200k buffer Octet String encoding
worked fine.  I authored this newer logic to handle larger buffers, the
SNACC encode operations were updated to re-alloc the memory from the macro
(I need to add some comments to the "sm_vdasnacc.h" include file around
these macros indicating that the 100k buffer is not the actual limit).
Soon, I will be updating the logic again to improve performance (hopefully
to use the actual application memory, avoiding the copy operations).

For your immediate problem, I suggest that you check that the application
and SNACC library builds both use the Project Settings, C/C++ Tab, Category:
Code Generation, Use run-time library: Multithreaded DLL (OR Debug
Multithreaded DLL).  Sorry, but this is a part of the Microsoft world, the
actual error is not always obvious.

Bob Colestock
VDA

-----Original Message-----
From: Nord, John D Contractor/NCCIM [mailto:john.nord@xxxxxxxxxxxxxxxxx]
Sent: Tuesday, September 12, 2000 4:03 PM
To: 'imc-sfl@xxxxxxx'
Subject: "DECODE_BUF_NOFAIL" failure


All,
	I am using the SFL/SNACC libraries to parse a P7M format file.  I
was
having a problem opening a somewhat large P7M file (the file I was parsing
was
208K).  The call stack to where I got an error is:  
	- CSM_MsgToVerify::PreProc(CSMIME *, CSM_Buffer *,
CSM_ListC<CSM_RecipientIdentifier> *)
	- CSM_MsgToVerify::PreProc(CSM_Buffer *)
	- CSM_DataToVerify::PreProc(CSM_Buffer *)
	- SME(DECODE_BUF_NOFAIL(m_pSnaccSignedData, pEncodedBlob, status))

The last line, the call to the macro "DECODE_BUF_NOFAIL", created an
exception
when the free() was called at the end of the macro.  It looks like this
macro
will not handle a buffer that is bigger than VDASNACC_ENCDEC_BUFSIZE
(100000).

	It would be nice if inside the macro (in "sm_vdasnacc.h"), the
constant
VDASNACC_ENCDEC_BUFSIZE could be changed to (blob)->Length(), such that the
new
macro looks like:

#define DECODE_BUF_NOFAIL(decodeData, blob, status)\
   {\
   char *pchBuffer = (char *)calloc(1, \
         (blob)->Length());\
   size_t encodedLen;\
   AsnBuf outputBuf;\
   int nDecStatus = 0;\
   \
   outputBuf.Init(pchBuffer, (blob)->Length());\
   outputBuf.ResetInWriteRvsMode();\
   SM_WriteToAsnBuf((blob), outputBuf);\
   outputBuf.ResetInReadMode();\
   if ((nDecStatus = (decodeData)->BDecPdu(outputBuf, encodedLen)) ==
false)\
     status = 1;\
   else\
     status = 0;\
   free(pchBuffer);\
   }

However, this doesn't work, because the macro is called with both a
CSM_Buffer
pointer and a CSM_Buffer reference in various places.  

	In order to make this macro work for CSM_Buffer's that are bigger
than
VDASNACC_ENCDEC_BUFSIZE, one of a few things is going to have to happen:
	(1) - the macro could be split into 2 macros, one that works for
CSM_Buffer pointers [(blob)->Length()] and one that works for CSM_Buffer
references [(blob).Length()].
	(2) - the change could be made to the macro as shown above, and all
calls to the macro in the SFL that currently call it with a CSM_Buffer
reference
could be changed to call the macro with a CSM_Buffer pointer.
	(3) - an argument could be added to the macro that specifies the
length
of the data in 'blob', and that length could take the place of
VDASNACC_ENCDEC_BUFSIZE in the macro definition.

	I'm not sure how I'm going to handle this.  Any of these proposed
changes would cause a lot of small changes all over the SFL.  Does anyone
have a
different/better idea?

Thanks,
John Nord