Debugging bizzare error help needed

[BCC]

I am getting a non-reproduceable release mode only error, that is
proving to be really a pain. I can in some cases narrow it down by
try/catch blocks but even that behavior is totally f*ed up.

For example, I have this gem:
try {
int x = Foo();
}
catch (...) {
int x = Foo();
}

Foo() blows up and throws, but when it is caught, it -works-. WTF?

Seems like a memory problem, but Ive tried all kinds of release mode
debugging (map files, purify, etc.) but nothing pins it down.

Has anyone seen any behavior like this before? Any pearls of wisdom out
there?

Thanks,
B

 

[Jon Slaughter]

I am getting a non-reproduceable release mode only error, that is proving
to be really a pain. I can in some cases narrow it down by try/catch
blocks but even that behavior is totally f*ed up.

For example, I have this gem:
try {
int x = Foo();
}
catch (...) {
int x = Foo();
}

Foo() blows up and throws, but when it is caught, it -works-. WTF?

Seems like a memory problem, but Ive tried all kinds of release mode
debugging (map files, purify, etc.) but nothing pins it down.

Has anyone seen any behavior like this before? Any pearls of wisdom out
there?

Your probably going to have to give more information. My guess is that the
first call of Foo is setting up some state that lets the second one work.

For example:

int Foo()
{
static int y = 0;
if (y == 0)
{
y++;
throw...
};
};


Simple but concise example of showing how something like that could happen.

Ofcourse since it works with debugging is probably being caused by memory
allocation/deallocation. It really depends on Foo, as you surely have
figured out... but you have not given anything about what Foo is. You
should try to find the smallest subset of code that reproduces the error
then post that.

Jon

 

[Mike Wahler]

I am getting a non-reproduceable release mode only error, that is proving
to be really a pain. I can in some cases narrow it down by try/catch
blocks but even that behavior is totally f*ed up.

For example, I have this gem:
try {
int x = Foo();
}
catch (...) {
int x = Foo();
}

Foo() blows up and throws, but when it is caught, it -works-. WTF?

There's absolutely no way for us to diagnose the problem
without at least seeing the definition of 'Foo()'. Also
there's the possibility that something went wrong previously
in some other unrelated part of you program, rendering
'undefined behavior', whereupon *anything* might happen,
and the same thing might or might not happen during
subsequent runs of the program.

Seems like a memory problem,

What causes you to think that? (I'm not saying it's not
a memory problem, but the limited information you give
contains no clues pointing in that direction).

but Ive tried all kinds of release mode debugging (map files, purify, etc.)
but nothing pins it down.

Try paring down your code to the smallest program that
still reproduces the error. If you still can't find it,
post the code.

Has anyone seen any behavior like this before?

I certainly have.

Any pearls of wisdom out there?

Perhaps there are, but we need more information.

-Mike

 

[BCC]

Perhaps there are, but we need more information.

-Mike

Thats kind of the problem. My 'Foo()' example is just one of the more
prevalent places it blows up. It also croaks in several other
functions, from what I can tell completely at random.

So there seems to be no use posting the contents of Foo(). But, in the
event I am wrong, here is what Foo does:

double CMCal::GetMass(double x) const
{
double m = 0.0;
if(inverse_function)
{
double d = mass_a[1] * x + mass_a[2];
if (d < 0) throw NoSuchMass();

d = sqrt(d) - 1.0;
m = mass_a[0] * d * d;
}
else {
m = (((mass_a[2] * x) + mass_a[1]) * x + mass_a[0]);
}

return m;
}

mass_a is just an array of 3 doubles.

I also know that NoSuchMass() is -not- being thrown, as catching it has
no effect.

B

 

[Mike Wahler]

Thats kind of the problem. My 'Foo()' example is just one of the more
prevalent places it blows up. It also croaks in several other functions,
from what I can tell completely at random.

That's exactly why I suggested to reduce your program to
a smaller one which gives the same problem. Often in
the process of doing this, you'll discover the trouble.

So there seems to be no use posting the contents of Foo().

If you post code that fails when it calls 'Foo()', how
are we to determine the problem if you won't post the
code in 'Foo()'?

But, in the event I am wrong, here is what Foo does:

double CMCal::GetMass(double x) const
{
double m = 0.0;
if(inverse_function)
{
double d = mass_a[1] * x + mass_a[2];
if (d < 0) throw NoSuchMass();

d = sqrt(d) - 1.0;
m = mass_a[0] * d * d;
}
else {
m = (((mass_a[2] * x) + mass_a[1]) * x + mass_a[0]);
}

return m;
}

Huh? That function's name is 'GetMass()'. Did you just
'make up' that name 'Foo'? Post the *real* code.

mass_a is just an array of 3 doubles.

But what are the values of the array elements? Did you
look at them with a debugger?

I also know that NoSuchMass() is -not- being thrown, as catching it has no
effect.

You don't show full context (such as where you're catching
NoSuchMass'. (BTW is 'NoSuchMass' a type or the name of
a function which returns some other type?)

So again, I say, "not enough information".

-Mike

 

[BCC]

Huh? That function's name is 'GetMass()'. Did you just
'make up' that name 'Foo'? Post the *real* code.

Have you ever seen a -real- function called 'Foo()'? Of course it was
made up.

But what are the values of the array elements? Did you
look at them with a debugger?

Yep. I have also dumped them out after catching the exception in
release mode. They are fine.

You don't show full context (such as where you're catching
NoSuchMass'. (BTW is 'NoSuchMass' a type or the name of
a function which returns some other type?)

NoSuchMass is a class.

So again, I say, "not enough information".

And there we are. Full context would require posting waaaaaay more code
that is reasonable, or legal. There is no specific section as of yet to
pinpoint, so to boil down this code to the simplest form that reproduces
the problem would take quite some time (although I may get there). But
again, for legal reasons I dont think I could post the code even if I did.

I was more hoping that this type of issue represents some kind of well
known memory error.

At any rate, Ill find it.

B

 

[Mike Wahler]

Have you ever seen a -real- function called 'Foo()'?
Yes.

Of course it was made up.

So you're making us guess. Why not post the real code?
That's what's giving you trouble, right?

Yep. I have also dumped them out after catching the exception in release
mode. They are fine.

"They are fine" tells us nothing. What are the *values*?

NoSuchMass is a class.


And there we are. Full context would require posting waaaaaay more code
that is reasonable, or legal. There is no specific section as of yet to
pinpoint, so to boil down this code to the simplest form that reproduces
the problem would take quite some time (although I may get there). But
again, for legal reasons I dont think I could post the code even if I did.

But you could create a small program to simulate the
part of the larger one that's causing trouble. IF it
works correctly, then you'll know to look elsewhere.

I was more hoping that this type of issue represents some kind of well
known memory error.

We can't know, because you gave so little information.

At any rate, Ill find it.

Good luck.

-Mike

 

[Mogens Heller Jensen]

Yes.

Did it by any chance return the value 42?

)

 

[John Harrison]

Has anyone seen any behavior like this before? Any pearls of wisdom out
there?

Thanks,
B

I my experience release version errors which don't exist in debug
version are usually caused by uninitialised variables.

john