Prev: How to list mapped drives in dialog running as service?
Next: No stack shown while remote debugging a crash
From: Joseph M. Newcomer on 6 May 2010 17:13
See below...
On Wed, 5 May 2010 12:01:01 -0700, Olegas <Olegas(a)community.nospam> wrote:

>Joseph,
>Thank you for the follow up.
>
>We enable full page heap for our application via the GFlags utility as
>follows:
>GFLAGS.exe /p /enable MyApp.exe /full
>
>Once we enabled full page heap, our application started crashing once in a
>while at our customer�s location. Unfortunately, it is not reproducible on
>demand either at the customer�s location or in the office under a debugger,
>which leads me to believe it has to be some type of timing related issue.
****
This suggests some seriously deep memory damage is happening. The most common cause of
this is uninitialized pointers. Full page heap allocation should catch these, and the
fact that you are seeing them only when full page heap is enabled could also mean that you
are using "stale" pointers, pointers to storage that has already been freed. With full
page allocation, these pages are mapped out of the address space.

I'd suggest trying the Application Verifier and turn on everything you can for storage
analysis. It might catch this a little better.
****
>
>In this particular dump, page heap�s guard pages essentially prevented heap
>corruption from taking place during memset() execution. If it wasn�t for the
>guard pages, memset() would happily overwrite 4 bytes past the end of
>allocated block and application would crash elsewhere down the road.
****
Well, this says your memset code is incorrect. Almost always, use of memset is sloppy
programming. Consider rewriting such code. But it sounds like your code wasn't very good
to start wtih, as evidenced by the use of memset and the fact that they are not correct.
joe

****
>
>Thank you,
>Olegas
>
>
>"Joseph M. Newcomer" wrote:
>
>> It looks to me like you are seeing a problem in synchronization. You have not shown that
>> any heap function is on the stack at this point.
>>
>> Note that heap corruption can occur at any time; when you get a message about heap
>> corruption, it is not saying "I have caused heap corruption" it is saying "I finally
>> discovered that some time in the unknown past, somebody has corrupted the heap". The
>> damage could be trillions of instructions in the past.
>>
>> While this is a good bug report, unfortunately it isn't much help in tracking down what
>> the correuption is or who did it. These still rank as the nastiest possible bugs to find
>> and fix.
>>
>> When you say "full page heap enabled" what are you doing to enable it?
>>
>> joe
>>
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Olegas on 7 May 2010 19:07
Joseph,

Well, that's not _my_ memset() code. Allow me to clarify: the code snippet
is from AFXTLS.cpp, which is a part of MFC. The project in question still
uses Visual Studio 6.

I suspect we are misusing MFC somehow, which leads to the issue.
I'll debug the problem a little bit more next week and post if I come across
anything new.

Thank you,
Olegas


"Joseph M. Newcomer" wrote:

> See below...
> On Wed, 5 May 2010 12:01:01 -0700, Olegas <Olegas(a)community.nospam> wrote:
>
> >Joseph,
> >Thank you for the follow up.
> >
> >We enable full page heap for our application via the GFlags utility as
> >follows:
> >GFLAGS.exe /p /enable MyApp.exe /full
> >
> >Once we enabled full page heap, our application started crashing once in a
> >while at our customer's location. Unfortunately, it is not reproducible on
> >demand either at the customer's location or in the office under a debugger,
> >which leads me to believe it has to be some type of timing related issue.
> ****
> This suggests some seriously deep memory damage is happening. The most common cause of
> this is uninitialized pointers. Full page heap allocation should catch these, and the
> fact that you are seeing them only when full page heap is enabled could also mean that you
> are using "stale" pointers, pointers to storage that has already been freed. With full
> page allocation, these pages are mapped out of the address space.
>
> I'd suggest trying the Application Verifier and turn on everything you can for storage
> analysis. It might catch this a little better.
> ****
> >
> >In this particular dump, page heap's guard pages essentially prevented heap
> >corruption from taking place during memset() execution. If it wasn't for the
> >guard pages, memset() would happily overwrite 4 bytes past the end of
> >allocated block and application would crash elsewhere down the road.
> ****
> Well, this says your memset code is incorrect. Almost always, use of memset is sloppy
> programming. Consider rewriting such code. But it sounds like your code wasn't very good
> to start wtih, as evidenced by the use of memset and the fact that they are not correct.
> joe
>
> ****
> >
> >Thank you,
> >Olegas
> >
From: Joseph M. Newcomer on 9 May 2010 01:38
There are a number of classic C++ failure modes that will end up being diagnosed as heap
damage. Some cause actual heap damage, and some are because things like stale pointers
are being used. Common causes include incorrectly assuming temporary C++ objects are not
freed at the semicolon, and using pointers for objects that have gone out of scope, among
others.

Key here is if you are getting exceptions, and you catch these in the debugger (or by
using the Application Verifier) then you need to look for the cause at that point.

The disappearing app is one of the worst kind of bugs to find.

Take a look at my suggestions for memory management handling on my MVP Tips site. One of
the best solutions I've found when someone sends me a piece of failing code is to add an
OnIdle handler to their CWinApp class, and have it do

ASSERT(_heapchk() == HEAP_OK)

(check the docs for the spelling of that constant; I'm trusting my memory here). This
forces the heap to be reexamined frequently, and usually isolates the problem to a single
menu item action (after you find which one causes it, you can sprinkle these ASSERTs
around in the execution path of the command or menu item to home in on the cause)
joe

On Fri, 7 May 2010 16:07:01 -0700, Olegas <Olegas(a)community.nospam> wrote:

>Joseph,
>
>Well, that�s not _my_ memset() code. Allow me to clarify: the code snippet
>is from AFXTLS.cpp, which is a part of MFC. The project in question still
>uses Visual Studio 6.
>
>I suspect we are misusing MFC somehow, which leads to the issue.
>I�ll debug the problem a little bit more next week and post if I come across
>anything new.
>
>Thank you,
>Olegas
>
>
>"Joseph M. Newcomer" wrote:
>
>> See below...
>> On Wed, 5 May 2010 12:01:01 -0700, Olegas <Olegas(a)community.nospam> wrote:
>>
>> >Joseph,
>> >Thank you for the follow up.
>> >
>> >We enable full page heap for our application via the GFlags utility as
>> >follows:
>> >GFLAGS.exe /p /enable MyApp.exe /full
>> >
>> >Once we enabled full page heap, our application started crashing once in a
>> >while at our customer�s location. Unfortunately, it is not reproducible on
>> >demand either at the customer�s location or in the office under a debugger,
>> >which leads me to believe it has to be some type of timing related issue.
>> ****
>> This suggests some seriously deep memory damage is happening. The most common cause of
>> this is uninitialized pointers. Full page heap allocation should catch these, and the
>> fact that you are seeing them only when full page heap is enabled could also mean that you
>> are using "stale" pointers, pointers to storage that has already been freed. With full
>> page allocation, these pages are mapped out of the address space.
>>
>> I'd suggest trying the Application Verifier and turn on everything you can for storage
>> analysis. It might catch this a little better.
>> ****
>> >
>> >In this particular dump, page heap�s guard pages essentially prevented heap
>> >corruption from taking place during memset() execution. If it wasn�t for the
>> >guard pages, memset() would happily overwrite 4 bytes past the end of
>> >allocated block and application would crash elsewhere down the road.
>> ****
>> Well, this says your memset code is incorrect. Almost always, use of memset is sloppy
>> programming. Consider rewriting such code. But it sounds like your code wasn't very good
>> to start wtih, as evidenced by the use of memset and the fact that they are not correct.
>> joe
>>
>> ****
>> >
>> >Thank you,
>> >Olegas
>> >
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
First  |  Prev  | 
Pages: 1 2
Prev: How to list mapped drives in dialog running as service?
Next: No stack shown while remote debugging a crash