Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

clang LTO (with -O4) triggers boost lock::error #851

Closed
artemp opened this Issue · 6 comments

2 participants

@artemp
Owner

If current HEAD (r3207) is built with link time optimization using clang:

$ clang --version
clang version 3.0 (trunk 138729)
Target: x86_64-apple-darwin10.8.0
Thread model: posix

Then immediately upon import of the python bindings boost throws with a lock error during image reader registration:

d:clang-lto dane$ python
Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import mapnik2
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::lock_error> >'
  what():  boost::lock_error
Abort trap

The backtrace looks like:


0   libSystem.B.dylib               0x00007fff8303c0b6 __kill + 10
1   libSystem.B.dylib               0x00007fff830dc9f6 abort + 83
2   libstdc++.6.dylib               0x00007fff890ed5d2 __tcf_0 + 0
3   libobjc.A.dylib                 0x00007fff85a02b4d _objc_terminate + 120
4   libstdc++.6.dylib               0x00007fff890ebae1 __cxxabiv1::__terminate(void (*)()) + 11
5   libstdc++.6.dylib               0x00007fff890ebb16 __cxxabiv1::__unexpected(void (*)()) + 0
6   libstdc++.6.dylib               0x00007fff890ebbfc __gxx_exception_cleanup(_Unwind_Reason_Code, _Unwind_Exception*) + 0
7   _mapnik2.so                     0x0000000101037fe3 void boost::throw_exception<boost::lock_error>(boost::lock_error const&) + 131
8   _mapnik2.so                     0x0000000101037f4c boost::unique_lock<boost::mutex>::lock() + 108
9   libmapnik2.dylib                0x0000000101824aff mapnik::singleton<mapnik::factory<mapnik::image_reader, std::string, mapnik::image_reader* (*)(std::string const&), mapnik::default_factory_error>, mapnik::CreateStatic>::instance() + 47
10  libmapnik2.dylib                0x000000010194d9af _GLOBAL__I_a2859 + 31
11  dyld                            0x00007fff5fc0d500 ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 228
12  dyld                            0x00007fff5fc0bcec ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int) + 236
13  dyld                            0x00007fff5fc0bc9d ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int) + 157
14  dyld                            0x00007fff5fc0bda6 ImageLoader::runInitializers(ImageLoader::LinkContext const&) + 58
15  dyld                            0x00007fff5fc08fbb dlopen + 573
16  libSystem.B.dylib               0x00007fff82ff3e40 dlopen + 61
17  org.python.python               0x00000001000abbe5 _PyImport_GetDynLoadFunc + 327
18  org.python.python               0x000000010009bcee _PyImport_LoadDynamicModule + 112
19  org.python.python               0x000000010009aaf8 PyImport_ReloadModule + 1347
20  org.python.python               0x000000010009af78 PyImport_ReloadModule + 2499
21  org.python.python               0x000000010009b56a PyImport_ImportModuleLevel + 1217
22  org.python.python               0x00000001000839cb _PyBuiltin_Init + 14264
23  org.python.python               0x000000010000aff3 PyObject_Call + 112
@artemp
Owner

[springmeyer] commenting the lock avoids the lock error (of course):

Index: include/mapnik/utils.hpp
===================================================================
--- include/mapnik/utils.hpp    (revision 3206)
+++ include/mapnik/utils.hpp    (working copy)
@@ -137,7 +137,7 @@
         if (!pInstance_)
         {
 #ifdef MAPNIK_THREADSAFE
-            mutex::scoped_lock lock(mutex_);
+            //mutex::scoped_lock lock(mutex_);
 #endif                        
             if (!pInstance_)
             {
@springmeyer
Owner

hit this again via node:


(gdb) bt
#0  0x00007fff92f1ace2 in __pthread_kill ()
#1  0x00007fff8d2147d2 in pthread_kill ()
#2  0x00007fff8d205a7a in abort ()
#3  0x00007fff91f817bc in abort_message ()
#4  0x00007fff91f7efcf in default_terminate ()
#5  0x00007fff8964b1cd in _objc_terminate ()
#6  0x00007fff91f7f001 in safe_handler_caller ()
#7  0x00007fff91f7f05c in std::terminate ()
#8  0x00007fff91f80152 in __cxa_throw ()
#9  0x0000000126501b53 in boost::throw_exception<boost::lock_error> ()
#10 0x00007fff5fc0fa66 in __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE ()
#11 0x00007fff5fc0d258 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE ()
#12 0x00007fff5fc0d1f1 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE ()
#13 0x00007fff5fc0e02b in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextERNS_21InitializerTimingListE ()
#14 0x00007fff5fc03189 in __dyld__ZN4dyld15runInitializersEP11ImageLoader ()
#15 0x00007fff5fc095cb in __dyld_dlopen ()
#16 0x00007fff937ff95b in dlopen ()
#17 0x0000000100002890 in node::DLOpen (args=@0x7fff5fbfeb50) at node.cc:1589
#18 0x000000010006b1df in v8::internal::Builtin_HandleApiCall () at node_crypto.h:122
Previous frame inner to this frame (gdb could not unwind past this frame)
@springmeyer
Owner

Cool, same one line patch to comment out that lock fixes it again - in this different scenario when calling from nodejs not python and with a much newer clang:


$ /opt/llvm/bin/clang++ -v
clang version 3.1 (trunk 143859)
Target: x86_64-apple-darwin11.2.0
Thread model: posix
@springmeyer
Owner

@artemp - any hunch whether this is a bug in clang, the lto linker, or mapnik?

To replicate simply use clang from trunk, set your DYLD_LIBRARY_PATH to the install prefix where you installed clang (so that the apple system linker (which should support LTO) can find libLTO) and then build mapnik with OPTIMIZATION=4

@springmeyer
Owner

no longer seeing this (at least with clang and lto) using the new -flto flag. So: closing. Going to consider the instance from node.js a fluke unless it re-appears. Tracking new clang lto bug at #2232

@springmeyer
Owner

actually closing, tracking remaining clang++/flto issues at #2339

@springmeyer springmeyer closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.