standard c++ containers, memory and aix - Aix

This is a discussion on standard c++ containers, memory and aix - Aix ; Hi, Recently we ported our application from sun solaris to ibm aix. The os version is 5.3 and the language is c++ with compiler as xlC v7. What was working perfectly in sun solaris is creating problems in aix. The ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: standard c++ containers, memory and aix

  1. standard c++ containers, memory and aix

    Hi,

    Recently we ported our application from sun solaris to ibm aix. The os
    version is 5.3 and the language is c++ with compiler as xlC v7. What
    was working perfectly in sun solaris is creating problems in aix. The
    application uses std::vector, fstream and dynamic_cast. When the input
    file has 5000 records, its working fine. The maximum records with
    which its working fine is 8636. One record greater than this count
    makes the program work differently. Do not know what this magical
    number is. The one difference i see is that aix has dinkum c++
    libraries while sun solaris has roguewave c++ libraries. Any
    directions would be of great help.

    I thought of posting this query in comp.lang.c++. The problem here is
    with respect to OS and not the language. Hence i am posting the query
    here. If this is not the right place, pls let me know the correct
    group.

    Thanks,
    Balaji.


  2. Re: standard c++ containers, memory and aix

    kasthurirangan.balaji@gmail.com writes:

    > Recently we ported our application from sun solaris to ibm aix. The os
    > version is 5.3 and the language is c++ with compiler as xlC v7. What
    > was working perfectly in sun solaris is creating problems in aix. The
    > application uses std::vector, fstream and dynamic_cast. When the input
    > file has 5000 records, its working fine. The maximum records with
    > which its working fine is 8636. One record greater than this count
    > makes the program work differently.


    It is most likely that there is a bug in the application, which
    you have never observed on Solaris, but which shows up on AIX.

    This is *very* common occurence when porting.

    > Do not know what this magical number is.


    It's the "magical number" after which your bug becomes visible
    on AIX.

    > I thought of posting this query in comp.lang.c++.


    It would be completely off topic there.

    Suggestions:
    1. describe in detail *how* the application starts "working
    differently" after you reach 8636 records.
    2. build your app with g++-4.x with -D_GLIBCXX_DEBUG, or using
    STLport in debugging mode, and check whether it has improper STL
    container/iterator usage.
    3. test your program with "heap debuggers" (Purify, Insure++) to
    check whether there are any heap-related issues.

    You can check [2] and [3] on either AIX or solaris. For [3], on a
    recent Solaris version you can also use libmem. See man umem_debug

    Cheers,
    --
    In order to understand recursion you must first understand recursion.
    Remove /-nsp/ for email.

  3. Re: standard c++ containers, memory and aix

    In addition to Paul's excellent suggestions, there is one more
    difference between AIX and Solaris that may explain an application
    failure that seems to be tied to "memory capacity".

    Solaris and AIX:
    Control heap usage with soft limits. If you exceed the soft limit, a
    malloc request will fail, returning a NULL pointer. If you aren't
    handling that null pointer possibility, the application will fail in a
    rude way.

    Check your data limits:
    ulimit -a

    Raise your heap soft-limit:
    ulimit -d unlimited

    http://publib.boulder.ibm.com/infoce...ipr40mst41.htm

    AIX:
    Has a memory "segment" architecture. In a 32-bit app, 256MB segments
    are allocated for various usages:

    0 -- The kernel
    1 -- The main() application code
    2 -- The Heap and the stack (by default)
    ....

    For a non-threaded app, the heap and stack occupy a single 256MB
    segment.
    - Stack grows downward
    - Heap (malloc) allocations grow upward
    - If the lines ever cross, you're out of memory.

    Suggestion:
    A simple way to test whether you are running out of space is to use an
    environment variable to increase the size of the heap allocation.

    $ testpgm

    Gets replaced with:

    $ ulimit -d unlimited
    $ LDR_CNTRL=MAXDATA=0x60000000 testpgm

    This will increase the heap from 1 segment (256MB) to 6 segments (1.5
    GB )

    To build your application with this default 1.5GB memory size, use
    this flag:

    xlC -bmaxdata=0x60000000 ...

    If it still fails, Paul's suggestions still apply.


+ Reply to Thread