Project

General

Profile

Actions

Bug #2989

closed

crash when destroying a resource

Added by mat Sch almost 10 years ago. Updated almost 10 years ago.

Status:
Rejected
Priority:
Urgent
Assignee:
-
Target version:
Start date:
04/24/2014
Due date:
% Done:

0%

Estimated time:

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.

Actions #1

Updated by Wim Dumon almost 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.

Actions #2

Updated by mat Sch almost 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
#2 0xb67e4657 in Wt::WApplication::notify (this=0x8e0dc18, e=
0xb19fccd4) at /home/mat/p4/hyas/main/3rdparty/wt-3.3.3.pre/src/Wt/WApplication.C:1454

#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

Actions #3

Updated by mat Sch almost 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

Actions #4

Updated by Koen Deforche almost 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

Actions #5

Updated by Koen Deforche almost 10 years ago

  • Status changed from Feedback to Rejected
Actions

Also available in: Atom PDF