«

I have a C program that GCC compiles without warnings and it runs just
fine. However, when I compile it using any of the -O options (-O0, -O1,
etc.) it segfaults when executed (still no compiler warnings or errors).

I know nothing about compiler otimization, other than it makes my program
run faster. Any suggestions on how to debug this, or what to look for
would be greatly appreciated.

Thank you.

In article <Xns9A6484D691516Jefflokiresearchcom@199.45.49.11> ,
Jeff Taylor <> wrote:

>I have a C program that GCC compiles without warnings and it runs just
>fine. However, when I compile it using any of the -O options (-O0, -O1,
>etc.) it segfaults when executed (still no compiler warnings or errors).

This seems rather surprising, since -O0 is documented to be the default.

Apart from that, the usual reason or optimisation resulting in a crash
is that your program has a bug, but one that does not show up without
optimisation. (Of course, it could conceivably be a bug in the
compiler.)

I suggest you run your program under a debugger (probably gdb), and
see just what is causing the segmentation fault.

-- Richard
--
:wq

On Mar 17, 1:20 pm, rich...@cogsci.ed.ac.uk (Richard Tobin) wrote:
> In article <Xns9A6484D691516Jefflokiresearch...@199.45.49.11> ,
> Jeff Taylor <dev.n...@spam.net> wrote:
>
> >I have a C program that GCC compiles without warnings and it runs just
> >fine. However, when I compile it using any of the -O options (-O0, -O1,
> >etc.) it segfaults when executed (still no compiler warnings or errors).
>
> This seems rather surprising, since -O0 is documented to be the default.
>
> Apart from that, the usual reason or optimisation resulting in a crash
> is that your program has a bug, but one that does not show up without
> optimisation. (Of course, it could conceivably be a bug in the
> compiler.)
>
> I suggest you run your program under a debugger (probably gdb), and
> see just what is causing the segmentation fault.
>
> -- Richard
> --
> :wq

If you have such available, or can install them, tools that detect
memory corruption are often very good for helping diagnose this kind
of thing. I'm partial to Valgrind these days, which is free, and used
to use Rational Purify a lot, which is not free. Which tools, if any,
are available depends on your particular system.

If you want much direct help from comp.lang.c, a good approach is to
try to reduce your problem to a smallish amount of code that
demonstrates the issue. That exercise may well help you figure it out
anyway

-David

On Mar 17, 10:04*am, Jeff Taylor <dev.n...@spam.net> wrote:
> I have a C program that GCC compiles without warnings and it runs just
> fine. *However, when I compile it using any of the -O options (-O0, -O1,
> etc.) it segfaults when executed (still no compiler warnings or errors). *
>
> I know nothing about compiler otimization, other than it makes my program
> run faster. *Any suggestions on how to debug this, or what to look for
> would be greatly appreciated.

What are the compile switches that you use?
Crank the warnings up to the maximum level.
Feed the code to splint:
http://www.splint.org/

Jeff Taylor wrote:
> I have a C program that GCC compiles without warnings and it runs just
> fine. However, when I compile it using any of the -O options (-O0, -O1,
> etc.) it segfaults when executed (still no compiler warnings or errors).
>

There are several approaches to this problem

1) The approach I usually take:
1.a Include the debug information when compiling (usually with -g)
1.b Do not strip the executable
1.c Start the gdb debugger and run your program within the debugger.
1.d When it crashes, take note of where it crashes. The specific
gdb command is "backtrace" as far as I remember.
1.e Look at the local variables. Note that the values displayed
by gdb are probably wrong since optimizations and debugging
do not mix well.
1.f Recompile the module where the crash happens WITHOUT
any optimizations
1.g Relink
1.h Rerun. Does the program crash? If no, you have found the
module where the fault is. Go to step 1.j
If yes, the fault is still there. Take another module from
the modules in the backtrace and recompile. Go to step 1.g.
1.i If you have recompiled all the modules in the backtrace and
the crash still persists, recompile one by one all other
modules until the crash disappears. The last module that
you recompiled is the module with the fault.
1.j Isolate the fault within the module. This can be tricky
unless there is a way to tell the compiler to enable/disable
optimizations in a function by function basis.

2) The approach recommended by the regulars in this group:
Read the source code. If you read hard enough the bug will be
obvious to you.

> I know nothing about compiler otimization, other than it makes my program
> run faster. Any suggestions on how to debug this, or what to look for
> would be greatly appreciated.
>

There is no free lunch. Optimized programs are more sensible to
programming errors than no optimized ones. Besides, you expose
yourself to the bugs of the optimizer, that are many.

If you are doing straight C though, it is highly unlikely that
there is a bug in the optimizer...


> Thank you.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Jeff wrote:
) I have a C program that GCC compiles without warnings and it runs just
) fine. However, when I compile it using any of the -O options (-O0, -O1,
) etc.) it segfaults when executed (still no compiler warnings or errors).
)
) I know nothing about compiler otimization, other than it makes my program
) run faster. Any suggestions on how to debug this, or what to look for
) would be greatly appreciated.

Optimization often reorders automatic variables, sometimes putting them
in registers instead of on the stack, sometimes putting several into the
same piece of memory if their lifetimes don't coincide. So a buffer
overflow or something similar would be one thing to look for.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

Jeff Taylor <dev.n...@spam.net> wrote:
> I have a C program that GCC compiles without warnings and
> it runs just fine.

Realise that output is not the only measure of correctness.

>*However, when I compile it using any of the -O options
> (-O0, -O1, etc.) it segfaults when executed (still no
> compiler warnings or errors). *

I'm afraid you are responsible for diagnosing errors in your
code, not your compiler.

> I know nothing about compiler otimization, other than
> it makes my program run faster.

It should not do so at the cost of changing the semantics,
unless your code relies on undefined or unspecified
behaviour.

>*Any suggestions on how to debug this, or what to look for
> would be greatly appreciated.

Strip the program down to the smallest compilable version
that exhibits the problem. This is not only useful for
posting to usenet for analysis, it is a very useful debugging
technique in its own right.

If debugging was as simple as 'if I get a segfault what are
the 6 things I need to check', then no one would ever need
forums because programming would be a doddle!

--
Peter

Peter Nilsson wrote:
> Jeff Taylor <dev.n...@spam.net> wrote:
>> I have a C program that GCC compiles without warnings and
>> it runs just fine.
>
> Realise that output is not the only measure of correctness.
>

Interesting interesting...

Can you name any other measure that doesn't rely on
output?

Using a psychic medium is not allowed.


>> However, when I compile it using any of the -O options
>> (-O0, -O1, etc.) it segfaults when executed (still no
>> compiler warnings or errors).
>
> I'm afraid you are responsible for diagnosing errors in your
> code, not your compiler.
>


Deep thought.

>> I know nothing about compiler otimization, other than
>> it makes my program run faster.
>
> It should not do so at the cost of changing the semantics,
> unless your code relies on undefined or unspecified
> behaviour.
>

Or unless the optimizer has a bug. It wouldn't be the first bug in gcc
and I would bet that it will not be the last one. Somehow you
fail to consider that possibility.

>> Any suggestions on how to debug this, or what to look for
>> would be greatly appreciated.
>
> Strip the program down to the smallest compilable version
> that exhibits the problem. This is not only useful for
> posting to usenet for analysis, it is a very useful debugging
> technique in its own right.
>
> If debugging was as simple as 'if I get a segfault what are
> the 6 things I need to check', then no one would ever need
> forums because programming would be a doddle!
>

With all respect Peter, this is not really helpful to the OP.
I tried to give a list of steps to follow (see my post).
Obviously that is one debugging strategy. You have (maybe) another.

It would be helpful for the OP if you tried to help him a bit you see?


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

jacob navia wrote:

> Peter Nilsson wrote:
>> Jeff Taylor <dev.n...@spam.net> wrote:
>>> I have a C program that GCC compiles without warnings and
>>> it runs just fine.
>>
>> Realise that output is not the only measure of correctness.
>>
>
> Interesting interesting...
>
> Can you name any other measure that doesn't rely on
> output?

A program that invokes a buffer overrun, but happens to produce expected
output is surely not correct?


> Using a psychic medium is not allowed.
>
>
>>> However, when I compile it using any of the -O options
>>> (-O0, -O1, etc.) it segfaults when executed (still no
>>> compiler warnings or errors).
>>
>> I'm afraid you are responsible for diagnosing errors in your
>> code, not your compiler.
>>
> Deep thought.

He means semantic errors. Or does your compiler do the programming for
the programmer?

<snip>

santosh wrote:
> jacob navia wrote:
>
>> Peter Nilsson wrote:
>>> Jeff Taylor <dev.n...@spam.net> wrote:
>>>> I have a C program that GCC compiles without warnings and
>>>> it runs just fine.
>>> Realise that output is not the only measure of correctness.
>>>
>> Interesting interesting...
>>
>> Can you name any other measure that doesn't rely on
>> output?
>
> A program that invokes a buffer overrun, but happens to produce expected
> output is surely not correct?
>

How the hell do you know that there is a buffer
overrun if the output is not affected?

To KNOW that there is a buffer overrun the program MUST
do something it should not do, i.e. produce an output
that is different than the expected output

If the output of the program is normal you have NO WAY
to know there is a buffer overrun.

And if you hook a debugger and see some buffer being
overrun that *is* output of course.

>
>> Using a psychic medium is not allowed.
>>
>>
>>>> However, when I compile it using any of the -O options
>>>> (-O0, -O1, etc.) it segfaults when executed (still no
>>>> compiler warnings or errors).
>>> I'm afraid you are responsible for diagnosing errors in your
>>> code, not your compiler.
>>>
>> Deep thought.
>
> He means semantic errors. Or does your compiler do the programming for
> the programmer?
>
> <snip>
>

What I mean is that such sentences are not helpful to the OP.
And we should try to be less patronizing with newcomers and
people that ask questions. I am sure the OP knows that it is the
programmer that debugs the program. He was asking us to help him
to do that, not to answer him

just do it pal...


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32