By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,227 Members | 1,175 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,227 IT Pros & Developers. It's quick & easy.

seg fault on different linux boxes with C++.

P: n/a
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
Jul 22 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
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.

Jul 22 '05 #2

P: n/a

"goktan" <go****@idealteknoloji.com> wrote in message
news:b0**************************@posting.google.c 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

Jul 22 '05 #3

P: n/a
> 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. :)
Jul 22 '05 #4

P: n/a

"goktan" <go****@idealteknoloji.com> wrote in message
news:b0**************************@posting.google.c 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

Jul 22 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.