You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Jason Schlauch <ja...@gmail.com> on 2010/01/25 23:56:41 UTC
Operation not permitted (qpid/sys/epoll/EpollPoller.cpp:254)
I'm getting the error mentioned in the subject line ("Operation not
permitted (qpid/sys/epoll/EpollPoller.cpp:254)") when my c++ client
tries to connect to the broker.
I dug into the source code and here's the relevant excerpt:
244 PollerPrivate() :
245 epollFd(::epoll_create(DefaultFds)),
246 isShutdown(false) {
247 QPID_POSIX_CHECK(epollFd);
248 ::sigemptyset(&sigMask);
249 // Add always readable fd into our set (but not listening to it yet)
250 ::epoll_event epe;
251 epe.events = 0;
252 epe.data.u64 = 0;
253 QPID_POSIX_CHECK(::epoll_ctl(epollFd, EPOLL_CTL_ADD,
alwaysReadableFd, &epe));
254 }
(I assume that the exception was actually thrown by line 253 which
might be a two line macro or something of the sort).
I think it's relevant that I *only* get an error from epoll_ctl when
my client is running as a daemon (but at this point I'm not sure why).
Is this a known issue in the qpid c++ client with respect to
integrating it into daemon code (or just a known issue period)? Any
hints on where to look for conflicts between epoll_ctl and my daemon
code ?
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Operation not permitted (qpid/sys/epoll/EpollPoller.cpp:254)
Posted by Jason Schlauch <ja...@gmail.com>.
On Mon, Jan 25, 2010 at 6:54 PM, Steve Huston <sh...@riverace.com> wrote:
>> (I assume that the exception was actually thrown by line 253
>> which might be a two line macro or something of the sort).
>
> No, I believe the line numbers should match, so you may be looking at
> source slightly different from what you're running. For now let's assume
> it's just off by a line, but you should check into this further.
You're correct on that one -- the code I was looking at was from the
qpid tarball downloaded from the Apache qpid site. The client binary
I'm using was created from the RedHat Messaging SRPM which I know has
a patch. I'll debug the issue again using the patched source.
> It's not a known problem, so please open a jira for it. Also, please be
> sure you're running the same version of the code you're reading.
I'll follow up after debugging against the RHM source.
Thanks!
Jason
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Operation not permitted (qpid/sys/epoll/EpollPoller.cpp:254)
Posted by Jason Schlauch <ja...@gmail.com>.
On Wed, Jan 27, 2010 at 12:37 PM, Steve Huston <sh...@riverace.com> wrote:
>
> Right - this seems to be the main problem to solve here. Could you
> please open a jira for it?
I worked around it by scaling back my daemon's file descriptor closing
to just stdin, stdout, and stderr. I did, however, open a JIRA for
it: QPID-2367
>> If an exception is thrown by the second QPID_POSIX_CHECK then
>> the file descriptor allocated by
>> epollFd(::epoll_create(DefaultFds)) is left dangling.
>
> Ahh, right... The destructor won't be called if the second
> QPID_POSIX_CHECK throws. Could you please also open a jira for this?
>
>> A ::close(epollFd) would be needed in the catch() block to free
>> it. There are a number of functions with a similar design in
>> EpollPoller.cpp that might be similarly affected.
>
> If you could note those in the jira, that would be appreciated.
I opened a second JIRA for this: QPID-2368
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
RE: Operation not permitted (qpid/sys/epoll/EpollPoller.cpp:254)
Posted by Steve Huston <sh...@riverace.com>.
Hi Jason,
> On Mon, Jan 25, 2010 at 6:54 PM, Steve Huston
> <sh...@riverace.com> wrote:
> > alwaysReadableFd is for a pipe - is there a chance you've closed it?
>
> I think there is. It looks like the static scope of
> alwaysReadable and alwaysReadableFd cause them to get
> initialized before main(). When my daemon class closes open
> file descriptors while fork()ing they get closed. I still
> have to figure out how to resolve the conflict.
Right - this seems to be the main problem to solve here. Could you
please open a jira for it?
> There is, however, still a bug in the code I originally cited:
>
> PollerPrivate() :
> epollFd(::epoll_create(DefaultFds)),
> isShutdown(false) {
> QPID_POSIX_CHECK(epollFd);
> ::sigemptyset(&sigMask);
> // Add always readable fd into our set (but not
> listening to it yet)
> ::epoll_event epe;
> epe.events = 0;
> epe.data.u64 = 0;
> QPID_POSIX_CHECK(::epoll_ctl(epollFd, EPOLL_CTL_ADD,
> alwaysReadableFd, &epe));
> }
>
> If an exception is thrown by the second QPID_POSIX_CHECK then
> the file descriptor allocated by
> epollFd(::epoll_create(DefaultFds)) is left dangling.
Ahh, right... The destructor won't be called if the second
QPID_POSIX_CHECK throws. Could you please also open a jira for this?
> A ::close(epollFd) would be needed in the catch() block to free
> it. There are a number of functions with a similar design in
> EpollPoller.cpp that might be similarly affected.
If you could note those in the jira, that would be appreciated.
Thanks,
-Steve
--
Steve Huston, Riverace Corporation
Total Lifecycle Support for Your Networked Applications
http://www.riverace.com
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Operation not permitted (qpid/sys/epoll/EpollPoller.cpp:254)
Posted by Jason Schlauch <ja...@gmail.com>.
On Mon, Jan 25, 2010 at 6:54 PM, Steve Huston <sh...@riverace.com> wrote:
> alwaysReadableFd is for a pipe - is there a chance you've closed it?
I think there is. It looks like the static scope of alwaysReadable
and alwaysReadableFd cause them to get initialized before main().
When my daemon class closes open file descriptors while fork()ing they
get closed. I still have to figure out how to resolve the conflict.
There is, however, still a bug in the code I originally cited:
PollerPrivate() :
epollFd(::epoll_create(DefaultFds)),
isShutdown(false) {
QPID_POSIX_CHECK(epollFd);
::sigemptyset(&sigMask);
// Add always readable fd into our set (but not listening to it yet)
::epoll_event epe;
epe.events = 0;
epe.data.u64 = 0;
QPID_POSIX_CHECK(::epoll_ctl(epollFd, EPOLL_CTL_ADD,
alwaysReadableFd, &epe));
}
If an exception is thrown by the second QPID_POSIX_CHECK then the file
descriptor allocated by epollFd(::epoll_create(DefaultFds)) is left
dangling. A ::close(epollFd) would be needed in the catch() block to
free it. There are a number of functions with a similar design in
EpollPoller.cpp that might be similarly affected.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
RE: Operation not permitted (qpid/sys/epoll/EpollPoller.cpp:254)
Posted by Steve Huston <sh...@riverace.com>.
Hi Jason,
> I'm getting the error mentioned in the subject line
> ("Operation not permitted
> (qpid/sys/epoll/EpollPoller.cpp:254)") when my c++ client
> tries to connect to the broker.
Ok; could you please report this in a jira?
(http://issues.apache.org/jira/browse/qpid)
> I dug into the source code and here's the relevant excerpt:
>
> 244 PollerPrivate() :
> 245 epollFd(::epoll_create(DefaultFds)),
> 246 isShutdown(false) {
> 247 QPID_POSIX_CHECK(epollFd);
> 248 ::sigemptyset(&sigMask);
> 249 // Add always readable fd into our set (but not
> listening to it yet)
> 250 ::epoll_event epe;
> 251 epe.events = 0;
> 252 epe.data.u64 = 0;
> 253 QPID_POSIX_CHECK(::epoll_ctl(epollFd, EPOLL_CTL_ADD,
> alwaysReadableFd, &epe));
> 254 }
>
> (I assume that the exception was actually thrown by line 253
> which might be a two line macro or something of the sort).
No, I believe the line numbers should match, so you may be looking at
source slightly different from what you're running. For now let's assume
it's just off by a line, but you should check into this further.
> I think it's relevant that I *only* get an error from
> epoll_ctl when my client is running as a daemon (but at this
> point I'm not sure why).
alwaysReadableFd is for a pipe - is there a chance you've closed it?
> Is this a known issue in the qpid c++ client with respect to
> integrating it into daemon code (or just a known issue
> period)? Any hints on where to look for conflicts between
> epoll_ctl and my daemon code ?
It's not a known problem, so please open a jira for it. Also, please be
sure you're running the same version of the code you're reading.
-Steve
--
Steve Huston, Riverace Corporation
Total Lifecycle Support for Your Networked Applications
http://www.riverace.com
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org