STL string segfault

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Vedran Vyroubal

    STL string segfault

    Hi all!
    I have a problem with STL string.
    My program segfaults after a period of time, it can run perfectly for
    days and than die after a week, and when it segfaults it doesn't have to
    be at the same place. This is a backtrace:

    Program received signal SIGSEGV, Segmentation fault.
    [Switching to thread 580.0x7b0]
    0x00485f66 in std::__default_ alloc_template< true, 0>::allocate(un signed) ()
    (gdb) bt
    #0 0x00485f66 in std::__default_ alloc_template< true,
    0>::allocate(un signed) ()
    #1 0x0047e0ec in std::string::_R ep::_S_create(u nsigned,
    std::allocator< char> const&) ()
    #2 0x0047dfed in std::string::_R ep::_M_clone(st d::allocator<ch ar>
    const&, unsigned) ()
    #3 0x0047f4d1 in std::string::re serve(unsigned) ()
    #4 0x0047e5f5 in std::string::ap pend(unsigned, char) ()
    #5 0x004801c2 in std::string::op erator+=(char) ()
    #6 0x00415fdd in T10::enable_del ivery() ()
    #7 0x004133f7 in T10::process_st atus() ()
    #8 0x0040bd80 in T10::process_co mmand(char*, char*) ()
    #9 0x0040688e in PSS::z3(int) ()
    #10 0x00405eee in PSS::switch_sta tes(int) ()
    #11 0x00404cba in PSS::pss_crunch er(std::string& ) ()
    #12 0x0041ba83 in V11_2::s9() ()
    #13 0x0041a773 in V11_2::runner() ()
    #14 0x0041a68b in V11_2::v11_star ter(int) ()

    This is just an example how it dies, but bt is always the same from
    "std::string::o perator+=(char) ()" upwards!
    Threading is minimal and critical sections are used, OS is Win2K and
    compiler is mingw (gcc version 3.2.3 (mingw special 20030504-1)).

    Help!

  • John Harrison

    #2
    Re: STL string segfault


    "Vedran Vyroubal" <vedran.vyrouba l@REMOVETHISine t.hr> wrote in message
    news:c242pl$le0 $1@ls219.htnet. hr...[color=blue]
    > Hi all!
    > I have a problem with STL string.
    > My program segfaults after a period of time, it can run perfectly for
    > days and than die after a week, and when it segfaults it doesn't have to
    > be at the same place. This is a backtrace:
    >
    > Program received signal SIGSEGV, Segmentation fault.
    > [Switching to thread 580.0x7b0]
    > 0x00485f66 in std::__default_ alloc_template< true, 0>::allocate(un signed)[/color]
    ()[color=blue]
    > (gdb) bt
    > #0 0x00485f66 in std::__default_ alloc_template< true,
    > 0>::allocate(un signed) ()
    > #1 0x0047e0ec in std::string::_R ep::_S_create(u nsigned,
    > std::allocator< char> const&) ()
    > #2 0x0047dfed in std::string::_R ep::_M_clone(st d::allocator<ch ar>
    > const&, unsigned) ()
    > #3 0x0047f4d1 in std::string::re serve(unsigned) ()
    > #4 0x0047e5f5 in std::string::ap pend(unsigned, char) ()
    > #5 0x004801c2 in std::string::op erator+=(char) ()
    > #6 0x00415fdd in T10::enable_del ivery() ()
    > #7 0x004133f7 in T10::process_st atus() ()
    > #8 0x0040bd80 in T10::process_co mmand(char*, char*) ()
    > #9 0x0040688e in PSS::z3(int) ()
    > #10 0x00405eee in PSS::switch_sta tes(int) ()
    > #11 0x00404cba in PSS::pss_crunch er(std::string& ) ()
    > #12 0x0041ba83 in V11_2::s9() ()
    > #13 0x0041a773 in V11_2::runner() ()
    > #14 0x0041a68b in V11_2::v11_star ter(int) ()
    >
    > This is just an example how it dies, but bt is always the same from
    > "std::string::o perator+=(char) ()" upwards!
    > Threading is minimal and critical sections are used, OS is Win2K and
    > compiler is mingw (gcc version 3.2.3 (mingw special 20030504-1)).
    >
    > Help!
    >[/color]

    It's simple enough to diagnose, but complex to fix. You have heap
    corruption, there is no way that string operator+= should fail except if the
    heap is corrupt. But the problem is what is causing the heap corruption?
    There is no reason that it should be your string handling, it could easily
    be something completely different in your program. Pointers and fixed size
    arrays are the usual culprits but really it could be anything.

    john


    Comment

    • Vedran Vyroubal

      #3
      Re: STL string segfault

      > It's simple enough to diagnose, but complex to fix. You have heap[color=blue]
      > corruption, there is no way that string operator+= should fail except if the
      > heap is corrupt. But the problem is what is causing the heap corruption?
      > There is no reason that it should be your string handling, it could easily
      > be something completely different in your program. Pointers and fixed size
      > arrays are the usual culprits but really it could be anything.
      >
      > john
      >
      >[/color]
      I was afraid of that! Thanks anyway!

      Comment

      • Sharad Kala

        #4
        Re: STL string segfault


        "Vedran Vyroubal" <vedran.vyrouba l@REMOVETHISine t.hr> wrote in message
        news:c245dp$41v $1@ls219.htnet. hr...
        [color=blue]
        > I was afraid of that! Thanks anyway![/color]

        I think using a tool like Rational Purify can certainly help here.



        Comment

        • visage

          #5
          Re: STL string segfault

          Vedran Vyroubal <vedran.vyrouba l@REMOVETHISine t.hr> wrote in message news:<c242pl$le 0$1@ls219.htnet .hr>...[color=blue]
          > Hi all!
          > I have a problem with STL string.
          > My program segfaults after a period of time, it can run perfectly for
          > days and than die after a week, and when it segfaults it doesn't have to
          > be at the same place. This is a backtrace:
          >
          > Program received signal SIGSEGV, Segmentation fault.
          > [Switching to thread 580.0x7b0]
          > 0x00485f66 in std::__default_ alloc_template< true, 0>::allocate(un signed) ()
          > (gdb) bt
          > #0 0x00485f66 in std::__default_ alloc_template< true,
          > 0>::allocate(un signed) ()
          > #1 0x0047e0ec in std::string::_R ep::_S_create(u nsigned,
          > std::allocator< char> const&) ()
          > #2 0x0047dfed in std::string::_R ep::_M_clone(st d::allocator<ch ar>
          > const&, unsigned) ()
          > #3 0x0047f4d1 in std::string::re serve(unsigned) ()
          > #4 0x0047e5f5 in std::string::ap pend(unsigned, char) ()
          > #5 0x004801c2 in std::string::op erator+=(char) ()
          > #6 0x00415fdd in T10::enable_del ivery() ()
          > #7 0x004133f7 in T10::process_st atus() ()
          > #8 0x0040bd80 in T10::process_co mmand(char*, char*) ()
          > #9 0x0040688e in PSS::z3(int) ()
          > #10 0x00405eee in PSS::switch_sta tes(int) ()
          > #11 0x00404cba in PSS::pss_crunch er(std::string& ) ()
          > #12 0x0041ba83 in V11_2::s9() ()
          > #13 0x0041a773 in V11_2::runner() ()
          > #14 0x0041a68b in V11_2::v11_star ter(int) ()
          >
          > This is just an example how it dies, but bt is always the same from
          > "std::string::o perator+=(char) ()" upwards!
          > Threading is minimal and critical sections are used, OS is Win2K and
          > compiler is mingw (gcc version 3.2.3 (mingw special 20030504-1)).
          >
          > Help![/color]

          Hard to tell without more code, but, given that something's going
          wrong in an allocate() method, that kinda points to a problem running
          out of memory. This hypothesis is supported by the fact that your
          program takes varying amounts of time to fail...Have you looked at how
          the program's memory usage varies over time?

          Comment

          • Vedran Vyroubal

            #6
            Re: STL string segfault

            >[color=blue]
            > Hard to tell without more code, but, given that something's going
            > wrong in an allocate() method, that kinda points to a problem running
            > out of memory. This hypothesis is supported by the fact that your
            > program takes varying amounts of time to fail...Have you looked at how
            > the program's memory usage varies over time?[/color]

            That's just the thing, mem usage is more or less fixed over time.
            Just to clarify more, this program controls a piece of hardware over
            RS-232 line, and the only place where memory varies is message queue I
            use, and I have checked this code over a million times already!
            The source of my frustration is that the code runs on two boxes, and the
            curious thing is that it dies a lot faster on the newer and faster box
            with 256 megs and 2 gig processor, while on the older one with 128 megs
            and 300 MHz processor on average it runs for a week. Go figure!

            Comment

            Working...