You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Olivier Langlois <Ol...@streamtheworld.com> on 2009/11/17 16:49:01 UTC
library function exception specification omitting std::bad_alloc
Hi,
My server has been terminated when a std::bad_alloc has been thrown from the ActiveMQCPP library and because this exception is not listed anywhere where the exception specification is used by the library methods declaration.
I am questioning whether or not omitting std::bad_alloc from the exception specification is the good thing to do.
We all agree that if this exception is happening it is an indication that there is a memory leak somewhere. However, by letting this exception pass, that would allow the library user to terminate nicely. In my context, that means closing all my network connections to clients of my service and updating the access log files. This information is crucial and everytime the server aborts the business loses money. That would also be inacceptable in a life critical software.
For these reasons, I would suggest you to consider adding std::bad_alloc in all the library exception specifications.
Olivier Langlois
C++ Technical Lead
STREAMTHEWORLD
t. 1 866 448 4037 ext. 675
t. 1 514 448 4037 ext. 675
f. 1 514 807 1861
olivier.langlois@streamtheworld.com
streamtheworld.com
StreamTheWorld launches its new BlackBerry application. Learn more
RE: library function exception specification omitting
std::bad_alloc
Posted by Timothy Bish <ta...@gmail.com>.
On Tue, 2009-11-17 at 11:13 -0500, Olivier Langlois wrote:
> Before you tell me, yes I know, I am still using a very old version but I just checked your trunk and the problem is still present.
>
> In void decaf::io::ByteArrayOutputStream::write( const unsigned char* buffer,
> std::size_t offset,
> std::size_t len )
>
> std::bad_alloc can occur.
>
> BTW, I see an optimization opportunity in that function:
>
> std::back_insert_iterator< std::vector<unsigned char> > iter( *activeBuffer );
> std::copy( buffer + offset, buffer + offset + len, iter );
>
> Which calls many times push_back() should be replaced with
>
> activeBuffer->insert( activeBuffer->end(),buffer + offset, buffer + offset + len );
>
> #0 0x007057a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
> #1 0x00746815 in raise () from /lib/tls/libc.so.6
> #2 0x00748279 in abort () from /lib/tls/libc.so.6
> #3 0x0064a1bb in __gnu_cxx::__verbose_terminate_handler () from /usr/lib/libstdc++.so.6
> #4 0x00647ed1 in __cxa_call_unexpected () from /usr/lib/libstdc++.so.6
> #5 0x00647f06 in std::terminate () from /usr/lib/libstdc++.so.6
> #6 0x00647f1b in std::terminate () from /usr/lib/libstdc++.so.6
> #7 0x00647e13 in __cxa_call_unexpected () from /usr/lib/libstdc++.so.6
> #8 0x00217bf9 in activemq::io::ByteArrayOutputStream::write () from /usr/lib/libactivemq-cpp-2.1.3.so.0
> #9 0x00214616 in activemq::io::DataOutputStream::write () from /usr/lib/libactivemq-cpp-2.1.3.so.0
> #10 0x00364f28 in activemq::connector::openwire::marshal::v2::MessageMarshaller::looseMarshal ()
> from /usr/lib/libactivemq-cpp-2.1.3.so.0
> #11 0x0033da18 in activemq::connector::openwire::marshal::v2::ActiveMQTextMessageMarshaller::looseMarshal ()
> from /usr/lib/libactivemq-cpp-2.1.3.so.0
> #12 0x0025ea10 in activemq::connector::openwire::OpenWireFormat::marshal ()
> from /usr/lib/libactivemq-cpp-2.1.3.so.0
> #13 0x00262005 in activemq::connector::openwire::OpenWireCommandWriter::writeCommand ()
> from /usr/lib/libactivemq-cpp-2.1.3.so.0
> #14 0x0028b595 in activemq::transport::IOTransport::oneway () from /usr/lib/libactivemq-cpp-2.1.3.so.0
> #15 0x0028a8e0 in activemq::transport::TransportFilter::oneway () from /usr/lib/libactivemq-cpp-2.1.3.so.0
> #16 0x00290705 in activemq::transport::filters::ResponseCorrelator::request ()
> from /usr/lib/libactivemq-cpp-2.1.3.so.0
> #17 0x00262cb1 in activemq::connector::openwire::OpenWireFormatNegotiator::request ()
> ---Type <return> to continue, or q <return> to quit---
> from /usr/lib/libactivemq-cpp-2.1.3.so.0
> #18 0x00269af2 in activemq::connector::openwire::OpenWireConnector::syncRequest ()
> from /usr/lib/libactivemq-cpp-2.1.3.so.0
> #19 0x0026b526 in activemq::connector::openwire::OpenWireConnector::send ()
> from /usr/lib/libactivemq-cpp-2.1.3.so.0
> #20 0x001f3a7f in activemq::core::ActiveMQSession::send () from /usr/lib/libactivemq-cpp-2.1.3.so.0
> #21 0x002010f9 in activemq::core::ActiveMQProducer::send () from /usr/lib/libactivemq-cpp-2.1.3.so.0
> #22 0x00200efc in activemq::core::ActiveMQProducer::send () from /usr/lib/libactivemq-cpp-2.1.3.so.0
> #23 0x00200c22 in activemq::core::ActiveMQProducer::send () from /usr/lib/libactivemq-cpp-2.1.3.so.0
> #24 0x081a3295 in STW::ActiveMQTxtMsgProducer::sendMsg (this=0xf65502d0, txtmsg=@0xf537074c,
> attrsmsg=0xf5370750, brokerCfg=@0xf65502c0)
> at /usr/lib/gcc/i386-redhat-linux/3.4.6/../../../../include/c++/3.4.6/memory:285
> #25 0x080f7189 in MG::RealTime::AccessLogService::Run (this=0x8377520) at Message.h:287
> #26 0x08184129 in STW::CRunnable::start_routine (this=0x8377520) at ../../STW/runnable.cpp:29
> #27 0x081b3051 in (anonymous namespace)::_start_routine (arg=0x93d3bd0) at ../../thread/thread.cpp:132
> #28 0x08203236 in ACE_Thread_Adapter::invoke_i ()
> #29 0x082031b5 in ACE_Thread_Adapter::invoke ()
> #30 0x0090f3cc in start_thread () from /lib/tls/libpthread.so.0
> #31 0x007e81ae in clone () from /lib/tls/libc.so.6
> (gdb)
>
> Olivier Langlois | STREAMTHEWORLD | t. 514 448 4037 ext. 675
>
> StreamTheWorld launches its new BlackBerry application. Learn more
>
>
> -----Original Message-----
> From: Timothy Bish [mailto:tabish121@gmail.com]
> Sent: Tuesday, November 17, 2009 10:56 AM
> To: dev@activemq.apache.org
> Subject: Re: library function exception specification omitting std::bad_alloc
>
> On Tue, 2009-11-17 at 10:49 -0500, Olivier Langlois wrote:
> > Hi,
> >
> > My server has been terminated when a std::bad_alloc has been thrown from the ActiveMQCPP library and because this exception is not listed anywhere where the exception specification is used by the library methods declaration.
> >
> > I am questioning whether or not omitting std::bad_alloc from the exception specification is the good thing to do.
> >
> > We all agree that if this exception is happening it is an indication that there is a memory leak somewhere. However, by letting this exception pass, that would allow the library user to terminate nicely. In my context, that means closing all my network connections to clients of my service and updating the access log files. This information is crucial and everytime the server aborts the business loses money. That would also be inacceptable in a life critical software.
> >
> > For these reasons, I would suggest you to consider adding std::bad_alloc in all the library exception specifications.
> >
> > Olivier Langlois
> > C++ Technical Lead
> >
> > STREAMTHEWORLD
> >
> > t. 1 866 448 4037 ext. 675
> > t. 1 514 448 4037 ext. 675
> > f. 1 514 807 1861
> >
> > olivier.langlois@streamtheworld.com
> > streamtheworld.com
> >
> > StreamTheWorld launches its new BlackBerry application. Learn more
> >
> >
>
> Do you have a stack trace showing which API call is allowing the
> exception to be thrown?
>
> Regards
> Tim
>
>
Happy to address the issue, would you mind opening a new Jira issue to
document the problem and attach any patches you might wish to provide?
Regards
Tim.
--
Tim Bish
http://fusesource.com
http://timbish.blogspot.com/
RE: library function exception specification omitting std::bad_alloc
Posted by Olivier Langlois <Ol...@streamtheworld.com>.
Before you tell me, yes I know, I am still using a very old version but I just checked your trunk and the problem is still present.
In void decaf::io::ByteArrayOutputStream::write( const unsigned char* buffer,
std::size_t offset,
std::size_t len )
std::bad_alloc can occur.
BTW, I see an optimization opportunity in that function:
std::back_insert_iterator< std::vector<unsigned char> > iter( *activeBuffer );
std::copy( buffer + offset, buffer + offset + len, iter );
Which calls many times push_back() should be replaced with
activeBuffer->insert( activeBuffer->end(),buffer + offset, buffer + offset + len );
#0 0x007057a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x00746815 in raise () from /lib/tls/libc.so.6
#2 0x00748279 in abort () from /lib/tls/libc.so.6
#3 0x0064a1bb in __gnu_cxx::__verbose_terminate_handler () from /usr/lib/libstdc++.so.6
#4 0x00647ed1 in __cxa_call_unexpected () from /usr/lib/libstdc++.so.6
#5 0x00647f06 in std::terminate () from /usr/lib/libstdc++.so.6
#6 0x00647f1b in std::terminate () from /usr/lib/libstdc++.so.6
#7 0x00647e13 in __cxa_call_unexpected () from /usr/lib/libstdc++.so.6
#8 0x00217bf9 in activemq::io::ByteArrayOutputStream::write () from /usr/lib/libactivemq-cpp-2.1.3.so.0
#9 0x00214616 in activemq::io::DataOutputStream::write () from /usr/lib/libactivemq-cpp-2.1.3.so.0
#10 0x00364f28 in activemq::connector::openwire::marshal::v2::MessageMarshaller::looseMarshal ()
from /usr/lib/libactivemq-cpp-2.1.3.so.0
#11 0x0033da18 in activemq::connector::openwire::marshal::v2::ActiveMQTextMessageMarshaller::looseMarshal ()
from /usr/lib/libactivemq-cpp-2.1.3.so.0
#12 0x0025ea10 in activemq::connector::openwire::OpenWireFormat::marshal ()
from /usr/lib/libactivemq-cpp-2.1.3.so.0
#13 0x00262005 in activemq::connector::openwire::OpenWireCommandWriter::writeCommand ()
from /usr/lib/libactivemq-cpp-2.1.3.so.0
#14 0x0028b595 in activemq::transport::IOTransport::oneway () from /usr/lib/libactivemq-cpp-2.1.3.so.0
#15 0x0028a8e0 in activemq::transport::TransportFilter::oneway () from /usr/lib/libactivemq-cpp-2.1.3.so.0
#16 0x00290705 in activemq::transport::filters::ResponseCorrelator::request ()
from /usr/lib/libactivemq-cpp-2.1.3.so.0
#17 0x00262cb1 in activemq::connector::openwire::OpenWireFormatNegotiator::request ()
---Type <return> to continue, or q <return> to quit---
from /usr/lib/libactivemq-cpp-2.1.3.so.0
#18 0x00269af2 in activemq::connector::openwire::OpenWireConnector::syncRequest ()
from /usr/lib/libactivemq-cpp-2.1.3.so.0
#19 0x0026b526 in activemq::connector::openwire::OpenWireConnector::send ()
from /usr/lib/libactivemq-cpp-2.1.3.so.0
#20 0x001f3a7f in activemq::core::ActiveMQSession::send () from /usr/lib/libactivemq-cpp-2.1.3.so.0
#21 0x002010f9 in activemq::core::ActiveMQProducer::send () from /usr/lib/libactivemq-cpp-2.1.3.so.0
#22 0x00200efc in activemq::core::ActiveMQProducer::send () from /usr/lib/libactivemq-cpp-2.1.3.so.0
#23 0x00200c22 in activemq::core::ActiveMQProducer::send () from /usr/lib/libactivemq-cpp-2.1.3.so.0
#24 0x081a3295 in STW::ActiveMQTxtMsgProducer::sendMsg (this=0xf65502d0, txtmsg=@0xf537074c,
attrsmsg=0xf5370750, brokerCfg=@0xf65502c0)
at /usr/lib/gcc/i386-redhat-linux/3.4.6/../../../../include/c++/3.4.6/memory:285
#25 0x080f7189 in MG::RealTime::AccessLogService::Run (this=0x8377520) at Message.h:287
#26 0x08184129 in STW::CRunnable::start_routine (this=0x8377520) at ../../STW/runnable.cpp:29
#27 0x081b3051 in (anonymous namespace)::_start_routine (arg=0x93d3bd0) at ../../thread/thread.cpp:132
#28 0x08203236 in ACE_Thread_Adapter::invoke_i ()
#29 0x082031b5 in ACE_Thread_Adapter::invoke ()
#30 0x0090f3cc in start_thread () from /lib/tls/libpthread.so.0
#31 0x007e81ae in clone () from /lib/tls/libc.so.6
(gdb)
Olivier Langlois | STREAMTHEWORLD | t. 514 448 4037 ext. 675
StreamTheWorld launches its new BlackBerry application. Learn more
-----Original Message-----
From: Timothy Bish [mailto:tabish121@gmail.com]
Sent: Tuesday, November 17, 2009 10:56 AM
To: dev@activemq.apache.org
Subject: Re: library function exception specification omitting std::bad_alloc
On Tue, 2009-11-17 at 10:49 -0500, Olivier Langlois wrote:
> Hi,
>
> My server has been terminated when a std::bad_alloc has been thrown from the ActiveMQCPP library and because this exception is not listed anywhere where the exception specification is used by the library methods declaration.
>
> I am questioning whether or not omitting std::bad_alloc from the exception specification is the good thing to do.
>
> We all agree that if this exception is happening it is an indication that there is a memory leak somewhere. However, by letting this exception pass, that would allow the library user to terminate nicely. In my context, that means closing all my network connections to clients of my service and updating the access log files. This information is crucial and everytime the server aborts the business loses money. That would also be inacceptable in a life critical software.
>
> For these reasons, I would suggest you to consider adding std::bad_alloc in all the library exception specifications.
>
> Olivier Langlois
> C++ Technical Lead
>
> STREAMTHEWORLD
>
> t. 1 866 448 4037 ext. 675
> t. 1 514 448 4037 ext. 675
> f. 1 514 807 1861
>
> olivier.langlois@streamtheworld.com
> streamtheworld.com
>
> StreamTheWorld launches its new BlackBerry application. Learn more
>
>
Do you have a stack trace showing which API call is allowing the
exception to be thrown?
Regards
Tim
--
Tim Bish
http://fusesource.com
http://timbish.blogspot.com/
Re: library function exception specification omitting
std::bad_alloc
Posted by Timothy Bish <ta...@gmail.com>.
On Tue, 2009-11-17 at 10:49 -0500, Olivier Langlois wrote:
> Hi,
>
> My server has been terminated when a std::bad_alloc has been thrown from the ActiveMQCPP library and because this exception is not listed anywhere where the exception specification is used by the library methods declaration.
>
> I am questioning whether or not omitting std::bad_alloc from the exception specification is the good thing to do.
>
> We all agree that if this exception is happening it is an indication that there is a memory leak somewhere. However, by letting this exception pass, that would allow the library user to terminate nicely. In my context, that means closing all my network connections to clients of my service and updating the access log files. This information is crucial and everytime the server aborts the business loses money. That would also be inacceptable in a life critical software.
>
> For these reasons, I would suggest you to consider adding std::bad_alloc in all the library exception specifications.
>
> Olivier Langlois
> C++ Technical Lead
>
> STREAMTHEWORLD
>
> t. 1 866 448 4037 ext. 675
> t. 1 514 448 4037 ext. 675
> f. 1 514 807 1861
>
> olivier.langlois@streamtheworld.com
> streamtheworld.com
>
> StreamTheWorld launches its new BlackBerry application. Learn more
>
>
Do you have a stack trace showing which API call is allowing the
exception to be thrown?
Regards
Tim
--
Tim Bish
http://fusesource.com
http://timbish.blogspot.com/