pthreads and c++ don't seem to mix

[awm129]

I'm having a problem porting some C++ code involving pthread to
Android. It seems if I include certain C++ headers and features in a
program that uses pthreads, I SIGSEGV before main() has a chance to
run. I specifically can recreate this issue using iostream but I fear
there are other headers/features that cause the same issue. I'm using
the Android NDK r5b with a include $(BUILD_EXECUTABLE) in my
Android.mk. Here is what I'm compiling:

//begin code

#include <pthread.h>
#include <stdio.h>
//#include <iostream>

class Foo
{
public:
Foo();
void go_thread();
void stop_thread();
private:
static void* worker( void* param );
pthread_t m_pt;
};

Foo::Foo()
{
m_pt = 0;
}

void Foo::go_thread()
{
int success = pthread_create( &m_pt, NULL, worker,
static_cast<void*>(this) );

if( success == 0 )
{
printf( "thread started\n" );
}
}

void Foo::stop_thread()
{
int success = pthread_join( m_pt, NULL );

if( success == 0 )
{
printf( "thread stopped\n" );
}
}

void* Foo::worker( void* p )
{
printf( "thread running\n" );
return 0;
}

int main()
{
Foo f;
f.go_thread();
f.stop_thread();

//std::cout << "crash me!" << std::endl;

return 0;
}

// end code

If I uncomment the two lines involving iostream and run the resulting
executable on a device, I SIGSEGV before main() has a chance to run.
Leaving the two lines commented out produces an executable that
behaves as expected. Any thoughts?

[Stephen Williams]

Are you sure it has to do with threading?  Are you able to use iostreams at all?  We avoid it, probably for this same crash reason.

sdw

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

--
--
Stephen D. Williams s...@lig.net scie...@gmail.com LinkedIn: http://sdw.st/in
V:650-450-UNIX (8649) V:866.SDW.UNIX V:703.371.9362 F:703.995.0407
AIM:sdw Skype:StephenDWilliams Resume: http://sdw.st/gres
Personal: sdw.st facebook.com/sdwlig twitter.com/scienteer

[awm129]

I have used iostreams successfully in other projects.

I'm concerned that the behavior I'm seeing seems to go beyond just
iostream. In my larger project (this is obviously just a contrived
example to illustrate the issue), I've grepped iostream out of
existence but still fail the same way when a pthread_create() is
included in my project.

> Stephen D. Williams s...@lig.net scient...@gmail.com LinkedIn:http://sdw.st/in

[Stephen Williams]

Do you have more than one .so?  It was mentioned recently that some C++ libraries have statics, static initializers, or thread-local storage mechanisms that break if multiple copies are present at runtime.  Most likely, one instance gets initialized last and gets control of something so that a different instance is incompatible.

sdw

[awm129]

Currently I'm building a monolithic executable with everything
statically linked (except the obvious like libc (bionic)). I'm using
the gnu_static variant of the std c++ library and I would have hoped g+
+ would throw up a link error for multiple definitions, but I
certainly wouldn't put it past it. Do you know if there is a list
anywhere of the C++ libs with global statics and or thread-local
storage?

[Tim Mensch]

On 4/5/2011 10:18 AM, awm129 wrote:
> I'm concerned that the behavior I'm seeing seems to go beyond just
> iostream. In my larger project (this is obviously just a contrived
> example to illustrate the issue), I've grepped iostream out of
> existence but still fail the same way when a pthread_create() is
> included in my project.

I avoid iostream like the plague, and I use pthread_create()
successfully in my game to create a worker thread and some mutex
objects, so I know pthreads does work.

Tim

[awm129]

Perhaps I'd have more luck building against the OSP as opposed to
using the NDK. I'll give that a go and see if the results improve.

[Tim Mensch]

On 4/5/2011 12:51 PM, awm129 wrote:
> Perhaps I'd have more luck building against the OSP as opposed to
> using the NDK. I'll give that a go and see if the results improve.

OSP? Not sure what you mean, but I'm building against the NDK, if an
older version (Crystax r4b -- I'm waiting for a version of r5 that works
on Android 2.1 and earlier reliably before making the switch).

Tim