Solved

Access violation - memory corruption?

Posted on 2014-11-05
4
255 Views
Last Modified: 2014-11-09
Hi Experts,

First off, I cannot post our code here, I have to keep this general.  Sorry in advance.

I have a call to a function where the first argument passed is an LPCSTR.  The actual parameter that the function takes is "const _variant_t & Source" (it's for a database query with ADO).

During the conversion of this string to the variant, there's an access violation on the AddRef here, from comutil.h:
inline _variant_t::_variant_t(IDispatch* pSrc, bool fAddRef) throw()
{
    V_VT(this) = VT_DISPATCH;
    V_DISPATCH(this) = pSrc;

    // Need the AddRef() as VariantClear() calls Release(), unless fAddRef
    // false indicates we're taking ownership
    //
    if (fAddRef) {
        if (V_DISPATCH(this) != NULL) {
            V_DISPATCH(this)->AddRef();  // KABOOM here...
        }
    }
}

Open in new window


Note that this code is called frequently before some specific functions actually get through here without a hitch.  It's after a specific previous function that I found with a binary search that when commented out, the issue goes away.

My question is, would you agree that this is likely a heap error?  I tried to detect it with windbg with no luck.  I looked at the code in the function that when commented out, the problem goes away, but I don't see the problem yet.  Is it highly likely that this is where the problem is?

And my most important question of all-->  If we skate around this issue and change the code in ways where we don't really fix it, but the error remains hidden, if it doesn't happen on my machine any more in debug or release mode, and the input to the function remains constant on customer machines, is it possible that other factors can expose this problem differenly on other machines?  (This is the "solution" that is being pushed on me and I'm thinking it's a very very bad idea)...

What do you think?

Thanks,
Mike
0
Comment
Question by:thready
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 2
4 Comments
 
LVL 86

Assisted Solution

by:jkr
jkr earned 150 total points
ID: 40425158
It looks more like using an object that has already been deleted, which you also could call 'memory corruption' or 'heap error'. I'd try to add logging code to the destructors that dumps the 'this' pointers and then see if you can pinpoint the usage of one of these instances with the above code.
0
 
LVL 86

Assisted Solution

by:jkr
jkr earned 150 total points
ID: 40425174
Another thing - you could check the 'IDispatch' pointer used to contruct the _variant_t using 'IsBadReadPtr()' (http://msdn.microsoft.com/en-us/library/windows/desktop/aa366713%28v=vs.85%29.aspx) and avoid using it then. Alternatively, you could still use a SEH handler to catch the exception, e.g.

__try {

  _variant_t var = ...;

} __except(ERROR_ACCESS_VIOLATION == GetExceptionCode()) {

  // handler code
}

Open in new window

0
 
LVL 34

Accepted Solution

by:
sarabande earned 350 total points
ID: 40425863
the V_DISPATCH(this) actually expands to ((this)->pdispVal)

the pdispVal is a union member of the Variant structure for VT_DISPATCH type and the argument pSrc would be assigned to it.

the following calls (most likely) are

STDMETHODIMP_(ULONG) COleDispatchImpl::AddRef()
{
	METHOD_PROLOGUE_EX_(CCmdTarget, Dispatch)
	return pThis->ExternalAddRef();
}
DWORD CCmdTarget::ExternalAddRef()
{
	// delegate to controlling unknown if aggregated
	if (m_pOuterUnknown != NULL)
		return m_pOuterUnknown->AddRef();

	return InternalAddRef();
}

Open in new window

a heap error would occur if malloc returns a NULL pointer, or free would not find the pointer passed as argument what both is not the case here.

here the pointer pSrc was invalid and was not pointing to a valid _variant_t, perhaps it was NULL or was not initialized.  unfortunately the 'IsBadReadPtr' function cannot used to decide whether a non-null pointer was corrupt as it is an obsolete function which doesn't work correctly (see the link jkr provided above).

alternatively to using the SEH try-catch as described by jkr, you also could catch the exception by a c++ try-catch when you choose the option 'Yes, with SEH exceptions' at configuration properties - c/c++ - code generation - enable c++ exceptions for your active project configuration.

Sara
0
 
LVL 1

Author Closing Comment

by:thready
ID: 40431593
Thank you very much!
0

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

What my article will show is if you ever had to do processing to a listbox without being able to just select all the items in it. My software Visual Studio 2008 crystal report v11 My issue was I wanted to add crystal report to a form and show…
Basic understanding on "OO- Object Orientation" is needed for designing a logical solution to solve a problem. Basic OOAD is a prerequisite for a coder to ensure that they follow the basic design of OO. This would help developers to understand the b…
The goal of the video will be to teach the user the difference and consequence of passing data by value vs passing data by reference in C++. An example of passing data by value as well as an example of passing data by reference will be be given. Bot…
The viewer will be introduced to the technique of using vectors in C++. The video will cover how to define a vector, store values in the vector and retrieve data from the values stored in the vector.

728 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question