RE: "DECODE_BUF_NOFAIL" failure

Bob,
	The "DECODE_BUF" macro in the file you sent correctly has the last line
"free(outputBuf.BlkPtr()/*pchBuffer*/);\".  However, the macro that is giving me
an error is "DECODE_BUF_NOFAIL".  The last line of that macro is
"free(pchBuffer);".  I guess I need to change the last line of the
"DECODE_BUF_NOFAIL" to be the same as the "DECODE_BUF" macro.

John

-----Original Message-----
From: Colestock, Robert [mailto:[email protected]]
Sent: Friday, September 15, 2000 2:55 PM
To: 'Nord, John D Contractor/NCCIM'
Cc: '[email protected]'
Subject: RE: "DECODE_BUF_NOFAIL" failure


John:

For some reason I tested the ENCODE_BUF(...), but I just re-tested the
DECODE_BUF(...).  It works fine with the following code.  It sounds like you
have an older include file with the reference to the original calloc buffer
pointer, instead of the current AsnBuf pointer 
("free(outputBuf.BlkPtr()/*pchBuffer*/);\", since it may be modified by the
buffer load routine).
I have included our present "sm_vdasnacc.h" include file for reference.


void    test_big_buffer()
{
    char pchBuffer[200000];
    CSM_Buffer *pM=new CSM_Buffer;
    AsnOcts N;

   SME_SETUP("test_big_buffer()");

   memset(pchBuffer, 'A', 200000);
   N.Set(pchBuffer, 200000);
   ENCODE_BUF(&N, pM);

   cout << "test_big_buffer: Octet STring encoded length of 200000 byte
buf=" << pM->Length();

   DECODE_BUF(&N, pM);

  SME_FINISH
  SME_CATCH_SETUP
        // local cleanup logic
  SME_CATCH_FINISH

}

Bob Colestock
VDA

-----Original Message-----
From: Nord, John D Contractor/NCCIM [mailto:[email protected]]
Sent: Friday, September 15, 2000 2:15 PM
To: 'Colestock, Robert'
Cc: '[email protected]'
Subject: RE: "DECODE_BUF_NOFAIL" failure


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:[email protected]]
Sent: Friday, September 15, 2000 8:30 AM
To: 'Nord, John D Contractor/NCCIM'; '[email protected]'
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:[email protected]]
Sent: Tuesday, September 12, 2000 4:03 PM
To: '[email protected]'
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