public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: "John S. Fine" <johnsfine@verizon.net>
To: Alireza Haghdoost <haghdoost@gmail.com>
Cc: gcc-help@gcc.gnu.org
Subject: Re: Segmentation fault after compilation with gcc-3.4 on 64-bit Linux
Date: Sat, 01 Aug 2009 14:53:00 -0000	[thread overview]
Message-ID: <4A7456E9.8060306@verizon.net> (raw)
In-Reply-To: <396d8f7c0908010728l2e128638v63a9c43cb9cae7c@mail.gmail.com>

Forget compilation flags and don't ask about or blame gcc.  There are 
bugs in your C code and that makes it crash.

Many 32 bit applications are filled with questionable casts and other 
constructs that assume things such as ints being the same size as 
pointers, that are correct in 32 bit mode but not in 64 bit mode.

When you port a large application like that from 32 bit to 64 bit, you 
have to be prepared to find and fix those bugs.

I've also seen a number of examples of code that is just wrong, even in 
32 bit mode, but shows no symptoms until you build it in 64 bit mode.  
That includes things like using fields in a structure after freeing the 
memory containing that structure and things like testing uninitialized 
stack variables and behaving correctly only if they are non zero.  
Almost anything that changes the size or layout of your program or data 
might change those errors from symptom free to seg fault.  It just 
happened that a switch from 32 bit to 64 bit did it.

If you know how to use a debugger, you can look at the code, data and 
callback stack at the point of the seg fault and deduce what bug caused 
the seg fault.  If you're lucky, finding and fixing a few of those bugs 
will solve the whole problem.  But many questionable casts and other 
usages that only works in 32 bit mode produce wrong results rather than 
seg faults when run in 64 bit.  If you program has those bugs, you need 
a good understanding of the whole program, rather than just some 
competence with a debugger, in order to find and fix the bugs.

You should be asking yourself why you need this program to run in 64 bit 
mode and whether it is really worth the effort.  If I were doing it, I 
would certainly try to find the bugs (I don't like leaving such bugs in 
my code even if running in 64 bit mode isn't important now).  But I know 
how to do that.  If you had to ask what you asked in the quoted message, 
I assume you don't know how to find the bugs in your program.

Alireza Haghdoost wrote:
> I mean that gcc-3.4 on 64-bit machine compiles my
> application well but when I try to run compiled application, it failed
> by Segmentation Fault error.
> I have tried several compilation Flags


  reply	other threads:[~2009-08-01 14:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-01 14:28 Alireza Haghdoost
2009-08-01 14:53 ` John S. Fine [this message]
2009-08-01 16:35 ` Andrew Haley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A7456E9.8060306@verizon.net \
    --to=johnsfine@verizon.net \
    --cc=gcc-help@gcc.gnu.org \
    --cc=haghdoost@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).