Bug #2814
closedSegbus in shared_count, called from Wt::WResource::handle
0%
Description
(regression, from 3.3.1 to 3.3.2-rc2)
When playing a lot with custom resources (many constructs/deletes)
[2014-Mar-13 13:43:17.984912] 25589 [/ IXXx082CXT6zQwta] [error] "wthttp: WtReply::send() called while still busy sending..."
AvConvTranscoder::~AvConvTranscoder called!
Killing child!
Killing child DONE
CONSTRUCTING RESOURCE
Cover found!
192.168.1.16 - - [2014-Mar-13 13:43:17.985624] "POST /?wtd=IXXx082CXT6zQwta HTTP/1.1" 200 1093
Program received signal SIGBUS, Bus error.
[Switching to Thread 0x7fffe4ff9700 (LWP 25600)]
shared_count (r=..., this=) at /usr/include/boost/smart_ptr/detail/shared_count.hpp:382
382 if( pi_ != 0 ) pi_->add_ref_copy();
(gdb)
(gdb) bt
#0 shared_count (r=..., this=) at /usr/include/boost/smart_ptr/detail/shared_count.hpp:382
#1 shared_ptr (this=) at /usr/include/boost/smart_ptr/shared_ptr.hpp:328
#2 Wt::WResource::handle (this=0x7fffc800c8b0, webRequest=0x7fffb433eda0, webResponse=0x7fffb433eda0, continuation=continuation@entry=0x7fffc800c160)
at /storage/emeric/MesProgs/wt/wt-3.3.2-rc2/src/Wt/WResource.C:113
#3 0x00007ffff700d86d in Wt::WResource::doContinue (this=, continuation=continuation@entry=0x7fffc800c160)
at /storage/emeric/MesProgs/wt/wt-3.3.2-rc2/src/Wt/WResource.C:95
#4 0x00007ffff7161ce3 in Wt::Http::ResponseContinuation::doContinue (this=0x7fffc800c160, event=)
at /storage/emeric/MesProgs/wt/wt-3.3.2-rc2/src/Wt/Http/ResponseContinuation.C:50
#5 0x00007ffff7bb1b72 in operator() (a0=Wt::WriteCompleted, this=0x7fffe4ff8580) at /usr/include/boost/function/function_template.hpp:767
#6 http::server::WtReply::writeDone (this=0x7fffb42e8ce0, success=) at /storage/emeric/MesProgs/wt/wt-3.3.2-rc2/src/http/WtReply.C:420
#7 0x00007ffff7b73b09 in http::server::Connection::handleWriteResponse (this=0x7fffb40215d0, reply=..., e=..., bytes_transferred=)
at /storage/emeric/MesProgs/wt/wt-3.3.2-rc2/src/http/Connection.C:430
#8 0x00007ffff7bac8c4 in call<boost::shared_ptrhttp::server::TcpConnection, boost::shared_ptrhttp::server::Reply, boost::system::error_code const, unsigned long> (
b3=, b2=..., b1=..., u=..., this=0x7fffe4ff8710) at /usr/include/boost/bind/mem_fn_template.hpp:384
#9 operator()<boost::shared_ptrhttp::server::TcpConnection > (a3=, a2=..., a1=..., u=..., this=0x7fffe4ff8710) at /usr/include/boost/bind/mem_fn_template.hpp:399
#10 operator()<boost::_mfi::mf3<void, http::server::Connection, boost::shared_ptrhttp::server::Reply, const boost::system::error_code&, long unsigned int>, boost::_bi::list2<const boost::system::error_code&, long unsigned int const&> > (a=, f=..., this=0x7fffe4ff8720) at /usr/include/boost/bind/bind.hpp:457
#11 operator()<boost::system::error_code, long unsigned int> (a2=@0x7fffe4ff8750: 131081, a1=..., this=0x7fffe4ff8710) at /usr/include/boost/bind/bind_template.hpp:102
#12 operator() (this=0x7fffe4ff8710) at /usr/include/boost/asio/detail/bind_handler.hpp:127
#13 asio_handler_invoke<boost::asio::detail::binder2<boost::_bi::bind_t<void, boost::_mfi::mf3<void, http::server::Connection, boost::shared_ptrhttp::server::Reply, boost::system::error_code const&, unsigned long>, boost::_bi::list4<boost::_bi::value<boost::shared_ptrhttp::server::TcpConnection >, boost::_bi::value<boost::shared_ptrhttp::server::Reply >, boost::arg<1> ()(), boost::arg<2> ()()> >, boost::system::error_code, unsigned long> > (function=...) at /usr/include/boost/asio/handler_invoke_hook.hpp:69
#14 invoke<boost::asio::detail::binder2<boost::_bi::bind_t<void, boost::_mfi::mf3<void, http::server::Connection, boost::shared_ptrhttp::server::Reply, boost::system::error_code const&, unsigned long>, boost::_bi::list4<boost::_bi::value<boost::shared_ptrhttp::server::TcpConnection >, boost::_bi::value<boost::shared_ptrhttp::server::Reply >, boost::arg<1> ()(), boost::arg<2> ()()> >, boost::system::error_code, unsigned long>, boost::_bi::bind_t<void, boost::_mfi::mf3<void, http::server::Connection, boost::shared_ptrhttp::server::Reply, boost::system::error_code const&, unsigned long>, boost::_bi::list4<boost::_bi::value<boost::shared_ptrhttp::server::TcpConnection >, boost::_bi::value<boost::shared_ptrhttp::server::Reply >, boost::arg<1> ()(), boost::arg<2> ()()> > > (context=..., function=...) at /usr/include/boost/asio/detail/handler_invoke_helpers.hpp:37
#15 asio_handler_invoke<boost::asio::detail::binder2<boost::_bi::bind_t<void, boost::_mfi::mf3<void, http::server::Connection, boost::shared_ptrhttp::server::Reply, boost::system::error_code const&, unsigned long>, boost::_bi::list4<boost::_bi::value<boost::shared_ptrhttp::server::TcpConnection >, boost::_bi::value<boost::shared_ptrhttp::server::Reply >, boost::arg<1> ()(), boost::arg<2> ()()> >, boost::system::error_code, unsigned long>, boost::_bi::bind_t<void, boost::_mfi::mf3<void, http::server::Connection, boost::shared_ptrhttp::server::Reply, boost::system::error_code const&, unsigned long>, boost::_bi::list4<boost::_bi::value<boost::shared_ptrhttp::server::TcpConnection >, boost::_bi::value<boost::shared_ptrhttp::server::Reply >, boost::arg<1> ()(), boost::arg<2> ()()> >, boost::system::error_code, unsigned long> (this_handler=0x7fffe4ff8710, function=...)
...
Debian, using libboost-1.55
Maybe this one is related with a peviously reported one.
Updated by Koen Deforche over 10 years ago
- Status changed from New to Feedback
- Assignee set to Koen Deforche
Hey,
[2014-Mar-13 13:43:17.984912] 25589 [/ IXXx082CXT6zQwta] [error] "wthttp: WtReply::send() called while still busy sending..."
This error message is bad; is it typical for a crash or do you get this too in other situations? You shouldn't be getting there and I can't imagine how you do this?
Can you try the following patch?
diff ---git a/src/http/WtReply.C b/src/http/WtReply.C
index 1b04603..434f1fd 100644
---- a/src/http/WtReply.C
- b/src/http/WtReply.C
@@ --434,13 +434,13 @@ void WtReply::send(const Wt::WebRequest::WriteCallback& callBack,
{
LOG_DEBUG("WtReply::send(): " << sending_);
+ fetchMoreDataCallback_ = callBack;
-
if (sending_ != 0) {
LOG_ERROR("WtReply::send() called while still busy sending...");
return;
}
- fetchMoreDataCallback_ = callBack; ¶
if (status() == no_status) {
if (!transmitting() && fetchMoreDataCallback_) {
/*
Regards,
koen
Updated by Emeric Poupon over 10 years ago
Thanks, this patch solved the problem!
Please note:
- I've also applied the patch submitted for the issue 2811.
- I don't reproduce the 2811 issue too.
Updated by Emeric Poupon over 10 years ago
Koen Deforche wrote:
Hey,
> [2014-Mar-13 13:43:17.984912] 25589 [/ IXXx082CXT6zQwta] [error] "wthttp: WtReply::send() called while still busy sending..."
This error message is bad; is it typical for a crash or do you get this too in other situations? You shouldn't be getting there and I can't imagine how you do this?
>
I've never noticed it before (3.3.1)
After your patch, it still appears when I'm destructing a resource that has a continuation attached. But at least, it does not crash anymore.
Updated by Koen Deforche over 10 years ago
- Status changed from Feedback to Resolved
- Target version changed from 3.3.2 to 3.3.3
Hey,
Thanks, your last comment also made me realize the scenario involved. You don't actually need the patch in 2811 (I've reverted this).
Regards,
koen
Updated by I. Lazaridis over 10 years ago
Koen Deforche wrote:
Hey,
Thanks, your last comment also made me realize the scenario involved. You don't actually need the patch in 2811 (I've reverted this).
How can I seriously use Wt, if I'm not able to track the latest development? See #2714.
Updated by Emeric Poupon over 10 years ago
I. Lazaridis wrote:
Koen Deforche wrote:
> Hey,
>
> Thanks, your last comment also made me realize the scenario involved. You don't actually need the patch in 2811 (I've reverted this).How can I seriously use Wt, if I'm not able to track the latest development? See #2714.
Well, for me it's pretty clear this fix will be available in the targeted release, i.e. 3.3.3 ?
As far I am concerned, users should just refer to public releases, and the usage of git/svn/... is an internal matter of the dev team.
However, I would expect the dev team to refer to the bug ID in the commit message when they commit their bugfix.
Updated by Koen Deforche over 10 years ago
- Status changed from Resolved to Closed