Frustrating bug in C++ program

M

mike3

Hi!


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));
}
 
J

Jim Langston

mike3 said:
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.
 
M

mike3

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?
 
J

Jim Langston

Frank Birbacher said:
Hi!


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?
 
M

mike3

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.)
 
M

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
 
J

Jim Langston

mike3 said:
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.
 
M

mike3

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.
 
M

mike3

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?
 
O

Old Wolf

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).
 
M

mike3

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?
 
O

Old Wolf

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.
 
M

mike3

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...
 
M

mike3

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...
 
O

Old Wolf

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..
 
M

mike3

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.

:)
 
L

LR

mike3 said:
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
 
L

LR

LR said:
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
 
M

mike3

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,780
Messages
2,569,608
Members
45,252
Latest member
MeredithPl

Latest Threads

Top