Prev: managed code and dll
Next: Application won’t launch from document
From: Joseph M. Newcomer on 19 Apr 2010 10:59
See below....
On Sun, 18 Apr 2010 19:50:34 -0400, Hector Santos <sant9442(a)nospam.gmail.com> wrote:

>I don't know if I agree with your manhole analogy. :) Its a matter of
>anticipation, expectation and knowledge of their existence and current
>state.
>
>If you never were aware of manholes, then you have no path planning
>(assert checks), not run time logic to check for them:
>
> void WalkStreet()
> {
> WaitStraight();
> }
>
>If you expect manholes, and they might be open, then you might have:
>
> void WalkStreet()
> {
> if (ManHole.Opened()) {
> WalkAround();
> } else {
> WalkStraight();
> }
****
Doesn't work well, because there is generally no reogust, reliable way to detect heap
damage. What I generally suggest is adding an OnIdle handler to the CWinApp class and
doing
ASSERT(_heapchk() == HEAP_OK);
[check docs to see if I remembered the name HEAP_OK correctly!]

which catches a lot of problems by checking early and often and isolates the problem to
the handler of the most recent message (usually a WM_COMMAND message).

But note that it requires the equivalent of crawling down the street on your hands and
knees, carefully looking for open manholes, before walking down the street.

And all it tells you is that there is an open manhole, and you should expect trouble.

Otherwise, you've got a lot of catch(...) phrases everywhere, and these don't handle the
internal assert and int3 problems which beginners call "crashes", but which are not
crashes in the strictest sense.

As you know, the use of the unqualified term "crash" is one of my hot buttons; it is a
nonsesnse word, by itself, and conveys nothing useful.
> }
>
>If the manhole MUST be closed at all times (a design concept), then an
>assertion is appropriate:
>
> void WalkStreet()
> {
> assert(ManHole.Opened());
> WalkStraight();
> }
****
Note that assert is NOT a "crash", and sloppy use of the word "crash" is misleading.

_heapchk() will handle this (as I showed) but once the assert happens, it does NOT tell
where the problem is, whether or not walking straight will drop you into the manhole (it
might be off on the side, so if you walk straight, down the middle or the opposite side,
you will not fall in), and it does not stop you from walking down the street, especially
in relelease mode.
****
>
>But if its possible, but not expected by the time you walk the street
>or walking around the manhole is a performance issue (no longer a
>straight line), then you could have:
>
> void WalkStreet()
> {
> if (ManHole.Opened()) {
> ReportToCity("ManHole #%d left open", ManHole.Number);
****
Again, the analogy breaks down here, because the "Manhole Number" does not exist, and all
get get back is a simple boolean result, in effect. It only tells you that you should not
continue walking down the street.
****
> If (ManHole.Cover.Location == NEARBY) {
****
The analogy doesn't work here because _heapchk doesn't tell you WHERE the damage is, or
whether or not your next action will detect it. So there IS no concept of "NEARBY" and
even if you knew it was nearby, it doesn't tell if your next step will drop you into it or
not.
****
> ManHole.Close();
****
This analogy breaks down because there is no way to repair the damage!
****
> } else {
> WalkAround();
****
This doesn't work because there is no way to "walk around" an instance of heap damage.

The analogy is intended to be simple, to cover the simple case. You are tryiing to
stretch it by bringing in mechanisms that simply do not exist. There are really only two
options: fall into the hole, or know that there is an open manhole somewhere on the street
into which you may or may not fall. That's all the mechanisms that exist.

The point of the analogy is to indicate the temporal separation between the event and its
detection; it is a common confusion to believe that the even that detected the problem is
the event that caused the problem.
****
> return;
> }
> }
> WalkStraight();
> }
>
>I guess your point is that he should be checking for ManHoles. :)
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Hector Santos on 19 Apr 2010 11:19
Joseph M. Newcomer wrote:

> This doesn't work because there is no way to "walk around" an instance of heap damage.
>
> The analogy is intended to be simple, to cover the simple case. You are tryiing to
> stretch it by bringing in mechanisms that simply do not exist. There are really only two
> options: fall into the hole, or know that there is an open manhole somewhere on the street
> into which you may or may not fall. That's all the mechanisms that exist.
>
> The point of the analogy is to indicate the temporal separation between the event and its
> detection; it is a common confusion to believe that the even that detected the problem is
> the event that caused the problem.


I don't disagree.

My point is that people must have the understanding of its existence
and how it plays a role before they can make any conclusion or
intelligent guess work at problem detection and resolution.

I think its safe to say that most people understand "Manholes" do
exist in streets and that most people do have a basic understanding
that its possible to exist and could be unsafe. In fact, even when
closed, I will still walk around it. :) IOW, IMV, its not a totally
blind attribute of the problem you correctly cite does exist.

However, I don't think you are going to stop people using the general
term crash which isn't a specific type of cause other that it
generally means the process has aborted, abend, faulted, stop running,
etc.

Anyway, My opinion. :)

--
HLS
From: Joseph M. Newcomer on 19 Apr 2010 12:46
I am SERIOUSLY trying to make people stop using the word "crash" when they do not describe
WHAT happened. Sadly, too many people confuse "assertion failure" with "crash" and NONE
of them actually spend any time in the debugger trying to figure out what went wrong.
joe

On Mon, 19 Apr 2010 11:19:01 -0400, Hector Santos <sant9442(a)nospam.gmail.com> wrote:

>Joseph M. Newcomer wrote:
>
>> This doesn't work because there is no way to "walk around" an instance of heap damage.
>>
>> The analogy is intended to be simple, to cover the simple case. You are tryiing to
>> stretch it by bringing in mechanisms that simply do not exist. There are really only two
>> options: fall into the hole, or know that there is an open manhole somewhere on the street
>> into which you may or may not fall. That's all the mechanisms that exist.
>>
>> The point of the analogy is to indicate the temporal separation between the event and its
>> detection; it is a common confusion to believe that the even that detected the problem is
>> the event that caused the problem.
>
>
>I don't disagree.
>
>My point is that people must have the understanding of its existence
>and how it plays a role before they can make any conclusion or
>intelligent guess work at problem detection and resolution.
>
>I think its safe to say that most people understand "Manholes" do
>exist in streets and that most people do have a basic understanding
>that its possible to exist and could be unsafe. In fact, even when
>closed, I will still walk around it. :) IOW, IMV, its not a totally
>blind attribute of the problem you correctly cite does exist.
>
>However, I don't think you are going to stop people using the general
>term crash which isn't a specific type of cause other that it
>generally means the process has aborted, abend, faulted, stop running,
>etc.
>
>Anyway, My opinion. :)
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Hector Santos on 19 Apr 2010 13:15
Ok, what do you want to say?

"My program stopped working."
"My program popped up GPF box"
"My program faulted"
"My program abend"
"My program aborted"
"My program refused to run."
"My program quit for some reason."

Crash is not suppose to describe what exactly happen. Only that
ultimate outcome has occurred.

Google:

define: crash

* stop operating; "My computer crashed last night";
"The system goes down at least once a week"

Webster:

d) of a computer system, component, or program : to suffer a
sudden major failure usually with attendant loss of data

http://en.wikipedia.org/wiki/Crash

# Crash (computing), a condition where a program ceases to respond

I actually don't like the Wikipedia insert. It should say:

# Crash (computing), a condition where a program no longer
operates correctly or continues to run.

It would be able to the user or developer to find out the reason why
their program crashed (aborted, abend, faulted, stop running, etc,
pick up).

--

Joseph M. Newcomer wrote:

> I am SERIOUSLY trying to make people stop using the word "crash" when they do not describe
> WHAT happened. Sadly, too many people confuse "assertion failure" with "crash" and NONE
> of them actually spend any time in the debugger trying to figure out what went wrong.
> joe
>
> On Mon, 19 Apr 2010 11:19:01 -0400, Hector Santos <sant9442(a)nospam.gmail.com> wrote:
>
>> Joseph M. Newcomer wrote:
>>
>>> This doesn't work because there is no way to "walk around" an instance of heap damage.
>>>
>>> The analogy is intended to be simple, to cover the simple case. You are tryiing to
>>> stretch it by bringing in mechanisms that simply do not exist. There are really only two
>>> options: fall into the hole, or know that there is an open manhole somewhere on the street
>>> into which you may or may not fall. That's all the mechanisms that exist.
>>>
>>> The point of the analogy is to indicate the temporal separation between the event and its
>>> detection; it is a common confusion to believe that the even that detected the problem is
>>> the event that caused the problem.
>>
>> I don't disagree.
>>
>> My point is that people must have the understanding of its existence
>> and how it plays a role before they can make any conclusion or
>> intelligent guess work at problem detection and resolution.
>>
>> I think its safe to say that most people understand "Manholes" do
>> exist in streets and that most people do have a basic understanding
>> that its possible to exist and could be unsafe. In fact, even when
>> closed, I will still walk around it. :) IOW, IMV, its not a totally
>> blind attribute of the problem you correctly cite does exist.
>>
>> However, I don't think you are going to stop people using the general
>> term crash which isn't a specific type of cause other that it
>> generally means the process has aborted, abend, faulted, stop running,
>> etc.
>>
>> Anyway, My opinion. :)
> Joseph M. Newcomer [MVP]
> email: newcomer(a)flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm



--
HLS
From: Joseph M. Newcomer on 19 Apr 2010 13:52
(a) My program reports an unhandled exception 0xC0000005 in the function XXXXXX at the
following line:
<source code here>
I examined the variables, and the value being passed in is 0xCCCCCD8.

[dead giveaway: uninitialized local pointer variable]

(b) My program, which is running under VS2008 without SP1, gave an assertion failure on
line NNNN or file XXXXXX.cpp (here is the function). I have indicated which of the
assertions failed. When I examined the value with the debugger, it was 0 (NULL). The
callback trace to my code is also shown, and the source line from my code is indicated
below
Something * v;
...stuff here...
v = SomeFunction(...);
SomeOtherFunction(v); <<== this is the last line issued before the assertion
failure

[dead giveaway: the SomeFunction failed, returned NULL as documented, and you failed to
test for this condition before using the value]

(c) My program, which is running under VS2008 SP1, gave an unhandled exception 0xC80000003
at the following line in the storage allocator:

[dead giveaway: attempting to free something twice, storage damage due to mishandled
bounds on an array store or fetch, etc., especially if the values are given! The source
line usually has comments indicating the reason for the failure, and from this we can
usually make a pretty good guess]

These are meaningful resports. All of the suggestions you give below are equivalent to
the word "crash" in terms of their useful content.

Note in the definition you give, a "crash" of a computer is rather different than a
"crash" of a program under development, and even then the description of "crash" is for
people like my mother, who can't tell an unhandled kernel exception from a heap
corruption; all she knows is her screen turned blue and the letter she was writing is
lost. I expect something a bit more coherent from someone who claims to be a programmer!

Note that all the definitions describe different conditions, which would require different
actions to handle. A non-responding program is quite a different problem from one which
has taken an unhandled exception, or one which has taken an assertion failure. Again, the
audiences are different; programmers are assumed to be capable of distinguishing all these
causes in a report and providing maximum information to allow diagnosis of the problem by
another programmer. So if I report that my program isn't running correctly, what,
exactly, do you think you can do to help me? But if I specifically say what I am
observing, and, as a programmer, tell you the values of the variables involved, I am
giving you the critical information you need to help me. This is a programmers'
newsgroup; I expect a programmer's description of the problem, not the description my
mother would give (she called me up once and said her computer said it had done something
illegal, and should she be concerned? But she was 85 at the time). So when a person who
claims to be a "programmer" says "my program crashed" I expect them to have the minimum
capability of reporting EXACTLY what happened in terms of the executing code!
joe


On Mon, 19 Apr 2010 13:15:47 -0400, Hector Santos <sant9442(a)nospam.gmail.com> wrote:

>
>Ok, what do you want to say?
>
> "My program stopped working."
> "My program popped up GPF box"
> "My program faulted"
> "My program abend"
> "My program aborted"
> "My program refused to run."
> "My program quit for some reason."
>
>Crash is not suppose to describe what exactly happen. Only that
>ultimate outcome has occurred.
>
>Google:
>
> define: crash
>
> * stop operating; "My computer crashed last night";
> "The system goes down at least once a week"
>
>Webster:
>
> d) of a computer system, component, or program : to suffer a
> sudden major failure usually with attendant loss of data
>
>http://en.wikipedia.org/wiki/Crash
>
> # Crash (computing), a condition where a program ceases to respond
>
>I actually don't like the Wikipedia insert. It should say:
>
> # Crash (computing), a condition where a program no longer
> operates correctly or continues to run.
>
>It would be able to the user or developer to find out the reason why
>their program crashed (aborted, abend, faulted, stop running, etc,
>pick up).
>
>--
>
>Joseph M. Newcomer wrote:
>
>> I am SERIOUSLY trying to make people stop using the word "crash" when they do not describe
>> WHAT happened. Sadly, too many people confuse "assertion failure" with "crash" and NONE
>> of them actually spend any time in the debugger trying to figure out what went wrong.
>> joe
>>
>> On Mon, 19 Apr 2010 11:19:01 -0400, Hector Santos <sant9442(a)nospam.gmail.com> wrote:
>>
>>> Joseph M. Newcomer wrote:
>>>
>>>> This doesn't work because there is no way to "walk around" an instance of heap damage.
>>>>
>>>> The analogy is intended to be simple, to cover the simple case. You are tryiing to
>>>> stretch it by bringing in mechanisms that simply do not exist. There are really only two
>>>> options: fall into the hole, or know that there is an open manhole somewhere on the street
>>>> into which you may or may not fall. That's all the mechanisms that exist.
>>>>
>>>> The point of the analogy is to indicate the temporal separation between the event and its
>>>> detection; it is a common confusion to believe that the even that detected the problem is
>>>> the event that caused the problem.
>>>
>>> I don't disagree.
>>>
>>> My point is that people must have the understanding of its existence
>>> and how it plays a role before they can make any conclusion or
>>> intelligent guess work at problem detection and resolution.
>>>
>>> I think its safe to say that most people understand "Manholes" do
>>> exist in streets and that most people do have a basic understanding
>>> that its possible to exist and could be unsafe. In fact, even when
>>> closed, I will still walk around it. :) IOW, IMV, its not a totally
>>> blind attribute of the problem you correctly cite does exist.
>>>
>>> However, I don't think you are going to stop people using the general
>>> term crash which isn't a specific type of cause other that it
>>> generally means the process has aborted, abend, faulted, stop running,
>>> etc.
>>>
>>> Anyway, My opinion. :)
>> Joseph M. Newcomer [MVP]
>> email: newcomer(a)flounder.com
>> Web: http://www.flounder.com
>> MVP Tips: http://www.flounder.com/mvp_tips.htm
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  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: managed code and dll
Next: Application won’t launch from document