Bug #2989
closedcrash when destroying a resource
0%
Description
Occasionally when a WResource is in the processes of getting destroyed and handling a request I will get either an abort from a mutex operation or a segfault pointing to an action on an invalid mutex. I've debugged this as far as seeing that WResource.C is always unlocking the mutex in WResource.C::handle(). That unlocking of the mutex code looks suspicious because the object could be deleted while the method is still executing.
Updated by Wim Dumon over 10 years ago
- Status changed from New to Feedback
Hi Mat,
We've fixed a bug with this in git, are you using 3.3.2 release or the current git version?
BR,
Wim.
Updated by mat Sch over 10 years ago
Hello Wim,
Same problem using 3.3.2 and latest from today. This is the sequence of events that cause the crash.
*Create Resource
*Browser requests Resource
*Resource gets destroyed
*Request for resource gets handled in a WResource with destroyed memory
Not sure if it matters, but 'haveMoreData' was called on the resource many times before an actual request came in.
For what it's worth the backtrace is below. The memory pointed to at the time of the backtrace is no longer valid.
Thanks,
-mat
Wt::WResource::handle (this=0x8df6260, webRequest=0xa9c064e8, webResponse=0xa9c064e8, continuation=0x0) at /usr/local/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:66
66 /usr/local/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp: No such file or directory.
in /usr/local/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp
(gdb)
(gdb)
(gdb)
(gdb)
(gdb) bt
#0 Wt::WResource::handle (this=0x8df6260, webRequest=0xa9c064e8, webResponse=0xa9c064e8, continuation=0x0) at /usr/local/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:66
#1 0xb6bad007 in Wt::WebSession::notify (this=0x8dafdb0, event=0xb19fccd4) at /home/mat/p4/hyas/main/3rdparty/wt-3.3.3.pre/src/web/WebSession.C:2104
0xb19fccd4) at /home/mat/p4/hyas/main/3rdparty/wt-3.3.3.pre/src/Wt/WApplication.C:1454
#2 0xb67e4657 in Wt::WApplication::notify (this=0x8e0dc18, e=
#3 0xb6ba1a5d in Wt::WebSession::handleRequest (this=0x8dafdb0, handler=@0xb19ff0a0) at /home/mat/p4/hyas/main/3rdparty/wt-3.3.3.pre/src/web/WebSession.C:1530
#4 0xb6b9092d in Wt::WebController::handleRequest (this=0x8dac860, request=0xa9c064e8) at /home/mat/p4/hyas/main/3rdparty/wt-3.3.3.pre/src/web/WebController.C:689
warning: (Internal error: pc 0xb658cc4f in read in psymtab, but not in symtab.)
#5 0xb658cc50 in boost::asio::detail::completion_handler<boost::_bi::bind_t<void, boost::_mfi::mf1<void, Wt::WebController, Wt::WebRequest*, boost::_bi::list2<boost::_bi::value<Wt::WebController*>, boost::_bi::value<http::server::HTTPRequest*> > > >::do_complete (owner=warning: (Internal error: pc 0xb658cbe0 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0xb658cc4f in read in psymtab, but not in symtab.)
0x8dadf18, base=0xa9c06568) at /usr/local/include/boost/bind/mem_fn_template.hpp:165
#6 0xb68d2966 in boost::asio::detail::task_io_service::run (this=0x8dadf18, ec=@0xb19ff34c) at /usr/local/include/boost/asio/detail/task_io_service_operation.hpp:37
#7 0xb68cc0e6 in Wt::WIOService::run (this=0x8dac828) at /usr/local/include/boost/asio/impl/io_service.ipp:59
#8 0xb68ccc95 in boost::detail::thread_data<boost::_bi::bind_t<void, boost::_mfi::mf0<void, Wt::WIOService>, boost::_bi::list1<boost::_bi::value<Wt::WIOService*> > > >::run (this=0x8090501)
at /usr/local/include/boost/bind/mem_fn_template.hpp:49
#9 0xb7718506 in thread_proxy () from /usr/lib/libboost_thread.so.1.49.0
#10 0xb4505f3b in start_thread () from /lib/libpthread.so.0
#11 0xb4366bee in clone () from /lib/libc.so.6
Updated by mat Sch over 10 years ago
I believe I see what's happening. My app is destroying the WResource in a thread other then the creation thread when a Boost shared pointer goes out of scope. The app->instance() is returning 0 and removeExposedResouce is not getting called.
I would say this isn't a wt bug, although i'm a bit confused over thread local storage. Any way to cheat this?
Thanks,
-mat
Updated by Koen Deforche over 10 years ago
Hey,
You need to make sure you have the update lock before you can that resource, anything else is prone to a race condition. The update-lock sets the thread local storage correctly so that WApplication::instance() works.
Regards,
koen
Updated by Koen Deforche over 10 years ago
- Status changed from Feedback to Rejected