«

I have an MFC app with 2000 users. I have one user that experiences a
crash in our software anywhere from 1 to 5 times a week when opening a
particular module. No other users have reported this particular crash
so I don't think anyone else is experiencing it but I know other users
are doing exactly what she is doing because it is our most popular
module.

I have analyzed the dmp files from several of this user's crashes
using windbg and all of the crashes seem to occur in widely different
places.

Here are 3 of them:
STATUS_ACCESS_VIOLATION_c0000005_MFC42.DLL!CMapPtr ToPtr::GetValueAt
STATUS_ACCESS_VIOLATION_c0000005_MyBaseClass.dll!C Global::GetID
HEAP_CORRUPTION_c0000005

I have noticed lately that the application has some memory leaks, but
it was my understanding that a Microsoft XP system (which is the OS
for this user) would not crash due to memory leaks. Any takers on
that? Can an Access Violation error be caused by a memory leak?

Nicole

On May 29, 3:06*pm, "nmehr...@gmail.com" <nmehr...@gmail.com> wrote:
> I have an MFC app with 2000 users. *I have one user that experiences a
> crash in our software anywhere from 1 to 5 times a week when opening a
> particular module. *No other users have reported this particular crash
> so I don't think anyone else is experiencing it but I know other users
> are doing exactly what she is doing because it is our most popular
> module.
>
> I have analyzed the dmp files from several of this user's crashes
> using windbg and all of the crashes seem to occur in widely different
> places.
>
> Here are 3 of them:
> STATUS_ACCESS_VIOLATION_c0000005_MFC42.DLL!CMapPtr ToPtr::GetValueAt
> STATUS_ACCESS_VIOLATION_c0000005_MyBaseClass.dll!C Global::GetID
> HEAP_CORRUPTION_c0000005
>
> I have noticed lately that the application has some memory leaks, but
> it was my understanding that a Microsoft XP system (which is the OS
> for this user) would not crash due to memory leaks. *Any takers on
> that? *Can an Access Violation error be caused by a memory leak?


Much of that is system specific, and OT here, you should ask in a MS
newsgroup.

But that being said, memory leaks (eg. you forget to free a block of
allocated memory when you're done with it) by themselves do not
directly cause access violations or the equivalent, since all you've
done is lost track of some allocated memory. The segfault (or
whatever) can really only happen if you try to access memory that
*isn't* allocated.

OTOH, if you leak enough memory, you'll run out of memory to allocate
(either by running out of real/virtual memory on the system, or by
running out of address space for the process). And if your new/malloc/
whatever fails, and you don't handle that correctly (which is
unfortunately common) you can quickly find your dereferencing a bad
pointer, which does commonly segfault.

OTTH, since the system appears to be reporting heap corruption, you
may want to look for dangling pointers - IOW, pointers that point to
areas of memory that are freed - storing into such areas can easily
corrupt the heap on many systems. Or just stores via bad pointers in
general.

If you think you've got memory management problems, a tool like
Valgrind or Purify might be helpful.

On 29 Mayýs, 23:06, "nmehr...@gmail.com" <nmehr...@gmail.com> wrote:
> I have an MFC app with 2000 users. *I have one user that experiences a
> crash in our software anywhere from 1 to 5 times a week when opening a
> particular module. *No other users have reported this particular crash
> so I don't think anyone else is experiencing it but I know other users
> are doing exactly what she is doing because it is our most popular
> module.
>
> I have analyzed the dmp files from several of this user's crashes
> using windbg and all of the crashes seem to occur in widely different
> places.
>
> Here are 3 of them:
> STATUS_ACCESS_VIOLATION_c0000005_MFC42.DLL!CMapPtr ToPtr::GetValueAt
> STATUS_ACCESS_VIOLATION_c0000005_MyBaseClass.dll!C Global::GetID
> HEAP_CORRUPTION_c0000005
>
> I have noticed lately that the application has some memory leaks, but
> it was my understanding that a Microsoft XP system (which is the OS
> for this user) would not crash due to memory leaks. *Any takers on
> that? *Can an Access Violation error be caused by a memory leak?
>
> Nicole

It seems like a memory allocation problem. You are trying to use a
memory place which is not allocated or already released. I think you
have to check your object creation/release sections.

I suspect this part of the question may belong in a different
newsgroup, but I will ask here so you can provide your opinion from an
MFC standpoint.

This user's operating system was built up from an existing image.
They say they have tried reapplying the image, and have also replaced
her workstation (and applied an image) to the workstation. Is it
possible that a problem in the OS image is causing these flakey
sporadic memory allocation errors in our MFC app?

Any suggestions as to which newsgroup may be more appropriate for a
question like this?

On Fri, 30 May 2008 09:09:12 -0700, wrote:

> I suspect this part of the question may belong in a different newsgroup,
> but I will ask here so you can provide your opinion from an MFC
> standpoint.

This whole thread belongs in a different newsgroup. MFC is *not* on topic
here. Please see:

http://www.parashift.com/c++-faq-lit...t.html#faq-5.9

Which contains suggestions for more appropriate groups.

--
Lionel B

wrote:
> I have an MFC app with 2000 users. I have one user that experiences a
> crash in our software anywhere from 1 to 5 times a week when opening a
> particular module. No other users have reported this particular crash
> so I don't think anyone else is experiencing it but I know other users
> are doing exactly what she is doing because it is our most popular
> module.
>
> I have analyzed the dmp files from several of this user's crashes
> using windbg and all of the crashes seem to occur in widely different
> places.
>
> Here are 3 of them:
> STATUS_ACCESS_VIOLATION_c0000005_MFC42.DLL!CMapPtr ToPtr::GetValueAt
> STATUS_ACCESS_VIOLATION_c0000005_MyBaseClass.dll!C Global::GetID
> HEAP_CORRUPTION_c0000005
>
> I have noticed lately that the application has some memory leaks, but
> it was my understanding that a Microsoft XP system (which is the OS
> for this user) would not crash due to memory leaks. Any takers on
> that? Can an Access Violation error be caused by a memory leak?

It may be that the application is running out of memory, either physical
memory or paged memory. Check how much memory that computer has compared to
the ones that run your application fine.

--
Jim Langston

On May 30, 8:48*pm, "Jim Langston" <tazmas...@rocketmail.com> wrote:
> nmehr...@gmail.com wrote:
> > I have an MFC app with 2000 users. *I have one user that experiences a
> > crash in our software anywhere from 1 to 5 times a week when opening a
> > particular module. *No other users have reported this particular crash
> > so I don't think anyone else is experiencing it but I know other users
> > are doing exactly what she is doing because it is our most popular
> > module.
>
> > I have analyzed the dmp files from several of this user's crashes
> > using windbg and all of the crashes seem to occur in widely different
> > places.
>
> > Here are 3 of them:
> > STATUS_ACCESS_VIOLATION_c0000005_MFC42.DLL!CMapPtr ToPtr::GetValueAt
> > STATUS_ACCESS_VIOLATION_c0000005_MyBaseClass.dll!C Global::GetID
> > HEAP_CORRUPTION_c0000005
>
> > I have noticed lately that the application has some memory leaks, but
> > it was my understanding that a Microsoft XP system (which is the OS
> > for this user) would not crash due to memory leaks. *Any takers on
> > that? *Can an Access Violation error be caused by a memory leak?
>
> It may be that the application is running out of memory, either physical
> memory or paged memory. *Check how much memory that computer has compared to
> the ones that run your application fine.
>
> --
> Jim Langston
> tazmas...@rocketmail.com- Hide quoted text -
>
> - Show quoted text -

The OS Image was not the problem. The errors were caused by a bug,
specifically trying to ask DAO to move to a record which the program
thought existed, but did not exist. I suspect that the symbol
information was inaccurate so the dump file analysis was inaccurate.

Replicating the issue required a very specific long sequence of user
actions combined with some special options and some minor user
errors. I found the issue by having someone unfamiliar with our
software test for a bit while recording his actions. He replicated
the bug in 6 minutes, but could never replicate it again after that
point because he only made the user errors the first time. Having
lost a couple weeks of my life to this problem, next time around I am
going to try an inexperienced tester much sooner!