By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,395 Members | 2,541 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,395 IT Pros & Developers. It's quick & easy.

Random crashes

P: n/a
I have written an application in Visual C++ for a customer but it seems
to crash randomly.

Could anyone give me any help on how I could track this down ?

Also, there appears there might be memory leaks too. How can i track
these down ?

Jul 23 '05 #1
Share this Question
Share on Google+
9 Replies


P: n/a
gr**********@gmail.com wrote:
Could anyone give me any help on how I could track this down ?


You ask to late: you should design your code to have not such errors
in the first place. The only thing I know which might help you now
is Purify: it highlights illegal accesses (e.g. out-of-bounds accesses,
reads to uninitialized memory, multiply released memory, memory leaks,
etc.).
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

Jul 23 '05 #2

P: n/a
You are telling there is no application ever written that does not
crash from time to time ?

Just humour me a minute. Theoretically, how would you go about finding
out what is causing a random crash ?

Jul 23 '05 #3

P: n/a
gr**********@gmail.com wrote:
You are telling there is no application ever written that does not
crash from time to time ?


If the application is controlling the communications of a spatial vehicle
orbiting Mars, it crash only one time ;)

--
Salu2
Jul 23 '05 #4

P: n/a

<gr**********@gmail.com> schrieb im Newsbeitrag
news:11**********************@o13g2000cwo.googlegr oups.com...
I have written an application in Visual C++ for a customer but it
seems
to crash randomly.

Could anyone give me any help on how I could track this down ?

Also, there appears there might be memory leaks too. How can i track
these down ?


I bet's it's something like:
int a[5]; a[7] = 13;

-Genrot
Jul 23 '05 #5

P: n/a

<gr**********@gmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
I have written an application in Visual C++ for a customer but it seems
to crash randomly.

Could anyone give me any help on how I could track this down ?

Also, there appears there might be memory leaks too. How can i track
these down ?


It's quite likely that the two are related. I would assume that you're
using new and delete in variaous places, as that is the easiest way to get
memory leaks, It's also an opening for crashes, if you don't handle your
pointers correctly. Look carefully in your code for everywhere you use
pointers. Memory leaks exist where pointers are newed but never deleted.
Also, anywhere you have a new[], you need a matching delete[], not just
delete.

Run your code in a debugger. It may not crash there, but it will help you
spot any place where you access an invalid pointer.

Look especially for use of pointers that have not had an object assigned to
them yet. These are called "uninitialized pointers", and are often the
problem if you've got code that didn't crash in a debug build but does in
release builds. That's especially true if you've got checks in the code for
testing if a pointer is NULL. In debug builds, the memory may get zeroed
out, so that uninitialized pointers test as NULL, but in the release buidls,
the memory is not zeroed out in advance, so the pointer contains garbage,
and your test for NULL fails. Make sure all pointers point to valid data or
are set to NULL when defined.

The other main memory issue that causes random crashes is overrunning the
end of an array. You may have forgotten to leave enough space for the null
terminator in a C-style string (char array). Or you may have a loop that
indexes the array starting at 1 instead of 0. In those cases, when you
write past the end of the array, you stomp on some other part of memory,
which may belong to code that executes an hour later, causing the "random"
crash.

Hope this helps...

-Howard


Jul 23 '05 #6

P: n/a
gr**********@gmail.com wrote:

You are telling there is no application ever written that does not
crash from time to time ?
He didn't tell you that.
All Dietmar said, is: If the application is designed right, the
likelyhood of crashes decreases. And if it crashes, then the programmer
most often knows what to do :-)

Just humour me a minute. Theoretically, how would you go about finding
out what is causing a random crash ?


The first thing that needs to be done:
Transform 'random crash' into:
'It crashes, if it does x, followed by y, followed by z.'

in other words: make the crashes deterministic or at least figure
out where the crash happens and what subsystems of the program are
involved. This might require you to write a logfile and carefull
study of that logfile to figure out what is going on. Once you know
where the crash happens and know what was involved with the crash, the
real fun begins: 'figuring out why it crashed'.

--
Karl Heinz Buchegger
kb******@gascad.at
Jul 23 '05 #7

P: n/a
greenings...@gmail.com wrote:
You are telling there is no application ever written that does not
crash from time to time ?
No, I don't. However, it is quite long since I had random crashes in
my own programs (except for some MT errors...): I either had blatant
errors which just crashed the program as soon as the code was executed
or the applications just run.
Just humour me a minute. Theoretically, how would you go about finding out what is causing a random crash ?


I actually already said how I would go about finding random crashes:
run the program with Purify. OK, that was before I checked the prices
(something like EUR 3000 and above...): this does not necessarily make
it a viable tool in all cases :-( However, it is definitely worth its
price for professional software development using C or C++: I'm using
this tool to verify the correctness of my programs (and it very rarely
detects anything) and to correct errors in programs, including ones
I haven't written. If you are not used to using Purify, it almost
certainl will highlight questionable program segments. Some of these
are actually false positives but these are easily suppressed (typical
suppression files I have include one or two dozens entries, often
duplicates due to different software versions). In general, Purify
only shows problems. You can get an evaluation version from IBM's site.

Assuming that Purify is no option due to its steep price, there are
a few other things you may be able to do:

- For the off-chance that the random crashes are actually a genuine
error caused at the crash site, you should load a core into your
debugger and analyse the code section for problems. If the random
errors are indeed random, this will not have much effect, however.

- Compilers are relatively smart about what a programmer should better
not do. Thus, you should compile your program with highest warning
level and act on each warning! The action may be a comment in the
code ("compiler warns about ... but this is actually OK") after
verifying that the code indeed does with it is supposed to do. Like
with Purify, compilers also give false positives and may force you
into a slightly different programming style to make the warnings go
away but often they are right about their complaints.

- Repeat the previous step with a different compiler! Actually, trying
to compile and run your code with a different compiler may provide
you with unexpected behavior already. Also, different compilers
enforce different rules, i.e. you should even expect compiler errors
when using a different compiler which also highlight problematic
section - at least often. Sometimes they are also due to inferior
compliance to the C++ standard, i.e. you probably want to use are
rather compliant compiler (e.g. Comeau C++ for just $50 is an
option).

This is mostly about static analysis and there are even programs
which specialize in static analysis e.g. from Gimpel (PCLint) and
Programming Research (QAC++). However, these tools also have a
rather non-negligible price.

- Search for uses of "known" dangerous functions, e.g. 'gets()',
'sprintf()', 'operator>>(char*)', etc. Where possibly, replace
them with safe alternatives (e.g. 'fgets()', 'snprintf()',
'operator>>(std::string)') and in all other places verify that
they cannot cause any problems, e.g. because the input is already
known and verified.

OK, this far the stuff is rather non-intrusive: the application is
not changed in any form specifically for testing (handling warnings
and errors may incur changes but these will stay in the code). If
this did not yield sufficient results or if you want to do further
verification, you would create a special test version of your
application:

- Some libraries, including standard libraries, come with debugging
versions or you can obtain some debugging version. For example,
you can using STLPort in debugging mode as a replacement for [most
of] the standard C++ library. In debugging mode this library will
test many things which a release version version does not test,
e.g. out of bound access in 'std::vector'. Run your application
after compiling it with the most aggressive debugging options
turned on.

- Some compilers have switches which will result in the memory of
released variables being overwritten by some fixed bit pattern.
Often you can replace the memory management functions ('malloc()',
'free()', 'operator new()', etc.) to do something similar. This
detects uses of stale objects.

- Again replacing the memory management functions, you can arrange
for memory blocks being located at page boundaries where the
adjacent page is access protected - at least if you are not
using lots of memory. efence is a library which does just that.

If nothing of the above helps, its time to purchase Purify... If
this is not an option, it is time to rework the whole application to
use modern C++ techniques, e.g. containers, smart pointers, etc.
These make some problem detection viable through libraries like
STLport. Of course, this get rather involved. If you are going down
this route, here are more things you might want to consider:

- Single step through the program and verify that the "right" thing
is happening. It is sometimes quite surprising that the program
does other things than you might expect.

- Do a thorough code review.

The important thing to note is that I'm not really making fun of you
if I state that you should have programmed your application
differently from ground up: some techniques lend to better error
discovery than others. Following certain styles, using certain
libraries, etc. helps with program correctness. It actually helps
that much that even in C++ "typical" programming errors like the
"random crash" can be prevented most of the time. The areas where
this can not [yet] be done seem to lack appropriate approaches, e.g.
multi-threading.
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

Jul 23 '05 #8

P: n/a
Hi,

You can check whether you are deleting an object that has already
being deleted.

Or you can use memory manager http://www.fluidstudios.com/?freeware
to detect memory leak

ko*****@w-manager.com

Jul 23 '05 #9

P: n/a
gr**********@gmail.com wrote:
You are telling there is no application ever written that does not
crash from time to time ?

Just humour me a minute. Theoretically, how would you go about finding
out what is causing a random crash ?


This is really outside the realm of the language you are using, but what
you need to learn about is post-mortem analysis. On Unix (which I am
more familiar with), when a program crashes it leaves a file called
'core' (or sometimes 'core.pid'). This file can be loaded with a
debugger and will show you the state of the process when it crashed.
Depending on what exactly caused the crash, you may be able to see the
specific cause of the crash (for example, trying to dereference a NULL
pointer). Hopefully you can then go from specific cause to root cause
(why did you program logic allow a NULL pointer at that place).

Unfortunately, not all crashes can easily be solved via post mortem
debugging. If memory gets trashed, by the time the program actually
crashes it can be extremely difficult to work out the root cause.

That said, on Windows there is some way to configure it to leave the
equivalent of a core called a user.dmp; you'll need to configure
DrWatson correctly to have one generated on crash.

samuel
Jul 23 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.