Project

General

Profile

Actions

Bug #2814

closed

Segbus in shared_count, called from Wt::WResource::handle

Added by Emeric Poupon about 10 years ago. Updated almost 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Start date:
03/13/2014
Due date:
% Done:

0%

Estimated time:

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.

Actions #1

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

Actions #2

Updated by Emeric Poupon about 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.
Actions #3

Updated by Emeric Poupon about 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.

Actions #4

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

Actions #5

Updated by I. Lazaridis about 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.

Actions #6

Updated by Emeric Poupon about 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.

Actions #7

Updated by Koen Deforche almost 10 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF