[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


	Thanks, I will replace this file.  FYI, the "sm_vdasnacc.h" file that I
was using is the one currently available from the SFL web page in zip file


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


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;


   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);

        // local cleanup logic


Bob Colestock

-----Original Message-----
From: Nord, John D Contractor/NCCIM [mailto:john.nord@xxxxxxxxxxxxxxxxx]
Sent: Friday, September 15, 2000 2:15 PM
To: 'Colestock, Robert'
Cc: 'imc-sfl@xxxxxxx'
Subject: RE: "DECODE_BUF_NOFAIL" failure

	I checked my project configurations, and the debug multithreaded
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
I did assume there was a memory overrun error.  
	I determined that the bomb I am getting is that a pointer is being
that has already been freed elsewhere.  In the code for the
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
(with calloc) as you said to a larger size, and the buffer that was passed
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
in the last line.


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


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

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

	I am using the SFL/SNACC libraries to parse a P7M format file.  I
having a problem opening a somewhat large P7M file (the file I was parsing
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
when the free() was called at the end of the macro.  It looks like this
will not handle a buffer that is bigger than VDASNACC_ENCDEC_BUFSIZE

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

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

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

	In order to make this macro work for CSM_Buffer's that are bigger
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
could be changed to call the macro with a CSM_Buffer pointer.
	(3) - an argument could be added to the macro that specifies the
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?

John Nord