[
https://issues.apache.org/jira/browse/AMQCPP-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987740#action_12987740
]
Timothy Bish commented on AMQCPP-294:
-------------------------------------
Great thanks for taking the time to look into it. I think I have some idea why
this would be an issue depending on how apple has implemented the detach.
I've always questioned the detach method there but without it you end up with a
memory leak on most linux distros (at least valgrind reports it as a leak).
The join is from the main threads in the tests etc waiting on the child threads
to terminate before calling the Thread objects destructor as that would pull
the rug out from under the running thread worker method. Apparently in the
Apple world the pthread_detch makes the pthread_t handle itself invalid, or at
least that's what I'd guess right now.
I will have to look into this when I have a bit more time to see what the right
thing to do here is. I'd be curious to see if valgrind reports a leak on Mac
with this change. Care to give it a try?
> RemoveInfo Segmentation Fault
> -----------------------------
>
> Key: AMQCPP-294
> URL: https://issues.apache.org/jira/browse/AMQCPP-294
> Project: ActiveMQ C++ Client
> Issue Type: Bug
> Affects Versions: 3.1.2
> Environment: Mac OS/X 10.5
> Reporter: Steve Pietrowicz
> Assignee: Timothy Bish
> Priority: Critical
>
> We're running a pretty complex software stack that uses ActiveMQCPP 3.1.2 on
> Mac OS/X 10.5, and seeing the following when we run tests against a remote
> broker (version 5.3.2). The same tests run property under Linux. It
> appears this is occurring because the broker isn't responding promptly, but
> it's hard for me to tell. Tests done locally (under Linux) to the same
> broker pass without error.
> No valid response received for command: Begin Class = RemoveInfo
> Value of RemoveInfo::ID_REMOVEINFO = 12
> Value of ObjectId is Below:
> Begin Class = ConnectionId
> Value of ConnectionId::ID_CONNECTIONID = 120
> Value of Value = 704fedd0-1e65-2300-3503-bb2230cd0086
> No Data for Class BaseDataStructure
> End Class = ConnectionId
> Value of LastDeliveredSequenceId = 0
> Begin Class = BaseCommand
> No Data for Class BaseDataStructure
> Response Required = 1
> Command Id = 6
> End Class = BaseCommand
> End Class = RemoveInfo
> , check broker.
> FILE: activemq/transport/correlator/ResponseCorrelator.cpp, LINE: 168
> FILE: activemq/transport/correlator/ResponseCorrelator.cpp, LINE: 176
> FILE: activemq/core/ActiveMQConnection.cpp, LINE: 629
> FILE: activemq/core/ActiveMQConnection.cpp, LINE: 348
> FILE: activemq/core/ActiveMQConnection.cpp, LINE: 255
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0xb0185048
> [Switching to process 6402 thread 0x11b]
> 0x9148dc7f in pthread_mutex_lock ()
> (gdb) bt
> #0 0x9148dc7f in pthread_mutex_lock ()
> #1 0x9148eb90 in _keymgr_get_and_lock_processwide_ptr_2 ()
> #2 0x914d9451 in _keymgr_get_and_lock_processwide_ptr ()
> #3 0x97b4ceea in _Unwind_Find_FDE ()
> #4 0x97b4a21e in _Unwind_GetIPInfo ()
> #5 0x97b4b729 in _Unwind_RaiseException ()
> #6 0x90049254 in __cxa_throw ()
> #7 0x00b1aade in decaf::net::SocketInputStream::read ()
> #8 0x00afaf89 in decaf::io::BufferedInputStream::bufferData ()
> #9 0x00afb5f1 in decaf::io::BufferedInputStream::read ()
> #10 0x00b05488 in decaf::io::DataInputStream::readInt ()
> #11 0x008e5da8 in activemq::wireformat::openwire::OpenWireFormat::unmarshal ()
> #12 0x0087b8f9 in activemq::transport::IOTransport::run ()
> #13 0x00b163be in decaf::lang::ThreadProperties::runCallback ()
> #14 0x00b142f2 in (anonymous namespace)::threadWorker ()
> #15 0x914b7155 in _pthread_start ()
> #16 0x914b7012 in thread_start ()
> (gdb)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
