"Junchang(Jason) Wang" wrote:
> We still believe this is a bug in epoll system even though we can't
> prove that so far. Both Andi and I are very interested in this problem
> and helping you experts solve this it. Just let us know if we can
> help.
I'm just another epoll user, definitely not an
Hi Eric,
Thanks again for looking at our bug report. I agree with Jason's comments: the
bug occurs independently of the socketCheck function; this function waits long
enough for the server to stop serving any more requests and then checks the
sockets to find out which ones still have data
Hi Eric,
Thanks again for looking at our bug report. I agree with Jason's comments: the
bug occurs independently of the socketCheck function; this function waits long
enough for the server to stop serving any more requests and then checks the
sockets to find out which ones still have data
Junchang(Jason) Wang junchang.w...@yale.edu wrote:
We still believe this is a bug in epoll system even though we can't
prove that so far. Both Andi and I are very interested in this problem
and helping you experts solve this it. Just let us know if we can
help.
I'm just another epoll user,
On Thu, Dec 20, 2012 at 4:32 PM, Eric Wong wrote:
> Andreas Voellmy wrote:
>> I wrote a C program that behaves similar to my original program and
>> triggers the bug. The bug only arises when I use enough cores and
>> threads (about 16). The program is here:
>>
Andreas Voellmy wrote:
> I wrote a C program that behaves similar to my original program and
> triggers the bug. The bug only arises when I use enough cores and
> threads (about 16). The program is here:
> https://github.com/AndreasVoellmy/epollbug/blob/master/epollbug.c
I finally took a closer
Andreas Voellmy andreas.voel...@yale.edu wrote:
I wrote a C program that behaves similar to my original program and
triggers the bug. The bug only arises when I use enough cores and
threads (about 16). The program is here:
https://github.com/AndreasVoellmy/epollbug/blob/master/epollbug.c
I
On Thu, Dec 20, 2012 at 4:32 PM, Eric Wong normalper...@yhbt.net wrote:
Andreas Voellmy andreas.voel...@yale.edu wrote:
I wrote a C program that behaves similar to my original program and
triggers the bug. The bug only arises when I use enough cores and
threads (about 16). The program is here:
We (i.e. I together with my colleague Jason Wang, cc'ed) installed the latest
stable kernel (3.7.1) and verified that the bug still occurs. The bug occurs
when testing the program across a network link and when testing on the loopback
interface.
We also noticed that when testing across the
We (i.e. I together with my colleague Jason Wang, cc'ed) installed the latest
stable kernel (3.7.1) and verified that the bug still occurs. The bug occurs
when testing the program across a network link and when testing on the loopback
interface.
We also noticed that when testing across the
BTW, I simplified the test program a bit: I removed the loop that epoll_waits
on the eventfd fd and reads from it (I also removed the epoll instance in that
loop). The bug still occurs with this removed. Now the bug is triggered simply
by adding the call to eventfd_write after processing each
BTW, I simplified the test program a bit: I removed the loop that epoll_waits
on the eventfd fd and reads from it (I also removed the epoll instance in that
loop). The bug still occurs with this removed. Now the bug is triggered simply
by adding the call to eventfd_write after processing each
On Dec 17, 2012, at 9:07 PM, Eric Wong wrote:
> Andreas Voellmy wrote:
>> There were a couple of errors in the code when I posted my last
>> message. I have fixed those. The epoll bug still occurs.
>
> Sorry I haven't gotten around to this.
>
> Can you reproduce this with fewer cores? (I
Andreas Voellmy wrote:
> There were a couple of errors in the code when I posted my last
> message. I have fixed those. The epoll bug still occurs.
Sorry I haven't gotten around to this.
Can you reproduce this with fewer cores? (I only have 4 at most).
Have you tried the latest stable kernel
Andreas Voellmy andreas.voel...@yale.edu wrote:
There were a couple of errors in the code when I posted my last
message. I have fixed those. The epoll bug still occurs.
Sorry I haven't gotten around to this.
Can you reproduce this with fewer cores? (I only have 4 at most).
Have you tried the
On Dec 17, 2012, at 9:07 PM, Eric Wong normalper...@yhbt.net wrote:
Andreas Voellmy andreas.voel...@yale.edu wrote:
There were a couple of errors in the code when I posted my last
message. I have fixed those. The epoll bug still occurs.
Sorry I haven't gotten around to this.
Can you
There were a couple of errors in the code when I posted my last message. I have
fixed those. The epoll bug still occurs.
-Andi
On Dec 13, 2012, at 7:16 PM, Andreas Voellmy wrote:
> I believe I have found a bug in epoll. This bug causes the behavior I
> described in earlier emails. The bug
There were a couple of errors in the code when I posted my last message. I have
fixed those. The epoll bug still occurs.
-Andi
On Dec 13, 2012, at 7:16 PM, Andreas Voellmy andreas.voel...@yale.edu wrote:
I believe I have found a bug in epoll. This bug causes the behavior I
described in
I believe I have found a bug in epoll. This bug causes the behavior I described
in earlier emails. The bug is caused by the interaction of epoll instances
which share no files in common.
I wrote a C program that behaves similar to my original program and triggers
the bug. The bug only arises
On 12/13/2012 04:32 AM, Eric Wong wrote:
> Andreas Voellmy wrote:
[trim /]
>>> Another thread, distinct from all of the threads serving particular
>>> sockets, is perfoming epoll_wait calls. When sockets are returned as
>>> being ready from an epoll_wait call, the thread signals to the
>>>
On 12/13/2012 07:08 PM, Phil Turmel wrote:
> On 12/13/2012 04:32 AM, Eric Wong wrote:
>> Andreas Voellmy wrote:
>
> [trim /]
>
Another thread, distinct from all of the threads serving particular
sockets, is perfoming epoll_wait calls. When sockets are returned as
being ready from
Hi Eric,
On Dec 13, 2012, at 4:32 AM, Eric Wong wrote:
> Andreas Voellmy wrote:
>
>>> Another thread, distinct from all of the threads serving particular
>>> sockets, is perfoming epoll_wait calls. When sockets are returned as
>>> being ready from an epoll_wait call, the thread signals to
Andreas Voellmy wrote:
> Using strace, I checked that my program is using epoll api as I
> described. Here is a fragment of the strace output that demonstrates
> my use:
>
> recvfrom(161, "GET / HTTP/1.1\r\nHost: 10.12.0.1:"..., 90, 0, NULL, NULL) = 90
> sendto(161, "HTTP/1.1 200 OK\r\nDate:
Andreas Voellmy andreas.voel...@yale.edu wrote:
Using strace, I checked that my program is using epoll api as I
described. Here is a fragment of the strace output that demonstrates
my use:
recvfrom(161, GET / HTTP/1.1\r\nHost: 10.12.0.1:..., 90, 0, NULL, NULL) = 90
sendto(161, HTTP/1.1 200
Hi Eric,
On Dec 13, 2012, at 4:32 AM, Eric Wong normalper...@yhbt.net wrote:
Andreas Voellmy andreas.voel...@yale.edu wrote:
Another thread, distinct from all of the threads serving particular
sockets, is perfoming epoll_wait calls. When sockets are returned as
being ready from an
On 12/13/2012 07:08 PM, Phil Turmel wrote:
On 12/13/2012 04:32 AM, Eric Wong wrote:
Andreas Voellmy andreas.voel...@yale.edu wrote:
[trim /]
Another thread, distinct from all of the threads serving particular
sockets, is perfoming epoll_wait calls. When sockets are returned as
being
On 12/13/2012 04:32 AM, Eric Wong wrote:
Andreas Voellmy andreas.voel...@yale.edu wrote:
[trim /]
Another thread, distinct from all of the threads serving particular
sockets, is perfoming epoll_wait calls. When sockets are returned as
being ready from an epoll_wait call, the thread signals
I believe I have found a bug in epoll. This bug causes the behavior I described
in earlier emails. The bug is caused by the interaction of epoll instances
which share no files in common.
I wrote a C program that behaves similar to my original program and triggers
the bug. The bug only arises
Hi list,
Using strace, I checked that my program is using epoll api as I described. Here
is a fragment of the strace output that demonstrates my use:
recvfrom(161, "GET / HTTP/1.1\r\nHost: 10.12.0.1:"..., 90, 0, NULL, NULL) = 90
sendto(161, "HTTP/1.1 200 OK\r\nDate: Tue, 09 O"..., 323, 0,
Hi list,
Using strace, I checked that my program is using epoll api as I described. Here
is a fragment of the strace output that demonstrates my use:
recvfrom(161, GET / HTTP/1.1\r\nHost: 10.12.0.1:..., 90, 0, NULL, NULL) = 90
sendto(161, HTTP/1.1 200 OK\r\nDate: Tue, 09 O..., 323, 0, NULL,
Hi list,
I am using epoll for the Linux (version 3.4.0) implementation of the event
notification subsystem of GHC's (Glasgow Haskell Compiler) RTS (runtime
system). I am running into a bug that has only popped up using many cores (>
16) and under particular kind of load. I've been debugging
Hi list,
I am using epoll for the Linux (version 3.4.0) implementation of the event
notification subsystem of GHC's (Glasgow Haskell Compiler) RTS (runtime
system). I am running into a bug that has only popped up using many cores (
16) and under particular kind of load. I've been debugging for
32 matches
Mail list logo
