seg fault on different linux boxes with C++.

Discussion in 'C++' started by goktan, Aug 2, 2004.

  1. goktan

    goktan Guest

    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
    goktan, Aug 2, 2004
    #1
    1. Advertising

  2. 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.
    Owen Jacobson, Aug 2, 2004
    #2
    1. Advertising

  3. "goktan" <> wrote in message
    news:...
    > 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
    John Harrison, Aug 2, 2004
    #3
  4. goktan

    goktan Guest

    > 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. :)
    goktan, Aug 2, 2004
    #4
  5. goktan

    Howard Guest

    "goktan" <> wrote in message
    news:...

    >... 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
    Howard, Aug 2, 2004
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Vinod

    Suprising seg fault!!!

    Vinod, Sep 27, 2003, in forum: C++
    Replies:
    3
    Views:
    460
    Ron Natalie
    Sep 27, 2003
  2. Corrine
    Replies:
    1
    Views:
    415
    Gianni Mariani
    Nov 27, 2003
  3. Manuel Maria Diaz Gomez

    fstream::open & seg fault

    Manuel Maria Diaz Gomez, Jul 20, 2004, in forum: C++
    Replies:
    3
    Views:
    1,174
    John Harrison
    Jul 20, 2004
  4. Matthias Kaeppler

    seg-fault on vector-auto-reserve

    Matthias Kaeppler, Feb 27, 2005, in forum: C++
    Replies:
    2
    Views:
    460
    Victor Bazarov
    Feb 27, 2005
  5. johnty

    seg fault in linux but not cygwin

    johnty, Feb 10, 2010, in forum: C Programming
    Replies:
    36
    Views:
    1,281
    Nick Keighley
    Feb 16, 2010
Loading...

Share This Page