Re: CFixedAlloc in CString crashing
This is a multi-part message in MIME format.
------=_NextPart_000_0098_01C5A739.DBB67730
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
You are returning a temporary object...
I.e. the CString object goes out of scope when your function returns, =
and if you touch it, it will no longer exist, and crash.
Change your code to return the the object by reference, or use some =
other technique.
"erik" <nospam@hotmail.com> wrote in message =
news:eH3Qk5eoFHA.2484@TK2MSFTNGP15.phx.gbl...
my app call the following statement (p is char pointer, len is the =
length to form the new CString)
return CString(p, len);
015eea24 6c3b7cdf 00000008 015eea84 780106e5 MFC42!Ordinal6585+0x5d ( =
?Alloc@CFixedAlloc@@QAEPAXXZ @ 6585 NONAME)
015eea34 6c3adc0c 00000008 015eea84 0045fde9 MFC42!Ordinal1585+0x29 =
(?AllocBuffer@CString@@IAEXH@Z @ 1585 NONAME)
015eea40 0045fde9 010eaf1e 00000008 010eade0 MFC42!Ordinal538+0x1e ( =
??0CString@@QAE@PBDH@Z @ 538 NONAME
the buffer allocation of CFixedAlloc is protected by critical section, =
the red line should be the crash point.
I just wonder why each time it happens at the same place? I simulate =
to run the codes more than 700,000 times without any problem. It should =
relate to my other portion of codes.
critcalsectionenter(&m_protect);
if (m_pNodeFree == NULL)
{
CPlex* pNewBlock = NULL;
TRY
{
// add another block
pNewBlock = CPlex::Create(...);
}
CATCH_ALL(e)
{
criticalcectionleave(&m_protect);
THROW_LAST();
}
END_CATCH_ALL
// chain them into free list
CNode* pNode = (CNode*)pNewBlock->data();
// free in reverse order to make it easier to debug
(BYTE*&)pNode += (m_nAllocSize * m_nBlockSize) - m_nAllocSize;
for (int i = m_nBlockSize-1; i >= 0; i--, (BYTE*&)pNode -= =
m_nAllocSize)
{
pNode->pNext = m_pNodeFree;
m_pNodeFree = pNode;
}
}
// remove the first available node from the free list
void* pNode = m_pNodeFree;
m_pNodeFree = m_pNodeFree->pNext;
criticalcectionleave(&m_protect);
"Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> wrote in message =
news:Oon6rGToFHA.3552@TK2MSFTNGP10.phx.gbl...
> erik wrote:
>> hi, guys,
>>
>> my program is a multi-threaded application. currently it always =
crashes at the same location in the CFixedAlloc in CString after running =
several hours or days.
>> If my program has heap corrutpion issue, it should be random =
location with access violation instead of a fixed location in =
CFixedAlloc.
>> Pls advise any possible root cause.
>>
>> the following is the call stack tracing
>
> What you posted is not the call stack but MFC code disassembled. It
> would be a great clue if you could determine from the actual call =
stack
> which of your CStrings is being accessed. A likely root cause is =
thread
> 1 changing or freeing the string while thread 2 is using a pointer =
to it
> or to its character buffer. Study each CString that is used by more
> than one thread.
>
> --
> Scott McPhillips [VC++ MVP]
>
------=_NextPart_000_0098_01C5A739.DBB67730
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; =
charset=iso-8859-1">
<META content="MSHTML 6.00.2900.2722" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>You are returning a temporary
object...</FONT></DIV>
<DIV><FONT face=Arial size=2>I.e. the CString object goes out of =
scope when your
function returns, and if you touch it, it will no longer exist, and
crash.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Change your code to return the =
the object by
reference, or use some other technique.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<BLOCKQUOTE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"erik" <<A =
href="mailto:nospam@hotmail.com">nospam@hotmail.com</A>>
wrote in message <A
=
href="news:eH3Qk5eoFHA.2484@TK2MSFTNGP15.phx.gbl">news:eH3Qk5eoFHA.2484=
@TK2MSFTNGP15.phx.gbl</A>...</DIV>
<DIV><FONT face=Arial size=2>my app call the following =
statement (p is
char pointer, len is the length to form the new =
CString) </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>return CString(p, len);</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>015eea24 6c3b7cdf 00000008 015eea84 =
780106e5
MFC42!Ordinal6585+0x5d ( </FONT><A href=""><FONT face=Arial
size=2>?Alloc@CFixedAlloc@@QAEPAXXZ</FONT></A><FONT face=Arial =
size=2> @ 6585
NONAME)<BR>015eea34 6c3adc0c 00000008 015eea84 0045fde9 =
MFC42!Ordinal1585+0x29
(</FONT><A href=""><FONT face=Arial
size=2>?AllocBuffer@CString@@IAEXH@Z</FONT></A><FONT face=Arial =
size=2> @ 1585
NONAME)<BR>015eea40 0045fde9 010eaf1e 00000008 010eade0 =
MFC42!Ordinal538+0x1e
( </FONT><A href=""><FONT face=Arial
size=2>??0CString@@QAE@PBDH@Z</FONT></A><FONT face=Arial size=2> =
@ 538
NONAME</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>the buffer allocation of CFixedAlloc =
is protected
by critical section, the red line should be the crash =
point.</FONT></DIV>
<DIV><FONT face=Arial size=2>I just wonder why each time it =
happens at the
same place? I simulate to run the codes more than 700,000 times =
without any
problem. It should relate to my other portion of codes.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial
size=2> critcalsectionenter(&m_protect);<BR> if =
(m_pNodeFree ==
NULL)<BR> {<BR> CPlex* pNewBlock =
NULL;<BR> TRY<BR> {<BR> // add =
another
block<BR> pNewBlock =
=
CPlex::Create(...);<BR> }<BR> CATCH_ALL(e)<BR> =
; {<BR> criticalcectionleave(&m_protect);<BR>&n=
bsp; THROW_LAST();<BR> }<BR> END_CATCH_A=
LL</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2> // chain them into free
list<BR> CNode* pNode =
(CNode*)pNewBlock->data();<BR> // free in reverse order =
to make
it easier to debug<BR> (BYTE*&)pNode += (m_nAllocSize =
*
m_nBlockSize) - m_nAllocSize;<BR> for (int i = =
m_nBlockSize-1; i
>= 0; i--, (BYTE*&)pNode -=
m_nAllocSize)<BR> {<BR> pNode->pNext =
=
m_pNodeFree;<BR> m_pNodeFree =
pNode;<BR> }<BR> }<BR> </FONT><FONT =
face=Arial><FONT
size=2> // remove the first available node from the free
list<BR> void* pNode = m_pNodeFree;<BR><STRONG><FONT
color=#ff0000> m_pNodeFree =
m_pNodeFree->pNext;</FONT></STRONG></FONT></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial
size=2> criticalcectionleave(&m_protect);<BR></FONT><FONT
face="Courier New" size=1></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>"Scott McPhillips [MVP]"
<org-dot-mvps-at-scottmcp> wrote in message </FONT><A
href="news:Oon6rGToFHA.3552@TK2MSFTNGP10.phx.gbl"><FONT face=Arial =
size=2>news:Oon6rGToFHA.3552@TK2MSFTNGP10.phx.gbl</FONT></A><FONT =
face=Arial
size=2>...</FONT></DIV><FONT face=Arial size=2>> erik =
wrote:<BR>>>
hi, guys,<BR>>> <BR>>> my program is a multi-threaded =
application.
currently it always crashes at the same location in the CFixedAlloc in =
CString
after running several hours or days.<BR>>> If my program has =
heap
corrutpion issue, it should be random location with access violation =
instead
of a fixed location in CFixedAlloc.<BR>>> Pls advise any =
possible root
cause.<BR>>> <BR>>> the following is the call stack
tracing<BR>> <BR>> What you posted is not the call stack but MFC =
code
disassembled. It<BR>> would be a great clue if you could =
determine
from the actual call stack<BR>> which of your CStrings is being
accessed. A likely root cause is thread<BR>> 1 changing or =
freeing
the string while thread 2 is using a pointer to it<BR>> or to its =
character
buffer. Study each CString that is used by more<BR>> than one =
thread.<BR>> <BR>> -- <BR>> Scott McPhillips [VC++
MVP]<BR>></FONT> </BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0098_01C5A739.DBB67730--