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

[Evan David Light]

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

 

[David Anderson]

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

 

[tom_usenet]

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

 

[Evan David Light]

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

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=...11260810.4414cb5%40posting.google.com&rnum=17">here</a>

 

[Evan David Light]

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

 

[David Anderson]

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]

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