example illustrating two issues

[rhaschke]

This isn't actually a PR, but a bug report. But the patch contains two example .cpp files illustrating the issues. IMHO the pluginlib doesn't work in cases where control over destruction of the ClassLoader is not possible. Typical use cases are e.g. liburdf to load urdf parsers.

issue1.cpp illustrates the use case I would expect:
In some function a ClassLoader is instantiated, some object from the lib is created and the ClassLoader is destroyed again. The destructor of ClassLoader tries to unload the lib, although the object is still in use. libclass_loader correctly notices the fact and denies unloading with a SEVERE WARNING.
IMHO, pluginlib's ClassLoader should simply use libclass_loader's ondemand_load_unload feature.

issue2.cpp illustrates actually an issue in libclass_loader:
As a work-around for issue1, people define their ClassLoader as static, thus postponing library unloading until program shutdown. However, as the order of releasing static variables is undefined, this fails, because an already freed static mutex is accessed:

issue2: /usr/include/boost/thread/pthread/recursive_mutex.hpp:110: void boost::recursive_mutex::lock(): Assertion `!pthread_mutex_lock(&m)' failed.

Program received signal SIGABRT, Aborted.
0x00007ffff6450cc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff6450cc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff64540d8 in __GI_abort () at abort.c:89
#2  0x00007ffff6449b86 in __assert_fail_base (fmt=0x7ffff659a830 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x43a53e "!pthread_mutex_lock(&m)", 
    file=file@entry=0x43a508 "/usr/include/boost/thread/pthread/recursive_mutex.hpp", line=line@entry=110, 
    function=function@entry=0x43bba0 <boost::recursive_mutex::lock()::__PRETTY_FUNCTION__> "void boost::recursive_mutex::lock()") at assert.c:92
#3  0x00007ffff6449c32 in __GI___assert_fail (assertion=0x43a53e "!pthread_mutex_lock(&m)", file=0x43a508 "/usr/include/boost/thread/pthread/recursive_mutex.hpp", line=110, 
    function=0x43bba0 <boost::recursive_mutex::lock()::__PRETTY_FUNCTION__> "void boost::recursive_mutex::lock()") at assert.c:101
#4  0x0000000000426653 in boost::recursive_mutex::lock (this=0x7ffff7dd9c20 <class_loader::class_loader_private::getLoadedLibraryVectorMutex()::m>) at /usr/include/boost/thread/pthread/recursive_mutex.hpp:110
#5  0x0000000000431fee in boost::unique_lock<boost::recursive_mutex>::lock (this=0x7fffffffcc40) at /usr/include/boost/thread/lock_types.hpp:346
#6  0x00000000004305fb in boost::unique_lock<boost::recursive_mutex>::unique_lock (this=0x7fffffffcc40, m_=...) at /usr/include/boost/thread/lock_types.hpp:124
#7  0x00007ffff7bbda58 in class_loader::class_loader_private::unloadLibrary (library_path="/homes/rhaschke/src/ros/devel/lib//libtest_plugins.so", loader=0x7abc00)
    at /homes/rhaschke/src/ros/src/ros/class_loader/src/class_loader_core.cpp:496
#8  0x00007ffff7bb93b7 in class_loader::ClassLoader::unloadLibraryInternal (this=0x7abc00, lock_plugin_ref_count=true) at /homes/rhaschke/src/ros/src/ros/class_loader/src/class_loader.cpp:99
#9  0x00007ffff7bb92c7 in class_loader::ClassLoader::unloadLibrary (this=0x7abc00) at /homes/rhaschke/src/ros/src/ros/class_loader/src/class_loader.cpp:83
#10 0x00007ffff7bc78cd in class_loader::MultiLibraryClassLoader::unloadLibrary (this=0x649a68 <test()::loader+104>, library_path="/homes/rhaschke/src/ros/devel/lib//libtest_plugins.so")
    at /homes/rhaschke/src/ros/src/ros/class_loader/src/multi_library_class_loader.cpp:94
#11 0x00007ffff7bc782f in class_loader::MultiLibraryClassLoader::shutdownAllClassLoaders (this=0x649a68 <test()::loader+104>) at /homes/rhaschke/src/ros/src/ros/class_loader/src/multi_library_class_loader.cpp:85
#12 0x00007ffff7bc745f in class_loader::MultiLibraryClassLoader::~MultiLibraryClassLoader (this=0x649a68 <test()::loader+104>, __in_chrg=<optimized out>)
    at /homes/rhaschke/src/ros/src/ros/class_loader/src/multi_library_class_loader.cpp:42
#13 0x0000000000428975 in pluginlib::ClassLoader<test_base::Fubar>::~ClassLoader (this=0x649a00 <test()::loader>, __in_chrg=<optimized out>) at /homes/rhaschke/src/ros/src/ros/pluginlib/include/pluginlib/class_loader_imp.h:80
#14 0x00007ffff6456259 in __run_exit_handlers (status=0, listp=0x7ffff67d86c8 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true) at exit.c:82
#15 0x00007ffff64562a5 in __GI_exit (status=<optimized out>) at exit.c:104
#16 0x00007ffff643becc in __libc_start_main (main=0x425858 <main(int, char**)>, argc=1, argv=0x7fffffffcf68, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffcf58) at libc-start.c:321
#17 0x00000000004254e9 in _start ()

[rhaschke]

This bug is related to libclass_loader only. Closing this issue in favor of ros/class_loader#33 and/or ros/class_loader#34.