Frustrating bug in C++ program

[mike3]

Hi.

I was writing a program in C++ that generates fractals. I got this
weird bug though right now that's holding it up and was wondering if
you could help.

Anyway, it seems that when this code is executed, it corrupts the
memory causing a crash later on (the program actually causes an
"access violation" error in Windows, which the program is running
under):

*WindowXStep_W /= (*Mag_W * (u32)2);
*WindowYStep_W /= (*Mag_W * (u32)2);

Here "WindowXStep_W", "Mag_W" are of a custom type called "BigFloat"
that contains a bignum implementation, with overloaded operators. I've
looked over all the calculation routines and can't find any reason
they would corrupt the memory. It seems to have something to do with
the use of operators that take two operands and then output one --
things like the multiplication above. When the code is changed to

*WindowXStep_W /= *Mag_W ;
*WindowYStep_W /= *Mag_W;
*WindowXStep_W /= (u32)2;
*WindowYStep_W /= (u32)2;

or even

*Mag_W *= (u32)2;
*WindowXStep_W /= *Mag_W;
*WindowYStep_W /= *Mag_W;

(which of cours secrews up Mag_W's value, but the change is for
debugging this specific problem.)

there's no problem. Similar problems seem to occur with any use of
operators that return a "BigFloat", like "*", "+", and "-", and not
"const BigFloat &" operators like "/=" and "*=" above. I even
"debased" them to remove the calculation guts and leave just "return
BigFloat(...)" at the end and still it crashes. I checked through
"EquateBF" which equates one BigFloat to another, and couldn't find
anyhting that would create a memory overflow or something.

Here's a few code snippets in case they might help:

/* Construct a BigFloat that is a copy of another. */
BigFloat::BigFloat(const BigFloat & bfValue)
{
FG3DError err;

/* Initialize */
err = this->Init(bfValue.length);
if(err.dwErrCode != FG3D_SUCCESS)
throw Exception(err);

/* Set to BigFloat */
err = this->EquateBF(&bfValue);
if(err.dwErrCode != FG3D_SUCCESS)
throw Exception(err);

/* Done! */
return;
}

(note: "u32" = "unsigned long")

BigFloat operator*(const BigFloat &a, u32 b)
{
FG3DError err;
BigFloat tmp = BigFloat((BOOL)FALSE, a.length);

/* Mul */
err = FG3DMPFloat_MulSmallU(&tmp, &a, b);
if(err.dwErrCode != FG3D_SUCCESS)
throw Exception(err);

/* Return result */
return(tmp);
}

/* Division operator: /= */
const BigFloat & BigFloat::operator/=(const BigFloat &a)
{
FG3DError err;

/* Div */
err = FG3DMPFloat_Div(this, this, &a);
if(err.dwErrCode != FG3D_SUCCESS)
throw Exception(err);

/* Return result */
return(*this);
}

[tony_in_da_uk]

On Aug 15, 4:54 pm, mike3 <[e-mail]:

*WindowXStep_W /= (*Mag_W * (u32)2);
*WindowYStep_W /= (*Mag_W * (u32)2);

Here "WindowXStep_W", "Mag_W" are of a custom type called "BigFloat"
that contains a bignum implementation, with overloaded operators. I've

Are they BigFloats, or BigFloat*s? If they really are BigFloats, then
please post the unary BigFloat::operator*() if any....

Tony

[Frank Birbacher]

Hi!

mike3 schrieb:

/* Construct a BigFloat that is a copy of another. */
BigFloat::BigFloat(const BigFloat & bfValue)
{

[snip]

}

Do you also have a custom operator = ?

BigFloat operator*(const BigFloat &a, u32 b)
{
FG3DError err;
BigFloat tmp = BigFloat((BOOL)FALSE, a.length);

/* Mul */
err = FG3DMPFloat_MulSmallU(&tmp, &a, b);
if(err.dwErrCode != FG3D_SUCCESS)
throw Exception(err);

/* Return result */
return(tmp);
}

There is a canonical implementation of binary operators which reuses the
other code:

BigFloat operator* (BigFloat tmp, u32 const b)
{
tmp *= b; //modify a copy
return tmp; //return
}

Also see here for automatic generation of operators:
http://www.boost.org/libs/utility/operators.htm

Frank

[mike3]

On Aug 15, 4:53 am, Frank Birbacher <[e-mail]:

Hi!

mike3 schrieb:

/* Construct a BigFloat that is a copy of another. */
BigFloat::BigFloat(const BigFloat & bfValue)
{

[snip]

}

Do you also have a custom operator = ?

Yes there is:

/* Assignment operator: = */
BigFloat & BigFloat::operator=(const BigFloat & a)
{
/* Equate */
FG3DError err = this->EquateBF(&a);
if(err.dwErrCode != FG3D_SUCCESS) throw Exception(err);
return(*this);
}

EquateBF method is defined as (The "FG3DRawInt"
routines operate on the raw string of "digits".
Here "DIGIT32" = "unsigned long"):

/* Equate a BigFloat to another. */
FG3DError BigFloat::EquateBF(const BigFloat *x)
{
DIGIT32 carry;

/* Safety */
if(digits == NULL)
return(FG3DError(FG3D_MP_UNINITIALIZED, (DWORD)this));
if(x->digits == NULL)
return(FG3DError(FG3D_MP_UNINITIALIZED, (DWORD)x));
/* Equate fields */
sign = x->sign;
exp = x->exp;
err = x->err;

/* Equate digits */
if(length >= x->length)
{
FG3DRawInt_Copy(digits+(length-x->length), x->digits, x-

>length);

FG3DRawInt_Zeroize(digits, length-x->length);
} else {
/* Round off excess digits */
carry = FG3DRawInt_CopyRounded(digits, x->digits, length, x-

>length);

if(carry)
{
if(exp == MAX_EXP)
{
/* Zounds! Overflow! */
err = 1;
return(FG3DError(FG3D_MP_OVERFLOW, (DWORD)this));
}

/* Shift in carry */
FG3DRawInt_Rsh(digits, digits, 1, length);
digits[length-1] |= MSBMask;
exp++;
}
}

/* Done! */
return(FG3DError(FG3D_SUCCESS));
}

BigFloat operator*(const BigFloat &a, u32 b)
{
FG3DError err;
BigFloat tmp = BigFloat((BOOL)FALSE, a.length);

/* Mul */
err = FG3DMPFloat_MulSmallU(&tmp, &a, b);
if(err.dwErrCode != FG3D_SUCCESS)
throw Exception(err);

/* Return result */
return(tmp);
}

There is a canonical implementation of binary operators which reuses the
other code:

BigFloat operator* (BigFloat tmp, u32 const b)
{
tmp *= b; //modify a copy
return tmp; //return

}

I tried it, thing still fails. It seems to
happen with operators that return "BigFloat"
and not "const BigFloat &".

Also see here for automatic generation of operators:http://www.boost.org/libs/utility/operators.htm

Frank

[mike3]

On Aug 15, 2:39 am, [e-mail] wrote:

On Aug 15, 4:54 pm, mike3 <[e-mail]:

*WindowXStep_W /= (*Mag_W * (u32)2);
*WindowYStep_W /= (*Mag_W * (u32)2);

Here "WindowXStep_W", "Mag_W" are of a custom type called "BigFloat"
that contains a bignum implementation, with overloaded operators. I've

Are they BigFloats, or BigFloat*s? If they really are BigFloats, then
please post the unary BigFloat::operator*() if any....

Tony

"*xxxx" means the BigFloat pointed at by the pointer
xxxx. These BigFloats are stored in something called
a "FractalMaker" that it used to generate the fractal
images. It has a list of pointers to BigFloats that
are created by it's constructor (using "XXXX = new
BigFloat(...)" for the pointer XXXX), and that hold
coordinates, etc. for the fractal.

[Frank Birbacher]

Hi!

mike3 schrieb:

I tried it, thing still fails. It seems to
happen with operators that return "BigFloat"
and not "const BigFloat &".

It seems there is something wrong with your copy constructor. But your
code is to complex for manual analysis. Can you possibly cut your code
down to a little working example which shows the error? Maybe drop all
but one operator (i.e. +) and all sourrounding code?

Frank

[Frank Birbacher]

Hi!

mike3 schrieb:

These BigFloats are stored in something called
a "FractalMaker" that it used to generate the fractal
images. It has a list of pointers to BigFloats that
are created by it's constructor (using "XXXX = new
BigFloat(...)" for the pointer XXXX), and that hold
coordinates, etc. for the fractal.

Is there a reason to use "new"? Why are the BigFloats not just ordinary
members of "FractalMaker"? Or at least managed by a container?

Frank

[r]

On Aug 15, 3:54 pm, mike3 <[e-mail]:

Hi.

I was writing a program in C++ that generates fractals. I got this
weird bug though right now that's holding it up and was wondering if
you could help.

Anyway, it seems that when this code is executed, it corrupts the
memory causing a crash later on (the program actually causes an
"access violation" error in Windows, which the program is running
under):

Sorry, I can't tell what the problem is with your code. But the way
to handle access violations is run the code under a debugger, make it
crash, then go through the call stack looking for the stray pointer.

[mike3]

On Aug 15, 3:36 pm, Frank Birbacher <[e-mail]:

Hi!

mike3 schrieb:

These BigFloats are stored in something called
a "FractalMaker" that it used to generate the fractal
images. It has a list of pointers to BigFloats that
are created by it's constructor (using "XXXX = new
BigFloat(...)" for the pointer XXXX), and that hold
coordinates, etc. for the fractal.

Is there a reason to use "new"? Why are the BigFloats not just ordinary
members of "FractalMaker"? Or at least managed by a container?

Frank

I set up a class that would test this method:

class Tester {
private:
BigFloat a;
public:
Tester();
~Tester();
};

Tester::Tester()
{
a = BigFloat((u32)4, 16); /* construct 512-bit BigFloat
* set to the value +4.
*/
}

Tester::~Tester()
{
delete &a;
}
When a "Tester" is created the default BigFloat
constructor though is called FIRST which constructs
a BigFloat with 64 bits and a value of zero. The
statement in Tester::Tester() above then
assigns it the value of a TEMPORARY BigFloat with
value 4 and 512 bits of precision as best as
it can, which means we LOSE 448 bits of precision!
Yikes!

[mike3]

On Aug 15, 3:31 pm, Frank Birbacher <[e-mail]:

Hi!

mike3 schrieb:

I tried it, thing still fails. It seems to
happen with operators that return "BigFloat"
and not "const BigFloat &".

It seems there is something wrong with your copy constructor. But your
code is to complex for manual analysis. Can you possibly cut your code
down to a little working example which shows the error? Maybe drop all
but one operator (i.e. +) and all sourrounding code?

Frank

See the thing is though that the problem
only became evident when it was used in a complex
program. But not using the offending area of code
seems to cause the problem to disappear. But I
can't just not use the code and I want the thing
to work.

[Jim Langston]

"mike3" <mi******@yahoo.comwrote in message
news:11*********************@l22g2000prc.googlegro ups.com...

On Aug 15, 3:31 pm, Frank Birbacher <[e-mail]:

>Hi!

mike3 schrieb:

I tried it, thing still fails. It seems to
happen with operators that return "BigFloat"
and not "const BigFloat &".

It seems there is something wrong with your copy constructor. But your
code is to complex for manual analysis. Can you possibly cut your code
down to a little working example which shows the error? Maybe drop all
but one operator (i.e. +) and all sourrounding code?

Frank

See the thing is though that the problem
only became evident when it was used in a complex
program. But not using the offending area of code
seems to cause the problem to disappear. But I
can't just not use the code and I want the thing
to work.

Copy your program to a new program. Start reducing the size trying to get it
to compile in a small a size as possible still showing the bug. Removing
things from the class that shouldn't be necessary to show the bug etc...

Either you'll reduce the program to something small enough to show us, or
you'll remove something and the program will stop working or the bug will go
away. At this point it might come up, "Oh, THAT'S why it's happening!"

[Frank Birbacher]

Hi!

mike3 schrieb:

I set up a class that would test this method:

class Tester {
private:
BigFloat a;
public:
Tester();
~Tester();
};

I replaced your ctor:

Tester::Tester()
: a((u32)4, 16) //construct "a"
{}

This construct is called "initialization list". You can list all members
and base classes separated by comma and make calls to their
constructors. This way you can even create "const" members.

Tester::~Tester()
{
delete &a;
}

Yikes! There is no "new", thus there MUST NOT be a "delete".

which means we LOSE 448 bits of precision!

Just because you didn't use ctors properly. So now we made your class a
lot safer. Good, isn't it?

Frank

[mike3]

On Aug 15, 6:48 pm, Frank Birbacher <[e-mail]:

Hi!

mike3 schrieb:

I set up a class that would test this method:

class Tester {
private:
BigFloata;
public:
Tester();
~Tester();
};

I replaced your ctor:

Tester::Tester()
: a((u32)4, 16) //construct "a"
{}

This construct is called "initialization list". You can list all members
and base classes separated by comma and make calls to their
constructors. This way you can even create "const" members.

Tester::~Tester()
{
delete &a;
}

Yikes! There is no "new", thus there MUST NOT be a "delete".

<laughing and giggling>

No, I don't have a new. I DO have deletes though in FractalMaker
since there ARE news. I left that in since I had a "Tester"
with a new originally, but forgot to pull out the delete when
I removed the new.

which means we LOSE 448 bits of precision!

Just because you didn't use ctors properly. So now we made your class a
lot safer. Good, isn't it?

I'll go and do that in the FractalMaker and see if my problem
goes away.

Oops, it's still there. (The problem, that is.) DARNIT.
ARGH <bangs head on wall>

Frank

[mike3]

On Aug 15, 6:40 pm, "Jim Langston" <[e-mail]:

"mike3" <[e-mail] in message

news:11*********************@l22g2000prc.googlegro ups.com...

On Aug 15, 3:31 pm, Frank Birbacher <[e-mail]:

Hi!

mike3 schrieb:

I tried it, thing still fails. It seems to
happen with operators that return "BigFloat"
and not "constBigFloat&".

It seems there is something wrong with your copy constructor. But your
code is to complex for manual analysis. Can you possibly cut your code
down to a little working example which shows the error? Maybe drop all
but one operator (i.e. +) and all sourrounding code?

Frank

See the thing is though that the problem
only became evident when it was used in a complex
program. But not using the offending area of code
seems to cause the problem to disappear. But I
can't just not use the code and I want the thing
to work.

Copy your program to a new program. Start reducing the size trying to get it
to compile in a small a size as possible still showing the bug. Removing
things from the class that shouldn't be necessary to show the bug etc...

Either you'll reduce the program to something small enough to show us, or
you'll remove something and the program will stop working or the bug will go
away. At this point it might come up, "Oh, THAT'S why it's happening!"

I've tried using debugger output functions to display messages that
wouldt
tell me what gets called, etc. before the crash and isolated it to
something
that uses memory (go figure), but it only fails when BigFloats are
used.
And that's where I'm stumped. Is the bug in BigFloat, or this? It's
this
peculiar interaction between BigFloat and this other thing that
doesn't make
any sense. None of them are supposed to overflow. And it's only when
"BigFloat"-returning operators get used in that thing I showed.

This is so strange.

[Jim Langston]

"mike3" <mi******@yahoo.comwrote in message
news:11**********************@x40g2000prg.googlegr oups.com...

On Aug 15, 6:40 pm, "Jim Langston" <[e-mail]:

>"mike3" <[e-mail] in message

news:11*********************@l22g2000prc.googlegr oups.com...

On Aug 15, 3:31 pm, Frank Birbacher <[e-mail]:
Hi!

>mike3 schrieb:

I tried it, thing still fails. It seems to
happen with operators that return "BigFloat"
and not "constBigFloat&".

>It seems there is something wrong with your copy constructor. But your
code is to complex for manual analysis. Can you possibly cut your code
down to a little working example which shows the error? Maybe drop all
but one operator (i.e. +) and all sourrounding code?

>Frank

See the thing is though that the problem
only became evident when it was used in a complex
program. But not using the offending area of code
seems to cause the problem to disappear. But I
can't just not use the code and I want the thing
to work.

Copy your program to a new program. Start reducing the size trying to get
it
to compile in a small a size as possible still showing the bug. Removing
things from the class that shouldn't be necessary to show the bug etc...

Either you'll reduce the program to something small enough to show us, or
you'll remove something and the program will stop working or the bug will
go
away. At this point it might come up, "Oh, THAT'S why it's happening!"

I've tried using debugger output functions to display messages that
wouldt
tell me what gets called, etc. before the crash and isolated it to
something
that uses memory (go figure), but it only fails when BigFloats are
used.
And that's where I'm stumped. Is the bug in BigFloat, or this? It's
this
peculiar interaction between BigFloat and this other thing that
doesn't make
any sense. None of them are supposed to overflow. And it's only when
"BigFloat"-returning operators get used in that thing I showed.

This is so strange.

It sounds like BigFloats may be overflowing some buffer somewhere and
screwing up the memory. Can you post the entire BigFloat class?

[mike3]

On Aug 16, 3:23 pm, "Jim Langston" <[e-mail]:

"mike3" <[e-mail] in message

news:11**********************@x40g2000prg.googlegr oups.com...

On Aug 15, 6:40 pm, "Jim Langston" <[e-mail]:

"mike3" <[e-mail] in message

>news:11*********************@l22g2000prc.googlegr oups.com...

On Aug 15, 3:31 pm, Frank Birbacher <[e-mail]:
Hi!

mike3 schrieb:

I tried it, thing still fails. It seems to
happen with operators that return "BigFloat"
and not "constBigFloat&".

It seems there is something wrong with your copy constructor. But your
code is to complex for manual analysis. Can you possibly cut your code
down to a little working example which shows the error? Maybe drop all
but one operator (i.e. +) and all sourrounding code?

Frank

See the thing is though that the problem
only became evident when it was used in a complex
program. But not using the offending area of code
seems to cause the problem to disappear. But I
can't just not use the code and I want the thing
to work.

Copy your program to a new program. Start reducing the size trying to get
it
to compile in a small a size as possible still showing thebug. Removing
things from the class that shouldn't be necessary to show thebugetc...

Either you'll reduce the program to something small enough to show us, or
you'll remove something and the program will stop working or thebugwill
go
away. At this point it might come up, "Oh, THAT'S why it's happening!"

I've tried using debugger output functions to display messages that
wouldt
tell me what gets called, etc. before the crash and isolated it to
something
that uses memory (go figure), but it only fails when BigFloats are
used.
And that's where I'm stumped. Is thebugin BigFloat, or this? It's
this
peculiar interaction between BigFloat and this other thing that
doesn't make
any sense. None of them are supposed to overflow. And it's only when
"BigFloat"-returning operators get used in that thing I showed.

This is so strange.

It sounds like BigFloats may be overflowing some buffer somewhere and
screwing up the memory. Can you post the entire BigFloat class?

It's not a simple thing -- over 5700 lines of code. This is
because it contains several implementations of the
arithmetic algorithms, some of which are trimmed-down versions
that are used in more time-critical areas of the program (ie.
fewer branch points, etc.). For example there's a "small integer"
multiply/divide that allows for easier multiplication/division
of BigFloats by small integers. I don't have a "small integer"
add/subtract yet since I haven't needed that operation in any
time-critical area and hence just fake it by constructing a
temporary BigFloat that is equal in value to a small integer.
There are also "fast" add/sub/mul routines that assume equal-sized
operands, for example, and hence don't do any resizing or
pointer gymnastics (hence reducing branch points/"if"s) and have
various optimizations (for instance the "fast add" and "fast sub"
routines use a loop that contains a bit shift and an add/sub
merged into one.).

[mike3]

On Aug 18, 8:09 pm, mike3 <[e-mail]:

On Aug 16, 3:23 pm, "Jim Langston" <[e-mail]:

"mike3" <[e-mail] in message

news:11**********************@x40g2000prg.googlegr oups.com...

On Aug 15, 6:40 pm, "Jim Langston" <[e-mail]:
>"mike3" <[e-mail] in message

>>news:11*********************@l22g2000prc.googleg roups.com...

On Aug 15, 3:31 pm, Frank Birbacher <[e-mail]:
>Hi!

>mike3 schrieb:

I tried it, thing still fails. It seems to
happen with operators that return "BigFloat"
and not "constBigFloat&".

>It seems there is something wrong with your copy constructor. But your
>code is to complex for manual analysis. Can you possibly cut your code
>down to a little working example which shows the error? Maybe drop all
>but one operator (i.e. +) and all sourrounding code?

>Frank

See the thing is though that the problem
only became evident when it was used in a complex
program. But not using the offending area of code
seems to cause the problem to disappear. But I
can't just not use the code and I want the thing
to work.

>Copy your program to a new program. Start reducing the size trying to get
>it
>to compile in a small a size as possible still showing thebug. Removing
>things from the class that shouldn't be necessary to show thebugetc...

>Either you'll reduce the program to something small enough to show us, or
>you'll remove something and the program will stop working or thebugwill
>go
>away. At this point it might come up, "Oh, THAT'S why it's happening!"

I've tried using debugger output functions to display messages that
wouldt
tell me what gets called, etc. before the crash and isolated it to
something
that uses memory (go figure), but it only fails when BigFloats are
used.
And that's where I'm stumped. Is thebugin BigFloat, or this? It's
this
peculiar interaction between BigFloat and this other thing that
doesn't make
any sense. None of them are supposed to overflow. And it's only when
"BigFloat"-returning operators get used in that thing I showed.

This is so strange.

It sounds like BigFloats may be overflowing some buffer somewhere and
screwing up the memory. Can you post the entire BigFloat class?

It's not a simple thing -- over 5700 lines of code. This is
because it contains several implementations of the
arithmetic algorithms, some of which are trimmed-down versions
that are used in more time-critical areas of the program (ie.
fewer branch points, etc.). For example there's a "small integer"
multiply/divide that allows for easier multiplication/division
of BigFloats by small integers. I don't have a "small integer"
add/subtract yet since I haven't needed that operation in any
time-critical area and hence just fake it by constructing a
temporary BigFloat that is equal in value to a small integer.
There are also "fast" add/sub/mul routines that assume equal-sized
operands, for example, and hence don't do any resizing or
pointer gymnastics (hence reducing branch points/"if"s) and have
various optimizations (for instance the "fast add" and "fast sub"
routines use a loop that contains a bit shift and an add/sub
merged into one.).

Any response? Do you still want to see it?

[Jim Langston]

"mike3" <mi******@yahoo.comwrote in message
news:11**********************@e9g2000prf.googlegro ups.com...

On Aug 18, 8:09 pm, mike3 <[e-mail]:

>On Aug 16, 3:23 pm, "Jim Langston" <[e-mail]:

"mike3" <[e-mail] in message

>news:11**********************@x40g2000prg.googleg roups.com...

On Aug 15, 6:40 pm, "Jim Langston" <[e-mail]:
"mike3" <[e-mail] in message

>>news:11*********************@l22g2000prc.googleg roups.com...

On Aug 15, 3:31 pm, Frank Birbacher <[e-mail]>
wrote:
Hi!

>mike3 schrieb:

I tried it, thing still fails. It seems to
happen with operators that return "BigFloat"
and not "constBigFloat&".

>It seems there is something wrong with your copy constructor. But
your
code is to complex for manual analysis. Can you possibly cut your
code
down to a little working example which shows the error? Maybe
drop all
but one operator (i.e. +) and all sourrounding code?

>Frank

See the thing is though that the problem
only became evident when it was used in a complex
program. But not using the offending area of code
seems to cause the problem to disappear. But I
can't just not use the code and I want the thing
to work.

>Copy your program to a new program. Start reducing the size trying
to get
it
to compile in a small a size as possible still showing thebug.
Removing
things from the class that shouldn't be necessary to show
thebugetc...

>Either you'll reduce the program to something small enough to show
us, or
you'll remove something and the program will stop working or
thebugwill
go
away. At this point it might come up, "Oh, THAT'S why it's
happening!"

I've tried using debugger output functions to display messages that
wouldt
tell me what gets called, etc. before the crash and isolated it to
something
that uses memory (go figure), but it only fails when BigFloats are
used.
And that's where I'm stumped. Is thebugin BigFloat, or this? It's
this
peculiar interaction between BigFloat and this other thing that
doesn't make
any sense. None of them are supposed to overflow. And it's only when
"BigFloat"-returning operators get used in that thing I showed.

This is so strange.

It sounds like BigFloats may be overflowing some buffer somewhere and
screwing up the memory. Can you post the entire BigFloat class?

It's not a simple thing -- over 5700 lines of code. This is
because it contains several implementations of the
arithmetic algorithms, some of which are trimmed-down versions
that are used in more time-critical areas of the program (ie.
fewer branch points, etc.). For example there's a "small integer"
multiply/divide that allows for easier multiplication/division
of BigFloats by small integers. I don't have a "small integer"
add/subtract yet since I haven't needed that operation in any
time-critical area and hence just fake it by constructing a
temporary BigFloat that is equal in value to a small integer.
There are also "fast" add/sub/mul routines that assume equal-sized
operands, for example, and hence don't do any resizing or
pointer gymnastics (hence reducing branch points/"if"s) and have
various optimizations (for instance the "fast add" and "fast sub"
routines use a loop that contains a bit shift and an add/sub
merged into one.).

Any response? Do you still want to see it?

Well, I'm not a mind reader. I can't help to find a bug in something I
can't see.

Without seeing the code all I can say is, look for a buffer overrun or
something similar.

If you need more help than that then, yes, we will need to see the code.

[Frank Birbacher]

Hi!

mike3 schrieb:

Any response? Do you still want to see it?

Maybe start with some small pieces:

What are the attributes of class BigFloat. What does BigFloat::Init do?
Does BigFloat have a default ctor?

Frank

[mike3]

On Aug 21, 2:39 am, "Jim Langston" <[e-mail]:

"mike3" <[e-mail] in message

news:11**********************@e9g2000prf.googlegro ups.com...

On Aug 18, 8:09 pm, mike3 <[e-mail]:

On Aug 16, 3:23 pm, "Jim Langston" <[e-mail]:

"mike3" <[e-mail] in message

news:11**********************@x40g2000prg.googlegr oups.com...

On Aug 15, 6:40 pm, "Jim Langston" <[e-mail]:
>"mike3" <[e-mail] in message

>>news:11*********************@l22g2000prc.googleg roups.com...

On Aug 15, 3:31 pm, Frank Birbacher <[e-mail]>
wrote:
>Hi!

>mike3 schrieb:

I tried it, thing still fails. It seems to
happen with operators that return "BigFloat"
and not "constBigFloat&".

>It seems there is something wrong with your copy constructor. But
>your
>code is to complex for manual analysis. Can you possibly cut your
>code
>down to a little working example which shows the error? Maybe
>drop all
>but one operator (i.e. +) and all sourrounding code?

>Frank

See the thing is though that the problem
only became evident when it was used in a complex
program. But not using the offending area of code
seems to cause the problem to disappear. But I
can't just not use the code and I want the thing
to work.

>Copy your program to a new program. Start reducing the size trying
>to get
>it
>to compile in a small a size as possible still showing thebug.
>Removing
>things from the class that shouldn't be necessary to show
>thebugetc...

>Either you'll reduce the program to something small enough to show
>us, or
>you'll remove something and the program will stop working or
>thebugwill
>go
>away. At this point it might come up, "Oh, THAT'S why it's
>happening!"

I've tried using debugger output functions to display messages that
wouldt
tell me what gets called, etc. before the crash and isolated it to
something
that uses memory (go figure), but it only fails when BigFloats are
used.
And that's where I'm stumped. Is thebugin BigFloat, or this? It's
this
peculiar interaction between BigFloat and this other thing that
doesn't make
any sense. None of them are supposed to overflow. And it's only when
"BigFloat"-returning operators get used in that thing I showed.

This is so strange.

It sounds like BigFloats may be overflowing some buffer somewhere and
screwing up the memory. Can you post the entire BigFloat class?

It's not a simple thing -- over 5700 lines of code. This is
because it contains several implementations of the
arithmetic algorithms, some of which are trimmed-down versions
that are used in more time-critical areas of the program (ie.
fewer branch points, etc.). For example there's a "small integer"
multiply/divide that allows for easier multiplication/division
of BigFloats by small integers. I don't have a "small integer"
add/subtract yet since I haven't needed that operation in any
time-critical area and hence just fake it by constructing a
temporary BigFloat that is equal in value to a small integer.
There are also "fast" add/sub/mul routines that assume equal-sized
operands, for example, and hence don't do any resizing or
pointer gymnastics (hence reducing branch points/"if"s) and have
various optimizations (for instance the "fast add" and "fast sub"
routines use a loop that contains a bit shift and an add/sub
merged into one.).

Any response? Do you still want to see it?

Well, I'm not a mind reader. I can't help to find a bug in something I
can't see.

Without seeing the code all I can say is, look for a buffer overrun or
something similar.

If you need more help than that then, yes, we will need to see the code.

Alright, I've got it zipped. The whole BigFloat implementation.
Where should I send it?

[mike3]

On Aug 21, 12:47 pm, Frank Birbacher <[e-mail]:

Hi!

mike3 schrieb:

Any response? Do you still want to see it?

Maybe start with some small pieces:

What are the attributes of class BigFloat. What does BigFloat::Init do?
Does BigFloat have a default ctor?

Frank

Attributes? You mean all the data fields, etc? It
has 6:

sign: The sign of the number, 0 for positive, 1 for
negative.
Type: u8

err: Error flag. This is 1 if an error occured during
calculation (overflow, div by 0, etc.)
Type: u8

exp: Exponent field, from -32768 to +32767. Power
of 2 the mantissa is multiplied by.
Type: s16

length: Length of mantissa in DIGIT32s.
Type: int

digits: Pointer to an array of DIGIT32s that holds
the mantissa of the number. The least significant
digit comes first. The most significant digit
is normalized so it's top bit is 1 since numbers
should be 1.xxxxxxxxxxxx... * 10^exp (everything
there is in binary, "10" = 2). Unnormal numbers
are treated as zeroes, so no "denormals" or "gradual
underflow" is implemented (in my application I can
settle for the reduced range of representable values.).
Type: DIGIT32 *

(Note: u8 = unsigned char, s16 = signed short,
int = int).

BigFloat has a default constructor, yes, which just
calls BigFloat::Init to the default precision (128bit).

BigFloat::Init allocates the memory for the BigFloat.
It's real simple:

/* Initialize a BigFloat. Used by all constructors. */
FG3DError BigFloat::Init(int reqprec)
{
/* Safety */
if(((reqprec < MIN_PRECISION) || (reqprec MAX_PRECISION)) &&
(reqprec != -1))
return(FG3DError(FG3D_INVALID_PRECISION, (DWORD)reqprec));

/* -1 means default precision */
if(reqprec == -1) reqprec = DEFAULT_PRECISION;

/* Set fields */
length = reqprec;
sign = 0;
err = 0;
exp = 0;
digits = NULL;

/* Allocate array of DIGIT32s */
digits = new DIGIT32[length];
if(digits == NULL)
return(FG3DError(FG3D_OUT_OF_MEMORY, (DWORD)this));

/* Zeroize digits */
FG3DRawInt_Zeroize(digits, length);

/* Done! */
return(FG3DError(FG3D_SUCCESS));
}

[Jim Langston]

"mike3" <mi******@yahoo.comwrote in message
news:11**********************@e9g2000prf.googlegro ups.com...

On Aug 21, 2:39 am, "Jim Langston" <[e-mail]:

>"mike3" <[e-mail] in message

news:11**********************@e9g2000prf.googlegr oups.com...

On Aug 18, 8:09 pm, mike3 <[e-mail]:
On Aug 16, 3:23 pm, "Jim Langston" <[e-mail]:

"mike3" <[e-mail] in message

>news:11**********************@x40g2000prg.googleg roups.com...

On Aug 15, 6:40 pm, "Jim Langston" <[e-mail]>
wrote:
"mike3" <[e-mail] in message

>>news:11*********************@l22g2000prc.googleg roups.com...

On Aug 15, 3:31 pm, Frank Birbacher <[e-mail]>
wrote:
Hi!

>mike3 schrieb:

I tried it, thing still fails. It seems to
happen with operators that return "BigFloat"
and not "constBigFloat&".

>It seems there is something wrong with your copy constructor.
But
your
code is to complex for manual analysis. Can you possibly cut
your
code
down to a little working example which shows the error? Maybe
drop all
but one operator (i.e. +) and all sourrounding code?

>Frank

See the thing is though that the problem
only became evident when it was used in a complex
program. But not using the offending area of code
seems to cause the problem to disappear. But I
can't just not use the code and I want the thing
to work.

>Copy your program to a new program. Start reducing the size
trying
to get
it
to compile in a small a size as possible still showing thebug.
Removing
things from the class that shouldn't be necessary to show
thebugetc...

>Either you'll reduce the program to something small enough to
show
us, or
you'll remove something and the program will stop working or
thebugwill
go
away. At this point it might come up, "Oh, THAT'S why it's
happening!"

I've tried using debugger output functions to display messages
that
wouldt
tell me what gets called, etc. before the crash and isolated it to
something
that uses memory (go figure), but it only fails when BigFloats are
used.
And that's where I'm stumped. Is thebugin BigFloat, or this? It's
this
peculiar interaction between BigFloat and this other thing that
doesn't make
any sense. None of them are supposed to overflow. And it's only
when
"BigFloat"-returning operators get used in that thing I showed.

This is so strange.

It sounds like BigFloats may be overflowing some buffer somewhere
and
screwing up the memory. Can you post the entire BigFloat class?

>It's not a simple thing -- over 5700 lines of code. This is
because it contains several implementations of the
arithmetic algorithms, some of which are trimmed-down versions
that are used in more time-critical areas of the program (ie.
fewer branch points, etc.). For example there's a "small integer"
multiply/divide that allows for easier multiplication/division
of BigFloats by small integers. I don't have a "small integer"
add/subtract yet since I haven't needed that operation in any
time-critical area and hence just fake it by constructing a
temporary BigFloat that is equal in value to a small integer.
There are also "fast" add/sub/mul routines that assume equal-sized
operands, for example, and hence don't do any resizing or
pointer gymnastics (hence reducing branch points/"if"s) and have
various optimizations (for instance the "fast add" and "fast sub"
routines use a loop that contains a bit shift and an add/sub
merged into one.).

Any response? Do you still want to see it?

Well, I'm not a mind reader. I can't help to find a bug in something I
can't see.

Without seeing the code all I can say is, look for a buffer overrun or
something similar.

If you need more help than that then, yes, we will need to see the code.

Alright, I've got it zipped. The whole BigFloat implementation.
Where should I send it?

Put it on some website somewhere, or use some binary newsgroup. I don't
have anyone send me anything to my personal e-mail because I won't respond.
I only respond to public message/inquiries.

[mike3]

On Aug 21, 11:38 pm, "Jim Langston" <[e-mail]:

"mike3" <[e-mail] in message

news:11**********************@e9g2000prf.googlegro ups.com...

On Aug 21, 2:39 am, "Jim Langston" <[e-mail]:

"mike3" <[e-mail] in message

>news:11**********************@e9g2000prf.googlegr oups.com...

On Aug 18, 8:09 pm, mike3 <[e-mail]:
On Aug 16, 3:23 pm, "Jim Langston" <[e-mail]:

"mike3" <[e-mail] in message

news:11**********************@x40g2000prg.googlegr oups.com...

On Aug 15, 6:40 pm, "Jim Langston" <[e-mail]>
wrote:
>"mike3" <[e-mail] in message

>>news:11*********************@l22g2000prc.googleg roups.com...

On Aug 15, 3:31 pm, Frank Birbacher <[e-mail]>
wrote:
>Hi!

>mike3 schrieb:

I tried it, thing still fails. It seems to
happen with operators that return "BigFloat"
and not "constBigFloat&".

>It seems there is something wrong with your copy constructor.
>But
>your
>code is to complex for manual analysis. Can you possibly cut
>your
>code
>down to a little working example which shows the error? Maybe
>drop all
>but one operator (i.e. +) and all sourrounding code?

>Frank

See the thing is though that the problem
only became evident when it was used in a complex
program. But not using the offending area of code
seems to cause the problem to disappear. But I
can't just not use the code and I want the thing
to work.

>Copy your program to a new program. Start reducing the size
>trying
>to get
>it
>to compile in a small a size as possible still showing thebug.
>Removing
>things from the class that shouldn't be necessary to show
>thebugetc...

>Either you'll reduce the program to something small enough to
>show
>us, or
>you'll remove something and the program will stop working or
>thebugwill
>go
>away. At this point it might come up, "Oh, THAT'S why it's
>happening!"

I've tried using debugger output functions to display messages
that
wouldt
tell me what gets called, etc. before the crash and isolated it to
something
that uses memory (go figure), but it only fails when BigFloats are
used.
And that's where I'm stumped. Is thebugin BigFloat, or this? It's
this
peculiar interaction between BigFloat and this other thing that
doesn't make
any sense. None of them are supposed to overflow. And it's only
when
"BigFloat"-returning operators get used in that thing I showed.

This is so strange.

It sounds like BigFloats may be overflowing some buffer somewhere
and
screwing up the memory. Can you post the entire BigFloat class?

It's not a simple thing -- over 5700 lines of code. This is
because it contains several implementations of the
arithmetic algorithms, some of which are trimmed-down versions
that are used in more time-critical areas of the program (ie.
fewer branch points, etc.). For example there's a "small integer"
multiply/divide that allows for easier multiplication/division
of BigFloats by small integers. I don't have a "small integer"
add/subtract yet since I haven't needed that operation in any
time-critical area and hence just fake it by constructing a
temporary BigFloat that is equal in value to a small integer.
There are also "fast" add/sub/mul routines that assume equal-sized
operands, for example, and hence don't do any resizing or
pointer gymnastics (hence reducing branch points/"if"s) and have
various optimizations (for instance the "fast add" and "fast sub"
routines use a loop that contains a bit shift and an add/sub
merged into one.).

Any response? Do you still want to see it?

Well, I'm not a mind reader. I can't help to find abugin something I
can't see.

Without seeing the code all I can say is, look for a buffer overrun or
something similar.

If you need more help than that then, yes, we will need to see the code.

Alright, I've got it zipped. The whole BigFloat implementation.
Where should I send it?

Put it on some website somewhere, or use some binary newsgroup. I don't
have anyone send me anything to my personal e-mail because I won't respond.
I only respond to public message/inquiries.

Binary newsgroups are not an option since Google does
not go to them and my ISP does not go to them and I
would not go and just spend lots of money just to
give a file. Do you know of a good (and FREE)
file hosting service that I could use?

[Jim Langston]

"Frank Birbacher" <bl************@gmx.netwrote in message
news:5i*************@mid.dfncis.de...

Hi!

mike3 schrieb:

>I tried it, thing still fails. It seems to
happen with operators that return "BigFloat"
and not "const BigFloat &".

It seems there is something wrong with your copy constructor. But your
code is to complex for manual analysis. Can you possibly cut your code
down to a little working example which shows the error? Maybe drop all
but one operator (i.e. +) and all sourrounding code?

Frank

Even better yet, give me a main.cpp file that reproduces the error with the
files given in your zip.

I can guess it might be something like:

int main()
{
BigFloat a;
BigFloat b;
BigFloat a /= b*(u32)5;
}

Would that reproduce the bug? And what headers are needed, all?

[mike3]

On Aug 23, 7:21 pm, "Jim Langston" <[e-mail]:

"Frank Birbacher" <[e-mail] in message

news:5i*************@mid.dfncis.de...

Hi!

mike3 schrieb:

I tried it, thing still fails. It seems to
happen with operators that return "BigFloat"
and not "const BigFloat &".

It seems there is something wrong with your copy constructor. But your
code is to complex for manual analysis. Can you possibly cut your code
down to a little working example which shows the error? Maybe drop all
but one operator (i.e. +) and all sourrounding code?

Frank

Even better yet, give me a main.cpp file that reproduces the error with the
files given in your zip.

I would have to give out the entire rest of the program
source code. Like I've said I'm not sure whether or not
I'm going to choose an open or closed source model for my
program's distribution, so I'm iffy about doing that. (I'll
decide on that once I get the program done, but first I
have to get that to happen of course and that means
fixing this problem.) I disclosed the bignum package
since it's just a bignum package after all, it's not
some earthshattering new thing. However I might see if
the error can be induced in alternative setups, maybe
craft some ad hoc program in which it causes trouble
that's somewhat akin to the real program it's supposed
to be used in but which I can just release the source
code for.

I can guess it might be something like:

int main()
{
BigFloat a;
BigFloat b;
BigFloat a /= b*(u32)5;

}

Would that reproduce the bug? And what headers are needed, all?

No, that would not. It only appears after the rest of
the entire program is in place. But when no BigFloats
are used it does not appear, even with the rest of
the program in place. Anyway, I'll test some basic
main() things to see if anything interesting happens
and I get a memory corruption. You have to have various
arrays of memory allocated, copied BigFloats
in copy constructors, etc.

Also, what headers? You mean in "main.h" to just use
the bignum pack? Just remove anything that does not
have "mp/" before it. Remember that it's meant to be
in a directory called "mp", after all. (And I bet you
can guess easily and correctly what "mp" stands for,
of course.)

[mike3]

Alright. I've just prepared a "gutted" version of the program
for which I can release the source code to, that contains the
bug. It's as stripped as I could get it, and it should compile
with any good Windows-supporting C++ compiler. I use Borland
C++ Builder, by the way, to compile it. You'll also need
Microsoft's DirectX SDK 9 to compile as well. Note: Since this
is gutted, you may notice references/prototypes of functions
that don't exist, etc. None of those get called, but I may
not have gotten all that out. Just an FYI. This IS a
testing/debugging package only, after all. I just
gutted the full complicated Fracgen3D program I told
you about to get your "minimal example" you wanted
as easily as I could (gutting seemed like the easiest
way to preserve the bug without lots of trial and error.).
To compile it just extract the zip to a directory.
After that go and tell the compiler to build and
link all the different C++ modules (and the resource
file fracgen3d.rc.). The MP package is included in this
package as well for convenience reasons.

Once compiled it should pop up a window. Click the "File"
menu, then "New", and you'll see a funny little message
box (this is a debug indicator I put in to check where
the program's at.). Clicking OK should cause a crash --
that's the bug. When the bug is not there, a second
message box should appear and after that a blank window
will pop up in the main one.

I've tried to gut as much as I could, but still wanted
to preverse a rough idea of the structure to aid in the
debug process.

Again, it's released under the same "license agreement"
as the MP code and will be taken down once debugging has
been complete.

The zip file is at:

http://www.mediafire.com/?5m4digtzbxk

[Jim Langston]

"mike3" <mi******@yahoo.comwrote in message
news:11********************@z24g2000prh.googlegrou ps.com...

Alright. I've just prepared a "gutted" version of the program
for which I can release the source code to, that contains the
bug. It's as stripped as I could get it, and it should compile
with any good Windows-supporting C++ compiler. I use Borland
C++ Builder, by the way, to compile it. You'll also need
Microsoft's DirectX SDK 9 to compile as well. Note: Since this
is gutted, you may notice references/prototypes of functions
that don't exist, etc. None of those get called, but I may
not have gotten all that out. Just an FYI. This IS a
testing/debugging package only, after all. I just
gutted the full complicated Fracgen3D program I told
you about to get your "minimal example" you wanted
as easily as I could (gutting seemed like the easiest
way to preserve the bug without lots of trial and error.).
To compile it just extract the zip to a directory.
After that go and tell the compiler to build and
link all the different C++ modules (and the resource
file fracgen3d.rc.). The MP package is included in this
package as well for convenience reasons.

Once compiled it should pop up a window. Click the "File"
menu, then "New", and you'll see a funny little message
box (this is a debug indicator I put in to check where
the program's at.). Clicking OK should cause a crash --
that's the bug. When the bug is not there, a second
message box should appear and after that a blank window
will pop up in the main one.

I've tried to gut as much as I could, but still wanted
to preverse a rough idea of the structure to aid in the
debug process.

Again, it's released under the same "license agreement"
as the MP code and will be taken down once debugging has
been complete.

The zip file is at:

http://www.mediafire.com/?5m4digtzbxk

Please download the zip file yourself, extract it to a directory, FIX THE
ERRORS, then repost it.

You are missing a lot of header files required to compile.

[mike3]

On Aug 26, 5:09 pm, "Jim Langston" <[e-mail]:

"mike3" <[e-mail] in message

news:11********************@z24g2000prh.googlegrou ps.com...

Alright. I've just prepared a "gutted" version of the program
for which I can release the source code to, that contains the
bug. It's as stripped as I could get it, and it should compile
with any good Windows-supporting C++ compiler. I use Borland
C++ Builder, by the way, to compile it. You'll also need
Microsoft's DirectX SDK 9 to compile as well. Note: Since this
is gutted, you may notice references/prototypes of functions
that don't exist, etc. None of those get called, but I may
not have gotten all that out. Just an FYI. This IS a
testing/debugging package only, after all. I just
gutted the full complicated Fracgen3D program I told
you about to get your "minimal example" you wanted
as easily as I could (gutting seemed like the easiest
way to preserve the bug without lots of trial and error.).

To compile it just extract the zip to a directory.
After that go and tell the compiler to build and
link all the different C++ modules (and the resource
file fracgen3d.rc.). The MP package is included in this
package as well for convenience reasons.

Once compiled it should pop up a window. Click the "File"
menu, then "New", and you'll see a funny little message
box (this is a debug indicator I put in to check where
the program's at.). Clicking OK should cause a crash --
that's the bug. When the bug is not there, a second
message box should appear and after that a blank window
will pop up in the main one.

I've tried to gut as much as I could, but still wanted
to preverse a rough idea of the structure to aid in the
debug process.

Again, it's released under the same "license agreement"
as the MP code and will be taken down once debugging has
been complete.

The zip file is at:

http://www.mediafire.com/?5m4digtzbxk

Please download the zip file yourself, extract it to a directory, FIX THE
ERRORS, then repost it.

You are missing a lot of header files required to compile.

Dang!

I've updated the package now. Turns out I forgot to remove
the references to some unneeded headers I removed from the
package. Only one (resource.h) was actually needed and
missing. It's in there now. And there were also a few other
errors but they too have been fixed. It all compiled now
on my compiler with no errors. The new package is located
at:

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

and the old one has been removed.

[mike3]

On Aug 26, 6:54 pm, mike3 <[e-mail]:

On Aug 26, 5:09 pm, "Jim Langston" <[e-mail]:

"mike3" <[e-mail] in message

news:11********************@z24g2000prh.googlegrou ps.com...

Alright. I've just prepared a "gutted" version of the program
for which I can release the source code to, that contains the
bug. It's as stripped as I could get it, and it should compile
with any good Windows-supporting C++ compiler. I use Borland
C++ Builder, by the way, to compile it. You'll also need
Microsoft's DirectX SDK 9 to compile as well. Note: Since this
is gutted, you may notice references/prototypes of functions
that don't exist, etc. None of those get called, but I may
not have gotten all that out. Just an FYI. This IS a
testing/debugging package only, after all. I just
gutted the full complicated Fracgen3D program I told
you about to get your "minimal example" you wanted
as easily as I could (gutting seemed like the easiest
way to preserve the bug without lots of trial and error.).

To compile it just extract the zip to a directory.
After that go and tell the compiler to build and
link all the different C++ modules (and the resource
file fracgen3d.rc.). The MP package is included in this
package as well for convenience reasons.

Once compiled it should pop up a window. Click the "File"
menu, then "New", and you'll see a funny little message
box (this is a debug indicator I put in to check where
the program's at.). Clicking OK should cause a crash --
that's the bug. When the bug is not there, a second
message box should appear and after that a blank window
will pop up in the main one.

I've tried to gut as much as I could, but still wanted
to preverse a rough idea of the structure to aid in the
debug process.

Again, it's released under the same "license agreement"
as the MP code and will be taken down once debugging has
been complete.

The zip file is at:

>http://www.mediafire.com/?5m4digtzbxk

Please download the zip file yourself, extract it to a directory, FIX THE
ERRORS, then repost it.

You are missing a lot of header files required to compile.

Dang!

I've updated the package now. Turns out I forgot to remove
the references to some unneeded headers I removed from the
package. Only one (resource.h) was actually needed and
missing. It's in there now. And there were also a few other
errors but they too have been fixed. It all compiled now
on my compiler with no errors. The new package is located
at:

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

and the old one has been removed.

Any comments yet?

[Old Wolf]

On Aug 26, 9:10 pm, mike3 <[e-mail]:

Alright. I've just prepared a "gutted" version of the program
for which I can release the source code to, that contains the
bug. It's as stripped as I could get it, and it should compile
with any good Windows-supporting C++ compiler. I use Borland
C++ Builder, by the way, to compile it.

Your problem sounds like a buffer overflow or memory error.
Try turning on CodeGuard and rebuilding your project.
(A better place to continue this discussion would be
one of the Borland newsgroups, such as borland.public.
cppbuilder.ide).

[mike3]

On Aug 28, 4:46 pm, Old Wolf <[e-mail]:

On Aug 26, 9:10 pm, mike3 <[e-mail]:

Alright. I've just prepared a "gutted" version of the program
for which I can release the source code to, that contains the
bug. It's as stripped as I could get it, and it should compile
with any good Windows-supporting C++ compiler. I use Borland
C++ Builder, by the way, to compile it.

Your problem sounds like a buffer overflow or memory error.
Try turning on CodeGuard and rebuilding your project.
(A better place to continue this discussion would be
one of the Borland newsgroups, such as borland.public.
cppbuilder.ide).

Actually that's not available with my version of the
compiler. Could I find something similar somewhere
else?

[Old Wolf]

On Aug 29, 12:43 pm, mike3 <[e-mail]:

On Aug 28, 4:46 pm, Old Wolf <[e-mail]:

On Aug 26, 9:10 pm, mike3 <[e-mail]:

Alright. I've just prepared a "gutted" version of the program
for which I can release the source code to, that contains the
bug. It's as stripped as I could get it, and it should compile
with any good Windows-supporting C++ compiler. I use Borland
C++ Builder, by the way, to compile it.

Your problem sounds like a buffer overflow or memory error.
Try turning on CodeGuard and rebuilding your project.
(A better place to continue this discussion would be
one of the Borland newsgroups, such as borland.public.
cppbuilder.ide).

Actually that's not available with my version of the
compiler. Could I find something similar somewhere
else?

Well, every version of C++Builder came with CodeGuard.
So I don't really know what you are talking about.
Ask on the Borland forums instead of here.

[mike3]

On Aug 28, 7:19 pm, Old Wolf <[e-mail]:

On Aug 29, 12:43 pm, mike3 <[e-mail]:

On Aug 28, 4:46 pm, Old Wolf <[e-mail]:

On Aug 26, 9:10 pm, mike3 <[e-mail]:

Alright. I've just prepared a "gutted" version of the program
for which I can release the source code to, that contains the
bug. It's as stripped as I could get it, and it should compile
with any good Windows-supporting C++ compiler. I use Borland
C++ Builder, by the way, to compile it.

Your problem sounds like a buffer overflow or memory error.
Try turning on CodeGuard and rebuilding your project.
(A better place to continue this discussion would be
one of the Borland newsgroups, such as borland.public.
cppbuilder.ide).

Actually that's not available with my version of the
compiler. Could I find something similar somewhere
else?

Well, every version of C++Builder came with CodeGuard.
So I don't really know what you are talking about.
Ask on the Borland forums instead of here.

Not the Borland C++ Builder 5.5 Freecompiler Command
Line Tools...

[mike3]

On Aug 26, 6:54 pm, mike3 <[e-mail]:

On Aug 26, 5:09 pm, "Jim Langston" <[e-mail]:

"mike3" <[e-mail] in message

news:11********************@z24g2000prh.googlegrou ps.com...

Alright. I've just prepared a "gutted" version of the program
for which I can release the source code to, that contains the
bug. It's as stripped as I could get it, and it should compile
with any good Windows-supporting C++ compiler. I use Borland
C++ Builder, by the way, to compile it. You'll also need
Microsoft's DirectX SDK 9 to compile as well. Note: Since this
is gutted, you may notice references/prototypes of functions
that don't exist, etc. None of those get called, but I may
not have gotten all that out. Just an FYI. This IS a
testing/debugging package only, after all. I just
gutted the full complicated Fracgen3D program I told
you about to get your "minimal example" you wanted
as easily as I could (gutting seemed like the easiest
way to preserve the bug without lots of trial and error.).

To compile it just extract the zip to a directory.
After that go and tell the compiler to build and
link all the different C++ modules (and the resource
file fracgen3d.rc.). The MP package is included in this
package as well for convenience reasons.

Once compiled it should pop up a window. Click the "File"
menu, then "New", and you'll see a funny little message
box (this is a debug indicator I put in to check where
the program's at.). Clicking OK should cause a crash --
that's the bug. When the bug is not there, a second
message box should appear and after that a blank window
will pop up in the main one.

I've tried to gut as much as I could, but still wanted
to preverse a rough idea of the structure to aid in the
debug process.

Again, it's released under the same "license agreement"
as the MP code and will be taken down once debugging has
been complete.

The zip file is at:

>http://www.mediafire.com/?5m4digtzbxk

Please download the zip file yourself, extract it to a directory, FIX THE
ERRORS, then repost it.

You are missing a lot of header files required to compile.

Dang!

I've updated the package now. Turns out I forgot to remove
the references to some unneeded headers I removed from the
package. Only one (resource.h) was actually needed and
missing. It's in there now. And there were also a few other
errors but they too have been fixed. It all compiled now
on my compiler with no errors. The new package is located
at:

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

and the old one has been removed.

Have you made any progress with the bug yet? I haven't...

[Old Wolf]

On Aug 29, 3:01 pm, mike3 <[e-mail]:

On Aug 28, 7:19 pm, Old Wolf <[e-mail]:

Well, every version of C++Builder came with CodeGuard.

Not the Borland C++ Builder 5.5 Freecompiler Command
Line Tools...

That isn't a version of C++Builder. It is a version
of the commandline tools that come with C++Builder.

You wouldn't call CMD.EXE a version of windows..

[mike3]

On Aug 29, 9:26 pm, Old Wolf <[e-mail]:

On Aug 29, 3:01 pm, mike3 <[e-mail]:

On Aug 28, 7:19 pm, Old Wolf <[e-mail]:

Well, every version of C++Builder came with CodeGuard.

Not the Borland C++ Builder 5.5 Freecompiler Command
Line Tools...

That isn't a version of C++Builder. It is a version
of the commandline tools that come with C++Builder.

You wouldn't call CMD.EXE a version of windows..

Heeheehee.

So then I've got just a compiler.

:)

[mike3]

Well, now that it's been a bit since I posted
the compilable without errors code at:

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

has anyone actually made any progress in finding
the bug? I haven't made much yet, just more brick
walls :(

[LR]

mike3 wrote:

Well, now that it's been a bit since I posted
the compilable without errors code at:

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

has anyone actually made any progress in finding
the bug? I haven't made much yet, just more brick
walls :(

Have you reduced your code to a small sample that demonstrates the
problem?

If you try that and post here, I think that you're far more likely to
get responses.

LR

[LR]

LR wrote:

mike3 wrote:

>Well, now that it's been a bit since I posted
the compilable without errors code at:

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

has anyone actually made any progress in finding
the bug? I haven't made much yet, just more brick
walls :(

Have you reduced your code to a small sample that demonstrates the problem?

If you try that and post here, I think that you're far more likely to
get responses.

Replying to my own post.

I meant to ask, do you want help reducing the code with the problem to
something smaller?

LR

[mike3]

On Aug 31, 6:46 am, LR <[e-mail]:

mike3 wrote:

Well, now that it's been a bit since I posted
the compilable without errors code at:

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

has anyone actually made any progress in finding
the bug? I haven't made much yet, just more brick
walls :(

Have you reduced your code to a small sample that demonstrates the
problem?

If you try that and post here, I think that you're far more likely to
get responses.

LR

That is a "gutted" sample right there, made by
stripping down the full program until only a husk
capable of showing the bug remains. You can't
compute fractals with it, you can't do anything
except see if the bug is there, really. I stripped
as much as it seemed I could take off.