[
https://issues.apache.org/jira/browse/QPID-4168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13423289#comment-13423289
]
Andrew Stitcher commented on QPID-4168:
---------------------------------------
The only "graceful" way to handle detecting this problem would be to exit in
any case. So I'm not sure how actually graceful this would be!
[If alwaysReadableFd is closed then there is no way to do some of the necessary
functions of EpollPoller so we'd have to assert in the case]
> Unhandled [rare] error condition in EpollPoller.cpp
> ---------------------------------------------------
>
> Key: QPID-4168
> URL: https://issues.apache.org/jira/browse/QPID-4168
> Project: Qpid
> Issue Type: Bug
> Components: C++ Client
> Affects Versions: 0.16
> Environment: RHEL 6.2 (probably all POSIX targets)
> Reporter: Rob Springer
> Assignee: Andrew Stitcher
> Priority: Minor
>
> There was a bug in one of our programs wherein a thread could call close() on
> what was effectively a random socket.
> Occasionally, it would happen to call close() on the alwaysReadableFd
> registered in the PollerPrivate constructor, which would result in an epoll
> event for that FD to be returned in the call to epoll_wait() on line 568.
> It'd
> then try to dereference the event's "ptr" element (which was set to 0x1 on
> registration for that FD), which would lead to a segfault.
> It's worth reiterating that the triggering bug is absolutely not in Qpid, so
> this isn't a core functionality issue - it's more of a graceful handling of a
> unexpected error condition.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
