[Boost-users] [shared_ptr] hangs on iPhone

[Igor R]

Hello,

My application works on iphone simulator, but hangs when running on
iphone itself. Pausing it and looking at the stack trace shows the
picture very similar to the one desribed here:
http://article.gmane.org/gmane.comp.lib.boost.user/47644
I.e., the call stack origins from different place each time, but ends
up with an attempt to addref shared_ptr and spinning in the spinlock.
I could try and use XCode "native" tr1::shared_ptr version, but
boost::shared_ptr is used by many other boost libraries, so it
wouldn't help.
So my question is if there's any fix/workaround/compiler-switch that I
can apply to overcome this issue and avoid re-writing the whole
project without boost?

Thanks!
_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Peter Dimov]

Igor R wrote:
> Hello,
>
> My application works on iphone simulator, but hangs when running on
> iphone itself. Pausing it and looking at the stack trace shows the
> picture very similar to the one desribed here:
> http://article.gmane.org/gmane.comp.lib.boost.user/47644
> I.e., the call stack origins from different place each time, but ends
> up with an attempt to addref shared_ptr and spinning in the spinlock.
> I could try and use XCode "native" tr1::shared_ptr version, but
> boost::shared_ptr is used by many other boost libraries, so it
> wouldn't help.
> So my question is if there's any fix/workaround/compiler-switch that I
> can apply to overcome this issue and avoid re-writing the whole
> project without boost?

You might try to comment out the lines

#if defined(__GNUC__) && defined( __arm__ ) && !defined( __thumb__ )
# include <boost/smart_ptr/detail/spinlock_gcc_arm.hpp>

in smart_ptr/detail/spinlock.hpp and see if that helps... although it might
be better to investigate why the ARM spinlock doesn't work on the iPhone. Is
your application multithreaded, or does even a simple uncontended use of
boost::detail::spinlock or boost::detail::spinlock_pool fail? (Their tests
can be found in libs/smart_ptr/test.)

[Igor R]

Thanks a lot for your answer, you pointed me in the direction I didn't
think of: __thumb__! Actually, my project was compiled with Thumb
switched on - which is default in XCode. On the other hand, boost
libraries was built with their default compiler switches for this
platform, as defined in boost.build/bjam configuration (probably,
thumb off?).
Anyway, now I switched off Thumb in my project settings, and
everything began to move as expected!

> Is your application multithreaded, or does even a simple uncontended use of boost::detail::spinlock or boost::detail::spinlock_pool fail?

My application is multithreaded, but spinlock_pool was hanging in
absolutely "uncontended" places - like in regex, which I use in 1
thread only.

I still don't understand why it behaved like this - afterall, if
thumb-enabled code doesn't support such a spinlock, it should crash,
and if it does support, it should work... But this's really less
important than the practical aspect, for the moment :) .

[Peter Dimov]

Igor R wrote:
> Thanks a lot for your answer, you pointed me in the direction I didn't
> think of: __thumb__! Actually, my project was compiled with Thumb
> switched on - which is default in XCode. On the other hand, boost
> libraries was built with their default compiler switches for this
> platform, as defined in boost.build/bjam configuration (probably,
> thumb off?).
> Anyway, now I switched off Thumb in my project settings, and
> everything began to move as expected!

Thanks for tracking this down.

>> Is your application multithreaded, or does even a simple uncontended
>> use of boost::detail::spinlock or boost::detail::spinlock_pool fail?
>
> My application is multithreaded, but spinlock_pool was hanging in
> absolutely "uncontended" places - like in regex, which I use in 1
> thread only.
>
> I still don't understand why it behaved like this - afterall, if
> thumb-enabled code doesn't support such a spinlock, it should crash,
> and if it does support, it should work...

The ARM-specific implementation is only used when __thumb__ is not defined:

#if defined(__GNUC__) && defined( __arm__ ) && !defined( __thumb__ )
# include <boost/smart_ptr/detail/spinlock_gcc_arm.hpp>

because Thumb doesn't support the swp instruction and spinlock_gcc_arm
doesn't compile. This causes an ABI mismatch when Thumb and non-Thumb files
are linked together; the inlined code is trying to lock a spinlock that
doesn't exist.

[Igor R]

> the inlined code is trying to lock a spinlock that doesn't exist.

...which should cause a crash, shouldn't it?

[Peter Dimov]

Igor R wrote:
>> the inlined code is trying to lock a spinlock that doesn't exist.
>
> ...which should cause a crash, shouldn't it?

It picks a memory location, thinking that it's a spinlock locked by another
thread, and waits for it to become "unlocked", which never happens. I guess.