Re: memory leak in the code?
On Jan 6, 9:19 am, kwikius <a...@servocomm.freeserve.co.uk> wrote:
On Jan 5, 6:53 pm, James Kanze <james.ka...@gmail.com> wrote:
On Jan 5, 5:38 pm, kwikius <a...@servocomm.freeserve.co.uk> wrote:
Neveretheless in this sitaution things can't get much
worse, so you should probably try doing the diagnostic (by
calling some code designed for this particular situation)
and quit the application if thats acceptable. The point
of this is... If that's the strategy, you adopt then any
dangling pointers will be cleaned up by the system so its
not worth worrying about them in practise. Its also
simple. You have done the right thing by the user. Its
their problem now.
You have very tolerant users. If my server goes down, even if
the reason is due to bad_alloc, my users complain to me. (In a
number of cases, there have even been conventional penalties for
down time.)
Its an interesting problem, and the solution is very dependent
on the context, the platform, the type of application and so
on, as you say.
Its also quite tricky to diagnose who is to blame.
By definition, I am to blame. (Or rather, my client, who is
providing the turn key system.)
It could be other applications on the system,
It's a dedicated system. There aren't (or shouldn't be) any
other "applications". Of course, there could be a bug in some
system service, that caused it to leak memory. But since we
decided to use Sun Solaris, running on a Sparc, rather than some
other system, that's our fault too. The contract is clear:
10.000 Euro per minute for down time. (I presume that there are
exceptions if, e.g. someone carelessly unplugs the machine, or
it gets destroyed in a terrorist attack, or something like
that.)
it could be that the size of some structure is dependent on
parameters supplied by the user,
We verify the parameters supplied by the user (the
configuration) before accepting it.
or it could (dare I say it) even be the fault of the
application.
As I said, the assumption is that if the application gets
bad_alloc, it is leaking memory.
The bare minimum is to try to get some feedback to the user
about the problem (ideally too to provide a probable cause and
even if possible a suggested solution),
We have logs, we can change the log configuration without
stopping the process, and we can even ftp into the users machine
to recover the log.
after all if users are complaining then you have users. Its
when they aren't complaining that you need to worry... either
your system is perfect, or you have no users ;-)
If your system is handling some critical job, it had better be
"perfect". (In fact, there are complaints, and there are
complaints. There's a very great difference between someone not
liking the background color on a monitor, and the system
crashing, and shutting down all long distance telephone services
in Germany.)
After satisfying that criteria, then I agree that doing
anything more useful is complicated. For example the user may
have asked for you to create a huge structure, but you may
have a memory leak anyway. In this case backing off and
(recursively) telling the user that their last request was too
big will be very frustrating!
That is a case I have encountered as a user, and its a very
good argument for not allocating raw pointers :-)
Or using garbage collection. In practice, the most critical
systems I've worked on have used neither garbage collection nor
smart pointers. They have used exceptionally good software
development processes, however, with effective code review,
paying particular attention to memory management issues.
I guess you also need to weigh up how much time you spend on
error feedback, versus the time you spend on adding cool new
features.
A cool new feature which disrupts telephone service on a
national level won't go over very well. A cool new feature
which means that the breaks won't apply in the locomotive won't
go over too well. A cool new feature which results in several
cellular phones being allocated the same IP address won't go
over too well.
On most of the systems I work on, the "user" never actually sees
the system, or knows what features it has. When someone in
Frankfurt calls someone in Berlin, he's (hopefully) totally
unaware that his call passes through machines that I've
programmed.
Of course the app may be a compiler. For example one of the
goals of CLANG is provide better diagnostics. Ultimately,
trying to provide useful error feedback does come to dominate
everything in many applications ( The timeline for a useful
C++ frontend is a couple of years)
http://clang.llvm.org/
For a lot of programs, error handling is most of the code. But
that can mean many different things---and hopefully, it
generally means user error handling, and not handling internal
errors in the code. (Even in the telephone applications, most
of the code was necessary to handle rerouting in case of
hardware problems. Error handling.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34