whats wrong with this stack

[abubakarm]

Hi,

There is a strang bug appearing not-so-often in my application. I'm
pasting the stack calls window contents when my app crashes. Following
it is:

msvcr80d.dll!fastcopy_I(void * dst=0x01e46130, void * src=0x00001280,
int len=0) + 0x4b bytes C
msvcr80d.dll!_VEC_memcpy(void * dst=0x01e46130, void * src=0x000012fc,
int len=8) + 0x52 bytes C
msvcr80d.dll!_VEC_memcpy(void * dst=0x01e46128, void * src=0x00001304,
int len=212202116) + 0xb4 bytes C
OC.dll!FlexibleBuffer::AddtoBuffer(const char * str=0x01d5c010,
unsigned int buf_length=31744304) Line 21 + 0x13 bytes C++
msvcr80d.dll!_VEC_memcpy(void * dst=0x01e46130, void * src=0x000012fc,
int len=8) + 0x52 bytes C
msvcr80d.dll!_VEC_memcpy(void * dst=0x01e46128, void * src=0x00001304,
int len=212202116) + 0xb4 bytes C
OC.dll!FlexibleBuffer::AddtoBuffer(const char * str=0x01d5c010,
unsigned int buf_length=31744304) Line 21 + 0x13 bytes C++
msvcr80d.dll!_VEC_memcpy(void * dst=0x01e46128, void * src=0x00001304,
int len=212202116) + 0xb4 bytes C

OC.dll!FlexibleBuffer::AddtoBuffer(const char * str=0x01d5c008, unsigned int buf_length=31744296) Line 21 + 0x13 bytes C++

OC.dll!FlexibleBuffer::AddtoBuffer(const char * str=0x01e46128,
unsigned int buf_length=4868) Line 21 + 0x13 bytes C++
OC.dll!DataReceiver::ReceiveAll(char * recvbuf=0x01dca028, int
recvbuflength=6412, char * * allfiledata=0x0ca5f46c) Line 316 C++
OC.dll!DataReceiver::internaldatarecv() Line 161 + 0x1d bytes C++
OC.dll!DataReceiver::ReceiveData() Line 213 + 0x8 bytes C++
OC.dll!HomePortClient::MaybeRecv(DataReceiver * datarecv=0x01ddac88)
Line 382 + 0x8 bytes C++
OC.dll!HomePortClient::CheckForOtherCommands() Line 368 C++
OC.dll!HomePortClient::connect() Line 289 C++
OC.dll!HomePortClient::Run() Line 46 C++
OC.dll!AsyncBase::ThreadStart(void * param=0x01e29f50) Line 22 + 0xe
bytes C++
KERNEL32.DLL!77e8987c()
[Frames below may be incorrect and/or missing, no symbols loaded for
KERNEL32.DLL]

look at the first call to DataReceiver::ReceiveAll, it calls the
AddtoBuffer, which again calls AddtoBuffer and it may look like a
recursive call but there is no way in my code that AddtoBuffer calls
itself. This second call is where buffer and integers show abnormal
values. How is it possible that these 2 calls are being shown in the
call stack? Who made the second call? Any idea on what places I should
check, can I write some source code which could help me debug this kind
of bug? Problem is that this code runs a LOT of times, say thousands of
times. And only sometimes it crashes. Also, this app is heavily
multithreaded, at the time this call stack was recorded, I think there
must be about 20+ threads running. But ofcourse I assume that at any
given time the call stack window only shows the calls of single thread.
I'm pasting the code for AddtoBuffer below:

void FlexibleBuffer::AddtoBuffer(const char * str, size_t buf_length)
{
_P_BUF_MEM_INFO b= new _BUF_MEM_INFO();

b->buf = new char [buf_length];
b->length_of_buf = buf_length;
memcpy ( b->buf, str, buf_length);
m_list_buffer.push_back ( b );
this->m_total_list_buffer_count += buf_length;

}

regards,
-ab.

 

[Oleg Starodumov]

look at the first call to DataReceiver::ReceiveAll, it calls the
AddtoBuffer, which again calls AddtoBuffer and it may look like a
recursive call but there is no way in my code that AddtoBuffer calls
itself. This second call is where buffer and integers show abnormal
values. How is it possible that these 2 calls are being shown in the
call stack? Who made the second call? Any idea on what places I should
check, can I write some source code which could help me debug this kind
of bug? Problem is that this code runs a LOT of times, say thousands of
times. And only sometimes it crashes. Also, this app is heavily
multithreaded, at the time this call stack was recorded, I think there
must be about 20+ threads running.

Since the application uses buffers on the heap, memcpy, multithreading,
etc., I would first check it for heap usage issues with PageHeap:
http://www.debuginfo.com/tips/userbpntdll.html

If the app passes PageHeap test clean, try to trace (OutputDebugString, etc.)
the values of all parameteres passed to all functions mentioned on the call
stack (and related functions, if needed), as well as entry/exit of those functions.
At the moment of the crash, use the tracing output to determine if the values
are correct, where have they come from, etc.

Also you might try to get the call stack with WinDbg, to see if it will
report it differently.

 

[abubakarm]

hey thanks !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

I installed the debugging tools and running my app in the gflags
changed the crash dialog n gave a error box "Memory Error". Although
this is not at all a descriptive error but from my earlier experience
with the application tells me what the problem was (it was with a third
party mini database dll cuz i didnt update the database table's schemas
after updating the dll). Something tells me that playing with the
debugging tools requires a lot of understanding of os related stuff and
I have only played with windbg while i used to play with sscli's source
code.

regards,
-ab.