[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: "DECODE_BUF_NOFAIL" failure
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.
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.
From: Nord, John D Contractor/NCCIM [mailto:john.nord@xxxxxxxxxxxxxxxxx]
Sent: Tuesday, September 12, 2000 4:03 PM
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_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, \
int nDecStatus = 0;\
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
(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