Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > seg fault on different linux boxes with C++.

Reply
Thread Tools

seg fault on different linux boxes with C++.

 
 
goktan
Guest
Posts: n/a
 
      08-02-2004
hi

i have been making a project with C++ including GTK+1.2, gtkmozembed
and libxml2. i'm using g++ 2.96 for compiling it. but while it is
working on Reh Hat 9, it is not working on Fedora core 2. the symptom
is; it is compiling with g++ 2.96 problemless on fedora but when i run
it with a normal user it is crashing and it is giving me seg fault and
when i use gdb for debugging it it says

-> x00c6f6ad in malloc_consolidate () from /lib/tls/libc.so.6

and after backtrace


-> Previous frame inner to this frame (corrupt stack?)

other gtk based or mozilla based programs are working on my fedora.
so, why it is not working on fedora and what is the meaning of corrupt
stack? the only difference of two system; one is kernel 2.4.20-8 and
the other is (fedora) 2.6.6-1. i tought that kernel 2.6's memory
management differs from other. can it be the problem.?


thanks for the help
goktan
 
Reply With Quote
 
 
 
 
Owen Jacobson
Guest
Posts: n/a
 
      08-02-2004
On Mon, 02 Aug 2004 01:56:19 -0700, goktan wrote:

> hi
>
> i have been making a project with C++ including GTK+1.2, gtkmozembed and
> libxml2. i'm using g++ 2.96 for compiling it.


Update your compiler. 2.96 is seriously outdated and has a number of
issues with C++.

> but while it is working on Reh Hat 9, it is not working on Fedora core
> 2. the symptom is; it is compiling with g++ 2.96 problemless on fedora
> but when i run it with a normal user it is crashing and it is giving me
> seg fault and when i use gdb for debugging it it says
>
> -> x00c6f6ad in malloc_consolidate () from /lib/tls/libc.so.6
>
> and after backtrace
>
> -> Previous frame inner to this frame (corrupt stack?)
>
> other gtk based or mozilla based programs are working on my fedora. so,
> why it is not working on fedora and what is the meaning of corrupt
> stack?


It means the execution stack has been corrupted -- probably because
something wrote past the end of an array, or outside of allocated space,
and smashed the return address.

> the only difference of two system; one is kernel 2.4.20-8 and the
> other is (fedora) 2.6.6-1. i tought that kernel 2.6's memory management
> differs from other. can it be the problem.?


Crystal ball's in the shop. Post the code. However, correct code
shouldn't[0] change behaviours because of a change in the OS's memory
manager, especially considering the stack isn't managed by it. I'd bet
you've written past the end of an array.

[0] I want to live in theory. In theory, everything works the way it's
documented to.

--
Some say the Wired doesn't have political borders like the real world,
but there are far too many nonsense-spouting anarchists or idiots who
think that pranks are a revolution.

 
Reply With Quote
 
 
 
 
John Harrison
Guest
Posts: n/a
 
      08-02-2004

"goktan" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
> hi
>
> i have been making a project with C++ including GTK+1.2, gtkmozembed
> and libxml2. i'm using g++ 2.96 for compiling it. but while it is
> working on Reh Hat 9, it is not working on Fedora core 2. the symptom
> is; it is compiling with g++ 2.96 problemless on fedora but when i run
> it with a normal user it is crashing and it is giving me seg fault and
> when i use gdb for debugging it it says
>
> -> x00c6f6ad in malloc_consolidate () from /lib/tls/libc.so.6
>
> and after backtrace
>
>
> -> Previous frame inner to this frame (corrupt stack?)
>
> other gtk based or mozilla based programs are working on my fedora.
> so, why it is not working on fedora and what is the meaning of corrupt
> stack? the only difference of two system; one is kernel 2.4.20-8 and
> the other is (fedora) 2.6.6-1. i tought that kernel 2.6's memory
> management differs from other. can it be the problem.?
>


The most likely explanation for you problems is that your code is bugged.
Bugged code behaves unpredictably, running fine on one system and failing on
another apparently identical (or nearly identical) system.

You should definitely not look to the different kernels as the reason for
your problems, the reason is (almost certainly) that you have a bug in your
code which shows up on one system but not on the other.

Now if we could see some of the code....

John



 
Reply With Quote
 
goktan
Guest
Posts: n/a
 
      08-02-2004
> Update your compiler. 2.96 is seriously outdated and has a number of
> issues with C++.

yep, i know g++ 2.96 is not a good compiler and it not fits the
standart of C++ somewhere. but i had to use it because a g++ bug on
3.2 series has some handicaps on gtkmozembed. and i also tried it with
gcc 3.3 and i had the same problem. but gcc 2.96 works fine on RH 9.


> It means the execution stack has been corrupted -- probably because
> something wrote past the end of an array, or outside of allocated space,
> and smashed the return address.
>

i'm using vectors instead of arrays at most places and the code
crashes at nearly the starting of the program. (if u know GTK) when i
want to create a window (its only allocating a struct) it is crashing.
no more no less... but under your comments i will recheck the code
again. but if there is an overflow bug why it is working on RH 9.?


> Crystal ball's in the shop. Post the code. However, correct code
> shouldn't[0] change behaviours because of a change in the OS's memory
> manager, especially considering the stack isn't managed by it. I'd bet
> you've written past the end of an array.
>
> [0] I want to live in theory. In theory, everything works the way it's
> documented to.


by the way, i didn't understand the crystal code part.
 
Reply With Quote
 
Howard
Guest
Posts: n/a
 
      08-02-2004

"goktan" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...

>... but if there is an overflow bug why it is working on RH 9.?
>


Because what is in memory at a given location (relative to your code) on one
machine may be entirely different from what is stored there on another
machine. Say you write eleven value to an array that is is only ten
integers in length. So you put a value where it doesn't belong. On one
machine, the location where you wrote that extra value may be another
variable, and your program may be perfectly content (even correct!) to have
that value there. But on another machine, that location might be the code
at the start of some functon. So when you call that function, the first
instruction at that location is no longer the instruction it was, but some
random instruction, and the result is (often) a crash.

This kind of behavior is quite common when writing to memory you're not
supposed to. In addition to different machines behaving differently,
another symptom of this error is that the debug version might work fine, but
the release version crashes. (That's often due to the optimizations and
lack of zero-initializing that may occur in release versions.)

-Howard



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
seg fault in linux but not cygwin johnty C Programming 36 02-16-2010 10:34 AM
seg-fault on vector-auto-reserve Matthias Kaeppler C++ 2 02-27-2005 10:01 PM
fstream::open & seg fault Manuel Maria Diaz Gomez C++ 3 07-20-2004 06:18 PM
seg fault because stdexcept.cc not found? Corrine C++ 1 11-27-2003 06:15 AM
Suprising seg fault!!! Vinod C++ 3 09-27-2003 02:43 PM



Advertisments