[shared_ptr] hangs on iPhone
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!
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.)
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 :) .
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 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.
participants (2)
-
Igor R
-
Peter Dimov