[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
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
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