seg fault on different linux boxes with C++.

G

goktan

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
 
O

Owen Jacobson

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.
 
J

John Harrison

goktan said:
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
 
G

goktan

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. :)
 
H

Howard

... 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
 

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,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top