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