Segmentation fault when function ends...

[Stefan Strasser]

Hello all,

I have a class member, which calls another member from the same class. The
problem I'm experiencing is that the nested function executes fine, but
causes a segmentation fault as it exits. I've traced it to the point in the
code just before the line following the nested function is to be called, or
conversely right after the last line of the nested function.

What might be my problem? I'm hoping someone can give me some guidance on
what sort of things to check. I can't even think where to start.

you've corrupted your stack somehow.
look for overflows in arrays on the stack and the like.

 

[deancoo]

Hello all,

I have a class member, which calls another member from the same class. The
problem I'm experiencing is that the nested function executes fine, but
causes a segmentation fault as it exits. I've traced it to the point in the
code just before the line following the nested function is to be called, or
conversely right after the last line of the nested function.

What might be my problem? I'm hoping someone can give me some guidance on
what sort of things to check. I can't even think where to start.

d

 

[Victor Bazarov]

I have a class member, which calls another member from the same class. The
problem I'm experiencing is that the nested function executes fine, but
causes a segmentation fault as it exits. I've traced it to the point in the
code just before the line following the nested function is to be called, or
conversely right after the last line of the nested function.

What might be my problem? I'm hoping someone can give me some guidance on
what sort of things to check. I can't even think where to start.

Sounds like a garden variety memory overrun problem. You stomp over your
own call stack, most likely. Check writing beyond the bounds of an array.

V

 

[Andre Kostur]

Hello all,

I have a class member, which calls another member from the same class.
The problem I'm experiencing is that the nested function executes
fine, but causes a segmentation fault as it exits. I've traced it to
the point in the code just before the line following the nested
function is to be called, or conversely right after the last line of
the nested function.

What might be my problem? I'm hoping someone can give me some
guidance on what sort of things to check. I can't even think where to
start.

[Note: platform specific answer, but hopefully generic enough....]

A couple of possibilities:

1) You've probably overrun one of your local variables, causing some
portion of your call stack to be stomped on. When your function attempts
to return to the calling site, the return address is scrambled. Check all
accesses to your local variables via a pointer. Also check if you have any
arrays as local variables and ensure that you haven't accessed beyond the
bounds of your array. That sort of thing.

2) A destructor of a local variable is going bad, and causing a segfault.

3) Something during the construction of the return value of your function
may be causing a segfault.

 

[deancoo]

Hello all,

I have a class member, which calls another member from the same class.
The problem I'm experiencing is that the nested function executes fine,
but causes a segmentation fault as it exits. I've traced it to the point
in the code just before the line following the nested function is to be
called, or conversely right after the last line of the nested function.

What might be my problem? I'm hoping someone can give me some guidance on
what sort of things to check. I can't even think where to start.

d

Found the problem, the function was previously defined to return something,
later I changed that to void by removing the 'return' statement only (dumb
me). Anyway, that's what happens when a function that's defined to return
something doesn't.

Thanks for your comments,
d

 

[Howard]

Found the problem, the function was previously defined to return
something, later I changed that to void by removing the 'return' statement
only (dumb me). Anyway, that's what happens when a function that's
defined to return something doesn't.

Thanks for your comments,
d

You removed the return statement, but the function still specified a return
type? That shouldn't even compile! I'd get a new compiler if it does.

-Howard

 

[Victor Bazarov]

[...]
Found the problem, the function was previously defined to return something,
later I changed that to void by removing the 'return' statement only (dumb
me). Anyway, that's what happens when a function that's defined to return
something doesn't.

It's called "undefined behaviour", and you got a very good example of it.
Unfortunately, you can't easily say that when the function returns with
a bang, it's because it falls off its end when defined to return some
object. FWIW, you could get nothing special -- it's allowed just like
anything else.

V

 

[Victor Bazarov]

[...]
You removed the return statement, but the function still specified a return
type? That shouldn't even compile! I'd get a new compiler if it does.

Why shouldn't it compile? Which part of the Standard says that a program
that has such function is ill-formed? While you're looking for it, check
out 6.6.3/2, the last sentence.

V

 

[deancoo]

You removed the return statement, but the function still specified a
return type? That shouldn't even compile! I'd get a new compiler if it
does.

-Howard

gcc 3.4.3

 

[Howard]

[...]
You removed the return statement, but the function still specified a
return type? That shouldn't even compile! I'd get a new compiler if it
does.

Why shouldn't it compile? Which part of the Standard says that a program
that has such function is ill-formed? While you're looking for it, check
out 6.6.3/2, the last sentence.

V

I don't have a copy of the Standard, but Stroustrup's book "The C++
Programming Language", in section 7.3, states: "A value must be returned
from a function that is not declared void". Obviously, stating that
something is required doesn't neccessarily mean that the standard dictates
that a program that does not meet such a requirement is ill-formed, but
surely in this case it is...? My compiler(s) certainly won't let it
compile, and I can't see any reason why any compiler _would_ allow it.

-Howard

 

[Victor Bazarov]

[...]
You removed the return statement, but the function still specified a
return type? That shouldn't even compile! I'd get a new compiler if it
does.

Why shouldn't it compile? Which part of the Standard says that a program
that has such function is ill-formed? While you're looking for it, check
out 6.6.3/2, the last sentence.

V

I don't have a copy of the Standard, but Stroustrup's book "The C++
Programming Language", in section 7.3, states: "A value must be returned
from a function that is not declared void". Obviously, stating that
something is required doesn't neccessarily mean that the standard dictates
that a program that does not meet such a requirement is ill-formed, but
surely in this case it is...?

It isn't. I do have a copy of the Standard and I gave you the location
in it where you should look (when you get yourself a copy, that is).

My compiler(s) certainly won't let it
compile, and I can't see any reason why any compiler _would_ allow it.

What if your function is never called? The fact that it doesn't return
has no relevance if it's never called, is it? What if even when it's
called, it never returns, only throws? Or simply never returns because
it has an infinite loop in it? Again, any return statement would be
irrelevant. I shouldn't have to put anything in my code that never gets
executed ("dead code").

In any case, your view is apparently different from the view of the
Committee and of many compiler implementors out there. Which compilers
refuse to compile a non-void function without a return statement, BTW?

V

 

[Howard]

Howard wrote:

[...]
You removed the return statement, but the function still specified a
return type? That shouldn't even compile! I'd get a new compiler if it
does.

Why shouldn't it compile? Which part of the Standard says that a program
that has such function is ill-formed? While you're looking for it, check
out 6.6.3/2, the last sentence.

V

I don't have a copy of the Standard, but Stroustrup's book "The C++
Programming Language", in section 7.3, states: "A value must be returned
from a function that is not declared void". Obviously, stating that
something is required doesn't neccessarily mean that the standard
dictates that a program that does not meet such a requirement is
ill-formed, but surely in this case it is...?

It isn't. I do have a copy of the Standard and I gave you the location
in it where you should look (when you get yourself a copy, that is).

My compiler(s) certainly won't let it
compile, and I can't see any reason why any compiler _would_ allow it.

What if your function is never called? The fact that it doesn't return
has no relevance if it's never called, is it? What if even when it's
called, it never returns, only throws? Or simply never returns because
it has an infinite loop in it? Again, any return statement would be
irrelevant. I shouldn't have to put anything in my code that never gets
executed ("dead code").

In any case, your view is apparently different from the view of the
Committee and of many compiler implementors out there. Which compilers
refuse to compile a non-void function without a return statement, BTW?

Visual C++ (both 6 and 7). CodeWarrior also balked at it, but apparently
because I had it set to treat warnings as errors. When I turned that off, I
get a warning instead of an error.

I'll grant you that Visual C++ is hardly the world-class expert on standards
conformance, but even CodeWarrior at least gives me a warning.

I find it interesting that "my view" is echoed by Stroustrup. He uses the
word "must" in his statement, not "should" or "ought to".

As for whether a function is called or not, that shouldn't be relevant to
how you write the function, should it? Did you write the function *knowing*
it would never be called? And if so, why did you write it?

Anyway, not to beat a dead horse...I'll concede the point and take your word
on what the standard says. But I'd still suggest that specifying a return
type in a function but not returning a value from it is (in the words of the
OP) dumb.

-Howard

 

[Howard]

Oh, I think I see why that should compile, and why your examples were
relevant. If the compiler can't *prove* that it will execute that function
and run off the end without throwing or returning elsewhere, then it is
*required* to compile the code. Correct? That would make VC++ 7 (.NET)
non-compliant in this case, because it will not compile such code. Maybe
it's *me* that needs a new compiler...?

-Howard

 

[Guest]

gcc 3.4.3

I recommend using lots of warning switches to catch silly mistakes like this
one. The use of


-Wall -Werror

would save you in this case.

Ali

 

[Victor Bazarov]

Oh, I think I see why that should compile, and why your examples were
relevant. If the compiler can't *prove* that it will execute that function
and run off the end without throwing or returning elsewhere, then it is
*required* to compile the code. Correct? That would make VC++ 7 (.NET)
non-compliant in this case, because it will not compile such code. Maybe
it's *me* that needs a new compiler...?

<kinda_ot>
Actually it isn't going to help. VC++ v8 still gives C4716 which is
a _warning_ according to their documentation. It's a level 1 warning
which is as they say "automatically promoted to an error". You can
change that if you use

#pragma warning(2:4716)

thus making it level 2 (here) or any other lower level.
</kinda_ot>

V