Problem using IRIX 6.5 CC (MIPSPro C++) STL I/O w/ POSIX threads
Evan David Light
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
std::cout << "foo" << std::endl; // also peachy keen
std::cout << "foo" << 1L << std::endl; // same problem as the int
and also...
printf( "foo %d\n", 1); // this WORKS
And, so, I am approaching wits end. 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.
Help?
Evan
Alexander Terekhov
Evan David Light wrote:
[...]
> Help?
Wrap it. You probably need a synchronizing wrapper. Instead of
std::cout << a << b;
you'll have
my_cout() << a << b;
http://groups.google.com/groups?selm=3DD6B913.4C8DA209%40web.de
You might also want to obfuscate it (sort of). I mean a macro using comma.
http://groups.google.com/groups?selm=bm5od5%24sc7%241%40newstree.wise.edt.ericsson.se
regards,
alexander.
Evan David Light
> Evan David Light wrote:
> [...]
> > Help?
>
> Wrap it. You probably need a synchronizing wrapper. Instead of
>
> std::cout << a << b;
>
> you'll have
>
> my_cout() << a << b;
Alexander,
Thanks for the reply. Honestly, I don't believe that this is the
case; however, I don't believe that I stated the problem adequately to
make that clear at first. I ran each one of those cout test cases,
that I mentioned above, individually within my test app (even though
they look like they ran within the same program). Every time that I
say that the line "worked", the multithreaded program ran to
completion. It really does seem more related to how SGI STL I/O
handles numeric values than a problem with sychronization. If I can
cout a string followed by a char, it follows, to me, that I ought to
be able ot cout a string followed by an int. Also, the test app that
I described above runs successfully on Solaris 2.9 further indicating
to me that this problem is limited to SGI.
Please refer to my somewhat delayed crosspost to comp.lang.c++ for
somewhat more information.
Thanks again,
Evan
Evan David Light
occurring using MIPSPro 7.3.
Evan David Light
that the core dump occurred during the dynamic_cast of something
called a _Facet within iostream. This occurred when I streamed a
string followed by a numeric value (int/long) to cout.
Even O. Andersen
>
> Additionally, I thought it worth mentiong that this problem is
> occurring using MIPSPro 7.3.
I've seen this happen with the 7.3 compilers,
7.3.1.3m seems to work ok.
Evan David Light
It may be worth noting that I've been communicating with a fellow at
SGI who has replicated this issue using 7.4. He's looking into it.