Bug in my C++ program seems really strange. (Update on debugging progress)

[mike3]

Hi.

I seem to have made some progress on finding that bug in my program. I
deactivated everything in the bignum package that was used except for
the returning of BigFloat objects. I even crippled all the
constructors. So now all the operations and constructors that were
used do is just return BigFloats but no memory is actually accessed at
any point, nor is any allocated. However, when I reenable those parts
of the constructor that allocate memory, and _then_ enable the part of
the _de_structor that _frees_ the memory, the bug appears. It only
seems when I go to allocate the "digits" buffer with (in constructor)

digits = new DIGIT32[length];

and free with (in destructor)

delete digits;

or:

(allocate in constructor) digits = (DIGIT32
*)malloc(length *sizeof(DIGIT32 ));

(free in destructor) free(digits);

When I don't call free or delete, though, the crash does not appear.
But it does not seem to be something needing the memory and then
accessing it as I tried it with none allocated in the first place and
"digits" set to a dummy pointer, and there was no bug nor any attempt
to access the memory as that would crash the program. It only happens
when you allocate memory in the constructor and free it in the
destructor. Freeing it immediately after allocation, in the
constructor, does not result in the crash bug.

What gives, anyway?

[mike3]

Ooops! Sorry about the double posting. Darn,
Google crashed...

[Gianni Mariani]

mike3 wrote:

On Aug 31, 10:32 pm, "Alf P. Steinbach" <[e-mail] wrote:

....

http://www.mediafire.com/?cfmzd1y3yij

How does one build all that ?

[BobR]

mike3 <mi******@yahoo .comwrote in message...

>
digits = new DIGIT32[length];

and free with (in destructor)

// delete digits;

delete [] digits;

If you 'new', you 'delete'.
If you 'new[]', you 'delete[]'.

--
Bob R
POVrookie

[mike3]

On Sep 1, 10:17 am, "BobR" <removeBadB...@ worldnet.att.ne twrote:

mike3 <mike4...@yahoo .comwrote in message...

digits = new DIGIT32[length];

and free with (in destructor)

// delete digits;

delete [] digits;

If you 'new', you 'delete'.
If you 'new[]', you 'delete[]'.

Tried that, still crashes!

--
Bob R
POVrookie

[BobR]

mike3 <mi******@yahoo .comwrote in message...

On Sep 1, 12:57 am, "Alf P. Steinbach" <[e-mail] wrote:

Changes to make it /compile/:

fracalg\compute frac.cpp(371):# if 0 file://APS
fracalg\compute frac.cpp(378):# endif file://APS
fracalg\compute frac.cpp(393):# if 0 file://APS
fracalg\compute frac.cpp(396):# else file://APS

Excuse me, why all this? Those were commented
out for debugging purposes to help minimalize
the code.

Then they should have been removed for posting. I would be pissed if I spent
good money to download it with my slow dial-up.

>

render\render.c pp(51): file://APS MessageBox(NULL , TEXT("Zorg."),
TEXT(""), MB_OK);
render\render.c pp(69): file://APS MessageBox(NULL , TEXT("Borg."),
TEXT(""), MB_OK);

Why couldn't it compile with those in?

It's windows code. GNU don't play that!

>

win32\CMainWnd. cpp(52): wcx.hCursor = LoadCursor(0,
IDC_ARROW); file://APS LoadCursor((HAN DLE)NULL, IDC_ARROW); /* cursor */

win32\fg3dImage Window.cpp(34): wcx.hCursor =
LoadCursor(0,ID C_ARROW); file://APS file://LoadCursor((HAN DLE)NULL,

IDC_ARROW); /*

cursor */

win32\fg3dNewIm ageWzrd.cpp(18) ://APS HWND gTmp;
win32\fg3dNewIm ageWzrd.cpp(32) ://APS gTmp = hwndTmp;
main.h(108)://APS extern HWND gTmp;
fracgen3d.cpp(7 9):// APS

Plus, the WinMain function must be changed to something like

int WINAPI WinMain(HINSTAN CE TheInstance, HINSTANCE LastInstance,
LPSTR lpszCmdLine, int iCmdShow){
__try{
return cppWinMain( TheInstance, LastInstance, lpszCmdLine,
iCmdShow );
}
__except(TRUE){
TCHAR szBuf[256];
StringCchPrintf (szBuf, 256, TEXT("EXCEPTION %08lX"),
GetExceptionCod e());
OutputDebugStri ng(szBuf);
return 0;
}
}

where cppWinMain contains the original code for that __try.

It's funny (is that the right word?) when the code contains C style
casts that makes it not compile, when all that's needed is to remove
those casts...

I must be using a really crappy C++ compiler then as
it allows that stuff.

Then set it up for standard compliance, and raise the warning levels.

>
So then it casts it automatically, you don't need all
that C-style stuff, then? Darn I'm too paranoid.

If you must, use the C++ casts so you get the proper warnings/errors.

>

Having done all the above the program crashes on using an invalid
pointer txtrptr in [render.cpp] at line 62, which is due to using an
uninitialized member "d3dlr" (presumably there should have been an
earlier call to FractalImage::L ockRectangle, but no such).

That is uninitialized? It calls LockRectangle() right
in there @ line 46.

Did you check whether the pointer is valid during/after the 'call'?

If nothing else, try something like:
std::cout<<"poi nter addr="<<pointer <<" calling:"<<*poi nter;

If the pointer is invalid, that should cause a 'crash'. Then you'll know.

I've run into trouble in my own "spaghetti" code. Now days I separate the
GUI interface, C++ interface, and the work-horse code. Makes it much easier
to track problems, port to another OS, etc.. ( even wxWidgets needs some
'tweaking' between windows and GNU (GTK), but the underlying std C++ code
stays the same.)

--
Bob R
POVrookie

[mike3]

On Sep 1, 2:45 pm, "BobR" <removeBadB...@ worldnet.att.ne twrote:

mike3 <mike4...@yahoo .comwrote in message...

On Sep 1, 12:57 am, "Alf P. Steinbach" <[e-mail] wrote:

Changes to make it /compile/:

fracalg\compute frac.cpp(371):# if 0 file://APS
fracalg\compute frac.cpp(378):# endif file://APS
fracalg\compute frac.cpp(393):# if 0 file://APS
fracalg\compute frac.cpp(396):# else file://APS

Excuse me, why all this? Those were commented
out for debugging purposes to help minimalize
the code.

Then they should have been removed for posting. I would be pissed if I spent
good money to download it with my slow dial-up.

Looking again at the changes he posted I'm not sure
what they were supposed to do, if they were to
remove undefines or add them in. I looked at my
package and there doesn't seem to be anything
commented out or otherwise removed. Perhaps he
could explain the problem that this was supposed
to remedy? I'm not sure what is going on there
now.

<snip>

Why couldn't it compile with those in?

It's windows code. GNU don't play that!

He was using GNU compilers? I thought there
were versions of the GNU compilers for Windows.
If his compiler, GNU or otherwise, was unable
to support Windows he couldn't have run the
program as the whole "main" thing, "wnd" stuff
was all Windows. I'm guessing his compiler did
support Windows since he was able to run it
without modifications _that_ extensive.

<snip>

I must be using a really crappy C++ compiler then as
it allows that stuff.

Then set it up for standard compliance, and raise the warning levels.

What compiler do you use, by the way? I've got a
version of the GNU compilers on my system too,
and I could feed the non-Windows stuff through
it. If you're using GNU compilers (as I've
assumed from your "GNU don't play that!" comment),
could you explain how you do this (the "set it up
for standard compilance" part. I already know
how to raise the warning level.).

>

So then it casts it automatically, you don't need all
that C-style stuff, then? Darn I'm too paranoid.

If you must, use the C++ casts so you get the proper warnings/errors.

Well I've been converting my main program to use
these.

>

Having done all the above the program crashes on using an invalid
pointer txtrptr in [render.cpp] at line 62, which is due to using an
uninitialized member "d3dlr" (presumably there should have been an
earlier call to FractalImage::L ockRectangle, but no such).

That is uninitialized? It calls LockRectangle() right
in there @ line 46.

Did you check whether the pointer is valid during/after the 'call'?

Why the scare quotes around "call", anyway?

If nothing else, try something like:
std::cout<<"poi nter addr="<<pointer <<" calling:"<<*poi nter;

If the pointer is invalid, that should cause a 'crash'. Then you'll know.

I've run into trouble in my own "spaghetti" code. Now days I separate the
GUI interface, C++ interface, and the work-horse code. Makes it much easier
to track problems, port to another OS, etc.. ( even wxWidgets needs some
'tweaking' between windows and GNU (GTK), but the underlying std C++ code
stays the same.)

--
Bob R
POVrookie

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

On 2007-09-01 23:17, mike3 wrote:

On Sep 1, 2:45 pm, "BobR" <removeBadB...@ worldnet.att.ne twrote:

>mike3 <mike4...@yahoo .comwrote in message...

On Sep 1, 12:57 am, "Alf P. Steinbach" <[e-mail] wrote:

<snip>

I must be using a really crappy C++ compiler then as
it allows that stuff.

Then set it up for standard compliance, and raise the warning levels.

What compiler do you use, by the way? I've got a
version of the GNU compilers on my system too,
and I could feed the non-Windows stuff through
it. If you're using GNU compilers (as I've
assumed from your "GNU don't play that!" comment),
could you explain how you do this (the "set it up
for standard compilance" part. I already know
how to raise the warning level.).

-std=c++98

--
Erik Wikström

[mike3]

On Sep 1, 5:06 pm, "Alf P. Steinbach" <[e-mail] wrote:

* mike3:

What would be a better compiler, by the way? I've only
got this one since I didn't have to pay money for it
and I do not have a lot of money.

It seems you forgot to state which compiler you're using.

I use the Borland C++ Builder 5.5 Command line tools.

However, seeing as this is Windows programming, Visual C++ 8.0 is fairly
good and gratis. Including an IDE, which, unfortunately, is crappy.

Gratis, really?

Is there a "stripped" version that has only the
C++ compilers, like with the Borland thing?

[snip]

Then I'd be curious to know. Does this require a cast,
to get the value of the pointer for our error information?:

FG3DError SomeRoutine(Big Float *a)
{
FG3DError err;

<blah blah blah>

if(<some operation on "a" failed>)
return(FG3DErro r(<Error code>, a)); <--- here
else
return(FG3DErro r(FG3D_SUCCESS) );
}

Do something like

void someRoutine( BigFloat const& a )
{
// some operation on "a"
}

If "some operation" fails it will throw an exception.

What if the operation though is something that returns
an error value instead? Oh and when I throw the exception
I also need to convert a pointer to give additional
information to whatever handler catches the exception,
(there's handlers in any area where exceptions may
get thrown out of) for example to show that an
operation on "a" failed.

Should there be _no_ functions that return error
values, and instead _always_ throw exceptions when
they fail (as that way you don't have to worry about
neglecting an error check around one, you can just
keep a few exception handlers at various levels,
etc.?)?

Notice how extremely much simpler this is, in addition to be much more safe.

And this?

long MultiplyShorts( short b, short c)
{
long a;

a = b*c;

return(a);
}

Here you need conversion:

inline long productOf( short a, short b )
{
long aLong const = a;
return aLong*b;
}

or

inline long productOf( short a, short b )
{
return (a+0L)*b;
}

Since this function is evidently intended to be used in expressions, the
name has been changed to indicate the result rather than the operation
(like, instead of "computeSin ", just "sin").

I actually do not have a function like that in my
program, but the situation shown in that minimal
function is often found in more complex functions
like the bignum routines, for example. So then
I'd need to create ad hoc variables specifically
for the purpose of converting?

Will this give the full "long" result

No, in the code you showed the arguments would be promoted to int, the
computation done as int, and only then the result converted to long.

So then you have to typecast, right?

or
do I need to typecast b and c to "short"?

?

I meant, typecast to "long", sorry.

[snip]

double DivideInts(int a, int b)
{
double t;

t = a/b;

return(t);
}

Does that give a full floating-point double-
precision quotient of a and b or an integer one?

Integer.

So then would a typecast be a good idea?

Or is does this do it, and is it "proper"?:

---
double DivideInts(int a, int b)
{
double adbl = a;
double bdbl = b;

return(adbl/bdbl);
}
---

(No typecasting)

By the _C++ standard_, remember. See, in all
three of these situations I've used a cast, and
it is these situations that account for the vast
majority of my cast use.

No need to use casts in any of the code you've shown.

By not using casts needlessly, and using the C++ style casts (like
static_cast, reinterpret_cas t, dynamic_cast, const_cast) where you
absolutely need one, you make it possible to /search/ for casts.

Searching for casts can be relevant because casts are a main source of
bugs -- which is the main reason to avoid them. ;-)

I've got nearly all the casts converted, so now I
can start removing them.

>>Having done all the above the program crashes on using an invalid
pointer txtrptr in [render.cpp] at line 62, which is due to using an
uninitializ ed member "d3dlr" (presumably there should have been an
earlier call to FractalImage::L ockRectangle, but no such).
That is uninitialized? It calls LockRectangle() right
in there @ line 46.
I'm just reporting what it did. There was no actual call to that
function at run-time, before the crash. As to why that should happen,
well. :-)

Uh oh...

Why wouldn't it call? That does not make any sense! It
calls on my machine.

Checking...

This happens with menu choice "New fractal...".

Oops, I said something wrong (hasty me). LockRectangle /is/ called, but
the section of code there that initializes the "d3dlr", where I
naturally placed the breakpoint, is within

if(LockStatus == FALSE) { ... }

and LockStatus has a non-zero value, apparently uninitialized.

Summing up, I think it would really help if you tried very hard to do
/guaranteed/ initialization. Not calling Init-functions. Using
constructors that either initialize everything successfully, or throw.

The structure, "FractalIma ge" has a real constructor,
but I only added the LockStatus flag in LATER, and FORGOT
to put it in the constructor! Dang!!!

It works now! The bug has been fixed!

The Init functions are *pnly* and I say again, *ONLY*
called in CONSTRUCTORS, period. And *always* called from
them. They're just there to save a bit of cutting-and-
pasting. At no point are they called anywhere else.

[snip]

The constructors do throw exceptions if they cannot initialize
something
completely and successfully. So it would be OK to remove all
initialization
checks except the exception throwing, then?

Yes, when the other aspects are fixed. By that I mean, not calling
Init-functions that call other functions... Using just constructors,
and even introducing dummy private base classes to do this.

Now as mentioned that isn't ideal. It's just a technical fix. Ideal
would be some redesign.

Could you tell me where my design is wanting, by the way?
I'd like to know so I can improve it.

But by limiting yourself to a very harsh initialization regime, you'll
avoid pitfalls that otherwise could and probably would strand you (until
you gain more experience with initialization concerns in C++).

I try to make sure it's all initialized, but as I add
more to the classes sometimes I forget to add something
(like the dilemma that caused this whole problem) to the
initializing procedures. That's called "human error",
and it's bound to happen eventually.

Cheers, & hth.,

- Alf

PS: *PLEASE DON'T QUOTE SIGNATURES!*

Signature snipped.

[Duane Hebert]

I use the Borland C++ Builder 5.5 Command line tools.

>

>However, seeing as this is Windows programming, Visual C++ 8.0 is fairly
good and gratis. Including an IDE, which, unfortunately, is crappy.

Gratis, really?

Is there a "stripped" version that has only the
C++ compilers, like with the Borland thing?

I think it just does c++ but it has an IDE. You can also get Borland's
Turbo
Explorer that's based on BDS2006. It has an IDE and a newer compiler
than 5.5. Or just get both and see what you like. Both are free.