3 Replies Latest reply: Jun 5, 2012 5:09 AM by 941031 RSS

    Segfaults in malloc/free when using new 12.3 compiler

    941031
      Dear All,

      Recently we've moved from studio 6 to studio12.3. Since then we are experiencing some memory problems. The (large ~100k loc) project throws 'random' segfaults on mallocs and free's, in very different parts of the system. The code is in general poorly written, but it worked fine with studio 6. Using a static code analysis tool (cppcheck) doesn't show memory leaks, and by using some macro we have made it impossible to free a pointer twice. The stacktraces from the core files don't show any usefull information.

      Is this some kind of known issue? Does the new studio use more strict memory libraries? Does the new compiler do more aggressive pointer stuff which breaks our code? Any help would be very much appreciated!

      - Studio 12.3
      - Solaris 5.10
      - Roguewave STL port

      Thanks in advance,
      Erik Vermij
        • 1. Re: Segfaults in malloc/free when using new 12.3 compiler
          Steve.Clamage-Oracle
          The big clue is "poorly-written program." :-)
          There is nothing in Studio 12.3 compared to WorkShop 6 that would result in new segfaults in itself.
          What has probably happened is that errors in the code having undefined behavior accidentally did no damage when compiled by the (relatively less efficient) WorkShop 6 compilers, but now cause problems in the different program layout created by the new compilers.

          Among the kinds of program errors that can lead to crashes like these are
          - using an invalid pointer
          -- uninitialized
          -- dangling (points to object that no longer exists)
          -- incremented or decremented outside object bounds
          -- points other than to an object start address
          - deleting an object more than once
          - reading or writing outside object bounds
          - failing to guard shared object in multi-threaded code
          - race condition in multi-threaded code
          The program failure usually occurs far away in space and time from the actual error.

          These errors do not always lead to a program crash
          An invalid pointer might sometimes by accident point to a harmless location.
          A race condition can go millions of cycles without causing a problem.
          Access to a deleted object can succeed by accident if the memory was not re-used.

          Any change in program code or compiler options can turn one of these
          programming errors into an actual failure, or the other way around.

          Of course, a compiler or system library bug might be the cause, but you
          can't tell from a core dump and stack trace.
          The core file presents a static picture after things have gone wrong.
          You need to trace the dynamic sequence of events to find where the first thing went wrong.

          You can try running the program under dbx with Run-Time Checking enabled.
          RTC will find many of these errors.
          Beginning with Studio 12.2, the Discover tool is the recommended replacement for dbx RTC, which is being phased out.
          Beginning with Studio 12, the Thread Analyzer tool will find race conditions in multi-threaded programs.

          Edited by: Steve_Clamage on Jun 1, 2012 8:57 AM
          • 2. Re: Segfaults in malloc/free when using new 12.3 compiler
            941031
            Thanks, for the reply. I'll fire up the discover tool!

            Erik
            • 3. Re: Segfaults in malloc/free when using new 12.3 compiler
              941031
              Found it! Thanks again,

              Erik