Skip to content

custom poco events reaching deadlock #62

Closed
Closed
custom poco events reaching deadlock#62

Description

@bakercp
bakercp
opened on Dec 4, 2012

Whenever a custom event is added, we are getting a deadlock. This is affecting a lot of the examples on the raspberry pi. This was tested and failed with Poco 1.4.4 and 1.4.5.

I believe this is happening in Poco, because Poco's own tests won't release when using mutexes.

A little more research is needed on this.

(gdb) backtrace
#0  0x4083c258 in __lll_lock_wait () from /lib/arm-linux-gnueabihf/libpthread.so.0
#1  0x40836cac in pthread_mutex_lock () from /lib/arm-linux-gnueabihf/libpthread.so.0
#2  0x0001b3b0 in Poco::MutexImpl::lockImpl (this=0x249ac0) at ../../../libs/poco/include/Poco/Mutex_POSIX.h:81
#3  0x0001b600 in Poco::FastMutex::lock (this=0x249ac0) at ../../../libs/poco/include/Poco/Mutex.h:259
#4  0x0001bf58 in Poco::ScopedLock<Poco::FastMutex>::ScopedLock (this=0xbefff3e0, mutex=...) at ../../../libs/poco/include/Poco/ScopedLock.h:60
#5  0x0001b650 in Poco::AtomicCounter::operator++ (this=0x249ac0) at ../../../libs/poco/include/Poco/AtomicCounter.h:318
#6  0x0001b728 in Poco::ReferenceCounter::duplicate (this=0x249ac0) at ../../../libs/poco/include/Poco/SharedPtr.h:62
#7  0x0002063c in Poco::SharedPtr<Poco::AbstractDelegate<float>, Poco::ReferenceCounter, Poco::ReleasePolicy<Poco::AbstractDelegate<float> > >::SharedPtr (
    this=0x249ae0, ptr=...) at ../../../libs/poco/include/Poco/SharedPtr.h:154
#8  0x0001f374 in __gnu_cxx::new_allocator<Poco::SharedPtr<Poco::AbstractDelegate<float>, Poco::ReferenceCounter, Poco::ReleasePolicy<Poco::AbstractDelegate<float> > > >::construct (this=0x2496d4, __p=0x249ae0, __val=...) at /usr/include/c++/4.6/ext/new_allocator.h:108
#9  0x0001f50c in std::vector<Poco::SharedPtr<Poco::AbstractDelegate<float>, Poco::ReferenceCounter, Poco::ReleasePolicy<Poco::AbstractDelegate<float> > >, std::allocator<Poco::SharedPtr<Poco::AbstractDelegate<float>, Poco::ReferenceCounter, Poco::ReleasePolicy<Poco::AbstractDelegate<float> > > > >::_M_insert_aux (this=0x2496d4, __position=..., __x=...) at /usr/include/c++/4.6/bits/vector.tcc:335
#10 0x0001e36c in std::vector<Poco::SharedPtr<Poco::AbstractDelegate<float>, Poco::ReferenceCounter, Poco::ReleasePolicy<Poco::AbstractDelegate<float> > >, std::allocator<Poco::SharedPtr<Poco::AbstractDelegate<float>, Poco::ReferenceCounter, Poco::ReleasePolicy<Poco::AbstractDelegate<float> > > > >::push_back (
    this=0x2496d4, __x=...) at /usr/include/c++/4.6/bits/stl_vector.h:834
#11 0x0001d470 in Poco::DefaultStrategy<float, Poco::AbstractDelegate<float> >::add (this=0x2496d0, delegate=...)
    at ../../../libs/poco/include/Poco/DefaultStrategy.h:88
#12 0x0001c838 in Poco::AbstractEvent<float, Poco::FIFOStrategy<float, Poco::AbstractDelegate<float> >, Poco::AbstractDelegate<float>, Poco::FastMutex>::operator+= (this=0x2496c0, aDelegate=...) at ../../../libs/poco/include/Poco/AbstractEvent.h:197
#13 0x0001b0d4 in ofAddListener<ofEvent<float>, float, testApp> (event=..., listener=0x2496b0, listenerMethod=
    (void (testApp::*)(testApp * const, float &)) 0x1ac04 <testApp::newFloat(float&)>) at ../../../libs/openFrameworks/events/ofEventUtils.h:61
#14 0x0001aa74 in testApp::setup (this=0x2496b0) at src/testApp.cpp:10
#15 0x0003d3d8 in ofNotifySetup () at ../../..//libs/openFrameworks/events/ofEvents.cpp:77
#16 0x000c2a00 in ofAppEGLWindow::runAppViaInfiniteLoop (this=0x23bb20, appPtr=0x2496b0) at ../../..//libs/openFrameworks/app/ofAppEGLWindow.cpp:471
#17 0x0003abd0 in ofRunApp (OFSA=0x2496b0) at ../../..//libs/openFrameworks/app/ofAppRunner.cpp:84
#18 0x000236a4 in main () at src/main.cpp:12

Activity

  1. bakercp commented on Dec 4, 2012

    @bakercp
    bakercp
    on Dec 4, 2012
    MemberAuthor

    I believe that the above happens when we attempt to call an ofAddListener within a function that was called via the Poco system (i.e. inside setup).

    The following happens when we try to create call ofAddListener inside of another function (in this case, it was called during the first call to update():

    (gdb) r
Starting program: /home/pi/openFrameworks/examples/events/advancedEventsExample/bin/advancedEventsExample_debug 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
ofAppEGLWindow constructor 
in ofAppEGLWINDOW: setupOpenGL
[New Thread 0x41a13310 (LWP 2939)]
[New Thread 0x42213310 (LWP 2940)]
[New Thread 0x42a13310 (LWP 2941)]
[New Thread 0x43213310 (LWP 2942)]
succes=0
   REQUESTED SCREEN SIZE w=1024 and  h=768
HARDWARE SCREEN SIZE IS sw=1360 and sh=768
CREATING A SCREEN THAT IS w=1024 and h=768
[ofAppEGLWindow::setupEGL:notice] setting EGL Display
[ofAppEGLWindow::setupEGL:notice] setting default Display
[ofAppEGLWindow::setupEGL:notice] EGL Display correctly set
[ofAppEGLWindow::setupEGL:notice] eglInitialize
[ofAppEGLWindow::setupEGL:notice] No current render selected.
[ofAppEGLWindow::setupEGL:notice] Default Renderer detected.
[ofAppEGLWindow::setupEGL:notice] eglChooseConfig
[ofAppEGLWindow::setupEGL:notice] eglCreateWindowSurface
[ofAppEGLWindow::setupEGL:notice] eglCreateContext
[ofAppEGLWindow::setupEGL:notice] eglMakeCurrent
EGL_VERSION = (null)
GL_RENDERER = VideoCore IV HW
GL_VERSION  = OpenGL ES-CM 1.1
GL_VENDOR   = Broadcom
CREATED SCREEN WITH SIZE 1024 x 768
[New Thread 0x43a13310 (LWP 2943)]
terminate called after throwing an instance of 'Poco::SystemException'
  what():  System exception

Program received signal SIGABRT, Aborted.
0x40879bfc in raise () from /lib/arm-linux-gnueabihf/libc.so.6
(gdb) backtrace
#0  0x40879bfc in raise () from /lib/arm-linux-gnueabihf/libc.so.6
#1  0x4087d97c in abort () from /lib/arm-linux-gnueabihf/libc.so.6
#2  0x406e3cfc in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#3  0x406e3cfc in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

    So, it seems that there is some odd thread stuff going on with poco. @arturoc could you take a look at this and see if you have any next steps for debugging? Once I exhaust our combined brain power, I'll take it over to the poco forums.

  2. bakercp commented on Dec 4, 2012

    @bakercp
    bakercp
    on Dec 4, 2012
    MemberAuthor

    This is resolved using debian repo poco libs (1.3) and should be resolved using @arturoc's recompiled 1.4.3p1 libs.

  3. bakercp commented on Dec 4, 2012

    @bakercp
    bakercp
    on Dec 4, 2012
    MemberAuthor

    fixed with #63

  4. bakercp
    closed this as completedon Dec 4, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions