Re: how to find error

On 8/23/21 6:27 AM, Robert Magdziarz wrote:
> I have an error in my program which occurs rarely (I see wrong values in XML output file). I inserted a few assertions into functions which (as I suppose) contain error. Unformtuantely I failed to reproduce error.
> Q: How to solve my problem, how to find error? What strategy should I use?
> I am not very experienced programmer, intermediate I would say. 

A call to assert() should have an effect only if it is triggered, in
which case you should see the assert message and the program should
terminate. If inserting an assert() does change the behavior without
getting triggered, that implies that some other part of your program has
behavior that is unspecified, and probably undefined. That,
unfortunately, doesn't help very much because there's such a huge
variety of different possible reasons why your code might have
unspecified behavior. That's pretty nearly 100% of what can be said
based upon what you've written above. As others have pointed out, you
really need to provide more information before anyone can help you with
this.

Now, you may be thinking "my program is way too big, I can't just post
the entire thing", and you're probably right about that. However, I can
give you some advice that will help you pare it down to a more
manageable size. It has the added advantage that following this process
often helps you figure out the problem by yourself.

You will be maintaining three copies of your program. The first is the
original version that demonstrated the problem, which won't be touched
by this process. The second version will be your working copy, which is
where you will make all of your changes. The third version is the most
recent version of the working copy that demonstrated the problem you're
investigating. If you're very familiar with a version control system of
some kind, it can be useful to use such a system to keep track of these
versions. Otherwise, just do it manually.

At the start, the second and third versions should be initialized by
copying from the original version.

The main part of this process is iterative.
First, remove some part of the program. It must be a part that should,
according to your understanding, have no effect on the ability of your
program to demonstrate the problem. Secondarily, it should be as large a
part of your program as possible. A good choice for the first iteration
would be to remove everything that's supposed to get executed only after
the part that's malfunctioning. You might need to re-write some of the
remaining code to make it work in some useful fashion after removing
that part. Keep notes on what part you removed at each step. If you're
using a version control system, good check-in comments can serve as your
notes.
The key point of removing that section is to determine whether or not
you were right about it having no effect. If you understood precisely
how your program actually works, you would already know how to fix it,
so you should expect to be incorrect about something. The next step,
therefore, is to test whether the modified version of your program
actually still demonstrates that problem.

If it does demonstrate the problem, your working version become the new
latest version that demonstrates the problem, and also becomes the
starting point for the next step through the iteration.
If it no longer demonstrates the problem, think very carefully about how
the change failed to have the effect you thought it should have. Often,
that's very important information that might lead you to figure out what
it was you were misunderstanding. If not, discard your changes, and go
back to the latest version that did demonstrate the problem, as the
starting point for your next step in the iteration. It's very importance
to make sure that whatever you remove during the next iteration be
different from what you removed during this iteration. Often you can
simpler remove less than you did during this iteration.

If you never figure out the problem for yourself, you'll eventually
reach the point where you can't think of anything more to remove. By
this time, it should be a lot shorter than the original version.
Therefore, it's time to give your complete but simplified program to
someone else to ask them for help, for example this newsgroup.

When you ask for that help, describe precisely the platform that you're
using, as well as the name of the compiler you're using, the version of
that compiler, and the options you selected when building it. Very
little code is perfectly portable, and that's particularly true of
whatever code you've written that's not doing what you think it should do.

If the program needs any inputs, document them. Explain precisely what
you expected the program to do - this might seem obvious, but problems
are often due to you having erroneous expectations. Then present
whatever evidence you have to show that it did something other than what
you expected.