By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,761 Members | 1,188 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,761 IT Pros & Developers. It's quick & easy.

crash in release build, but it works on debug build

P: n/a
Hi All,

We meet an evil condition for our project. Our project has 3 layers.
A C# layer to do some business logic, and Managed C++ layer translate
managed values to native ones or vice verse.(vs2005, /clr:oldSyntax) .
UI layer are written in native C++.

Currently, we meet a random crash bug in release build. It is ok in
debug build. If we replace the managed c++ dll with the debug one, it
works also. So we think there must be something wrong in Managed C++
layer.

We intensively convert System::String to TCHAR * in Managed C++
layer. The code snippet is as belows:

TCHAR * strName = NULL;
System::String * Name = dv->Name; //get the value from C# layer
if(Name)
{
nLength = Name->Length;
strName = new TCHAR[nLength+1];
ptr = Marshal::StringToHGlobalUni(Name);
if(ptr != IntPtr::Zero)
{
lstrcpy(strName ,
reinterpret_cast<__wchar_t*>(static_cast<void*>(pt r)));
}
}

The crash are random. But all crashes are occur after some code try
to alloc some native memory.

Call stack in Crash Scenario 1
Unhandled exception at 0x77fcca14 (NTDLL.DLL) : 0xC0000005: Access
violation writing location 0x00000000.

NTDLL.DLL!_RtlpCoalesceFreeBlocks@16
NTDLL.DLL!_RtlpExtendHeap@8
NTDLL.DLL!_RtlAllocateHeap@12
msvcr80.dll!malloc
msvcr80.dll!operator new
05f1d90c()
mscorwks.dll!SecurityPolicy::IsDefaultThreadSecuri tyInfo()(
...

Call stack in Crash Scenario 2
Unhandled exception at 0x77fcc024 (NTDLL.DLL): 0xC0000005: Access
violation writing location 0x00000052.

NTDLL.DLL!_RtlAllocateHeap@12
KERNEL32.DLL!_LocalAlloc@8
MFC71u.dll!CNoTrackObject::operator new
MFC71u.dll!CThreadSlotData::SetValue
MFC71u.dll!CThreadLocalObject::GetData
MFC71u.dll!AFX_MAINTAIN_STATE2::AFX_MAINTAIN_STATE 2
xxxxxx.dll!02c10101() (it is our UI dll)
...

But when I use Performance Monitor, the private heap is used
little. Also the usage of CLR memory is very low also. What is happen
to the memory heap?

Do you know what is wrong to Managed C++ module? Is there a good
tool to monitor the memory to the Interop program? Or there are some
special compiler setting for release build.

Any help are appreciated.

Thanks.

ding

Jul 14 '06 #1
Share this Question
Share on Google+
2 Replies


P: n/a

Such call stacks usually mean that the native heap is corrupted.
You can try to enable PageHeap to detect the place where
the corruption occurs.
http://www.debuginfo.com/tips/userbpntdll.html

Regards,
Oleg
[VC++ MVP http://www.debuginfo.com/]

Jul 14 '06 #2

P: n/a
Hi Oleg,

We had solved the bug. The developer had wrote some code that cause
buffer overflow. We are very new with this kind of bug in Managed C++,
it always crashed when any code want to allocate the memory. We found
Heap Manager is corrupt already, but we don't think it more.

Thanks very much for your kindly help.

Regards,

ding
Oleg Starodumov 写道:
Such call stacks usually mean that the native heap is corrupted.
You can try to enable PageHeap to detect the place where
the corruption occurs.
http://www.debuginfo.com/tips/userbpntdll.html

Regards,
Oleg
[VC++ MVP http://www.debuginfo.com/]
Jul 17 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.