Re: Combined usage of exception handling

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Severian wrote:
> On Thu, 31 Mar 2005 11:30:38 -0800, "Eugene Gershnik"
> <gershnik@xxxxxxxxxxx> wrote:
>
>> Severian wrote:
>>>
>>> For the crashes we see in the real world (after alpha and beta
>>> testing), with hundreds of thousands of users, 99% or more of them
>>> produce valid, usable logs with stack traces (the most important
>>> part). We also provide a command-line option to create a log while
>>> running, which usually is able to pinpoint the other <1% of problems
>>> (hangs, silent crashes).
>>
>> So if I understand correctly you are saying that since you never saw
>> a problem with exception handler failing because of corrupted state
>> it is ok to rely on it.
>
> No, I said it DOES fail, we know it fails (the <1% mentioned in the
> paragraph you just read), and have other (less convenient) ways to try
> to work on such problems.

Ok, it just wasn't clear from the text. The interesting thing is the "less
convenient" term above. More about it below.

[...]

> We use it ONLY to provide us with information when something unusual
> goes wrong! Everyone makes mistakes; this helps us track them down.
>
> We DO NOT rely on it for normal operation of the program -- only to
> help diagnose crashes. There is no such thing as perfect code.
>
> And we completely understand that it can fail to work, thus we have
> other ways to diagnose such problems.

I understand this. Another way to look at this is that data your application
operates on is not so critical as to make worry about its possible
corruption (this is one possible effect of exception handler operating on
garbaged state). Which is perfectly legitimate.

[...]

>> All of this is doable in a *safe* way from external process.
>
> Perhaps someday I'll do it that way. There has been no need so far --
> our application is stable; crashes are very rare and in my business,
> we do not have the resources to write an external debugger that runs
> on every platform we support (95 -> 2k3).

IOW the perceived cost of implementing safe solution is high. Basically here
you provide the last element in the "money" balance.

1) The cost of current solution - the "less convenient" from above - is low
2) The worst case impact of current solution's flaws (corrupt data,
frustrated users waiting for a longer fix etc.) is low
3) The cost of implementing better solution is high

I can perfectly understand this evaluation. Just one question. Did you
actually try to quantify the costs above? In my experience, which as any
single person experience, is very limited (though I too work at a place with
too many customers) the cost of (1) is too high compared with (3) over long
term while (2) depends on application domain.

> And when the bugs in this external process raise their ugly heads and
> it crashes, do we write a third?

It is similar to the problem of Achilles and a turtle. Theoretically you
will need an infinity of debuggers while practically one is enough. It all
comes down to code complexity and costs (money again ;-) ). The debugger
will be much less complex than your main "system" so accordingly it will
have much less bugs. Even though it may fail the costs of these failures
probably will be sufficiently low unless you work in some really critical
domain.


> I have not personally used Dr Watson since Windows 3.1 or Windows 95,
> so I can't say a lot about it, but even the logs I have seen recently
> do not begin to provide the type of application-specific information
> that we gather.

Sure.

> Outside the context of our process, the locations of
> application-specific information that we log would be unavailable
> unless we distributed debug information with our product.

Not really. There are many ways to deal with this ranging from simple
(inject a pre-built code into the crashed process) to a grandiose (use debug
info from the main application(s) when building the debugger to embedd the
knowlege of important memory locations). The first way will be very similar
to what you do now only with guarantee that the handler code and data will
not be corrupted and will run from another thread which is also very useful.
The only real argument against this solution (which beleive me is quite
simple) is the need to support 9x.

--
Eugene


.

Relevant Pages

  • Re: Is this a sign of memory going bad?
    ... working fine and need some lubrification or a clean, ... than the cost of random downtime and recovering from crashes in a production ... >the build crashes went away. ...
    (freebsd-questions)
  • Re: Is this a sign of memory going bad?
    ... than the cost of random downtime and recovering from crashes in a production ... I am *really* not a hardware guy. ... the build crashes went away. ...
    (freebsd-questions)
  • Re: Crashing Dell
    ... cost of a new Dell. ... small hard disk (30 ... checker. ... | It works on the 'Net fine now but it still often crashes. ...
    (microsoft.public.windowsxp.hardware)
  • Re: eFlyBook
    ... for crashes at altitude. ... since the cost was less than two years of the charts that the ...
    (rec.aviation.ifr)
  • Re: Combined usage of exception handling
    ... >> No, I said it DOES fail, we know it fails (the <1% mentioned in the ... >corruption (this is one possible effect of exception handler operating on ... of permanent corruption of the user's data is very, ... >IOW the perceived cost of implementing safe solution is high. ...
    (microsoft.public.vc.language)