Safer STL

CS 509 - Advanced Programming II, Spring 2003

Table of Contents

What is it?

Safer STL is a modified version of the STL; the modifications involve adding checks to STL code to catch common programming errors. Safer STL is based on the STLPort implementation of the STL; the modifications are based on those implemented by Cay Horstman in his SafeSTL. I have extended Horstman's set of checks to include more errors, and applied them wherever an error is allowed to occur by the STL.

Why do I care?

You should care about Safer STL because I'm going to use it when I compile your code for testing. If Safer STL blows up during testing, you're going to lose points.

How do I use it?

Unfortunately, using Safer SLT more complicated than using the regular STL. I'm trying to figure out how to make it simpler, but for now, the best way to go about it is to break the process up into two steps: compiling the source and linking the objects.

There are a few things you should know before tackling Safer STL:

With the preliminaries out of the way, here's how to you get your program to use Safer STL instead of the default STL:

  1. Compiling the source. When compiling your source into .o object files, make sure the compiler picks up the Safer STL versions of the include files by using the -I command-line option to add the Safer STL include directory /export/home/class/cs-509:

    $ g++ -g -c -I/export/home/class/cs-509/include/stlport

    If you do not use the -I option to specify the Safer STL include directory, the compiler will use the default STL.

    You cannot mix Safer STL and the default STL in the same program; you must either compile all your files to use Safer STL or to use the default STL.

    The -g command-line option generates extra information useful for debugging code. You do not have to specify -g, but you probably should. If you do use the -g option, make sure you use it for all the files you compile.

    You do not have to change your #include statements to switch between Safer STL and the default STL. Switching between the two is done by the the -I option as described above.

  2. Linking the objects. Once you have all your source files compiled into object files, you can link them together to produce an executable. The linking command you should use will look like this:

    $ g++ -g your-files-here.o /export/home/class/cs-509/lib/libstlport_gcc.a

    The libstlport_gcc.a file is a library containing code implementing various features of Safer STL, including the iostream classes. This file should be listed last after all other object files on the command line.

    If you compiled your source with the -g option, you should link them with the -g option as shown. If you didn't use -g during compilation, you can skip it during linking. Once your progam is linked to produce an executable, you can run it as you normally would.

Makefiles can make compiling and linking less onerous; see the example makefile in /export/home/class/cs-509/misc.

My Program Crashed. Now What?

If Safer STL detects a problem, it will print an error message and abort the program with a coredump contained in a file named core.

$ ./a.out
Accessing element 1 in an empty vector.


Assuming you used the g++ compiler and the -g option, you can use the gdb debugger to find out where your code went wrong:

  1. Start the debugger using the command line gdb your-program core:

    $ gdb a.out core
    GNU gdb 5.2
    Copyright 2002 Free Software Foundation, Inc.
    GDB is free software, covered by the GNU General Public License, and you are
    welcome to change it and/or distribute copies of it under certain conditions.
    Type "show copying" to see the conditions.
    There is absolutely no warranty for GDB.  Type "show warranty" for details.
    This GDB was configured as "sparc-sun-solaris2.8"...
    Core was generated by ./a.out.
    Program terminated with signal 6, Aborted.
    Reading symbols from /usr/local/lib/
    Loaded symbols for /usr/local/lib/
    Reading symbols from /usr/lib/
    Loaded symbols for /usr/lib/
    Reading symbols from /usr/local/lib/
    Loaded symbols for /usr/local/lib/
    Reading symbols from /usr/lib/
    Loaded symbols for /usr/lib/
    Reading symbols from /usr/lib/
    Loaded symbols for /usr/lib/
    Reading symbols from /usr/platform/SUNW,Ultra-5_10/lib/
    Loaded symbols for /usr/platform/SUNW,Ultra-5_10/lib/
    #0  0xff21a3dc in _libc_kill () from /usr/lib/

  2. At the (gdb) command prompt, type the where command. This produces the stack trace of your program that existed when it crashed:

    (gdb) where
    #0  0xff21a3dc in _libc_kill () from /usr/lib/
    #1  0xff1b5324 in abort () from /usr/lib/
    #2  0x0003fdc4 in _STL::vector<int, _STL::allocator<int>
        >::_M_range_check(unsigned) const (this=0xffbee778, __n=1) at
    #3  0x0003fc1c in _STL::vector<int, _STL::allocator<int>
        >::operator[](unsigned) (this=0xffbee778, __n=1) at
    #4  0x00035f74 in main () at

    Read the stack trace from the bottom up, starting at main(), looking for the point at which you stop recognizing subroutine names. The last subroutine name you recognize is probably the place you should start looking for the problem.

    In this example, the problem occured in main() at line 6 in file

This page last modified on 8 January 2003.