Problem using IRIX 6.5 CC (MIPSPro C++) STL I/O w/ POSIX threads

Discussion in 'C++' started by Evan David Light, Nov 26, 2003.

  1. After agonizing over this problem for a few days, I've decided to seek
    help. No, not the variety that involes a jacket that zips up the back
    but this august body of intrepid individuals.

    I've discovered the following:
    - My compile line should resemble:
    CC -D_PTHREADS -D_POSIX_C_SOURCE=199506L -LANG:std -n32 -mips3 -c
    <src> -o <obj>
    - My link line should resemble:
    CC -LANG:std -n32 -mips3 <objs> -o <executable> -lpthread
    - the -D_POSIX_C_SOURCE=199506L specifies the supported version of the
    POSIX standard
    - the -D_PTHREADS is necessary to inform the MIPSPro C++ STL headers
    that I intend to use pthreads and require them to use pthread
    functions for locking purposes.

    The problem is such:

    I have written a simple test program that creates several threads.
    Each pthread runs the same function: 1) it creates a
    std::vector<std::string> and pushes several strings into the vector,
    2) iterates over the vector printing its contents via std::cout, and
    3) exits.

    The problem that is occurring is that a simple line such as below

    std::cout << "foo" << 1 << std::endl;

    causes the program to crash.

    Using Purify, I was able to determine that, for some oddball
    reason, streaming an int to cout was the culprit. So then I begin to
    play around...

    std::cout << "foo" << '1' << std::endl; // works just fine

    and..

    std::cout << "foo" << std::endl; // also peachy keen

    and...

    std::cout << "foo" << 1L << std::endl; // same problem as the int

    and also...

    printf( "foo %d\n", 1); // this WORKS

    I tested each of the above cases individually within my test app.
    Every time that I said that it worked, I mean that the multithreaded
    test application successfully ran to completion.

    And, so, I am approaching wits end. I have run my same test
    application on Solaris 2.9 using Sun Workshop C++ and it behaves just
    fine. It's only with IRIX 6.5 MIPSPro C++ that I run into a problem.
    It seems reasonably clear to me
    that this problem is specific to MIPSPro C++ STL I/O and, perhaps, its
    handling of pthreads. I haven't as yet attempted this same experiment
    with SGI threads as I'm not especially interested in the results. I
    only wrote this test case as I have a customer who needs our product
    to support IRIX 6.5 32-bit mulithreaded.

    I'm fairly certain that this is not a locking issue as some of the
    above cases work run without any hiccups within my threads.

    Help?

    Evan
     
    Evan David Light, Nov 26, 2003
    #1
    1. Advertising

  2. In article <>,
    Evan David Light <> wrote:
    >After agonizing over this problem for a few days, I've decided to seek
    >help. No, not the variety that involes a jacket that zips up the back
    >but this august body of intrepid individuals.


    You do give the CC command line (helpful).

    You don't give any of
    the MIPSpro compiler version involved
    versions -b |grep ompil
    the IRIX version involved (probably irrelevant, but which 6.5.x is it?)
    a complete compileable and runnable test case.
    (unless it's right there in front of me and I missed it...?)

    Maybe someone can answer you without those, but I can't help
    without them. Sorry.
    David Anderson davea at sgi dot com
     
    David Anderson, Nov 26, 2003
    #2
    1. Advertising

  3. Evan David Light

    tom_usenet Guest

    On 26 Nov 2003 07:42:14 -0800, (Evan David Light)
    wrote:

    >After agonizing over this problem for a few days, I've decided to seek
    >help. No, not the variety that involes a jacket that zips up the back
    >but this august body of intrepid individuals.


    >The problem is such:
    >
    > I have written a simple test program that creates several threads.
    > Each pthread runs the same function: 1) it creates a
    >std::vector<std::string> and pushes several strings into the vector,
    >2) iterates over the vector printing its contents via std::cout, and
    >3) exits.
    >
    > The problem that is occurring is that a simple line such as below
    >
    > std::cout << "foo" << 1 << std::endl;
    >
    >causes the program to crash.


    Typically, std::cout cannot be used from multiple threads without
    locking. This is true of all streams objects in general. If you want
    thread safety, either use printf, or lock accesses to the stream.

    >
    > Using Purify, I was able to determine that, for some oddball
    >reason, streaming an int to cout was the culprit. So then I begin to
    >play around...
    >
    >std::cout << "foo" << '1' << std::endl; // works just fine

    1 2
    Even if this happens to work, you might have another thread multiplex
    output at 1 and/or 2.

    >and also...
    >
    >printf( "foo %d\n", 1); // this WORKS


    Usually printf provides the necessary locking in a thread-safe
    library.

    >I tested each of the above cases individually within my test app.
    >Every time that I said that it worked, I mean that the multithreaded
    >test application successfully ran to completion.
    >
    >And, so, I am approaching wits end. I have run my same test
    >application on Solaris 2.9 using Sun Workshop C++ and it behaves just
    >fine.


    It is possible that this is because Solaris disables buffering of
    std::cout.

    It's only with IRIX 6.5 MIPSPro C++ that I run into a problem.
    >It seems reasonably clear to me
    >that this problem is specific to MIPSPro C++ STL I/O and, perhaps, its
    >handling of pthreads. I haven't as yet attempted this same experiment
    >with SGI threads as I'm not especially interested in the results. I
    >only wrote this test case as I have a customer who needs our product
    >to support IRIX 6.5 32-bit mulithreaded.
    >
    >I'm fairly certain that this is not a locking issue as some of the
    >above cases work run without any hiccups within my threads.


    That's just because the successful methods don't happen to modify the
    state of std::cout (they only call threadsafe methods of the
    underlying C apis). If std::cout is unbuffered, then many calls won't
    modify the state.

    I'd recommend locking all accesses to std::cout. Using a locking proxy
    class is the usual approach (it locks on creation, unlocks on exit).
    e.g.

    //use comma operator!
    #define COUT (LockingProxy(mycout_mutex), std::cout)

    COUT << "whatever" << 10 << std::endl; //proxy destructs here.

    Tom

    C++ FAQ: http://www.parashift.com/c -faq-lite/
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
     
    tom_usenet, Nov 26, 2003
    #3
  4. (David Anderson) wrote in message news:<bq2l85$937pq$>...
    > In article <>,
    > Evan David Light <> wrote:


    > You do give the CC command line (helpful).


    Really? I wrote this above:
    CC -D_PTHREADS -D_POSIX_C_SOURCE=199506L -LANG:std -n32 -mips3 -c
    <src> -o <obj>

    >
    > You don't give any of
    > the MIPSpro compiler version involved
    > versions -b |grep ompil
    > the IRIX version involved (probably irrelevant, but which 6.5.x is it?)
    > a complete compileable and runnable test case.
    > (unless it's right there in front of me and I missed it...?)


    That's because I goofed and failed to cross post properly. See <a
    href="http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=eb0e5592.0311260810.4414cb5%40posting.google.com&rnum=17&prev=/groups%3Fq%3DSTL%2BMIPSPro%26start%3D10%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3Deb0e5592.0311260810.4414cb5%2540posting.google.com%26rnum%3D17">here</a>
     
    Evan David Light, Dec 1, 2003
    #4
  5. tom_usenet <> wrote in message news:<>...
    > I'd recommend locking all accesses to std::cout. Using a locking proxy
    > class is the usual approach (it locks on creation, unlocks on exit).
    > e.g.
    >
    > //use comma operator!
    > #define COUT (LockingProxy(mycout_mutex), std::cout)
    >
    > COUT << "whatever" << 10 << std::endl; //proxy destructs here.


    For simplicity's sake, I did the sample

    pthread_mutex_lock
    cout << ...
    pthread_mutex_unlock

    around all of my couts and I still encountered the same problem.

    Evan
     
    Evan David Light, Dec 1, 2003
    #5
  6. In article <>,
    Evan David Light <> wrote:
    >tom_usenet <> wrote in message news:<>...
    >> I'd recommend locking all accesses to std::cout. Using a locking proxy
    >> class is the usual approach (it locks on creation, unlocks on exit).
    >> e.g.
    >>
    >> //use comma operator!
    >> #define COUT (LockingProxy(mycout_mutex), std::cout)
    >>
    >> COUT << "whatever" << 10 << std::endl; //proxy destructs here.

    >
    >For simplicity's sake, I did the sample
    >
    >pthread_mutex_lock
    >cout << ...
    >pthread_mutex_unlock
    >
    >around all of my couts and I still encountered the same problem.


    MIPSpro7.3 is now quite old (released May 1999).
    7.3.1.1,7.3.1.2, 7.3.1.3, 7.4, 7.4.1 followed it.
    (7.4.1 released June 2003). I would suggest 7.4.1 as the
    best choice available today.


    uname -R
    versions -b |grep ompil
    would give the versions info that would mean most to me,
    but that's not going to help, I'm afraid, given that
    you're unable to supply a compileable runable test case
    (if you did so, I've been unable to find it) so no one can
    really verify that any particular release fixes the problem.

    Even the original thread in comp.programming.threads does
    not seem to have a complete test case.

    Have you tried creating a small test case, using pthreads
    and cout, to see if you reproduce the problem?

    David Anderson
     
    David Anderson, Dec 1, 2003
    #6
  7. In article <bqfsbg$aebgg$>,
    David Anderson <> wrote:

    >Have you tried creating a small test case, using pthreads
    >and cout, to see if you reproduce the problem?



    Evan Light provided a test case, which I have simplfied slightly.
    pth2.cxx:
    #include <iostream>
    int
    main()
    {
    std::cout << 1 << std::endl;
    }



    Makefile:
    pth2: pth2.cxx
    CC -D_PTHREADS -D_POSIX_C_SOURCE=199506L -LANG:std \
    -n32 -mips3 pth2.cxx -o pth2a
    CC -D_POSIX_C_SOURCE=199506L -LANG:std \
    -n32 -mips3 pth2.cxx -o pth2b


    pth2a crashes (segv). pth2b runs ok, printing
    test1 <newline>

    The -D_PTHREADS is provoking the crash.

    This with 7.4.1, IRIX 6.5.22.
    With earlier IRIX this may not compile (you get complaints
    about some scanf stuff).

    I'll see this gets looked into and keep you informed.
    I created bug 905611 to track this issue.
    Sorry about this, rather looks like our bug.
    David Anderson
     
    David Anderson, Dec 1, 2003
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Chaman Singh

    STL map and Posix Threads

    Chaman Singh, Apr 8, 2004, in forum: C++
    Replies:
    3
    Views:
    552
    Nick Hounsome
    Apr 9, 2004
  2. Christopher M. Lusardi
    Replies:
    4
    Views:
    455
    Thomas Matthews
    May 13, 2004
  3. r5
    Replies:
    0
    Views:
    323
  4. Marc Poinot

    MPI and python+threads on IRIX

    Marc Poinot, Jan 21, 2005, in forum: Python
    Replies:
    0
    Views:
    303
    Marc Poinot
    Jan 21, 2005
  5. Bram Stolk
    Replies:
    4
    Views:
    353
    Bram Stolk
    May 25, 2005
Loading...

Share This Page