Optimasation and seg faults

G

grid

Hi,
Many times I have observed that some program which functions properly
without optimisation or with debug option dosn't seem to work when
optimasation is on or at a higer level.And occasionally it results in a
segment violation error.

Which part of the code's/constructs are the most likely things to cause
this kind of issues ? If from your experience you have gained any
hints,please share.

~
 
G

Grumble

grid said:
Many times I have observed that some program which functions properly
without optimisation or with debug option dosn't seem to work when
optimasation is on or at a higer level.And occasionally it results in a
segment violation error.

Which part of the code's/constructs are the most likely things to cause
this kind of issues ? If from your experience you have gained any
hints,please share.

Do you have a (small) example of such a program?

I would enable extra warnings, and see if the compiler complains.

e.g. gcc -O1 -Wall -Wextra
 
S

SM Ryan

# Which part of the code's/constructs are the most likely things to cause
# this kind of issues ? If from your experience you have gained any
# hints,please share.

Any place you've ignored the language definition and gotten by with
"it works so far despite..." Optimisers in stable compilers rarely
break; what they do is rewrite your program into a new one that
according to the language definition is equivalent to the original.

For example, suppose you've learned you can free a block and still
get the contents until the next malloc. That violates the interface;
an optimiser might feel it can get better code by moving the malloc
forward, in front of the reference you thought safe.

There are many cases, like improper aliassing, stale values that
get overwritten, etc.
 
J

John Bode

grid said:
Hi,
Many times I have observed that some program which functions properly
without optimisation or with debug option dosn't seem to work when
optimasation is on or at a higer level.And occasionally it results in a
segment violation error.

Which part of the code's/constructs are the most likely things to cause
this kind of issues ? If from your experience you have gained any
hints,please share.

~

IME, this always comes down to bad pointer and/or memory management.
Most of those cases are due to dereferencing an unitialized pointer;
some are due to buffer overruns or some other memory stompage that may
or may not clobber something important depending on how items are
arranged in memory, which depends on debug mode or optimization
settings.
 
E

Eric Sosman

John said:
IME, this always comes down to bad pointer and/or memory management.
Most of those cases are due to dereferencing an unitialized pointer;
some are due to buffer overruns or some other memory stompage that may
or may not clobber something important depending on how items are
arranged in memory, which depends on debug mode or optimization
settings.

Other mistakes I've seen that led to different behavior
with and without optimization include

- Failure to `return value' from a non-void function.
One usually gets whatever result happened to be lying
around in some CPU register or other, and when the
optimizer shuffles things around the register can wind
up with different contents.

- Failure to respect sequence-point rules. I recall an
expression like `a = expression involving i++' that
"worked" without optimization but failed utterly once
the optimizer kicked in.

- Failure to respect aliasing rules (this may fall under
John Bode's "bad pointer management"). Type-punning by
pointing at a single object with multiple pointers of
different types may "work" without optimization but fail
as soon as the optimizer says "This `double*' cannot
possibly point to the same object as that `long*', so
I can rearrange their data accesses freely."

- (More rarely) Failure to use `volatile' in conjunction
with setjmp() and longjmp(). Without optimization it is
often the case that the local variables get stored to
memory routinely and are "intact" when longjmp() causes
setjmp() to return a second time. Turn on the optimizer
and variables start to get retained in registers, where
their values are (typically) not safe from longjmp().

Optimizers get blamed for a lot of bugs, and sometimes the
blame is well-placed: optimizers can be quite complex programs
that have bugs of their own. Far more often, though, it turns
out that the code being compiled was dodgy if not flat-out wrong
to begin with, and the optimizer is just the scapegoat.
 
C

Chris Croughton

# Which part of the code's/constructs are the most likely things to cause
# this kind of issues ? If from your experience you have gained any
# hints,please share.

Any place you've ignored the language definition and gotten by with
"it works so far despite..." Optimisers in stable compilers rarely
break;

I have a bridge to sell you...

Unless you are defining a "stable compiler" as one which has no bugs
(and therefore does not exist in reality), the optimiser is in my
experience the area most likely to have bugs, and they generally show up
only under rare conditions. I've used a commercial compiler intended
for embedded work (and hence situations where a fault is likely to be
fatal) have optimisation errors.
what they do is rewrite your program into a new one that
according to the language definition is equivalent to the original.

Theoretically. Of course, that's pretty much the definition of a
compiler in general. And like all translation, sometimes the result is
nothing like the original...

Chris C
 
G

grid

Do you have a (small) example of such a program?
I would enable extra warnings, and see if the compiler complains.
e.g. gcc -O1 -Wall -Wextra

I am sorry,but I cannot show a compilable version,as I still dont know
where the error lies and just wanted to figure out what could be the
possible causes.
Its working fine on one particular platform and fails on another.That
does say that this sort of things can again depend on other factors like
the implementation/platform.

Thanks,
~
 
L

lawrence.jones

Chris Croughton said:
Unless you are defining a "stable compiler" as one which has no bugs
(and therefore does not exist in reality), the optimiser is in my
experience the area most likely to have bugs, and they generally show up
only under rare conditions.

If "they generally show up only under rare conditions", that would mean
that they "rarely break", no? Buggy code that just happens to work on
one or more implementations is far more common than optimizer bugs.

-Larry Jones

I've never seen a sled catch fire before. -- Hobbes
 
C

CBFalconer

grid said:
I am sorry,but I cannot show a compilable version,as I still dont
know where the error lies and just wanted to figure out what could
be the possible causes.

Its working fine on one particular platform and fails on another.
That does say that this sort of things can again depend on other
factors like the implementation/platform.

The cause is the undefined behavior in line # 242.

That is a more useful diagnosis than the information you have
given. My car stopped yesterday. Why? Stop wasting our time.
 
C

Chris Croughton

If "they generally show up only under rare conditions", that would mean
that they "rarely break", no? Buggy code that just happens to work on
one or more implementations is far more common than optimizer bugs.

No, because the ones which show up easily are normally caught before the
compiler gets to the production stage. So if you are using a
beta-version of a compiler then yes, you will more likely find errors
which are easily triggered and reproduced. But in production compilers,
just as with any other large application, the bugs are almost all the
ones which "rarely break".

Unless, of course, you use compilers from places where they don't bother
testing the code...

Chris C
 
L

Lawrence Kirby


Err, if problems show up only under rare conditions then it follows that
they only show up rarely. If problems only show up rarely then they rarely
break code.
because the ones which show up easily are normally caught before the
compiler gets to the production stage.

And the ones that don't show up easily are likely to be triggered rarely.
So if you are using a
beta-version of a compiler then yes, you will more likely find errors
which are easily triggered and reproduced. But in production compilers,
just as with any other large application, the bugs are almost all the
ones which "rarely break".

Your statement seems to fully support what Larry said, yet you said "no". :)
Unless, of course, you use compilers from places where they don't bother
testing the code...

So you're saying that release compilers don't tend to have bugs that get
triggered in common code. That is also Larry's implication i.e. that bugs
are typically more common in the source code being compiled than in the
compiler.

Lawrence
 
S

SM Ryan

# >> Unless you are defining a "stable compiler" as one which has no bugs
# >> (and therefore does not exist in reality), the optimiser is in my
# >> experience the area most likely to have bugs, and they generally show up
# >> only under rare conditions.

My experience maintaining optimisers is that the rare conditions are as
often programs that violate the language definition as real optimiser
problems. It's like aborts in malloc or free are almost never problems
with the malloc code, but in how memory is trashed elsewhere.
 

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,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top